[Python-ideas] Statement local functions and classes (aka PEP 3150 is dead, say 'Hi!' to PEP 403)
Greg Ewing
greg.ewing at canterbury.ac.nz
Thu Oct 13 23:46:36 CEST 2011
Nick Coghlan wrote:
> postdef x = weakref.ref(obj, def)
> def report_destruction(obj):
> print("{} is being destroyed".format(obj))
>
> postdef funcs = [def(i) for i in range(10)]
> def make_incrementor(i):
> postdef return def
> def incrementor(x):
> return x + i
>
> postdef sorted_list = sorted(original, key=def)
> def normalise(item):
> …
>
> That actually looks quite readable to me, and is fairly explicit about
> what it does:
Sorry, but I think it only looks that way to you because
you invented it. To me, all of these look like two
completely separate statements: some weird thing starting
with "postdef", and then a function definition.
It might be slightly better if the subsequent def were
indented and made into a suite:
postdef x = weakref.ref(obj, def):
def report_destruction(obj):
print("{} is being destroyed".format(obj))
Now it's very clear that the def is a subordinate clause.
> With this variant, I would suggest that any postdef clause be executed
> *in addition* to the normal name binding. Colliding on dummy names
> like "func" would then be like colliding on loop variables like "i" -
> typically harmless, because you don't use the names outside the
> constructs that define them anyway.
That sounds reasonable. However, if we're binding the name
anyway, why not use it in the main clause instead of introducing
something weird like a lone 'def'?
postdef x = weakref.ref(obj, report_destruction):
def report_destruction(obj):
print("{} is being destroyed".format(obj))
This makes it even more obvious what's going on. Furthermore,
there's no longer any need to restrict ourselves to a single
'def' in the body, or even any need for the defining statement
to be a 'def' -- anything that binds a name would do.
We've now arrived at something very like PEP 3150, but
without the local-namespace idea that was causing all the
difficulties.
--
Greg
More information about the Python-ideas
mailing list