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

From: Mark Bottjer (mark_bottjer_at_hotmail.com)
Date: 08/13/04


Date: Thu, 12 Aug 2004 19:16:22 -0400

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



Relevant Pages

  • Re: Whats the best python web-developers editor
    ... It gives nice syntax ... highlighting, indentation and you can run your script with it too. ... > development - for both discrete and mixed python and html code, ...
    (comp.lang.python)
  • Re: Python syntax in Lisp and Scheme
    ... > I think everyone who used Python will agree that its syntax is ... Python does not a have very good ... > add Pythonistic syntax to Lisp or Scheme, ... which says if an expression is unmatched switch off indentation. ...
    (comp.lang.lisp)
  • Re: Why dont people like lisp?
    ... > Python was a while ago and I did not even get to some of that syntax. ... Lisp *really* has lots of parentheses, ... Lisp syntax needs more "ragged" indentation than average syntaxes. ...
    (comp.lang.lisp)
  • Re: Python syntax in Lisp and Scheme
    ... syntax rules out nesting statements inside expressions (without adding ... Python syntax) and you might run into similar difficulties if adding ... Lisp than to add macro capabilities to Python. ... If the indentation thing appeals, ...
    (comp.lang.lisp)
  • Re: Unification of Methods and Functions
    ... >would have the greatest concentration of unbound method use (my reasoning was ... staticmethod syntax is relatively new, and there is a long tradition ... in Python of using various alternatives to static methods. ...
    (comp.lang.python)