A decorator syntax not yet mentioned (I think!)

[Mark Bottjer]

Jeff Shannon wrote:
> Mark Bottjer wrote:
>> FWIW, I don't object to the keyword, I object to the indented
>> block. I agree that newbies will need to look either up. My only
>> real concern is that certain suggested syntaxes (mostly the list or
>> tuple forms) look innocuous enough that newbies may not realize
>> that they've hit something new. Everything past there seems more
>> and more like simple preference.
> 
> The interesting thing here is that it seems that the reason you
> dislike the indented block is the reason given for preferring it by
> those people who *do* like it -- the fact that it *looks* like normal
> Python.

Essentially, yes. Because to me it doesn't *act* like normal Python.

> Frankly, if a new feature is so radically different from the rest of
>  Python that it's deemed that it needs to *look* radically different
> from the rest of Python for it to be understood... that, to me,
> suggests that it's a feature that shouldn't exist in Python.

Again, yes. In fact, I think that this is why the ternary operator 
finally got dropped. It just didn't fit, and the angst over trying to 
force it to made that clear.

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

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

> I see your point about it looking a bit odd that an indented block 
> contain only declarative statements.  However, the @pie mess in front
> of function defs looks, to me, to be not just odd, but downright 
> obfuscatory.  It's *much* harder for my eyes to pick out the def and
>  thus the function name, and all I see is a function body dangling
> from a blob of @pies.

Yup.

> Yes, this is personal preference, but it seems that it's a preference
>  shared by many people -- isn't Python supposed to fit my brain,
> rather than forcing my brain into Python's shape?

There seem to be many people who share a preference for each of the 
other options, as well. That's the problem: they all look horrible to 
someone. We can't seem to agree what "fits"; maybe that's a clue that 
the idea itself doesn't fit.

> The fact that one can get used to @pie-syntax doesn't mean it's
> intuitive.

This argument can be used for any of the syntaxes. "Intuitive" is in the 
eye of the beholder. In this case, what GvR's eye beholds is all that 
really matters.

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

   -- Mark