Alternative decorator syntax decision

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

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

 

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

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]

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"

 

[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 ([email protected]) <*> 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." (e-mail address removed)

 

[Thomas Heller]

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]

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]

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]

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]

Paul Morrow wrote:




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

 

[Colin J. Williams]

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.