Call for signatories for J2

[Jeff Shannon]

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

 

[Paul Rubin]

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.

 

[Michael Sparks]

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

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.

 

[Alex Martelli]

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

 

[Paul Rubin]

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.

 

[Paul Moore]

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

 

[Scott David Daniels]

This is a call for all who wish to sign the proposal, either for,
against, or abstaining.

Count me as a "for" (although I don't really have anywhere as much
dislike of "@" as many of my co-signers).

-Scott Davd Daniels
(e-mail address removed)

 

[djw]

For

Don Welch

 

[Anthony Baxter]

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.

That's not the way Python works - we don't rip stuff out once it's
been in a final release. from __future__ is added so that people can
turn on a new feature gradually, without their code being instantly
broken.

 

[Greg Ewing]

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.

It came as a shock to people *in* python-dev, too. It just
appeared one day as a fait accompli, without any opportunity
for discussion.

 

[Anthony Baxter]

It came as a shock to people *in* python-dev, too. It just
appeared one day as a fait accompli, without any opportunity
for discussion.

*shrug* I posted a couple of weeks before from Guido saying "here's
another syntax that Guido is leaning towards", and asking for a
volunteer to write a patch. Patch was done, there was a bit of
back-and-forth in the patch tracker on SF, then it came down to a
Guido decision.

I don't know what additional discussion on python-dev would have
accomplished. Almost no-one spoke up about the @syntax when I posted
the first note.

 

[Alex Martelli]

b:int worked ok in Pascal.

And "b as integer" works quite reasonably in Visual Basic -- I'm not a
VB fan, by any means, but that particular tidbit of VB syntax sugar is
(IMHO) quite good.

A precedent for a dual use of AS, quite close to what we'd have here, is
in SQL. "SELECT foo AS bar" is a local renaming, just like Python's
"import foo as bar"; "CAST(foo AS integer)" is type coercion. Note that
both SQL uses are good parallel for some of the 'overloads' of 'AS' in
English;-).

All in all, the argument that declarator syntax 'might' end up doing
double use for typing purposes is hardly a strong deterrent to the use
of keyword 'as' in declarator syntax.


Alex

 

[Peter Otten]

For J2

Peter Otten

Though I don't like "using".

 

[Leif K-Brooks]

This is a call for all who wish to sign the proposal, either for,
against, or abstaining.

For.

Leif K-Brooks.

 

[Richie Hindle]

[Michael]

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

Nice one - well done for all your work on this.

British Broadcasting Corporation, Research and Development

Is my license fee paying for this? If so, great! Makes for a much
better investment than Fame Academy.

 

[Nick Jacobson]

I'm not nuts about "using", but it's far better than "@" (as would be
lots of other keywords).

I vote FOR.

--Nick Jacobson

 

[Michael Sparks]

[Michael]

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

Nice one - well done for all your work on this.

You're very welcome. I'd encourage anyone who's interested in python's
advancement to do the same, to be honest. The codebase is one of the
cleanest I've encountered and fairly easy to get started with, and it's
been a pleasure to work on. This experience will certainly encourage me
to participate more in future. (Probably on my own time though!)

Is my license fee paying for this? If so, great! Makes for a
much better investment than Fame Academy.

Yep. (Well, as well as my own time at the weekend/evenings, but that's
common for open source

We have a (small) allocation in our time for "bright ideas" regarding
things that'll help the BBC in ways outside normal projects, and help
further tools etc we use. I think I've probably used mine up for a
while now, but I think it's been worthwhile.

We use Python (amongst many other languages) in R&D for prototyping
ideas and I'm aware of various other parts of the BBC using python as
well, so by helping the python community we help ourselves and everyone
wins (Even if the patch is rejected it'll help resolve an argument!)

I couldn't *possibly* begin to comment on Fame Academy though, I might
say something I shouldn't ;-)

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

 

[Nick Efford]

This is a call for all who wish to sign the proposal, either for,
against, or abstaining.

FOR. I could live with @ but I'm warming to J2, and you've
done some great work in presenting cogent arguments.

I'm with Alex M. in favouring 'as' over 'using'.


Nick Efford

 

[Richie Hindle]

[Michael]

I'd encourage anyone who's interested in python's
advancement to do the same, to be honest. The codebase is one of the
cleanest I've encountered and fairly easy to get started with, and it's
been a pleasure to work on.

Seconded. I've been there and done that (implemented the Set Next Statement
command for Python debuggers), and was pleasantly surprised at how clean and
comprehensible the code was - even in performance-sensitive areas like
ceval.c.

We have a (small) allocation in our time for "bright ideas" regarding
things that'll help the BBC in ways outside normal projects, and help
further tools etc we use.

A good policy. Nice to see that the Beeb's suits can think outside the box
(no pun intended

 

[A.M. Kuchling]

I don't know what additional discussion on python-dev would have
accomplished. Almost no-one spoke up about the @syntax when I posted
the first note.

A similar thing happened with the various cataloging efforts. A number of
individuals wrote prototypes and asked for comments from the community,
never getting any. Finally Richard Jones wrote PyPI, put it on python.org,
and contributed the 'register' Distutils subcommand to the standard library;
there was little outside input on all of this.

Of course, the difference is that PyPI hasn't been controversial. But I
think it does demonstrate that Python development is steered mostly by
individuals, not by the vague wishes of the community.

--amk