[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