Alternative decorator syntax decision

N

Nicolas Fleury

Hi all,

The part of the Python community that doesn't like @decorators needs to
unite behind an alternative syntax to propose to Guido. I suggest we
use this thread to try to do it. If you agree with @decorators, then I
suggest you stop reading this message;)

Many syntaxes have been put on http://www.python.org/moin/PythonDecorators.

I suggest to fight the current @descriptors on these two points:
- Less Readable. The @ character adds a new character with a magical
sense. It doesn't read in english as the rest of Python.
- Not Pythonic. It's a line without a block (like try/finally) that
affects a following line of code. It breaks interactive shells.

I suggest that the alternative syntax is both more readable and more
pythonic. Many syntaxes have been ruled out by Guido, but he seems to
be open to a new keyword accessible with a "from __future__ import".
Since a new keyword would make the syntax more readable (and easier to
find doc about), so I suggest to discuss these two alternatives, not
necessarily with these keywords:

Proposal 1:

decorate: staticmethod
def foo(a, b):
...

decorate:
accepts(int,int)
returns(float)
def bar(low, high):
...

other possible keywords: predef, from, as, with

This proposal has basically the advantages of @decorators with a more
Pythonic approach. The main drawback is that the decorate block doesn't
contain anything like normal statements, as with @decorators.
Implementation already exists.


Proposal 2:

def foo(a,b):
using staticmethod
...

def bar(low, high):
using accepts(int, int)
using returns(float)

other possible keywords: decorate, transform, with, postdef, as

The pool on Wiki suggest that most people would prefer an inside def
syntax. It would place decorators at the same place as docstrings,
which is very Pythonic, since it's consistent with the rest of the
language. The main concern is that it places information that can be
important to callers far from the def. I guess the answer would be that
it's not that far from the def and that sometimes the parameters names
would give strong hints about the decorators. For example, even if it's
not forced by the language, a method with a first parameter not named
self would be strong hint to check the first line of the body to see if
it's a static method, etc. I suggest to force descriptors to be before
the docstring to make them as closer as possible to the def and ease
finding them. (Another answer could be that scanning down from the def
is not that more bad than scanning up from the def).
Is there any implementation existing?

My questions would be: which of these proposals do you prefer to current
@decorators. Both? None?

What keywords would you prefer? Do you see any that I have not listed?

Do you think there's an alternative that I should have listed, even
considering what have been ruled out by Guido?

Regards,

Nicolas
 
A

Anthony Baxter

- Not Pythonic. It's a line without a block (like try/finally) that
affects a following line of code. It breaks interactive shells.

I've seen this mentioned a couple of times, but as far as I can see,
it's really not true:
.... return func
.... .... def _deco(func, kwdict=kwdict):
.... for k,v in kwdict.items():
.... setattr(func,k,v)
.... return func
.... return _deco
.... .... @funcattr(foo=1,bar='bozo',bing=['b','o','n','g'])
.... def testfunc(whatever):
.... pass
.... ['b', 'o', 'n', 'g']

[ snip - decorate block before def ]
This proposal has basically the advantages of @decorators with a more
Pythonic approach. The main drawback is that the decorate block doesn't
contain anything like normal statements, as with @decorators.
Implementation already exists.

Note that the implementation, as far as I know, is not yet complete - it
doesn't include the from __future__ stuff. I don't know much about that
area of the implementation, so can't offer an opinion on how hard that
is.

The implementation also doesn't seem to have been submitted as a
patch to SF. This needs to be done.
Proposal 2:

def foo(a,b):
using staticmethod

This form (decorators inside the block) has been pretty convincingly
ruled out by Guido. I think the "last man standing" is the decorator-before-def
form, I really doubt you're going to convince people that the form inside the
function is workable.
 
N

Nicolas Fleury

Anthony said:
I've seen this mentioned a couple of times, but as far as I can see,
it's really not true:

I just copied from Wiki honestly.
This form (decorators inside the block) has been pretty convincingly
ruled out by Guido. I think the "last man standing" is the decorator-before-def
form, I really doubt you're going to convince people that the form inside the
function is workable.

I sadly discovered after my post it has been ruled out. I agree the
"last man standing" is the decorator-before-def form. In fact, we
should make a thread about only this proposal.

Regards,
Nicolas
 
A

Anthony Baxter

We can safely ignore Guido's "rejections" when deciding upon an
alternative to agree upon. Many people felt his rejections of C1 (a
longtime community favorite), E1 and other alternatives were wrong.
http://mail.python.org/pipermail/python-dev/2004-August/048134.html

Uh, what? No, you _can't_ ignore Guido's rejections - if you really decide
that you must have a form he's objected to, you need a _damn_ strong
argument to back that up. A "longtime community favorite" doesn't mean
a thing - this is language design, not American Idol - that a lot of people
like it makes no difference.
 
D

Doug Holton

Anthony said:
Uh, what? No, you _can't_ ignore Guido's rejections - if you really decide
that you must have a form he's objected to, you need a _damn_ strong
argument to back that up. A "longtime community favorite" doesn't mean
a thing - this is language design, not American Idol - that a lot of people
like it makes no difference.

Um, yes. The point is to determine what the *community* decides on, and
*then* present that to Guido. You're just helpping confound this second
vote even more. Some people aren't voting for what they think is best,
but what they think Guido hasn't "rejected". That is ridiculous.
You'll end up with a syntax that nobody really ever liked most, even Guido.
 
J

Jeff Shannon

Doug said:
Um, yes. The point is to determine what the *community* decides on,
and *then* present that to Guido. You're just helpping confound this
second vote even more. Some people aren't voting for what they think
is best, but what they think Guido hasn't "rejected". That is
ridiculous. You'll end up with a syntax that nobody really ever liked
most, even Guido.


On the other hand, if the community decides that the only thing they
prefer to @pie is something that Guido's already rejected... then we get
@pie.

I can vote for Superman for president all I want, and I can talk all my
friends into voting for him, but even if a majority of the country votes
for Superman, he's still not gonna be taking any inaugural oath.
Instead of voting for an impossible fantasy, it's much more sensible to
restrict myself to voting for people/options with *some* chance of success.

Keep in mind here, that what we're trying to do is vote for something
for which we think we can create a convincing case that it's better than
@pie. And Guido is the only person for whom "convincing" is relevant.
If he's already rejected something, it will be *extremely* difficult to
convince him that his rejection was a mistake. I'd rather focus my
efforts where they're a little more likely to bear fruit.

Jeff Shannon
Technician/Programmer
Credit International
 
G

Gyro Funch

Jeff said:
On the other hand, if the community decides that the only thing they
prefer to @pie is something that Guido's already rejected... then we get
@pie.
I can vote for Superman for president all I want, and I can talk all my
friends into voting for him, but even if a majority of the country votes
for Superman, he's still not gonna be taking any inaugural oath.
Instead of voting for an impossible fantasy, it's much more sensible to
restrict myself to voting for people/options with *some* chance of success.

Keep in mind here, that what we're trying to do is vote for something
for which we think we can create a convincing case that it's better than
@pie. And Guido is the only person for whom "convincing" is relevant.
If he's already rejected something, it will be *extremely* difficult to
convince him that his rejection was a mistake. I'd rather focus my
efforts where they're a little more likely to bear fruit.

Jeff Shannon
Technician/Programmer
Credit International

From python-dev
>>If the community can *agree* on
>
>>
>> Even if it's []-after-args?


If most people favor that over prefix @deco, sure, I'll give it
another look. (It better come with an implementation though.)

--Guido van Rossum (home page: http://www.python.org/~guido/)
 
A

Anthony Baxter

Um, yes. The point is to determine what the *community* decides on, and
*then* present that to Guido. You're just helpping confound this second
vote even more. Some people aren't voting for what they think is best,
but what they think Guido hasn't "rejected". That is ridiculous.
You'll end up with a syntax that nobody really ever liked most, even Guido.

You're misinterpreting what I said - I said that "if you want a form
he's rejected,
you need _damn_ strong arguments to back it up". I was replying to someone
saying that it's not necessary to pay attention to Guido's rejections of various
forms, and pointing out that in fact you _do_ need to pay attention to them. If
there's a community concensus for an already-rejected form, but no-one has
bothered addressing the existing concerns, then it's something of a waste of
time.

I'm not _trying_ to "confound the vote". I'm trying to *help* the
process. If that's
not considered useful, I'm quite happy to just step away from the entire issue.
 
A

Anthony Baxter

If the community can *agree* on
something they can support, I will listen.
Even if it's []-after-args?
[Guido]:
If most people favor that over prefix @deco, sure, I'll give it
another look. (It better come with an implementation though.)

Note - "another look". "Lots of people like this form", with no technical
justifications for it, will probably result in it being a very short look <wink>
 
A

Andrew Durdin

You're misinterpreting what I said - I said that "if you want a form
he's rejected,
you need _damn_ strong arguments to back it up". I was replying to someone
saying that it's not necessary to pay attention to Guido's rejections of various
forms, and pointing out that in fact you _do_ need to pay attention to them. If
there's a community concensus for an already-rejected form, but no-one has
bothered addressing the existing concerns, then it's something of a waste of
time.

I'm not trying to inflame this discussion, but that doesn't appear to
tally with Guido's comments -- when discussing a community consensus
regarding list-after-def, he asked if there was a consensus that his
concerns with that syntax were incorrect, which suggests that he'd
reconsider his concerns (though that may not change them).
Additionally, two people (myself one) addressed his concerns
point-by-point on python-dev, and Guido didn't respond, except to say
that he doesn't want a hundred people arguing point-by point.
From all this and his other comments, I gather that Guido wants a
community consensus on one syntax (with an implementation); he'll look
at it (even if he previously rejected it), and the current
@-decorators, and make a final decision on which will be kept
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top