What's up with rebinding assignment?
cben at techunix.technion.ac.il
Sun Mar 23 17:24:14 CET 2003
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  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 ````. 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!
More information about the Python-list