[Python-ideas] Access to function objects

Jim Jewett jimjjewett at gmail.com
Sun Aug 7 20:25:55 CEST 2011


On Sun, Aug 7, 2011 at 8:10 AM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Aug 7, 2011 at 3:46 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> On Sat, Aug 6, 2011 at 11:36 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>>> Eric Snow wrote:

> Right. 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.)

They are better from a purity standpoint ... if your function is later
renamed (or stored anonymously in an array of functions), and then the
name is reused, then using the name allows silent bugs.  As a style
guide, I can certainly understand "Don't do that", but I prefer to
program libraries defensively, because that sort of bug won't show up
until the system is already pretty complex.

Using __function__ is similar to using self instead of presuming that
you know the class name, except that overridden class attributes (vs
self) are far more common (and therefore also far easier to catch when
debugging).

> There are IIRC also some use cases where an API expects a module
> object (or at least something whose attributes it can set and/or get)
> and passing the current module is clumsy:
>
>  foo(sys.modules[__name__])

And it may not work, if the installation is complex enough that there
are multiple modules with the same name.  For me, this falls in the
gray area of "Don't do that, but beware that others might."

-jJ



More information about the Python-ideas mailing list