[Python-ideas] Before and after the colon in funciton defs.

[Nick Coghlan]

On Fri, Sep 23, 2011 at 3:44 PM, Carl Matthew Johnson
<cmjohnson.mailinglist at gmail.com> wrote:
> I feel like I have the same complaint that other people did earlier in the thread: I understand that locals don't work like that *now*. (And they understood that decorators can't do an inject *now*.) When I said "locals" I was using a shorthand, because I don't know all the correct terminology. What I'm proposing is a change to how the system works. I want the byte code for functions to be created differently after this change.  Obviously, that can't be done by the function objects, but it will need to be done beforehand. There's probably much more to this sort of change than I realize--maybe even so much that it wouldn't be worth it to do it, since the benefit would be relatively small. If so, that's fine. But objecting that this isn't how it really works feels like it's missing the point to me. The more relevant objection is that it would be too huge of a project to make it work a different way.

That's exactly my point though - the default argument use cases to be
addressed are *trivial*. A trivial problem requires a comparably
trivial answer - there is *nothing* in the use cases being discussed
that even comes close to justifying substantial changes to the way the
language works. Changing the way locals works, allowing variable
injection, those are huge, language changing ideas, that require
powerful, compelling use cases to motivate them. As far as I am aware,
those use cases don't exist (and if they do, they certainly haven't
been raised in this thread).

It would be really helpful if people could comment on ideas that have
at least some chance of making it under that "simple enough to be
worth doing" bar. Obviously, I consider adjusting 'nonlocal' so we can
use it to store cell references on the function being defined to be
one such idea, as it is essentially just blending PEP 3104 with the
underlying implementation of PEP 3135's magic '__class__' reference in
methods.

As far as I can tell, the biggest potential practical problem with it
is on the compiler side, where the AST nodes for the initialisation
expressions would need to be lifted out for inclusion in the code
generated in the surrounding scope. That's not impossible (we already
do something similar in deciding whether a def statement is defining
an ordinary function or a generator), but the state to be collected is
a fair bit more complicated than anything the symbol analysis pass
currently handles.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia