Call for signatories for J2

[Michael Sparks]

Paul Rubin wrote:
> Michael Sparks <michaels at 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.