Decorator syntax

[Reinhold Birkenfeld]

Paul McGuire wrote:

Please reconsider the "def f() [classmethod]:" construct. Instead of
invoking a special punctuation character, it uses context and placement,
with familiar old []'s, to infuse the declaration of a function with special
characteristics. If this causes def lines to run longer than one line,
perhaps the same rule that allows an unmatched "(" to carry over multiple
lines without requiring "\" continuation markers could be used for unmatched
"["s, as in:

def f() [ staticmethod,
synchronized,
alphabetized,
supersized,
returns('d') ]:


"If I'd wanted mucilage, I'dve ordered mucilage." - Humphrey Bogart, "All
Through the Night"
If I'd wanted to write in Java, I'dve written in Java.

Keep Python Beautiful.

Full ACK!

But I fear that without a formal "voting" Python will go the pragmatic
way - that is, keep @ as it's already implemented.

So what would be the most effective way to notify the developers that
(I'm guessing) 90% of the Python community dislike the @ syntax and want
an other?

Reinhold

 

[Anthony Baxter]

But I fear that without a formal "voting" Python will go the pragmatic
way - that is, keep @ as it's already implemented.

Sorry - but would "formal voting" be a good way to design a language?
Based on various languages that have gone through a committee type
process, I'd have to say "god no".

So what would be the most effective way to notify the developers that
(I'm guessing) 90% of the Python community dislike the @ syntax and want
an other?

As I've said (repeatedly) - this isn't a popularity contest. The point is to
produce the best technical result. If you have a better solution, put together
a case for it, and convince Guido.

I'd also question how you can be so sure that "90% of the community
dislike it" -
over on python-dev, there's been quite a number of people who've actually
tried the syntax, and found it to be quite good. This includes me -
when I first saw it, I recoiled, but after using it, I find it pretty good.
Please, please - download a2. Try the decorator syntax out (or look at
test_decorators, or the hopefully-finished-with-the-rewrite-soon PEP318
(which I'll also post here) for examples.

Anthony

 

[paolo veronelli]

As I've said (repeatedly) - this isn't a popularity contest. The point
is to
produce the best technical result. If you have a better solution, put
together
a case for it, and convince Guido

wrong list for this

Please, please - download a2. Try the decorator syntax out (or look at
test_decorators, or the hopefully-finished-with-the-rewrite-soon PEP318
(which I'll also post here) for examples.

There is no need to use a new syntax to appriciate it,it's only a syntax
we can read it.

Anthony

If it has been simple to estabilish the use of the docstring (which I
don't use waiting (in vain ?) for a literate python) now
this story of decorators has nothing to do with a decoration of the
language.It's like we must learn a new way of reading our
favourite way of coding,and some of us don't understand why we must do
it,as this feature is not for making new things.
All in all:if it's only a new way of writing things they can already be
written,it's very normal every typer/reader want to express
his/her preference,mainly because wants to use it.
Every language has a sensual side,Python (and Ruby eheh) beats them all
and this battle shows the pride of loving it.

Paolino

 

[Hallvard B Furuseth]

How about

def foo(a, b, c):
foo.accepts = (int, int, list)
foo.author = 'Chris King'

That already has a different meaning: Function foo sets those attributes
on itself each time it is called. They should be set once, before the
function is called.

$ python2.3.... foo.accepts = (int, int, list)
.... foo.author = 'Chris King'
.... Traceback (most recent call last):
'Chris King'