Call for signatories for J2

[Michael Sparks]

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