Decorators: an outsider's perspective

[Paul Morrow]

Anthony Baxter wrote:
> On Mon, 16 Aug 2004 06:20:18 -0400, Paul Morrow <pm_mon at yahoo.com> wrote:
> 
>>>Python currently doesn't _care_ about the argument list, and the variable
>>>names in it.
>>>
>>
>>One thought is, to preserve backwards compatability, this special
>>behavior would only be invoked for subclasses of the new Object class.
> 
> 
> How is this backwards compatible? If you'd introduced it at the same time
> as object, _maybe_ you could argue that. But this isn't the case here.
> 
> 

It's backwards compatible in the sense that existing code doesn't break, 
as it isn't derived from the new Object class (capital 'O') that 
enforces the conventions.

>>>Adding this sort of behaviour is nasty. How, for instance, would you handle
>>>adding a method to a class at runtime? Do you poke into the newly added
>>>method to make sure you get it right? Do you not do this?
>>
>>Same rules apply.  The Python system would dynamically determine the
>>method's type when you add it (at runtime), so you'd need to make sure
>>that the first parm name is correct in advance.
> 
> 
> Really. And how would you implement this special casing in a way that
> wasn't incredibly tricky to explain to users running across it? 

I'm not quite sure what you mean here.  It would be easy to document the 
difference between static, class, and instance methods, and how to 
declare each.  "To declare an instance method, use 'self' as the first 
param", etc...


> One of the
> great things about Python is that if you need to, or you want to, you can
> poke into the innards of the OO system and see how it works (particularly
> since descriptors were added). This adds Perl-like levels of OO-hackery.
> If that comment is unclear, I mean that when you poke into Perl's OO,
> it becomes very clear, very quickly, that it's a hack.
> 

I don't see what you're talking about here either.  You'd still be able 
to see the innards.  Poke away.  The methods will look as though you had 
explicitly declared them.


>>>What about for more complex decorators? Remember, staticmethod and
>>>classmethod are the trivial cases that this feature addresses. How do you
>>>handle the more complex ones?
>>
>>The point is that method type declarations are not needed, so decorators
>>wouldn't be concerned with this.  Take them off the list of things
>>decorators can do.
> 
> 
> Huh? You proposed a hack to specify class and static methods, using a 
> custom meta-class that pokes at the argument list of a function, and 
> suddenly you've removed the need for decorators for this? 

Well, Yes.  That's right (although the metaclass I wrote isn't finished 
by any means, nor am I even sure that we can do everything from a 
metaclass).  Why have another way to do it?  So that we can appease the 
static typing folks?  We don't like unnecessary static typing, remember?


> Please - feel 
> free to use your metaclass in your own code, but  don't think that this is 
> in any way a solution that should be considered for "mainstream" python 
> use. It's a hack - a neat hack and a nice example of some of the things
> metaclasses can do[1], but it's not a valid "solution" for the problem that
> decorators are meant to solve. Look, staticmethod and classmethod are
> a tiny tiny fraction of the things that decorator will be used for. Looking 
> at a large amount of Python code I've got here, I can see three examples
> of classmethods (all alternate constructors) and no uses of staticmethod
> at all.
> 
> Anthony
> 
> ([1] and, I should note, one I was about to post until I saw your post <wink>)

Well good, then you shouldn't mind if we restrict decorators to those 
things that you do have lots of examples of. :-)

Q: What if I had a metaclass that would make any method private whose 
name started with two underbars (by, I dunno, mangling the name 
somehow)?  Would you consider that a hack too? ;-)