Alternative decorator syntax decision

[Colin J. Williams]

J2 C1 C1

Colin W.

Paul McGuire wrote:
[snip]

 

[Arthur]

C1 C1 C1

If we are allowed to make negative votes:

-J2 -J2 -J2

I personally find J2 worse than the current pie
syntax. Something that looks odd and does something
odd seems the lesser evil vs something that looks
normal yet does something odd.

A1 A1 A1

On a similar line of thinking - if we do indeed need some syntax. And
the vote seems to assume we do, or at least accepts Anthony as
speaking with some authority (I hope he hasn't overstepped) by
declaring that not having some syntax in 2.4 is not an option.

And finding @before def is in-your-face odd.

Nobody would confuse it with real Python

Art

 

[threeseas]

I don't think so. C1 was the clear community favorite for months and
still has many supporters. And putting the decorator at the top of the
function had many supporters in the poll last week.



J2 is winning because it was actively discussed right here on this
newsgroup this past week. When I did a poll last week, E1 had just been
actively discussed and it gained a lot of support. Next week who knows
what will be the current flavor?

a definable syntax is the solution direction, even if only as a stepping
stone to letting the "standard" simply come about the old fashon way...
popular use.

This newsgroup is far to python user limited, and I'd imagine the
mailing list is not much better, and IRC....

what is the estimate user/coder count regarding python? (perhaps what
would be more accurate would be coding hours over user/coder count)
where any changes or new things should keep the sum low.

Python promotes ease of use in regards to power/functionality level.

shrug...

not that I really care, but perhaps its a bit more objective.

 

[Anthony Baxter]

Another six months won't make much difference. The transform
functionality is there now. PEP 318 formalizes things.

Except that with 12-18 months between releases, that's actually a lot longer.

Look, the decision that decorators are going to be in 2.4 was made some
time ago. I've seen absolutely nothing to indicate that this is even faintly
likely to change.

 

[Daniel Arbuckle]

My votes (J1, J2, C1)

 

[Jeffrey Froman]

I'll vote for D2 D2 and just to open-minded, J2

Jeffrey

 

[richard]

FWIW

J2 J2 J2


Richard

 

[Denis S. Otkidach]

C2 C2 C1

 

[Jess Austin]

hi,

I vote:

J2, J2, J2

and thus the split-vote mechanism is completely defeated. I don't
think you can enforce 2nd-choice voting on a newsgroup. I find suite
expansion to be far more pythonic than anything else we've come up
with.

Just to be clear, the following is J2:

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

while this is E4, which I think has some traits that Guido has already
vetoed in http://mail.python.org/pipermail/python-dev/2004-August/047279.html:

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
[snip]

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

I like "decorate" much better than "transform", because "transform"
encompasses more than the specific concept of decoration. If there is
a concern that decoration is a larger concept than what is proposed in
PEP 318, then I would consider some other, more specific verb.

Verb it must be, though, as opposed to something adverbial or
prepositional or even gerundy. It seems to have been made quite clear
that decoration is a separate action from definition. If we use a
word that isn't another transitive verb, that word will attach itself
to "def" and the syntax will obscur the semantics.

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

Solutions that are already or obviously will be rejected by Guido
contribute to noise levels. b-)

 

[Jess Austin]

There would be two kinds of decorators. Those that are simply
informative (like __author__ or __version__), and those that have
side-effects (like __metaclass__, __synchronized__, __automethods__,
etc.). Those with side-effects would be implemented as special functions...

def synchronized(func, trueOrFalse):
__decorator__ = True
__author__ = 'Billy Batson'
__version__ = '0.1'
#
# perform the synchronized operation on func...
#

How would the parser know the difference between informative function
variables like "__author__" and your special side-affecting function
variables?

I-like-J2-ly,
Jess

 

[Paul Morrow]

How would the parser know the difference between informative function
variables like "__author__" and your special side-affecting function
variables?

In this proposal, the "side-effecting" functions would all be decorated
with "__decorator__ = True". So the interpreter would tell the
difference that way: for any given attribute __xxx__, if no function
exists with the name xxx and which also defined __decorator__ = True,
then xxx would be considered informational only.

Whether or not this idea has merit, it is too different than what is
seriously being considered to have a chance of being adopted. However
there is a compromise that is much more consistent with the current
decorator proposals yet doesn't require any new syntax.

The idea is that we mirror the __metaclass_ syntax, and introduce a new
magic variable __features__ which takes as its value a tuple of
decorators...

def foo():
""" This is a docstring. """
__features__ = synchronized, returns(None)
# function body goes here

The decorators would be located/resolved/applied as in the popular
proposals.

 

[Corey Coughlin]

J2 J2 H

Although in the H category I prefer the spaced option. The vertical
line as an arrow is a little more appealing that a smudgy decoration.

 

[Robin Becker]

I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major

......

except that these wrappers/transformers/decorators are able to do what they like
to the code including turning methods into properties, changing the argument
list etc etc etc.

All the pain of self modifying code will be available as it already is, but
with a new funky syntax to make it seem OK.

I also don't like the def coming last, but if the thing isn't what you think it
is the "here be dragons" is probably a good idea.

 

[Avner Ben]

I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."

My vote: C2, E4, J2

Avner.

 

[Colin J. Williams]

I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."

My vote: C2, E4, J2

Avner.

Your expectation list makes sense to me. There is merit in having the
docstring before the 'decorator', i.e. E4

Colin W.

 

[Colin J. Williams]

I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."

My vote: C2, E4, J2

Avner.

Your expectation list makes sense to me. There is merit in having the
docstring before the 'decorator', i.e. E4

Colin W.

 

[Colin J. Williams]

I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."

My vote: C2, E4, J2

Avner.

Your expectation list makes sense to me. There is merit in having the
docstring before the 'decorator', i.e. E4

Colin W.

 

[Colin J. Williams]

Apologies! One response was more than enough.

Your expectation list makes sense to me. There is merit in having the
docstring before the 'decorator', i.e. E4

Colin W.

 

[Godefroid Chapelle]

Hi all,

It might be too late to send a vote...

I'd understand this easily.

So do not take the time to tell me I am too late ;-)


C2 C2 C2


Godefroid Chapelle aka __gotcha

 

[Avner Ben]

>[snip]
except that these wrappers/transformers/decorators are able to do what
they like to the code including turning methods into properties,
changing the argument list etc etc etc.

Which is ok with me, as long as they only stress and specialize the
status of the function (how) but do not completely alter the
requirement (as understood from the name and arguments). Once this is
not only allowed, but actively supported by the language, reading
Python will become as easy and obvious as reading COBOL.

Avner.