On Tue, Jul 24, 2012 at 10:59 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Mon, Jul 16, 2012 at 10:28 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Yeah, this is still valuable. However, at this point it would be a 3.4 addition (_if_ it gets committed). Updating the patch in the tracker is on my todo for the next few months.
FWIW, the possibility of exposing something like __function__ in the function locals is less likely to garner support than the initial f_func approach. Said Guido[1]:
<quote> If it were expected that people would start writing recursive calls using __function__ routinely, in situations where a name reference works, I'd be very unhappy with the new feature. (And if someone wants to make the argument that recursive calls using __function__ are actually better in some way I am willing to filibuster.) </quote>
So there's a metric that f_func passes much more readily. That said, the f_func patch would also make "__function__" easier to implement if that feature passed muster.
Python 3 already has an implicit lexical __class__ reference (courtesy of PEP 3135) and it refers to the inner *undecorated* version of the class. References by name, on the other hand, refer to the postdecorated version bound in the outer scope (which may or may not be the same object, depending on the specific decorators). A PEP for 3.4 that proposes a mechanism that more cleanly incorporates __class__ into the language data model (thus addressing http://bugs.python.org/issue12370) would be most welcome. Such a PEP could also attempt to make a symmetry argument for a __def__ reference that refers directly to the undecorated function object (as it's a lexical reference, it's worth emphasising the keyword over the kind of object). An implicit reference to the *decorated* object would not be acceptable, as decorators need to be able to call the function, even if it relies on the implicit reference. (This is the same reason why __class__ refers to the undecorated version: so that the class definition is complete while the decorator is running, which means they can instantiate it and call methods that use the new shorthand style super() invocation) The module self reference aspect discussed in PEP 3130 should just be dropped as using "mod = importlib.import_module(__name__)" is enough to avoid the odd behaviour associated with trying to use "__import__" directly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia