Rather than decorators, how about sections?

[Stefan Eischet]

Hi.

On 11.08.2004, at 20:55, Christophe Cavalaria wrote:

> Paul Morrow wrote:
>
>>> class Foo(object):
>>>     def spam(Foo):
>>>         print "Class Method"
>
> What is that ? It's ugly, it's a name alias and it'll be incredibly
> confusing when classmethods are inherited, which is exactly the most 
> common
> use case for classmethods.

Right, I don't even like it myself, but I still like it better than the 
pie for daily work.
How about using "class" as a first parameter? Even uglier, I fear.

You cut the good part of my post, I think ;-)

>> I like it!  It's simple, clear, ... Why isn't this the hands-down best
>> solution? Why do we want to be more verbose than necessary?
>
> It isn't a solution. It only "resolves" the problem for staticmethod 
> and
> classmethod which are only a very small part of what we do/want to do 
> with
> decorators.

And IMHO this is a part you should keep your ugly pies out of, because 
they're suggesting that something special is going on, though it's just 
a static method you're defining.


I was only referring to static methods and class methods, and since I 
don't see no use in decorators for my daily work (which does NOT mean 
they won't help many people!), I won't argue about other uses.

<putting on bulletproof vest>
If you really think it's necessary to have special syntax for caching 
return values, for checking parameter types etc, you're welcome, even 
if I personally doubt the usefullness of that stuff - you can still 
cache results *in your method*, for example. Or will we decorate our 
methods so much that they all resolve to a single "pass" instruction in 
the body? Some pie decorator examples look like the function body, 
stacked on top of the def line. *That* is ugly. ;-)
</>

For common stuff like static methods, I do still think decorators are 
overkill and the wrong way to go.

>> I wonder if there are people out there who've chosen something other
>> than *self* for the 1st arg (shame on them if they did! <grin>) who's
>> code this would break.  I've never understood why we didn't require 
>> that
>> it be called self in the first place --- why give them more than one 
>> way
>> to do *that*?
>
> Well, it might seem strange but :
> - It will break a lot of code which use a name different than self for 
> the
> first argument

Right. Starting with the usual Python tutorials and lots of books, I 
trained myself not to use other first args than self for normal methods 
*as they all suggest*. Perhaps self should've been a keyword from the 
start?

> - It'll break all existing classmethods

I didn't say "get rid of the old way of doing def m(x); 
m=classmethod(m);", so I don't think it would break any existing 
classmethod. When @decorators are in 2.4, will classmethod() and 
staticmethod() be removed at the same time? That would also break each 
and every legacy classmethod, wouldn't it?

> - It'll break code that binds arbitrary functions as a member 
> function. You
> can't do things like that anymore :
>
>>>> def f(s):
>>>>     print "Hi, I'm function f"
>>>> class Klass:
>>>>     doIt = f
>>>> Klass().doIt()

Okay, this might break, depending on how all this gets implemented. I 
wasn't even aware that this worked, perhaps because I'm usually 
restricting myself to a *very* obvious subset of Python. (My general 
rule is: I might be hit by a bus tomorrow, so a poor Java programmer 
might need to learn to read my code very quickly. I try to never write 
stuff that breaks this rule.)

How would you solve this problem with decorators, btw?
class Klass:
     @stuff
     doIt = f
?

If there was a rule that assigned functions in the class body (doIt=f) 
default to normal methods whatever their first arg is called, would 
that be okay? After all, that is how it works right now.

   Stefan

// stefan at eischet.com //