walterbyrd a écrit :
On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelque ch...@free.quel quepart.frwrote :
>>>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_obje ct' 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).
