[Python-ideas] Long Live PEP 3150 (was: Re: Statement local functions and classes (aka PEP 3150 is dead, say 'Hi!' to PEP 403))
Nick Coghlan
ncoghlan at gmail.com
Sun Oct 16 09:16:40 CEST 2011
Since I didn't get around to posting my own announcement email, I'll
just note this here:
As suggested by Eric's change to the subject line, I've now withdrawn
the short-lived PEP 403, revived PEP 3150 (statement local namespaces)
and updated it based on the feedback received in relation to PEP 403.
The current draft of PEP 3150 is available on python.org:
http://www.python.org/dev/peps/pep-3150/
On Sun, Oct 16, 2011 at 3:20 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> If the new syntax were exclusive to simple statements then that's a
> good fit. I still prefer the in-order variant for compound statements
> though (they already have their own suite). If PEP 3150 were to march
> ahead with post-order, we probably couldn't add in-order given clauses
> for compound statements later, could we? Does it matter?
Not really, because you can embed arbitrary compound statements inside
a PEP 3150 style "given" clause if you really want to. If we ever
added "given" clauses to compound statements, I'd actually suggest we
do it selectively in the respective header lines, assigning scoping
semantics that are appropriate for the affected statements.
For example:
# Embedded assignments in if statements
if match is not None given match=re.search(pattern, text):
# process match
else:
# handle case where regex is not None
# Embedded assignments in while loops
while match is not None given match=re.search(pattern, text):
# process match
else:
# handle case where regex is not None
# Shared state for functions
def accumulator(x) given tally=0:
tally += x
return x
We may also decide to eliminate the "new scope" implications for
'given' statements entirely and focus solely on the "out of order
execution" aspect. That would not only simplify the implementation,
but also make for a cleaner extension to the compound statement
headers.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list