Re: A decorator syntax not yet mentioned (I think!)

From: Jeff Shannon (jeff_at_ccvcorp.com)
Date: 08/13/04 

Date: Thu, 12 Aug 2004 16:40:28 -0700

Mark Bottjer wrote:

> Jeff Shannon wrote:
>
>> All the criticisms aimed at the decorate: syntax, ISTM, apply equally
>> well to @pie syntax, except for the few that are based on indentation
>> level.
>
>
> Which are the only ones *I* was really trying to debate. :)
>
> BTW: "ISTM"?

"... it seems to me ..." :)

>> And on those, *I* at least feel that it'd be preferable to pattern
>> decorators after existing language constructs, rather than
>> deliberately breaking all the patterns that Python has established.
>
>
> Again, agreed. It seems like we both agree that the @pie syntax
> doesn't follow any extant pattern. Where we seem to differ is in our
> opinions of how well the decorate: syntax follows those same patterns.

Perhaps. (Though, before this post, I was getting the impression that
you were in favor of @pies, which would imply a different aesthetic
sense of the code as well; I'm willing to allow a bit more slack on
breaking established patterns in order to avoid the sort of eyesore that
@pie represents to me.)

>> The fact that the feature is new doesn't mean that we need an entire
>> new code-layout principle. The differences between class & def, on
>> the one hand, and try/except & if/else on the other, don't seem to
>> confuse people too much. I'd rather see the same layout principle
>> applied in a different way than see an unprecedented and unfamiliar
>> layout principle used in one or two special cases.
>
>
> FWIW, I agree. That's why I like this option the best:
>
> class C:
> def c(self):
> meta: #declare, decorate, transform, fubar, whatever...
> staticmethod
> doc('Doc.')
> pass
>
> IMHO, this form passes all the of the criteria we've been debating. The
> only criterion it fails is that it is "inside" the function, but I don't
> consider that too big an issue: once you know where to look for the
> additional information, you'll look there. Where-ever that may be.

I'd be happiest with this option, too. But it seems that GvR has
already ruled out anything other than prefix syntax, so I'm not wasting
my energy backing this. With prefix syntax as a given, I'd prefer to
have the closest we can come to this form, which is to have the meta (or
decorate, or whatever) block immediately preceding the def.

Though I must say, I don't see how putting a meta: block inside the
function is any less a violation of established patterns than having it
outside the function. You seem to be implying that you think it's fine
inside, but an abomination outside. I'm saying that this sort of block
structure is (IMO) the most pythonic way to do this, and while I'd like
it inside I don't particularly care if it's outside, and that in any
case it's far less of an abomination that @pies are. :)

Jeff Shannon
Technician/Programmer
Credit International

Relevant Pages

  • Re: Call for signatories for J2
    ... It's very possible that we might end up with @pie syntax or nothing. ... My recollection of the discussion regarding decorators (which I ... The feature might be ripped out ...
    (comp.lang.python)
  • Re: Call for signatories for J2
    ... >> listening to arguments and deciding that I could live with @pie happily ... however in the absence of a decorators in the language people are ... >> programmatically munge people's code if syntax does change. ...
    (comp.lang.python)
  • Re: Call for signatories for J2
    ... I don't have a strong opinion of whether J2 is better than @pie or vice ... > better than a metaclass approach) ... I really wouldn't worry too much about the effect on current syntax ...
    (comp.lang.python)
  • Re: decorator syntax polling suggestion
    ... and we have a wide consensus that syntax ... have invested significant mindshare in getting used to) @pie. ... When, or if, we reach a consensus, then we start to involve ... and reasons on the "decorate:" syntax? ...
    (comp.lang.python)
  • Re: A decorator syntax not yet mentioned (I think!)
    ... even though they are at the same indentation level. ... > in any way changed how the def statement itself is handled. ... >> elsewhere in Python to this syntax, I would expect the effect of the ... >> decorate statement to be limited to the statements indented under it. ...
    (comp.lang.python)