Rather than decorators, how about sections?

[Christophe Cavalaria]

Stefan Eischet wrote:

> 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.

How about cls ?

> 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.

It's true that decorators are a somewhat weird mean to define classmethods
and staticmethods. But like I said, it's not the only use case for
decorators. You can't just say : Here's a new syntax for decorators. Oh, by
the way, it only works for staticmethod and classmethod but who uses the
other decorators anyway ?

>> - 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?

No since @decorate is only a shortcut for the old syntax which was deemed
unclear and at the wrong position :)

Anyway, I don't think it's possible to implement that in the grammar, and
even if it's possible, it'll be really tricky to handle both the old and
the new syntax for classmethods at the same time. There will be some
serious compiler magic going on then.

>> - 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
> ?

Decorators don't solve that problem. I was just pointing at a current use
case that would probably break with that new proposal for classmethods.

> 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.

And there's even better :

class Klass:
    pass
Klass.doIt = f

That one works too :)

>    Stefan
> 
> // stefan at eischet.com //