Collections of non-arbitrary objects ?

[Bruno Desthuilliers]

walterbyrd a écrit :
> On Jun 24, 10:31 pm, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
> 
> 
>>>Especially since variables in python do not have to be explicitly
>>>assigned
>>
>>???
> 
> 
> 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.

You haven't changed b, you have changed the object bound to name 'b'. 
Which happens to be also bound to name 'a'.

> After I
> assigned a to b,

Well, I guess the term "assignment" is misleading you then. "binding" 
would be more accurate - you bound names 'a' and 'b' to the same object. 
Then, whether you access this object via name 'a' or name 'b', you're 
still accessing the same object.

> I never did another "b =" yet b changed anyway

Doing 'b = some_other_object' would still not 'change b' - you don't 
change a name - but rebind name 'b' to another object.

You perhaps don't know this, but most statically typed languages have 
the notion of either pointers or references, that can cause similar - 
and usually worse - problems.

> 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.

Yes - assuming names L, X, Y and Z are bound to the same list.

And it would also crash if one the dicts was modified between the moment 
it is added to the list and the moment you pass the list to your 
function. Which makes "typed" lists totally useless anyway. And even if 
you use a smarter 'correctness' test (like a callback function checking 
that every item added or inserted supports keying and has the correct 
keys), it would still be useless since you could still manage to modify 
one of the items of the list *after* it has been added to it.

> Of course, you can always work around this by just  programming very
> carefully,

You do program carefully, don't you ?-)

> and doing a lot of error checking.

That's usually not even necessary - most of the time (ie: almost 
always), you'll have a nice traceback in the minutes following the 
moment you introduced the error.

> That is always true in
> any language.

Nope. In Python, you seldom have to do error *checking* - the language 
do it for you (that's what exceptions are for). What you have to do is 
1/ testing, and 2/ error *handling*.

Now did you actually had any effective problem with Python's dynamism ? 
Or are you just scared ?

You know, Python is now something like 17 years old, and is used by a 
*lot* of peoples for a *lot* of programs - some of them far from 
trivial. I think you can be confident in this experience. IOW, just 
write your code, and you'll find out that the kind of problems you seem 
to fear so much will not happens that often.

> But, I think sometimes it's helpful to use a structure that is little
> more restrictive, to sort of enforce a degree of integrity.

Sometimes you do have to check the validity of the data you are supposed 
to work on, true - mostly when it comes to program inputs (be it wia 
files, sockets, forms, environment, whatever). Once this is done, you 
shouldn't have to worry too much - just let Python crash when there's 
something wrong, carefully read the traceback, and correct the offending 
code (which is very likely in the last modifications you made).

> An example
> I have already given: why use tuples instead of a list? Tuples are
> actually a bit more restrictive.

You don't use tuples "instead of" lists. Lists are collections, tuples 
are structured data.

> 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.

Not builtin. You can roll your own if it makes you happy, but that would 
  be a waste of time - been here, done that, you see...

> The
> "restrictedlist" class discussed in another thread may be the sort of
> thing I was looking for.

So please take time to read the whole thread.

> BTW: I think polymorphism is great and all. But it does have (and IMO
> should have) it's limitations.

Yes, indeed - if an object doesn't understand a message, then you have 
an exception. But since the only way to know if an object can handle a 
message is to send the message (please refer to my previous post), 
enforcing 'type'-based (with 'type'=='class') restriction in Python is 
not only useless, it's also harmful. IOW, stop fighting against the 
language - just use it.

> For example, I don't think you can
> divide a string by another string.

No, because this operation is not implemented for strings - IOW, strings 
doesn't understand this message. What would be the meaning of dividing 
strings anyway ? (while concatening string is a well-known operation).