[Edu-sig] re: Naming in Python

The Bauman Family baumanpdx at comcast.net
Sat Jan 29 19:25:48 CET 2005


Kirby Urner wrote:

> As for decorators, at the moment I'm having no problems with the new 
> syntax.
> You may have seen that post on the calculus.  I was gratified to discover
> that @ may be used to hand off the function that follows to a class 
> (to some
> __init__ method), so long as what's returned is likewise a function.  
> Wait,
> is that what I did?  No, not exactly.  I fed the function to class and
> thereby get back an *object*, but this object was *callable*, and that's
> enough to make its behavior *like* a function's.  So everything worked.
> Cool.
>  
>
Although everybody already knows this, I'm sure, a function actually is 
a class, so technically it is a function if you have all the things you 
get if you dir() a function. The only weird part here is that there's an 
endless number of functions (actually methods, which are treated exactly 
the same as functions for our purposes) inside these classes, like 
__repr__, so you can do:

 >>> def afunction():
   return 0

 >>> afunction()
0
 >>> dir(afunction)
['__call__', '__class__', '__delattr__', '__dict__', '__doc__', 
'__get__', '__getattribute__', '__hash__', '__init__', '__module__', 
'__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 
'func_dict', 'func_doc', 'func_globals', 'func_name']
 >>> dir(afunction.__repr__)
['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', 
'__hash__', '__init__', '__name__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__str__']
 >>> dir(afunction.__repr__.__repr__)
['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', 
'__hash__', '__init__', '__name__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__str__']
 >>> dir(afunction.__repr__.__repr__.__repr__)
['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', 
'__hash__', '__init__', '__name__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__str__']
 >>> dir(afunction.__repr__.__repr__.__repr__.__repr__)
['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', 
'__hash__', '__init__', '__name__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__str__']
 >>> afunction.__repr__.__repr__.__repr__.__repr__()
'<method-wrapper object at 0x41152c0c>'

I wonder how Python deals with this endless chain of __repr__'s. Maybe a 
function's attributes are generated on use, in which case they /aren't/ 
really an object at all, just a data type that looks like an object and 
acts like an object. I've never looked at any code having to do with 
Python in C or C++, so I wouldn't know.

One thing that would be very useful in the next version of Python 
(regarding decorators) would be the ability to use @return or maybe 
@print (although I can't think of a use for @print); the ability to put 
statements (I think that's what they are called) as decorators.

Tim

-- 
Visit my website: (and please be a supporter of ... free
software, ... free dom, ... by giving others the url)
http://kmg.is-a-geek.org
Garunteed to be down at least 5% of the time.
stff rmed4ur bndwdth
"Do you want to reconsider your answer?" "No, I'll remain disconnected."


More information about the Edu-sig mailing list