Greg Ewing <greg at cosc.canterbury.ac.nz> writes:
> Michael Hudson <mwh at python.net>:
>
>> In particular what happens if the iteration variable is a local in the
>> frame anyway? I presume that would inhibit the renaming
>
> Why?
Well, because then you have the same name for two different bindings.
>> but then code like
>>
>> def f(x):
>> r = [x+1 for x in range(x)]
>> return r, x
>>
>> becomes even more incomprehensible (and changes in behaviour).
>
> Anyone who writes code like that *deserves* to have the
> behaviour changed on them!
This was not my impression of the Python way. I know I'd be pretty
pissed if this broke my app.
I have no objection to breaking the above code, just to breaking it
silently! Having code *silently change in behaviour* (not die with an
expection, post a warning at compile time or fail to compile at all)
is about an evil a change as it's possible to contemplate, IMO.
> If this is really a worry, an alternative would be to
> simply forbid using a name for the loop variable that's
> used for anything else outside the loop. That could
> break existing code too, but at least it would break
> it in a very obvious way by making it fail to compile.
This would be infinitely preferable!
Cheers,
mwh
--
I like silliness in a MP skit, but not in my APIs. :-)
-- Guido van Rossum, python-dev
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4