What's up with rebinding assignment?

[Beni Cherniavsky]

On 2003-03-22, Alex Martelli wrote:

> I think that we're at the stage at which a PEP or two might help,
> and in fact even patches to implement lexical vs := well might.  A
> PEP should (as I see things) pick one alternative and discuss the
> others (including existing possibilities and alternate changes,
> e.g. if the PEP focused on 'lexical' it should mention := as an
> alternative and why it's rejected).

I don't have preference to any syntax here; both would work fine and
should be mentioned.  In fact I always wondered why does ``global`` go
directly to the outer-most scope instead of behaving like the proposed
``lexical``.  Now it's probably too late to change (perhaps not: a
``__future__`` import would be needed for ``lexical`` too, unless it's
made a pseudo-keyword, so there is nothing to lose).

> Having a patch would let the speedups, claimed as one important
> advantage wrt the existing possibilities, be MEASURED (always more
> convincing) rather than GUESSED AT.

I would not want it myself if it's only a speedup.  The question is
whether this is cleaner and more readable than wrapping things in a
class or using the singleton list hack.  My typical use case is to
change variables of a function from helper functions, created either
for callbacks of avoiding code duplication.

> Finding places in the standard Python library where the new
> construct would help would be a real boon, too.
>
A full scan for places that might benefit from this is a big task...
Yesterday I made a quick grep for [0] assignments, expecting to see
many occurences of the singleton list hack.  I was shocked when I
didn't find a single occurence:

The standard library (in parentheses - including the testing suite)
contains 23 (49) assignments, simple or augmented, to something ending
in ``[0]``.  Only 1 (5) of them is to a singleton list serving as a
mutable container - in ``cgitb.py`` and ``test/test_iter.py`` - but in
all these cases the list is created at definition time as a default
argument, it's never a variable of an outer scope.

So I guess it's not as needed as I felt...  OTOH, perhaps if it was
availiable, people would have different coding habits.

> As it's clearly too late for this to get into Python 2.3, the
> time available is quite long -- say 6+ months until the first
> likely glimmerings of a future Python 2.4 start appearing.
>
Of course - 2.3 has a ban on syntax changes.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>,
whose 12x CD burner works at 24x with cdrecord in linux - sheer magic!