Alternative decorator syntax decision

[Paul McGuire]

There are a number of messages on the python-dev mail list that indicate
that Guido is looking for some concensus to come from this list as to what
*one* alternative syntax for decorators we would like him to consider in
place of the @ syntax that is currently in 2.4a2.

I think special thanks are due to:
- Anthony Baxter for his continuing efforts in this regard
- Steven Bethard for some of the clearest thinking and writing on this topic
- Michael Sparks for actually implementing one of the options

We've all done our share of pitching and whining, but we need to settle on
*one* option for Guido to consider.

(And let's not get wrapped up complaining about the "process" being followed
in this whole thing, personally I think it is quite poor. But let's play
with the cards we've been dealt, and at least make a collective proposal.)

The significant alternatives have been listed on the Python wiki at
http://www.python.org/moin/PythonDecorators .

Interested parties should also look at the comments in the python-dev
archive for the past month, at
http://mail.python.org/pipermail/pyt...st/thread.html .

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.

I am not going to argue that this is scientific in any respect, but it
*should* allow the major 1 or 2 choices to bubble to the top. I have used
this process at work many times in the past when it was necessary for a
large group to set priorities among a large list of choices.

My vote is: J2 J2 C1

By the way, once an option has been chosen, it *still* needs an
implementation for Guido to accept it. This puts some of the options way
ahead of the others, in my mind.

(And let's hope we get at least as good a response as the "average age"
thread!)

-- Paul

[Thomas Reichelt]

Paul McGuire wrote:

My vote is: J2 J2 C1

My vote is: J2 J2 C2

--
greetz tom

[Istvan Albert]

David Fraser wrote:

Thats because the point of this vote is to try and gather a consensus
about what the best alternative is,
But what if the alternative is that you don't need a best
alternative? There lies the crux of the problem.
not to try and out-vote the original contender.

If you cannot out-vote the original contender than what
is the whole point of the poll? Why would this proposal be
accepted if it cannot outclass the original one?

Voting is an extremely tricky business. Arrow's theorem
proves that there is not voting scheme that could provide
a proper selection whenever there are more than two candidates
(in the two candidate case the scheme is simple majority).

Yet there are better and there are worse ways to reduce
the field to two candidates. What this poll attempts to do
(going only after the second place) is incorrect. It is bad
not just from the inherent unreliability of internet
polling but from design perspective.

Istvan.

[Istvan Albert]

Paolino wrote:

d2 d2 j2

Thanks for the piece of democracy

or more likely the 'illusion' of it.

[Ville Vainio]

>>>>> "Paul" == Paul McGuire <pt***@austin.rr._bogus_.com> writes:

Paul> I'm afraid I have to agree, the subject is a poor one. I
Paul> noticed that yesterday as the responses were slow to come
Paul> in. Something more on the order of "READ THIS - IT'S
Paul> FREAKIN' IMPORTANT!" is surely warranted.

Yup - for those just joining in, post somewhere in this thread, it
involves voting that all pythonistas know & love (along with the
associated grain of salt that goes with it here in
pythonland). Instructions in the root message.

--
Ville Vainio http://tinyurl.com/2prnb

[Paul McGuire]

"Ville Vainio" <vi***@spammers.com> wrote in message
news:du****************@lehtori.cc.tut.fi...

>> "Paul" == Paul McGuire <pt***@austin.rr._bogus_.com> writes:

Paul> I'm afraid I have to agree, the subject is a poor one. I
Paul> noticed that yesterday as the responses were slow to come
Paul> in. Something more on the order of "READ THIS - IT'S
Paul> FREAKIN' IMPORTANT!" is surely warranted.

Yup - for those just joining in, post somewhere in this thread, it
involves voting that all pythonistas know & love (along with the
associated grain of salt that goes with it here in
pythonland). Instructions in the root message.

--
Ville Vainio http://tinyurl.com/2prnb

Will you vote now? :)

[Ville Vainio]

H H J2
Yes, I like

| decorate2
| decorate1(42, "hello")
def f(x):
return x+1

And I don't mind the pie syntax either anymore.

--
Ville Vainio http://tinyurl.com/2prnb

[Ville Vainio]

>>>>> "Paul" == Paul McGuire <pt***@austin.rr._bogus_.com> writes:

Yup - for those just joining in, post somewhere in this thread, it
involves voting that all pythonistas know & love (along with the
associated grain of salt that goes with it here in
pythonland). Instructions in the root message.

Paul> Will you vote now? :)

Did already, on the thread w/o subject line change (I wasn't sure
whether your script/whatever would handle changing the subject line).

--
Ville Vainio http://tinyurl.com/2prnb

[Peter Maas]

D2, D2, D2

With dotted decorators above docstring

[Peter Hansen]

Istvan Albert wrote:

David Fraser wrote:

Thats because the point of this vote is to try and gather a consensus
about what the best alternative is,

But what if the alternative is that you don't need a best
alternative? There lies the crux of the problem.

No, deciding if an alternative should be chosen is step two
at this point.

> not to try and out-vote the original contender.

If you cannot out-vote the original contender than what
is the whole point of the poll? Why would this proposal be
accepted if it cannot outclass the original one?

It will *not* be accepted on the basis of whether or not
it can "outclass" (I assume you mean get more votes than)
the original one. As has been pointed out repeatedly,
this is not a democracy, and outvoting the @pie syntax
would do nothing.

The point is that we were asked *specifically* for a
community consensus on an alternative, if there should
be an alternative. This vote is to help form that consensus,
not to decide *if* there should be an alternative.

You might even say that the decision as to whether there
should be an alternative cannot be made until the outcome
of the vote is known. If no alternative gets overwhelming
support, then we are in the same situation as the old ternary
operator debate.

You were around for that, weren't you? The community could
not agree on *which alternative to doing nothing* was best,
so in the end nothing happened.

The parallel with the present debate is that if the community
cannot rally around any alternative as being better than
all the other non-@pie alternatives, then "nothing will happen"
and in this case that means @pie wins out and goes in 2.4.

-Peter

[Paolino]

Istvan Albert wrote:

Paolino wrote:

d2 d2 j2

Thanks for the piece of democracy

or more likely the 'illusion' of it.

IMO democracy stands in the will of helping people partecipate.Illusion
of democracy relays on (among the rest) convincing not to do it.....
Entropy leads us somewhere where we could easy define democracy in a
pragmatic way.If python is not a well defined politically correct
system,its users can still laugh about that while they ride the entropic
wave.

Paolino

[Doug Holton]

> Exactly. From this standpoint, the list on the wiki should be filtered

to something that
1) doesn't have the declaration in the body of the function
2) doesn't have the declaration following the parameters

1) rules out D1 D2 E1 E2
2) rules out C1 C2 C3 C4 E3
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.
With the voting going the way it currently is J2 is winning anyway,

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?

[Doug Holton]

Paul McGuire wrote:

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.
My vote is: J2 J2 C1

I've heard of different voting methods like ranking your top choices,
but I've never heard of this one. It appears that if someone is open
minded about more than one option, their opinion counts *less* that
someone who is doggedly determined about one particular syntax. They
get three votes while you get one. That doesn't seem fair or the best
way to determine a community favorite.

[Ville Vainio]

>>>>> "Doug" == Doug Holton <in****@spam.here> writes:

Doug> I've heard of different voting methods like ranking your top
Doug> choices, but I've never heard of this one. It appears that
Doug> if someone is open minded about more than one option, their
Doug> opinion counts *less* that someone who is doggedly
Doug> determined about one particular syntax. They get three
Doug> votes while you get one. That doesn't seem fair or the best
Doug> way to determine a community favorite.

I think it's less about finding a community favourite than just
picking out one or two alternative approaches for Guido's
consideration. The idea is to reduce the number of syntaxes to shoot
down :-).

--
Ville Vainio http://tinyurl.com/2prnb

[John Marshall]

J2 J2 C1

Thanks,
John

[Nick Jacobson]

> I'd like to change my vote to J2 J2 J2.

-Peter

I also vote J2 J2 J2.

--Nick

[Arien Malec]

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in
news:wX*****************@fe1.texas.rr.com:

"Arien Malec" <ar*********@yahoo.com.REMOVE> wrote in message
news:Xn********************************@64.164.98. 7...

M, any keyword option using "transform"

(I care more about semantics than syntax)

I can interpret "any keyword option using "transform"" to match J1,
J2, or L.

C2, J2

But my metavote is: make the sematics really clear.

Arien

[Dan Christensen]

J2 J2 J2

[Gary Herron]

My vote:
J2 J2 and J2
because it puts everything in the correct position (meaning in the
same position as the pie syntax), but still *LOOKS* like python.

Keyword could remain "decorate", but I'd be fid just about anything
acceptable.

Gary Herron

[Gary Herron]

On Friday 20 August 2004 09:35 am, Gary Herron wrote:

My vote:
J2 J2 and J2
because it puts everything in the correct position (meaning in the
same position as the pie syntax), but still *LOOKS* like python.

Keyword could remain "decorate", but I'd be fid just about anything
acceptable.
Yuck -- I usually proof read better than that. Should be "I'd find
just about anything acceptable"
Gary Herron

[daishi]

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.

Also, it seems the options in J have very little
to do with each other. E.g., I would actually
support J1.

[Aahz]

Vote: C1 C1 C1
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --*****@lion.austin.ibm.com

[Thomas Heller]

go****@daishi.fastmail.fm (daishi) writes:

C1 C1 C1
Hm, I like the pie syntx, so

A1 A1 A1

(is A2 really different from A1?)
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.

Exactly my feeling.

Thomas

[Paul McGuire]

> >

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.

Why is decorating a function by wrapping it with some "helping" logic of
some sort perceived to be "odd"?

I would guess that generators and list comps were thought "odd" by some when
they were proposed, too, but we have acclimated ourselves to their concepts,
and embraced them. I'm sure part of this receptiveness was the fact that
the selected syntax did not include some eye-jarring splat of punctuation.

But '@' will forever look odd, even after we have accustomed ourselves to
the utility of function decoration, with the likes of memoize, etc.

If you truly feel function decoration is an "odd" thing, why is it getting
into the language at all? Why not instead look ahead to when function
decoration is accepted as part of the rich toolkit of power Python
programming, and marvel at how seamlessly it blends into the syntactic
terrain. I think the only way this can happen is to incorporate decorators
while maintaining the clean consistency of its syntax forms: source
indentation to indicate hierarchy of logic (or declaration); conventional
punctuation, such as [], :, and (); native data type constructs, such as
lists and dictionaries; powerful class definition tools.

Just because Java uses @ for declaring new function attributes does not sway
me towards accepting it - I don't see us adopting {}'s in place of
indentation, even though C, C++, Perl, and Java all use them. I see the
absence of '@' in Python to be a *good* thing, and I hope hope hope that it
will stay *out* of the language.

-- Paul

[Paul Morrow]

Note: This is *not* about implicit method typing... :-)

Although I haven't seen it discussed anywhere, we already have a
decorator syntax (of sorts) that we use to annotate functions and
classes. The " __var__ = " business. Have we decided that it is
woefully insufficient? I know that there is a preference for the
decorators to appear outside of the function def, but putting that
aside, this 'style' of decorating already has a precendent in python, so
it is probably as pythonic as you can get...

class Foo:
__metaclass__ = M
__automethods__ = True
__author__ = 'Paul Morrow'
__version__ = '0.1'

def baz(a,b,c):
__synchronized__ = True
__accepts__ = (int,int,int)
__returns__ = int
__author__ = 'Fred Flintstone'

return a + b + c
What is the burning desire to abandon this style?

Paul

[Paul Morrow]

Paul Morrow wrote:

def baz(a,b,c):
__synchronized__ = True
__accepts__ = (int,int,int)
__returns__ = int
__author__ = 'Fred Flintstone'

return a + b + c

Sorry about the indentation screw-up on that return stmnt...

[Christophe Cavalaria]

Paul Morrow wrote:

Note: This is *not* about implicit method typing... :-)

Although I haven't seen it discussed anywhere, we already have a
decorator syntax (of sorts) that we use to annotate functions and
classes. The " __var__ = " business. Have we decided that it is
woefully insufficient? I know that there is a preference for the
decorators to appear outside of the function def, but putting that
aside, this 'style' of decorating already has a precendent in python, so
it is probably as pythonic as you can get...

class Foo:
__metaclass__ = M
__automethods__ = True
__author__ = 'Paul Morrow'
__version__ = '0.1'

def baz(a,b,c):
__synchronized__ = True
__accepts__ = (int,int,int)
__returns__ = int
__author__ = 'Fred Flintstone'

return a + b + c
What is the burning desire to abandon this style?

Paul

By what kind of black magic would setting the property __synchronized__ to
True would make that function synchronized ? And how can I define my own
decorators then ? And what about the other usage patterns for decorators
like the easy property getter/setter definition ?

[Paul Morrow]

Christophe Cavalaria wrote:

Paul Morrow wrote:

Note: This is *not* about implicit method typing... :-)

Although I haven't seen it discussed anywhere, we already have a
decorator syntax (of sorts) that we use to annotate functions and
classes. The " __var__ = " business. Have we decided that it is
woefully insufficient? I know that there is a preference for the
decorators to appear outside of the function def, but putting that
aside, this 'style' of decorating already has a precendent in python, so
it is probably as pythonic as you can get...

class Foo:
__metaclass__ = M
__automethods__ = True
__author__ = 'Paul Morrow'
__version__ = '0.1'

def baz(a,b,c):
__synchronized__ = True
__accepts__ = (int,int,int)
__returns__ = int
__author__ = 'Fred Flintstone'

return a + b + c
What is the burning desire to abandon this style?

Paul

By what kind of black magic would setting the property __synchronized__ to
True would make that function synchronized ? And how can I define my own
decorators then ?

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...
#
Here 'func' would be bound to baz (the function being decorated), and
trueOrFalse would be bound to True (the value assigned to
__synchronized__ in the definition of baz).

So we could define our own decorator functions and they would get called
the same way that synchronized does.

def simpleFunction(a, b, c):
__myDecorator__ = (73, 'hello', [5,6,7])

# ...

def myDecorator(func, a, b, c):
__decorator__ = True
print func # 1.
print a # 2.
print b # 3.
print c # 4.
"""Footnotes:
1. prints <function simpleFunction at 0x0092B630>
2. prints 73
3. prints 'hello'
4. prints [5,6,7]
"""


And what about the other usage patterns for decorators
like the easy property getter/setter definition ?

Sorry, not sure what you mean. But would the above cover it?

Paul

[Paul Paterson]

My vote: J2 J3 C1

Is J2EE an option ;

[Robin Becker]

I vote B B B
--
Robin Becker

[Colin J. Williams]

Anthony Baxter wrote:

On 20 Aug 2004 00:31:35 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:

My conclusion: Python 2.4 should not have new decorator syntax. Stay
with the existing stuff, for now.

This is not an option that is going to happen. The decorators thread
has been discussed on python-dev for 2 1/2 years. The case for including
them has been decided. The original decorators (classmethod, staticmethod)
were introduced in Python 2.2, released late 2001. How long do you think
we should wait?

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

Colin W.

Discussion and exploration should continue and the question should be
revisited for 2.5. For 2.4, extend the current kludgy (decorators
separated from the function) mechanism if needed to provide necessary
functionality, but deprecate any new such feature as soon as it's
introduced, with the explanation that it's exploratory.

This is not the way Python works. "experimental" stuff doesn't stay experimental
once the first beta release is out. I see no reason to change this -
it increases
the costs dramatically for companies who are using Python if they have to
rewrite their code every second release.

[Colin J. Williams]

J2 C1 C1

Colin W.

Paul McGuire wrote:
[snip]

[Arthur]

On 20 Aug 2004 12:07:22 -0700, go****@daishi.fastmail.fm (daishi)
wrote:

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]

Doug Holton wrote:

Exactly. From this standpoint, the list on the wiki should be filtered
to something that
1) doesn't have the declaration in the body of the function
2) doesn't have the declaration following the parameters

1) rules out D1 D2 E1 E2
2) rules out C1 C2 C3 C4 E3

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.

With the voting going the way it currently is J2 is winning anyway,

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]

On Sat, 21 Aug 2004 08:39:39 -0400, Colin J. Williams <cj*@sympatico.ca> wrote:

This is not an option that is going to happen. The decorators thread
has been discussed on python-dev for 2 1/2 years. The case for including
them has been decided. The original decorators (classmethod, staticmethod)
were introduced in Python 2.2, released late 2001. How long do you think
we should wait?

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

--
Denis S. Otkidach
http://www.python.ru/ [ru]

[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:

Nicolas Fleury <ni******@yahoo.com_removethe_> wrote in message news:<w0*********************@wagner.videotron.net >...

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/pyt...t/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]

Paul Morrow <pm****@yahoo.com> wrote in message news:<ma**************************************@pyt hon.org>...

By what kind of black magic would setting the property __synchronized__ to
True would make that function synchronized ? And how can I define my own
decorators then ?

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]

Jess Austin wrote:

Paul Morrow <pm****@yahoo.com> wrote in message news:<ma**************************************@pyt hon.org>...

By what kind of black magic would setting the property __synchronized__ to
True would make that function synchronized ? And how can I define my own
decorators then ?

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?

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.

[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.

[Robin Becker]

Avner Ben wrote:

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.
--
Robin Becker

[Colin J. Williams]

Avner Ben wrote:

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]

Avner Ben wrote:

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]

Avner Ben wrote:

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.

Colin J. Williams wrote:

Avner Ben wrote:

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.

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

Robin Becker wrote:

[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.