[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