[Python-Dev] Object customization (was: Arbitrary attributes on funcs and methods)

[Gordon McMillan]

Vladimir Marangozov wrote:

> Gordon McMillan wrote:
> > 
> > I don't see anything here but an argument that allowing 
> > attributes on function objects makes them vaguely similar to 
> > instance objects. To the extent that I can agree with that, I fail 
> > to see any harm in it.
> > 
> 
> To the extent it encourages confusion, I think it sucks.
> 
> >>> def this():
> ...     sucks = "no"
> ...
> >>> this.sucks = "yes"
> >>>
> >>> print this.sucks
> 'yes'
> 
> Why on earth 'sucks' is not the object defined in the function's namespace?

Because that one is a local. Python allows the same name in 
different places. Used wisely, it's a handy feature of 
namespaces.

> Who made that deliberate decision? 

What decision? To put a name "sucks" both in the function's 
locals and as a function attribute? To print something 
accessed with object.attribute notation in the obvious manner? 
Deciding not to cause gratuitous UnboundLocalErrors?

This is nowhere near as confusing as, say, putting a module 
named X in a package named X and then saying "from X 
import *", (hi, Marc-Andre!).

> Clearly 'this' defines a new namespace,
> so it'll be also legitimate to get a NameError, or to:
> 
> >>> print this.sucks
> 'no'
> 
> Don't you think?

Only if you've done "this.sucks = 'no'". Or are you saying that 
if functions have attributes, people will all of a sudden expect 
that function locals will have initialized and maintained state?

We certainly get plenty of newbie confusion about 
namespaces, assignment and scoping; maybe I've seen one 
or two where people thought function.local should be legal (do 
Python-tutors see this?). In those cases, is it the existence of 
function.__doc__ that causes the confusion? If yes, and this 
is a serious problem, then you should be arguing for the 
removal of __doc__. If not, why would allowing adding more 
attributes exacerbate the problem?
 
> And don't explain to me that this is because there's a code object,
> different from the function object, which is compiled at the function's
> definition, then assotiated with the function object, blah, blah, blah...

No problem. 

[Actually, the best argument against this I can see is that 
functional-types already try to use function objects where any 
sane person knows you should use an instance; and since 
this doesn't further their agenda, the bastard's will just scream 
louder <wink>].

- Gordon