[Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

[Boris Borcic]

Josiah Carlson wrote:
> Boris Borcic <bborcic at gmail.com> wrote:
>> Hello,
>>
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
>>>> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
>>>> doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles
>>>> the following code incorrectly:
>>> No, no, it's an underground move by Jeremy to allow assignment to
>>> variables of enclosing scopes:
>> ...
>>> Credits to Samuele's evil side for the ideas.  His non-evil side doesn't
>>> agree, and neither does mine, of course :-)
>> ...
>>> More seriously, a function with a variable that is only written to as
>>> the target of augmented assignments cannot possibly be something else
>>> than a newcomer's mistake: the augmented assignments will always raise
>>> UnboundLocalError.
>> I am not really a newcomer to python. But lately I find myself regularly bitten
>> by this compiler behavior that I tend to view as a (design) bug. This started
>> happening after I saw that sets are just as good as lists performance-wise and I
>> began changing code like this
> 
> I see your attempted use of a closure as a design bug in your code.

<aside> original_post.replace('(design)','(design?)') </aside>

It was no "attempted" use but working code (incorporating a closure) that was 
being transformed to profit from simplifications I expected sets to allow. 
There, itemwise augmented assigments in loops very naturally transform to 
wholesale augmented assignments without loops. Except for this wart.

> Remember that while closures can be quite convenient, there are other
> methods to do precisely the same thing without needing to use nested
> scopes.

Of course there are other methods. I pointed out one relatively straightforward 
workaround that Python offered me in its usually friendly manner. You seem to 
say that I should have considered wholesale restructuration of my code using 
classes as a more appropriate workaround. Hum.

What's unnerving is to be stopped in the course of applying a straightforward 
simplification to working code, by a compiler (!) objection in favor of an 
interpretation that *has no use-cases*.

NB : That the compiler's interpretation has no use-cases is my crucial point, 
it's the reason why I dared suggest a design bug - as you seem to take at heart.

Are you telling me closures have no use cases ? Of course not. Are you telling 
me closures have use cases to which mine don't belong ? Please point me to the 
part of documentation where I should have learned that will of the Gods.

 >  I find that it would be far easier (for the developers of
> Python)

Could you be more specific ? This thread started with Thomas Wouter announcing 
he assigned a bug because pre-beta 2.5 unwittingly behaved as I would prefer. 
This implies that said behavior can't be _far_ more difficult to implement, right ?

Or is what you mean that python developers feel especially bad about the typical 
confusion of newcomers when the automatic scoping rules of python fail to 
provide the most helpful error messages ?

So that I shouldn't complain about, well, error dynamics getting special-cased 
for augmented assignments, to feature python with an error message that's 
perfectly to the point... for an audience that the developers of python intend 
to capture by her serendipitous misuse of augmented assignment, right ? An 
audience to which me and my use-cases don't belong, and therefore, should be 
designed out of existence ?

Judging from the rest of your intervention, I guess that's it. Well, I think the 
principle of it at least deserves debate. First, please face/state the explicit 
notion that while you speak of the "designers of python", what's the object of 
design here is actually not python itself at all but "how python should be 
learned by spontaneous (trials and) errors". (Proof: or else you have no 
use-cases worthy of the name).

Once you admit the matter belongs to the business of designing a, well, 
spontaneous human learning process; rather than the business of designing a 
programming language for actual use-cases, then maybe we could have a 
constructive discussion between adults.

(To anticipate on it, I must confess a deeply felt aversion for whatever starts 
resembling a constraining curriculum of errors to make and then rectify. Or else 
I would be programming in Java).

> and significantly more readable if it were implemented as a
> class.

I'll deny that flatly since first of all the issue isn't limited to closures. It 
would apply just as well if it involved globals and top-level functions.

> 
> class solve:
>     def __init__(self, problem):
>         self.freebits = ...
>     ...
>     def search(self, data):
>         ...
>         self.freebits ^= swaps
>         ...
>     ...
> 
> Not everything needs to (or should) be a closure

Right. Let's thus consider

freebits = ...

def search(data) :
     ...
     freebits ^= swaps

Boris
--
"On naît tous les mètres du même monde"