Rejecting the J2 decorators proposal

Robert and Python-dev,

I've read the J2 proposal up and down several times, pondered all the
issues, and slept on it for a night, and I still don't like it enough
to accept it. The only reason to accept it would be to pacify the
supporters of the proposal, and that just isn't a good enough reason
in language design.

However, it got pretty darn close! I'm impressed with how the
community managed to pull together and face the enormous challenge of
picking a single alternative (from more than two dozen on the Wiki!)
and arguing consistently. I expect to see more proposals like this in
the future, and I'm sure that some of them will be good enough to make
it into the language.

I've also (again) learned a lesson: dramatic changes must be discussed
with the community at large. In a large enough group there are no
uncontroversial proposals, so this will take time, but it's worth it
-- one of the main issues with the  <at> decorator syntax was not technical
but socio-political, in the sense that it hadn't been properly
discussed outside a *very* small circle. I take the full blame for
that, and I don't want to hide behind my current lack of time which,
realistically, won't change until either my ESI stock options earn me
an early retirement, or the PSF strikes it rich and can pay me full
time .

So let me explain why I'm not choosing J2, and what's next.

There are two major issues and one minor that made me decide against J2.

Weekly Python Patch/Bug Summary

Patch / Bug Summary
___________________

Patches :  247 open (-12) /  2596 closed (+23) /  2843 total (+11)
Bugs    :  758 open (+13) /  4415 closed (+10) /  5173 total (+23)
RFE     :  148 open ( -2) /   131 closed ( +1) /   279 total ( -1)

New / Reopened Patches
______________________

compiler.transformer: correct lineno attribute when possible  (2004-08-25)
       http://python.org/sf/1015989  opened by  Thenault Sylvain

configure.in change to allow compilation on AIX 5  (2004-08-25)
CLOSED http://python.org/sf/1016224  opened by  Trent Mick

bsddb's DB.keys() method ignores transaction argument  (2004-08-27)
       http://python.org/sf/1017405  opened by  Jp Calderone

Fix for bug 1017546  (2004-08-27)
       http://python.org/sf/1017550  opened by  Michael

ifdeffery patch  (2004-08-28)
CLOSED http://python.org/sf/1018291  opened by  Ilya Sandler

fix for several sre escaping bugs (fixes #776311)  (2004-08-28)
       http://python.org/sf/1018386  opened by  Mike Coleman

fix bug 807871 : tkMessageBox.askyesno wrong result  (2004-08-29)
       http://python.org/sf/1018509  opened by  Jiba

Freezing for alpha3 - trunk FROZEN from 2004-09-01 13:00 UTC

I plan to start alpha3 in about 24 hours time. From about 12 hours from
now, the trunk should be considered frozen - that's starting at about
1700 UTC on 2004-09-01.

If your name isn't Anthony, Fred or Martin, please do NOT check in while
we're doing the release. Really. Really, really, really. I'm cc'ing
python-checkins as well this time, as a few folks missed this last time.
The trunk will stay frozen until about 6 hours or so after the release
is done - this makes it easier for me to do an emergency brown-paper-bag
release in the case of a cockup <wink>

Thanks,
Anthony
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Right curry considered harmful

Peter Harris <scav@...> writes:

> I think we'll see if partial() is a useful enough feature to be
> worth optimising once it actually makes it into a build and gets
> used.

We've now had a couple of comments regarding efficiency (Raymond
Hettinger made this point as well). As a C implementation exists, and
I can also imagine that this is the sort of thing that could get used
in performance-sensitive areas, why not use the C implementation?

Paul.
--

-- 
Ooh, how Gothic. Barring the milk.

_______________________________________________
Python-Dev mailing list
Python-Dev@...
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: <at> character choice and Jython (was: Rejecting the J2 decorators proposal)

Guido van Rossum wrote:

> So, what's next? In Python 2.4a3 (to be released this Thursday),
> everything remains as currently in CVS. For 2.4b1, I will consider a
> change of  <at>  to some other single character, even though I think that  <at> 
> has the advantage of being the same character used by a similar
> feature in Java. It's been argued that it's not quite the same, since
>  <at>  in Java is used for attributes that don't change semantics. But
> Python's dynamic nature makes that its syntactic elements never mean
> quite the same thing as similar constructs in other languages, and
> there is definitely significant overlap.

One issue with the ' <at> ' character choice is that in the context of
Jython things can get rather confusing and I mean beyond the fact
that the need of an "annotation" to get a static method will seem
rather bizarre to Java people. It somewhat put the burden on Jython to 
try to do the obvious thing:

Consider this java annotation definition (concretely these get compiled 
to interfaces):

public  <at> interface Author {
     String value() default "";
}

Now this potential Jython code:

import Author

classs A: # not inheriting from a Java class

Re: python/nondist/peps pep-0318.txt,1.30,1.31

On Wednesday 01 September 2004 11:02 am, anthonybaxter <at> users.sourceforge.net 
wrote:
 > (I'm not sure if the "Community Concensus" section should be trimmed
 > down radically now - it's a lot of words for a rejected form, and the
 > case for the form is still available on the web and in the mailing
 > list archives... opinions, anyone?)

I'm for leaving the text in; wikis are fragile, and this is a valuable bit of 
Python history.  A reader can ignore it if that's not interesting to them.

  -Fred

--

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

Re: python/nondist/peps pep-0318.txt,1.30,1.31

>  > (I'm not sure if the "Community Concensus" section should be trimmed
>  > down radically now - it's a lot of words for a rejected form, and the
>  > case for the form is still available on the web and in the mailing
>  > list archives... opinions, anyone?)
> 
> I'm for leaving the text in; wikis are fragile, and this is a valuable bit of
> Python history.  A reader can ignore it if that's not interesting to them.

+1

--

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
Ask me about gmail.

Re: Re: <at> character choice and Jython (was: Rejecting the J2 decorators proposal)

> One issue with the ' <at> ' character choice is that in the context of
> Jython things can get rather confusing and I mean beyond the fact
> that the need of an "annotation" to get a static method will seem
> rather bizarre to Java people. It somewhat put the burden on Jython
> to try to do the obvious thing:

[snipped example showing that Jython can do the right thing, at least
for Java-derived classes, with Java annotation interfaces]

> My point is basically that ' <at> ' will likely generate more user
> questions (which are time consuming) and expectations than a
> different character choice in Jython context.

Have you gotten cynical?  This should be counted as an argument *for*
the  <at>  character.

--

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
Ask me about gmail.
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: [Python-checkins] python/nondist/peps pep-0318.txt, 1.30, 1.31

    anthony> (I'm not sure if the "Community Concensus" section should be
    anthony> trimmed down radically now - it's a lot of words for a rejected
    anthony> form, and the case for the form is still available on the web
    anthony> and in the mailing list archives... opinions, anyone?)

I'd just refer to the wiki and Robert Brewer's J2 proposal.

Skip
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: (my) revisions to PEP318 finally done.

I've now updated the PEP to the current state of play,
which is pretty much done. If there's no significant
feedback, I'll post this to c.l.py tomorrow.

PEP: 318
Title: Decorators for Functions and Methods
Version: $Revision: 1.31 $
Last-Modified: $Date: 2004/09/01 15:02:22 $
Author: Kevin D. Smith, Jim Jewett, Skip Montanaro, Anthony Baxter
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Jun-2003
Python-Version: 2.4
Post-History: 09-Jun-2003, 10-Jun-2003, 27-Feb-2004, 23-Mar-2004, 30-Aug-2004,
2-Sep-2004

WarningWarningWarning
=====================

This document is meant to describe the decorator syntax and the
process that resulted in the decisions that were made.  It does not 
attempt to cover the huge number of potential alternative syntaxes, 
nor is it an attempt to exhaustively list all the positives and 
negatives of each form.

Abstract
========