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