Collections of non-arbitrary objects ?

[walterbyrd]

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?

 

[Larry Bates]

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?

Code the record as an object (class) and place instances of those objects inside
a list or dictionary (depending on access required). Or if you don't want to do
much with the records just put each instance of a record (normally a record is
implemented as a tuple at least thats how SQL databases return rows) inside a
list or a dictionary (again depending on access required).

-Larry

 

[bruno.desthuilliers]

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries.

And sets.

But what if I want a collection
of non-arbitrary objects?

Then only put the kind of objects you want in the collection.

A list of records, or something like that

'Records' can be implemented as tuples, dicts or using a custom class.

 

[Ben Finney]

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a
collection of non-arbitrary objects? A list of records, or something
like that?

Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the question. What
are you asking for that you don't already have? A list can contain a
sequence of objects of the same type already. What are you expecting
that a list does not provide?

 

[Grant Edwards]

Lists never contain arbitrary objects, they contain only
objects that you put there. The reason that other languages
have typed containers (e.g. array of type T) is that the
elements of the array don't know what type they are, so you've
got to limit what you put in there. In python, all objects
know what type they are, so there's no point in labelling the
references to the objects with type info as well.

Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the
question. What are you asking for that you don't already have?
A list can contain a sequence of objects of the same type
already. What are you expecting that a list does not provide?

I was also a bit baffled by the question. The only things I
could think of are:

1) a "container" that raised an exception if the type of a new
item doesn't match the type of what's in it already. I
don't really see much benefit in that. If you want a list
to contain only objects of type T, then only put that type
of objects in it.

2) an "array" that contains a large number of small things
(e.g. integer or floating point numbers) that need to be
stored with minimal overhead. That's a useful thing, and
there are several packages that do that -- numpy is the one
generally recommended for new designs.

 

[walterbyrd]

That's a flippant response, but I don't understand the question.

Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.

 

[Ben Finney]

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

 

[Gabriel Genellina]

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Sure. You can implement it yourself, if you want; it's not so hard even
for a beginner. It's just not needed enough, or required enough, to become
a builtin type.
Look for some recent posts about a RestrictedList.

 

[Paddy]

Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.

Hi Walterbyrd,
What happens when you are given good advice that may be contrary to
intuition?

Unfortunately its how we usually do things in Python and do NOT
suffer because of it. Try writing your application without it. Test
without it. Write other applications without it. Others do,
successfully.

- Paddy.

 

[walterbyrd]

Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.

 

[7stud]

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

if hasattr(elmt, some_func):
elmt.some_func()

 

[Marc 'BlackJack' Rintsch]

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

It raises an exception. What want you an "typed list" to do when a wrong
object is put into it? Raising an exception? So all you change is the
point in time when the exception is raised.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.

But this doesn't really change with a "typed list". It's easy to take
an object and completely replace all its attributes so it behaves very
different.

Ciao,
Marc 'BlackJack' Rintsch

 

[Paddy]

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.

Reminds me a bit of that (awful) sketch:
Patient: Doctor doctor it hurts if I do that.
Doctor: Well don't do that then.

The data for the list should have been checked when it entered
your program. It is up to you to then only stuff the list with
data expected by the routine. If you don't then Python will most
likely throw a runtime exception, but it is up to you to trust
your co-workers on the project.

- Paddy

 

[Bjoern Schliessmann]

if hasattr(elmt, some_func):
elmt.some_func()

Personally, I prefer

try:
elmt.some_func()
except AttributeError:
# do stuff

Regards,


Björn

 

[Ben Finney]

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list
that doesn't conform to the type could give you unexpected results,
maybe crash your application.

A routine that demands its inputs to be of a certain *type*, rather
than requiring that the implement the required *behaviour*, breaks
polymorphism.

Polymorphism is considered valuable in Python; search for any of
"polymorphism", "duck typing" and "easier to ask forgiveness than
permission".

 

[Bruno Desthuilliers]

walterbyrd a écrit :

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type.

it should expects every item to support a given protocol (expose a given
interface, have a given set of attributes, whatever...).

OOP is not about "types" or "classes", it's about objects. And in a
dynamic language like Python, where you can add/remove/replace almost
each attribute (including methods and even it's class...) of an object
at runtime, override the way the attribute look-up is done, etc, this is
specially true.

The fact that an object is an instance of a given class doesn't
necessarily imply that it supports the same protocol. And the fact that
an object is an instance of a given class is only true at a given
time... So testing on type to allow inclusion of an object in a list for
"type safety" reasons is mostly a waste of time. It's also
counter-productive since it would reject objects that actually supports
the right protocol but are not of the "correct type".

Something in the list that
doesn't conform to the type

s/conform to the type/support the protocol/

could give you unexpected results, maybe
crash your application.

Yes. But... you do test your application, don't you ?-)

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list

No. cf above.

- or any such
structure. To me, that seems like a potentially vulnerability.

Did you actually had some effective problem with this ?

Especially since variables in python do not have to be explicitly
assigned

???

I suppose you meant something else here, probably about declarative typing ?

- another variable that points to the same thing, could
change the data that a variable points to.

Give me a reference to an object in a list, and I can change almost any
attribute of the object - even it's class.

FWIW, a similar - but usually much much worse wrt/ possible results -
problem exists in C with pointers and memory.

I came to Python from statically typed languages, and first had a
similar reaction. It took me some time to believe it, but type errors
are quite less frequent that you would imagine, and most of the time
quite trivial to spot and fix. I've had bigger problems with memory
handling and dangling pointers in C, Pascal or C++.

 

[walterbyrd]

???

I have probably expressed this incorrectly. What I meant was:

a = [1,2,3]
b = a
a[1] = 'spam'

Here, I have changed b, without an explicit assignment. After I
assigned a to b, I never did another "b =" yet b changed anyway
because I changed a. I am not saying there is anything wrong with
this, I'm just explaining what I meant.

So let's say I have list L, and I have a routine that expects every
item in L to be a dictionary like: {'name':'joe', 'job':'dev', 'pay':
min_wage}.

Not only could the app crash if an incorrect item where inserted into
L. But the app could crash if an incorrect item were inserted in lists
X,Y, or Z.

Of course, you can always work around this by just programming very
carefully, and doing a lot of error checking. That is always true in
any language.

But, I think sometimes it's helpful to use a structure that is little
more restrictive, to sort of enforce a degree of integrity. An example
I have already given: why use tuples instead of a list? Tuples are
actually a bit more restrictive.

I don't think there is anything wrong with the data structures that
exist in python. I was just wondering if there was a structure that
would restrict a collection to only allow certain types. The
"restrictedlist" class discussed in another thread may be the sort of
thing I was looking for.

BTW: I think polymorphism is great and all. But it does have (and IMO
should have) it's limitations. For example, I don't think you can
divide a string by another string.

 

[Eduardo \EdCrypt\ O. Padoan]

I don't think there is anything wrong with the data structures that

exist in python. I was just wondering if there was a structure that
would restrict a collection to only allow certain types. The
"restrictedlist" class discussed in another thread may be the sort of
thing I was looking for.

Just remenber that if you write a library using such a thing, your
(consenting adults) users will not be able to store objects in your
list that implement (part of) the interface of the type that you
restricted.

 

[Neil Cerutti]

BTW: I think polymorphism is great and all. But it does have
(and IMO should have) it's limitations. For example, I don't
think you can divide a string by another string.

It might be a pointless new spelling for the .split method.

x = 'Smith, Ted, 15 Smedly Rd."
last, first, street = x / ', '

Tongue-in-cheekily-yours,

 

[Marius Gedminas]

Personally, I prefer

try:
elmt.some_func()
except AttributeError:
# do stuff

That also hides attribute errors that occur within some_func. I think
I'd rather know when elmt has an implementation of some_func that is
buggy. Thus I prefer the hasattr version.