A decorator syntax not yet mentioned (I think!)

Jeff Shannon jeff at ccvcorp.com
Fri Aug 13 01:40:28 CEST 2004


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




More information about the Python-list mailing list