[Python-Dev] Re: Call for defense of @decorators

Tim Peters tim.peters at gmail.com
Fri Aug 6 18:06:49 CEST 2004


[Barry Warsaw]
> So I spent a little time futzing with python-mode and some of my
> decorator code, to try some alternative leading characters.  Of the ones
> that cannot be used in valid Python code today (i.e. no backward
> compatibility issues), I tried ':', '/', '=', '*', and '|'.
> 
> : wasn't bad, and it had some nice symmetry with the function definition
> that follows.  But those two little dots can be hard to read in some
> fonts ...

Indeed!  I read that paragraph four times before I realized it started
with a colon -- a fleck of dirt on the screen obscured it completely.

> / and | also weren't bad, although bar is probably preferred.

Ya, but then we preclude adding the unary-pipe operator.  This is very
important for numeric types that need to implement half the absolute
value:

>>> |3
1.5
>>> |-3
1.5

...
> Someone else pointing out that the bar kind of looks like it's anchoring the
> decorator to the function, and I got a similar sense of that.

OK, seriously, me too.

> ...
> In summary, I can definitely sympathize with the concern of tool authors
> who have settled on @ as a meta-character that Python will not use.

Yup.

> I wonder how the Leo or ipython folks would feel if the only change to the
> current implementation of PEP 318 was to change the decorator
> introducing character.  If we can increase the community's consensus by
> making this little change, I wouldn't oppose it.

Me neither.

> My preference then would be to use = with | and : as alternatives, in
> that order.

Same here, except -1 on the colon.  Although = would preclude
introducing the unary-equals operator, which is very important for
numeric types that need to implement the absolute value rotated by 90
degrees.


More information about the Python-Dev mailing list