Scope rule pecularities

[Terry Reedy]

"Josiah Carlson" <jcarlson at uci.edu> wrote in message
news:c8ge9k$7le$1 at news.service.uci.edu...
> As you mentioned later, in C, you can use *a = 1 to modify a single
> instance of 'a'.  However, immutables in Python never do the *a = 1
> assignment.  Mutables do so,

I am not sure what you mean to say that mutables 'do the *a=1 assignment'.
This does not strike me as a useful viewpoint for understanding Python.

>which is why the final line of...
>    m = n = []

At this point, m is n, not merely m == n.  Both names are bound to one and
the same object.

>    m.append(7)

At this point m is still n since mutation of the one and same object (a
list, in this case) may bind or rebind indexed *slots* within the
collection object but does not rebind either 'm', 'n', or any other name.
I don't see that the C-ism '*a=1' adds anything to this explanation.

>    m == n

Because m is n ==> m == n for anything without funny special methods that
disable the implication.

> For immutables, on modification, a new instance of the immutable is
> created, the value being set accordingly.

Since immutable objects cannot be modified, I am not sure what you are
saying.  In any case,

name = expression

always binds or rebinds name to the object calculated by expression,
regardless of the mutability of the object, if any, previously bound to
name.  Similarly, except for possible bizarre methods,

name.method(args)

never rebinds name, regardless of the mutability of the associated object.
(One possible exception: name is bound at global scope and method checks
globals to find all names bound to self and then modifies globals to rebind
all such names to something else.  But no builtin method does anything like
this.)

> Now that we've gotten to the point, __iadd__ and friends, we know we
> disagree.  If you feel terribly strongly about it, post a bug report or
> feature requrest to SF.

No, please do not burden the volunteer developers with false bug reports or
useless feature requests.  The semantics of += and family were debated when
added a few years ago and will not change for the foreseeable future.  Keep
repeated debate and explanation of such things to c.l.p.

>  I would venture a guess that within a week it
> will be closed with a message stating, "yeah, we like it the way it is".

Or it might hang around a couple of years while people focus on real
problems.


About dictionaries: keys must be hashable (have __hash__ method);
mutability is not directly involved (and there is indeed no direct test for
such).  It would have been possible to key dictionaries by object id, and
one can do so for user classes with def __hash__(s): return id(s).  But for
fairly obvious reasons, builtins are hashed and keyed by value.  Perhaps
less obviously, this can be true even across types.

>>> d={0:'zero'}
>>> d[0.0]
'zero'
>>> d[0+0j]
'zero'
>>> d[''] = 'empty'
>>> d[u'']
'empty'

Terry J. Reedy