[Python-ideas] How can I get own instance of generator in itself code

[Nick Coghlan]

On Tue, Jul 24, 2012 at 10:59 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Mon, Jul 16, 2012 at 10:28 AM, Eric Snow <ericsnowcurrently at 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 at gmail.com   |   Brisbane, Australia