Scope rule pecularities

[Antoon Pardon]

Op 2004-05-13, Josiah Carlson schreef <jcarlson at uci.edu>:
> >>The real thing to remember is that Python isn't <insert the language 
> >>you expect Python to behave like>,
> >
> > I think it is reasonable to expect a language to behave consistently.
> >
> > I would like to be able the understand what += does to
> > an object without the need of knowing it is mutable or
> > not.
>
> Well then, that is easy, += does whatever the object says it should do. 
>    The only builtin type that is actually modified in place (via +=) are 
> lists.  Everything else uses single name rebinding.  Is that a simple 
> enough rule, because had you done /any/ sort of critical investigation, 
> you would have discovered it yourself.  Your investigation would have 
> turned up that immutables behave as they should, and a list's __iadd__ 
> method is an alias for its extend method.

Well I think that if you need such a critical investigation, something
is wrong. I could just as well write a vector and matrix module that
uses "-" for addition and if people then complain tell them that they
should have done a critical investigation, then they would have found
out that the "-" works as it should.

>
> >>>I now expect a and c still to be the same object.
> >>
> >>If 'a' is mutable, and 'a' has the proper __iadd__ operator, then 'a'
> >>and 'c' will be the same object when you are done.  However, integers,
> >>strings, floats,... are immutable, so 'a' and 'c' won't be the same
> >>object in those cases (Python only rebinds objects that are specified,
> >>due to the whole "explicit is better than implicit" Zen).
> >
> > Python does more than enought things in an implicit way.
>
> And automatically rebinding /every/ name that references an object is 
> more explicit?  I don't think so.

I didn't say that. I just want to point out that python does enough
things implicitly so that the "explicit is better than implicit"
argument is invalid.

> If all you can say is, "I don't like it, it should be more consistant", 
> then I ask, "what would be more consistant?"  Should we keep a list of 
> every name that references an object so that functionally, everything is 
> passed by reference and can be modified at will?  Should we force 
> everything to be mutable, only interning (and making immutable) objects 
> used as keys in a dictionary?  Honestly, I don't believe either option 
> is a good idea.  Let us look at an example and find out why.

IMO python being the language that it is with immutable objects, the
only consistant solution would have been to just translate a += b
into something equivalent to a = a + b and leave it at that.
No __ixxx__ methods, no inplace modifications.

> Hmmm, dictionaries.  Dictionaries are hash tables that contain a key and 
> value pair.  In order to handle dynamic expansion of the hash table, we 
> must keep the key (Python keeps a pointer to the key, it is much faster 
> that way).

I doubt it is much faster overall. The faster dictionary expansion
is at the expense of having to turn your mutable objects you
want to use as a key into an immutable equivallent.

> Right now, only immutables are able to be keys.  Why is this 
> so?  Let us imagine that we use a mutable string as a key in a 
> dictionary.  Everything is fine and dandy, until we modify the string. 
> At that point, in order for the dictionary to stay consistant, we must 
> make a copy of that string to keep it as a key.  No big deal, right? 
> Wrong.  What if that string were 500k?  500M?  It becomes a big deal.

It already is a big deal. Because you can't mutate strings, that means
that every time you need a minor change to one a lot of copying will
go on instead of inplace modifications.

Each time you need to do something like name = name[:-3] + newsuffix
you make a copy, with strings that are 500k or 500M that is just
as big an issue.

So either you work with mutable values and then you need to copy
them into an immutable before they can be used as a key or you
work with immutables and then all manipulations you do on them
will involve copying. So Python uses immutables as key because
that is faster, is irrelevant to me because it is just a deviation
of the cost, not a reduction within the whole program.

And besides you can have muttable objects within immutables.

> Similarly, rebinding all names that point to an immutable, when that 
> immutable is modified via += is a fool's errand, /especially/ when we 
> can use l = 1000000*[0].  According to the rebinding method, all million 
> pointers would need to be rebound to the new object, which would be the 
> same as making an integer mutable, which has the problem described in 
> the previous paragraph.

It would only be a problem with a specific kind of implementation.

> I think you'll find Python's handling of all immutable values to 
> coincide with how C handles single integers (except for the 
> pass-by-reference in function calls).

Except that if we compare with C, then Python doesn't use integers
but pointers to integers with automatic referencing. And if in
C I do *a += 1, then all pointers to that integer will see the
new value and it wouldn't take a million rebindings in case
of an array/list with a million elements.

> >>and your expectations are not what
> >>actually happens.  What you think /should/ happen is not what /does/
> >>happen, and I am quite sure it is not what /Guido thinks should happen/.
> >
> > So? Is what Guido thinks should happen above criticism. I think
> > that if what Guido thinks should happen makes the language
> > behave inconsistenly then
>
> No, Guido is not above criticism.  The mistakes he believes he has made 
> will be fixed in the 3.0 release.  If you can't wait for it, then 
> perhaps you should write the interpreter/compiler for the language you 
> want to use.  It seems to be in vogue these days.

I sometimes dream about that, but I fear I don't have the time
nor the motivation to finish such a project properly. I'll
just make a choice among the languages that are available.
In general I like python, the warts sometimes frustrate me,
but I see that as a token of affection, e.g. I don't care
about the warts of C++, because I find it so ugly and
complicated I avoid using it. So I'll wait what 3.0
has is store and see what I like about it.

-- 
Antoon Pardon