Call for signatories for J2

Robert Brewer wrote:
....

The patch is nearly complete;
Patch against current CVS passes all the tests* and has been uploaded to
SourceForge. I'm currently looking at how __future__ declarations work, and
that will be the next step, but based on useful feedback this looks
relatively simple to do.

* Well, put another way, the only tests that fail are those that fail with
an unmodified CVS tree.
This is a call for all who wish to sign the proposal, either for,
against, or abstaining. Please sign by either posting on
comp.lang.python (replying to this is fine),

Please consider this a vote FOR - I doubt that'll surprise however ;-)

Regards,
Michael.

Jul 18 '05 #5

Nicolas Fleury

For.

Regards,
Nicolas Fleury

Jul 18 '05 #6

For.

Paul McGuire

Jul 18 '05 #7

Paul Paterson

For

Paul Paterson

Jul 18 '05 #8

David Pokorny

Vote For.

David

Jul 18 '05 #9

Colin J. Williams

For J2, this is better than 2.4.2a version, but there are more Pythonic
ways.

Colin W.

Jul 18 '05 #10

Mahesh Padmanabhan

In article <ma**************************************@python.o rg>,
"Robert Brewer" <fu******@amor.org> wrote:

The J2 proposal is as complete as it will ever be.

http://www.aminus.org/rbre/python/pydec.html

The patch is nearly complete; only the future declaration and some
document tweaks remain. It should be updated on SourceForge today or
tomorrow.

This is a call for all who wish to sign the proposal, either for,
against, or abstaining. Please sign by either posting on
comp.lang.python (replying to this is fine), or sending email to
fu******@amor.org (for some of you reading this, here's a link:
mailto:fu******@amor.org). Please include your full name. If you reject
the proposal, please also include a short description of why you are
rejecting it. You will not receive a reply regarding the rejection or
description; it will be included for Guido's information purposes only.

Please read the proposal carefully before signing. In particular,
carefully read the statement (for, against, or abstaining) to which you
are signing your name; each is explicit and means exactly what it says.

Thanks again to those who have contributed in all forms. Hopefully, we
can put this decorator issue to rest soon and move on.
Robert Brewer
MIS
Amor Ministries
fu******@amor.org

P.S. I'll be out of town from Friday morning to Sunday evening (U.S.
Pacific Time), so get your name in early. Given sufficient volume, I'll
promote this to Guido just before I leave; otherwise, I'll wait 'til
Sunday night to finish compiling names.

I vote for J2.

Jul 18 '05 #11

Michele Simionato

Uhm... the choice between @ and J2 is tough for me. "@" is somewhat
less intrusive (I automatically ignore it, look at the function body
and then go back at the decorator) whereas J2 focus too much the
attention on the using clause. This is probably because it reminds
me a try: except: block, where the attention is focused on the try:
part. It is probably matter of time to get used to it.

OTOH I think that J2 is more consistent with the rest of Python and
it avoids the introduction of the pie sign which conflicts with Leo
and IPython, so there are strong arguments in its favor.

Conclusion: I would be happy both with "@" and J2 (or even with
"|" instead of "@"). However, the work done by Robert Brewer and
Micheal Sparks is impressive and deserve to be supported, so
count me as a mild "FOR" ;)
Michele Simionato

Jul 18 '05 #12

Alex Martelli

Robert Brewer <fu******@amor.org> wrote:

This is a call for all who wish to sign the proposal, either for,
against, or abstaining. Please sign by either posting on
comp.lang.python (replying to this is fine), or sending email to

For.

I wish we'd use a better keyword than 'using' which would have a
bazillion other possible and useful future interpretations. Of the
possible keywords mentioned on the site, several (by, per, through, via)
appear better to me, and I'd particularly love the three-letter ones as
they'd align well with 'def' -- my own preference would be 'per'.

However, I suspect it's too late to submit J2 with anything but 'using'
and I'd rather have J2 with 'using' than the pie-before-def thingy, so,
here's my "tactical" FOR vote:-).
Alex

Jul 18 '05 #13

David Fraser

FOR

Thanks for all the hard work

David Fraser

Jul 18 '05 #14

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in message
news:bP******************@fe2.texas.rr.com...

For.

Paul McGuire

I'd also like to echo Alex Martelli's comments regarding 'per'. I can live
with 'using', but the common case of

using:
staticmethod
def foo():
pass

reads better to me with 'per' as the keyword:

per:
staticmethod
def foo():
pass

(Interestingly, @ and 'per' are similar in that "12 @ $

Jul 18 '05 #15

> (Interestingly, @ and 'per' are similar in that "12 @ $

ahem!

"12 @ $1.50" is shorthand for "12 at $1.50 per item" was what I meant to say
before I was interrupted!

"per" as a Latin word would help its adoption beyond English-speaking
regions. It's meaning as "by" is consistent with the decorator notion that
foo() is modified _by_ the decorator methods before it is fully defined.

And Alex cites "per"s three-letter-ness, as a nice parallel to the
corresponding "def".

-- Paul
(now I'm really through)

Jul 18 '05 #16

John Crichton

Vote: FOR

Could I also echo Fernando Perez's sentiments in thanking the people
who have worked so hard putting this proposal together.

Best wishes,

John Crichton

Jul 18 '05 #17

Alex Martelli wrote:
....

I wish we'd use a better keyword than 'using' which would have a
bazillion other possible and useful future interpretations. Of the
possible keywords mentioned on the site, several (by, per, through,
via) appear better to me, and I'd particularly love the three-letter
ones as they'd align well with 'def' -- my own preference would be
'per'.

However, I suspect it's too late to submit J2 with anything but
'using' and I'd rather have J2 with 'using' than the pie-before-def
thingy, so, here's my "tactical" FOR vote:-).

It might (or might not) be too late but just as a check I checked
to see if "per" is used by any projects listed in the proposal. (I
was checking Twisted and Zope for "using" so decided to do "per"
as well)

The irony here is that just like "using" the only project that I could
find out of those list on the proposal, Twisted and Zope X3 using "per"
is python itself. Specifically Idle uses it internally as a shorthand
for "percolator".

Changing the patch to work with "per" would be simple, and I don't know
if Guido reads this group (I suspect not?), but for the record "using"
and "per" appear to have the same risk level to existing code - ie very
low.

"per"'s risk level might be marginally lower because it's only used
in idle's guts, whereas "using" is used in webbrowser's get method
as a sole named parameter. Whilst I can't find anything using the
latter, it's certainly more likely than someone relying on the guts
of a project to remain unchanging.

Best regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

Jul 18 '05 #18

Ksenia Marasanova

I vote FOR J2.

Ksenia Marasanova.

Jul 18 '05 #19

Walter Dörwald

Using decorators for docstrings would look much better
with the J2 proposal:

using:
"""
...
"""
def foo(bar):
...

instead of

@doc("""
....
""")
def foo(bar):
...

(Of course this requires special support for a bare string
inside the using suite)

And folding would really be helpful with long docstrings.

Consider this a vote for the J2 proposal.

Bye,
Walter Dörwald

Jul 18 '05 #20

Dennis Benzinger

I vote FOR J2.

Dennis Benzinger

Jul 18 '05 #21

Nigel Rowe

For.

--
Nigel Rowe
A pox upon the spammers that make me write my address like..
rho (snail) swiftdsl (stop) com (stop) au

Jul 18 '05 #22

Ville Vainio

I vote FOR on the J2 syntax.

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

Jul 18 '05 #23

Pierre-Frédéric Caillaud

I'll vote for it.
Can we insert conditional expressions in the decorator list ?

On 26 Aug 2004 15:00:05 +0300, Ville Vainio <vi***@spammers.com> wrote:

I vote FOR on the J2 syntax.

Jul 18 '05 #24

"Pierre-Frédéric Caillaud" <pe****@free.fr> wrote in message
news:opsdb950eb1v4ijd@musicbox...

I'll vote for it.
Can we insert conditional expressions in the decorator list ?

On 26 Aug 2004 15:00:05 +0300, Ville Vainio <vi***@spammers.com> wrote:
I vote FOR on the J2 syntax.

Only in ternary operator format. :)

Jul 18 '05 #25

Pierre-Frédéric Caillaud wrote:

Can we insert conditional expressions in the decorator list ?

Not directly, but yes. Both J2 and A1 are "limited" to putting just
values that resolve to a function in the decorator list. In practice
this means that if you REALLY want to do things like conditional
expressions you can:

Given:
x=1
def memoise(f):
print "memoise"
return f

def esiomem(f):
print "esiomem"
return f

Using current syntax: (untested)

class Foo:
@staticmethod
@eval("(memoise,esiomem)[x==0]")
def Hoo(Who, *args):
print "Yoo", Who

Using proposed J2: (tested)
class Foo:
using:
staticmethod
eval("(memoise,esiomem)[x==0]")
def Hoo(Who, *args):
print "Yoo", Who

Personally that strikes me as relatively evil, but it works.

Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

Jul 18 '05 #26

Anthony Baxter

On Thu, 26 Aug 2004 14:44:27 +0100, Michael Sparks
<mi******@rd.bbc.co.uk> wrote:

Using proposed J2: (tested)
class Foo:
using:
staticmethod
eval("(memoise,esiomem)[x==0]")
def Hoo(Who, *args):
print "Yoo", Who

Why wouldn't you instead write this as:

if x == 0:
dec = esiomem
else:
dec = memoise
@staticmethod
@dec
def Hoo(Who, *args):
....

Don't use eval unless it's absolutely necessary, _please_.

Jul 18 '05 #27

Tim Hoffman

Big plus one from me for J2 over @ syntax

Rgds

Tim Hoffman

Jul 18 '05 #28

Anthony Baxter wrote:

On Thu, 26 Aug 2004 14:44:27 +0100, Michael Sparks
<mi******@rd.bbc.co.uk> wrote:
Using proposed J2: (tested)
class Foo:
using:
staticmethod
eval("(memoise,esiomem)[x==0]")
def Hoo(Who, *args):
print "Yoo", Who
Why wouldn't you instead write this as:

....
[alternative using an if statement before]
.... Don't use eval unless it's absolutely necessary, _please_.

The question was asking about using a conditional expression in the
decorator list. Since the closest equivalent as an expression that
evaluates to a function is something like (memoise,esiomem)[x==0] and
since you can only put function calls there, that was why I put eval
there.

I suppose instead I could've had:

def identity(actualFunc):
def decorate(func):
return actualFunc(func)
return decorate

class Foo:
@staticmethod
@identity((memoise,esiomem)[x==1])
def Hoo(Who, *args):
print "Yoo", Who

Which is nicer, but still pretty hideous. I'd agree that the preceding
if statement approach is better than a conditional expression.

Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

Jul 18 '05 #29

"Michael Sparks" <mi******@rd.bbc.co.uk> wrote in message
news:cg**********@nntp0.reith.bbc.co.uk...

Anthony Baxter wrote:
I suppose instead I could've had:

def identity(actualFunc):
def decorate(func):
return actualFunc(func)
return decorate

class Foo:
@staticmethod
@identity((memoise,esiomem)[x==1])
def Hoo(Who, *args):
print "Yoo", Who

Which is nicer, but still pretty hideous. I'd agree that the preceding
if statement approach is better than a conditional expression.

On the contrary, I think it likely that, in the event a module of standard
decorators is eventually provided (I thought I heard something like this in
some prior thread, perhaps on python-dev), that there will need to be some
flavors of nullDecorator such as unchanged and disabled below (I think I
have the decorator syntax down, if not I hope you get the idea):

def unchanged(func):
"This decorator doesn't add any behavior"
return func

def disabled(func):
"This decorator disables the provided function, and does nothing"
def emptyFunc(*args,**kargs):
pass
return emptyFunc

# define this as equivalent to unchanged, for nice symmetry with disabled
enabled = unchanged
Now you could do something like:

globalEnableFlag = True

@( (disabled,enabled)[globalEnableFlag ] )
def specialFunctionFoo()
pass

or

using:
(disabled,enabled)[globalEnableFlag ]
def specialFunctionFoo()
pass

-- Paul

Jul 18 '05 #30

> Robert Brewer wrote:

...
The patch is nearly complete;
Patch against current CVS passes all the tests* and has been uploaded
to SourceForge. I'm currently looking at how __future__ declarations
work.

Patch against current CVS including __future__ statements/declarations
has now been created, tested and uploaded to SourceForge. All tests
pass.

For those interested this means the full patch now allows:

----------------------
from __future__ import decorators

def memoise(f):
"dummy memoisation function"
return f

class Foo:
using:
staticmethod
memoise
def Hoo(Who, *args):
print "Yoo", Who

Foo.Hoo("HOO")
----------------------

For the __future__ work I followed the approach taken by
generators/yield in 2.2 . Using decorators without an explicit
import from __future__ results in a failure.

On a slightly different topic, when I was looking at how __future__
statments work, I must admit when I saw the following, it made me
smile:
python

Python 2.3.3 (#1, Apr 6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from __future__ import braces File "<stdin>", line 1
SyntaxError: not a chance

Digging around the python source I must admit has been a pleasurable
experience (especially when finding nuggets like this! :). Whether or
not syntax J2 gets accepted or not, this has been fun - my compliments
to the python-dev team :)

Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

Jul 18 '05 #31

Tim Hochberg

Alex Martelli wrote:

Robert Brewer <fu******@amor.org> wrote:

This is a call for all who wish to sign the proposal, either for,
against, or abstaining. Please sign by either posting on
comp.lang.python (replying to this is fine), or sending email to

For.

I also have a weak preference for 'per' over 'using', FWIW. The
shortness of 'per' is one virtue. Another is that, because it's slightly
obscure, it may be easier to indoctrinate users that 'per...def' is the
correct order, not 'def...per'. For me at least it's 'obvious' that if
'using...def' works then so should 'def...using', which of course it
can't. The order is amenable to memorization, but I still anticipate
more thinkos of this type from using than from per. On the downside, per
may be extremely obscure to those that are neither native speakers of
English or one of the romance languages.

-tim
For.

I wish we'd use a better keyword than 'using' which would have a
bazillion other possible and useful future interpretations. Of the
possible keywords mentioned on the site, several (by, per, through, via)
appear better to me, and I'd particularly love the three-letter ones as
they'd align well with 'def' -- my own preference would be 'per'.

However, I suspect it's too late to submit J2 with anything but 'using'
and I'd rather have J2 with 'using' than the pie-before-def thingy, so,
here's my "tactical" FOR vote:-).
Alex

Jul 18 '05 #32

Michael Sparks <mi******@rd.bbc.co.uk> writes:

It might (or might not) be too late but just as a check I checked
to see if "per" is used by any projects listed in the proposal. (I
was checking Twisted and Zope for "using" so decided to do "per" as well)

I'm still not crazy about J2 but I like "per" much better than "using".

I'm afraid that the clpy proposals, and the @pie syntax, both seem to
me like "extreme programming", i.e. an approach of "if you see a
reasonable looking approach to a problem, implement it without
worrying too much, and re-do ('refactor') it afterwards if it turns
out not to be the right thing. But for new language syntax, whatever
gets implemented, we are going to be stuck with. There will be no
refactoring possible. It's imperative to get it right the first time.
The Scheme community understood this idea and was extremely careful
about adding new features to Scheme even when it was clear that the
features were needed. I think Scheme benefited as a result.

Jul 18 '05 #33

Doug Holton

Tim Hochberg wrote:

I also have a weak preference for 'per' over 'using', FWIW. The
shortness of 'per' is one virtue. Another is that, because it's slightly
obscure, it may be easier to indoctrinate users that 'per...def' is the
correct order, not 'def...per'. For me at least it's 'obvious' that if
'using...def' works then so should 'def...using', which of course it
can't. The order is amenable to memorization, but I still anticipate
more thinkos of this type from using than from per. On the downside, per
may be extremely obscure to those that are neither native speakers of
English or one of the romance languages.

Even in common English usage, "per" usually comes in the middle of a
phrase, not the beginning, like "miles per hour" or "Changes were made
to the manuscript per the author's instructions" (people would more
commonly use the phrase "according to" rather than "per" there).

None of those uses bare any resemblance to how decorators affect
functions. "per:" by itself on a line is pretty much meaningless.
Looks more like you misspelled pre.

If people are liking Latin keywords for decorators now, why not "sic"?

Jul 18 '05 #34

John Carter

For

John Carter

Jul 18 '05 #35

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

Even in common English usage, "per" usually comes in the middle of a
phrase, not the beginning, like "miles per hour" or "Changes were made
to the manuscript per the author's instructions" (people would more
commonly use the phrase "according to" rather than "per" there).

It's also perfectly ok to say "Per the author's instructions, changes
were made to the manuscript".

Jul 18 '05 #36

Shalabh Chaturvedi

Doug Holton wrote:

Tim Hochberg wrote:
I also have a weak preference for 'per' over 'using', FWIW. The
shortness of 'per' is one virtue. Another is that, because it's
slightly obscure, it may be easier to indoctrinate users that
'per...def' is the correct order, not 'def...per'. For me at least
it's 'obvious' that if 'using...def' works then so should
'def...using', which of course it can't.

Even in common English usage, "per" usually comes in the middle of a
phrase, not the beginning, like "miles per hour" or "Changes were made
to the manuscript per the author's instructions" (people would more
commonly use the phrase "according to" rather than "per" there).

None of those uses bare any resemblance to how decorators affect
functions. "per:" by itself on a line is pretty much meaningless.
Looks more like you misspelled pre.

As per meaning #3 of the Merriam-Webster Online Dictionary [1], per also
means 'according to'. In fact when I first saw the suggestion of 'per' I
could immediately make sense of it in that context. I'm still debating
whether to vote for or abstain, since I'm not that fond of 'using'.

Cheers,
Shalabh

[1] http://m-w.com/cgi-bin/dictionary?bo...va=per&x=0&y=0

Jul 18 '05 #37

Tim Hochberg

Doug Holton wrote:

Tim Hochberg wrote:
I also have a weak preference for 'per' over 'using', FWIW. The
shortness of 'per' is one virtue. Another is that, because it's
slightly obscure, it may be easier to indoctrinate users that
'per...def' is the correct order, not 'def...per'. For me at least
it's 'obvious' that if 'using...def' works then so should
'def...using', which of course it can't. The order is amenable to
memorization, but I still anticipate more thinkos of this type from
using than from per. On the downside, per may be extremely obscure to
those that are neither native speakers of English or one of the
romance languages.

Even in common English usage, "per" usually comes in the middle of a
phrase, not the beginning, like "miles per hour" or "Changes were made
to the manuscript per the author's instructions" (people would more
commonly use the phrase "according to" rather than "per" there).

Per the author's instructions, changes were made.
Changes were made per the author's instructions.

Using only hand tools, we built the treehouse.
We built the treehouse using only hand tools.

Both of 'per' and 'using' (and most of the other keyword options that
aren't really horrible) have a bias for being read backwards. My
contention was that since 'per' is probably a bit less familiar it would
be easier to beat the nonstandard order into ones head.
None of those uses bare any resemblance to how decorators affect
functions.
I don't agree. Or at least I don't agree that:

per:
instructions
def func():
...

Is any worse a model for what's going on than:

using:
functions
def func():
...

Neither's great, both are suggestive of what's going on. Unless we use:

use_the_following_functions_to_transform_the_subse quent_def

It's going to be pretty hard to get something that's much more than
suggestive.
"per:" by itself on a line is pretty much meaningless.
Looks more like you misspelled pre.
If "pre:" was legal Python, I certainly wouldn't support 'per:'. While
'per' may in fact be too obscure, and that's legitimate point to argue,
I'm not sure that arguing about how it reads out of context is all that
relevant. Whatever keyword is chosen, I expect it to be fairly close to
the subsequent def.

If people are liking Latin keywords for decorators now, why not "sic"?

It's even vauger than per. I'll give it that. When I was young, I was
too lazy to look it up, so I backronymed this into Spelling
Intentionally Compromised. In retrospect, this probably fits the real
usage better than the Latin, so no harm done.

-rim

Jul 18 '05 #38

Ville Vainio

>>>>> "Paul" == Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Paul> out not to be the right thing. But for new language syntax,
Paul> whatever gets implemented, we are going to be stuck with.
Paul> There will be no refactoring possible. It's imperative to
Paul> get it right the first time. The Scheme community
Paul> understood this idea and was extremely careful

Well, there will be py3k that will be able to break the
compatibility. Code using decorators also be automatically
modified to use a different decorator syntax (or no syntax at all) if
they, for some reason, turn out to be a terrible idea.

Paul> about adding new features to Scheme even when it was clear
Paul> that the features were needed. I think Scheme benefited as
Paul> a result.

As proved by its mindblowing success ;-)? *ducks*

Python culture is fundamentally different from the Scheme culture, and
even Lisp culture - this is possibly one of the reasons for its
success. It's not about "we've got all we need, thank you - and don't
you dare suggest anything else" but "this would allow much more
elegant code, even if not strictly necessary". That's why we have List
Comprehensions, generators, iterators at core, and soon genexps (and
yes, decorators).

Down that road doesn't necessarily lie C++, which has problems with
its basic foundation, not with the later additions. Python computation
model has a very simple and "obvious" feel to it, and additions just
enable us to rev it up a little bit more.

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

Jul 18 '05 #39

Paul Rubin wrote:

Michael Sparks <mi******@rd.bbc.co.uk> writes:
It might (or might not) be too late but just as a check I checked
to see if "per" is used by any projects listed in the proposal. (I
was checking Twisted and Zope for "using" so decided to do "per" as well)
I'm still not crazy about J2 but I like "per" much better than "using".

It's very possible that we might end up with @pie syntax or nothing. (I
suspect the latter is very unlikely, but it's still possible)
I'm afraid that the clpy proposals, and the @pie syntax, both seem to
me like "extreme programming", [ which isn't really very good for
language _design _ ]

I think I'd agree. However for many people outside of python-dev and those
who only dip into c.l.p, the @pie came as a big shock. I think that was
compounded by the impact on commonly used tools.

Why a shock? My recollection of the discussion regarding decorators (which I
first encountered at EuroPython) was pretty much:
* Who wants list before def? (Lots of votes - let's call it X)
* Who prefers list after def? (Lots of votes - about the same as X)
* Who'd prefer to delay their introduction in favour of a better syntax
(about 2*X) ?

There was also a comment regarding Java style decorators using an @ sign,
but I don't recall any real discussion on the topic, and I also don't
recall any example. There's a good chance I've misremembered things
however! Between Europython and now despite dipping in & out of occasional
posts for the mailing list digest I didn't spot anything serious regarding
decorators until the @pie syntax was merged.

That's not anyone's fault IMO, just the way it is, most people tend to
concentrate more on what they're doing than everyone else. I also suspect
that I'm not atypical - it's not that I didn't care, it's just that as has
been said we all have a finite amount of time to devote to things we care
about, and lets face it, we do all trust Guido and the rest of the team.

My personal initial reaction to the syntax was "ugh", followed by listening
to arguments and deciding that I could live with @pie happily (I do like
perl after all so I've not got a huge aversion to punctuation). Then a nice
alternative (IMO) was posted leading to me wondering how hard it would be
to implement. (I've been rather pleasantly surprised I'm pleased to say :)

Personally I think this has led to a useful discussion, albeit crushed up in
a very short time span. However there are several things could happen now:

1 The @pie implementation might stay as is.
2 The @pie implementation might stay, but require explicit activation
needing a __future__ statement. This to my mind is a good option - it
clearly marks the feature as experimental, making people shy away from
use unless they really do need it.
3 J2 might be accepted.
4 The feature might be ripped out
* etc...

Options 2 or 3 strike me as the best approach here - introduce a feature,
mark it as experimental, with a large warning that it might change in the
next release. That potentially allows the best of both worlds - people can
use the feature in earnest, but do so on the understanding that the feature
may change in a later release meaning that if they use it they have to be
prepared to change their code. Furthermore if they release code using the
feature they should be very careful how they use the feature.

Speaking from personal experience we started using generators in 2.2 because
they allowed a modicum of co-routine type behaviour (indeed this was part of
the reason for choosing python), but the fact you had to put __future__
statements in everywhere in order to use them ensured that we limited their
use to one location.

I would hope that functionality added into a __future__ module would move
from __future__ to standard syntax unchanged, but it does allow Guido and
co the ability to change the language in those areas. It's for this reason
that I *hope* that any decorator syntax when the final decision is taken is
only introduced via the __future__ module approach.

I do share your concerns about "if it's a mistake we're stuck with it", but
unless something goes in there are two problems:
* People will revert to using metaclass approaches, which having
tried them I think people will find worse than something more
explicit & in your face. (Almost any syntax on the wiki IMO is
better than a metaclass approach)
* There will be no single approach taken - leading to more hidden magic
than you can shake a stick at...

At the end of the day though, the decision lies with someone we all trust
the judgement of. Even the J2 patch is just a means of opening up options.
The only way sometimes of discovering something is a mistake is to try it.
The patch allows Guido and everyone else to decide whether it is a mistake
or not.

Almost finally, personally I think this process has been enormously
productive - it's gotten many more people involved in python than before,
there has been constructive discussion that whilst perhaps it should've
happened months ago it HAS happened. Personally this strikes me as
incredibly healthy.

Finally, if there is a chance that the syntax will have to change after it's
been used in earnest then IMHO option A1 should be chosen, via a __future__
import. Whilst I'm obviously in favour of J2, option A1 strikes me as by
_far_ the simplest to write or provide tools to programmatically munge
people's code if syntax does change. (Much like the tools to remove
unnecessary __future__ statements)

Best Regards,
Michael.

Jul 18 '05 #40

Jeff Shannon

Robert Brewer wrote:

The J2 proposal is as complete as it will ever be.

http://www.aminus.org/rbre/python/pydec.html

I'll sign in favor of this proposal.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #41

Michael Sparks <za*****@thwackety.com> writes:

It's very possible that we might end up with @pie syntax or nothing. (I
suspect the latter is very unlikely, but it's still possible)
I don't have a strong opinion of whether J2 is better than @pie or vice
versa. I dislike both.
My personal initial reaction to the syntax was "ugh", followed by listening
to arguments and deciding that I could live with @pie happily (I do like
perl after all so I've not got a huge aversion to punctuation).
My problem with @pie is that it doesn't get enough mileage out of the
@ character. I'd almost rather use @ as a keyword introducer, like #
in the prepreprocessor. And of course, @pie should be useable on
classes rather than just functions.
* People will revert to using metaclass approaches, which having
tried them I think people will find worse than something more
explicit & in your face. (Almost any syntax on the wiki IMO is
better than a metaclass approach)
I think decorators can do things that metaclasses can't.
been used in earnest then IMHO option A1 should be chosen, via a
__future__ import. Whilst I'm obviously in favour of J2, option A1
strikes me as by _far_ the simplest to write or provide tools to
programmatically munge people's code if syntax does change. (Much
like the tools to remove unnecessary __future__ statements)

I really wouldn't worry too much about the effect on current syntax
tools. There aren't that many of them, and they do get updated.
Changing Python's syntax will have longer-lasting consequences than
having to update some tools.

Jul 18 '05 #42

Alex Martelli

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al*****@yahoo.com (Alex Martelli) writes:
I think a keyword that's ALREADY a keyword has been almost ignored,
though people occasionally did mention it re decorators: 'as'. I'd love
to see 'as' used as THE decorator keyword. personally I'd prefer
'def as classmethod foo(...):'
followed by

How do you handle the other proposed uses of decorators, e.g. type
declarations?

def foo as int (a as string, b as int):
...

seems pretty awful to me.

Type declarations make me cringe, but if I *had* to have them then 'b as
int' is the best syntax I could imagine for them offhand.
Alex

Jul 18 '05 #43

al*****@yahoo.com (Alex Martelli) writes:

Type declarations make me cringe, but if I *had* to have them then 'b as
int' is the best syntax I could imagine for them offhand.

b:int worked ok in Pascal.

Jul 18 '05 #44

Paul Rubin wrote:

Michael Sparks <za*****@thwackety.com> writes:
It's very possible that we might end up with @pie syntax or nothing. (I
suspect the latter is very unlikely, but it's still possible)
I don't have a strong opinion of whether J2 is better than @pie or vice
versa. I dislike both.

I'm aware of that - I was largely just stating that IMO based on
everything I've read that there is more chance of @pie staying than
decorators being removed. Given the "Zen of Python" epithet saying
"In the face of ambiguity, refuse the temptation to guess." that to
me *is* a strike against J2. (assuming that it describes Guido's
philosophy well - something I don't know :)

My personal initial reaction to the syntax was "ugh", followed by
listening to arguments and deciding that I could live with @pie happily
(I do like perl after all so I've not got a huge aversion to
punctuation).

My problem with @pie is that it doesn't get enough mileage out of the
@ character. I'd almost rather use @ as a keyword introducer, like #
in the prepreprocessor. And of course, @pie should be useable on
classes rather than just functions.

So why not put forward an alternative proposal? (*) If the proposal is good
someone might think "ooh, I like that", and implement it if you don't
feel like implementing it yourself - much like happened with J2 - it
was hardly my invention! :-)
* If you have I must've missed it... sorry :-(
I think decorators can do things that metaclasses can't.
Agreed, however in the absence of a decorators in the language people are
very likely to use metaclasses in their place for many of the tasks.

been used in earnest then IMHO option A1 should be chosen, via a
__future__ import. Whilst I'm obviously in favour of J2, option A1
strikes me as by _far_ the simplest to write or provide tools to
programmatically munge people's code if syntax does change. (Much
like the tools to remove unnecessary __future__ statements)

I really wouldn't worry too much about the effect on current syntax
tools.

I wasn't really thinking of current syntax tools - I was thinking about a
hypothetical situation:
* Decorators incorporated via the __future__ mechanism
* A subset of people use them in earnest
* It's found that it would be useful to change the syntax whilst it's
still in the experimental __future__ phase. (As might've happened but
didn't with yield and generators)

In this scenario if you choose J2 then it's much harder for people to build
their own tools to change their code to the new syntax. (It can be done of
course, but it is harder) If you choose A1 then this is simpler. (This is
what I meant regarding the tool that remove unnecessary __future__
statements)

Whether that situation matters to you depends on who you are :)
Changing Python's syntax will have longer-lasting consequences than
having to update some tools.

Absolutely.

Regards,
Michael.

Jul 18 '05 #45

Paul Moore

"Robert Brewer" <fu******@amor.org> writes:

The J2 proposal is as complete as it will ever be.

http://www.aminus.org/rbre/python/pydec.html

Against.

I can't see anything to convince me this is better that pie-syntax
(which is in place, and complete, *right now*). And it still doesn't
specify the keyword - which means there's another argument waiting to
happen.

Paul
--
Instant gratification takes too long -- Carrie Fisher

Jul 18 '05 #46