Call for signatories for J2

[Dennis Benzinger]

I vote FOR J2.

Dennis Benzinger

 

[Nigel Rowe]

For.

 

[Ville Vainio]

I vote FOR on the J2 syntax.

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?=]

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

 

[Michael Sparks]

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.
--
(e-mail address removed)
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.

 

[Paul McGuire]

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

Only in ternary operator format.

 

[Anthony Baxter]

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

 

[Tim Hoffman]

Big plus one from me for J2 over @ syntax

Rgds

Tim Hoffman

 

[Michael Sparks]

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.
--
(e-mail address removed)
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.

 

[Michael Sparks]

...

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.

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.
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.
--
(e-mail address removed)
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.

 

[Paul McGuire]

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

 

[Tim Hochberg]

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

 

[Paul Rubin]

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.

 

[John Carter]

For

John Carter

 

[Doug Holton]

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"?

 

[Paul Rubin]

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

 

[Shalabh Chaturvedi]

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?book=Dictionary&va=per&x=0&y=0

 

[Tim Hochberg]

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

 

[Ville Vainio]

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.

 

[Michael Sparks]

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.