[Python-ideas] PEP 3150 (statement local namespaces) updated based on April discussion

geremy condra debatem1 at gmail.com
Mon Jun 13 18:59:55 CEST 2011


On Sun, Jun 12, 2011 at 2:20 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 6/12/2011 11:44 AM, Nick Coghlan wrote:
>>
>> The rationale and proposed semantics sections of PEP 3150 have been
>> heavily modified based on the various discussions on the topic back in
>> April.
>>
>> http://www.python.org/dev/peps/pep-3150/
>>
>> (Note that the PEP is still officially Deferred - this entire idea
>> still intrigues me, but I'm also still not convinced it's worth the
>> additional language complexity).
>
> I tried to read this with an open mind, but I still strongly dislike it. I
> think it would make Python harder to learn and read and would lead to more
> confusion and questions on python-list.
>
> I think having a different rule for function compilation makes the proposal
> even worse, as people would come to expect early binding (outside the given
> context) even more than now. If one does not like default args, one can
> either use class instances or closures. The latter were explicitly
> introduced as an alternative to using default args. Do we really need a
> fourth solution to the same problem?
>
> I do not see comprehensions, which are *expressions*, as a precedent for
> out-of-order *statements*. Nested expressions are not left-to-right either,
> nor are assignments: "a[3] = b*f(c+d)".
>
> 'Given' or 'where' constructs are sometimes used in mathematical writings,
> especially formula exposition, but they typically, if not always, are
> isolated (like the examples in the PEP), and not part of a code sequence. So
> this is notreally a precedent to me. Example:
>
>  fv = p * (1 + i/12)**t... , where
>    fv = present value
>    p  = principle
>    i  = nominal annual interest rate
>    t  = time in months
>
> -(1+whatever)

I've historically been in favor of this kind of proposal specifically
because I'd like to be able to write the above code, but I have to
admit that many of the examples given in the PEP terrify me. The point
of exposition like this is to enhance readability by making the flow
of information (defined by the equation on the first line) extremely
clear; tucking functions and classes with their own flow into the
out-of-order block just makes it really hard to figure out what's
happening where and when.

Geremy Condra



More information about the Python-ideas mailing list