Mailman 3 August 2004 - Python-Dev

pie-thon redux
by Anthony Baxter 07 Aug '04

07 Aug '04

As a break from the decorator thread, NTK (www.ntk.net) had this writeup of the Pie-Thon. It amused me. >> HARD NEWS << Perl hullabaloos Last year, DAN SUGALSKI, lead developer of the forthcoming Perl6 virtual machine, Parrot, bet the Python developers that run Python faster on the fledgling VM - and the creator of Python could throw a pie at him at the next OSCON if he didn't. He didn't; the pie-ing was duly arranged. As everyone knows, while Perlites are chaotic/good trickster archetypes who love such events, Pythonistas are peaceful, have-their-glasses-on-a-little-string types, like hobbits or the Dutch. In the end, Guido van Rossum refused to throw the pie, and instead offered to share it as food with the Perl developers. Nothing, of course, could have been more guaranteed to throw Perlsters into violent rage. An extended period of acrimonious bargaining followed, in which the Perl crew grew more and more insistent that their own chief developer be humiliated, with many walking out of the session, muttering about "all foreplay and no sex". Later, the Perl faction took it upon themselves to pie Sugalski - much, we are sure, to the shock of the pacifistic Pythonese, who may well have planned that using their psychomathematics and indented whitespace necromancy all along. (Mind you, that didn't stop Guido finally joining in. Feel the punctuation rising in you, Guido!) http://www.sidhe.org/~dan/blog/archives/000372.html - Dan gets last laugh later in August -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

3 2

PEP-0006, Bug Fix Releases
by Anthony Baxter 07 Aug '04

07 Aug '04

This is an updated version of PEP-0006, the Bugfix Release PEP. Unless I hear some screams, I'll be checking this into CVS. It more accurately reflects the current state of the bugfix process. (This has been sitting in my todo list for a while) PEP: 6 Title: Bug Fix Releases Version: $Revision: 1.10 $ Author: aahz(a)pobox.com (Aahz), anthony(a)interlink.com.au (Anthony Baxter) Status: Active Type: Informational Created: 15-Mar-2001 Post-History: 15-Mar-2001 18-Apr-2001 Abstract Python has historically had only a single fork of development, with releases having the combined purpose of adding new features and delivering bug fixes (these kinds of releases will be referred to as "feature releases"). This PEP describes how to fork off maintenance, or bug fix, releases of old versions for the primary purpose of fixing bugs. This PEP is not, repeat NOT, a guarantee of the existence of bug fix releases; it only specifies a procedure to be followed if bug fix releases are desired by enough of the Python community willing to do the work. Motivation With the move to SourceForge, Python development has accelerated. There is a sentiment among part of the community that there was too much acceleration, and many people are uncomfortable with upgrading to new versions to get bug fixes when so many features have been added, sometimes late in the development cycle. One solution for this issue is to maintain the previous feature release, providing bug fixes until the next feature release. This should make Python more attractive for enterprise development, where Python may need to be installed on hundreds or thousands of machines. Prohibitions Bug fix releases are required to adhere to the following restrictions: 1. There must be zero syntax changes. All .pyc and .pyo files must work (no regeneration needed) with all patch releases forked off from a feature release. 2. There must be zero pickle changes. 3. There must be no incompatible C API changes. All extensions must continue to work without recompiling in all patch releases in the same fork as a feature release. Breaking any of these prohibitions requires a BDFL proclamation (and a prominent warning in the release notes). Not-Quite-Prohibitions Where possible, bug fix releases should also: 1. Have no new features. The purpose of a bug fix release is to fix bugs, not add the latest and greatest whizzo feature from the HEAD of the CVS root. 2. Be a painless upgrade. Users should feel confident that an upgrade from 2.x.y to 2.x.(y+1) will not break their running systems. This means that, unless it is necessary to fix a bug, the standard library should not change behaviour, or worse yet, APIs. Helping the Bug Fix Releases Happen Here's a few pointers on helping the bug fix release process along. 1. Backport bug fixes. If you fix a bug, and it seems appropriate, port it to the CVS branch for the current bug fix release. If you're unwilling or unable to backport it yourself, make a note in the commit message. 2. If you're not sure, ask. Ask the person managing the current bug fix releases if they think a particular fix is appropriate. 3. If there's a particular bug you'd particularly like fixed in a bug fix release, jump up and down and try to get it done. Do not wait until 48 hours before a bug fix release is due, and then start asking for bug fixes to be included. Version Numbers Starting with Python 2.0, all feature releases are required to have a version number of the form X.Y; patch releases will always be of the form X.Y.Z. The current feature release under development is referred to as release N; the just-released feature version is referred to as N-1. In CVS, the bug fix releases happen on a branch. For release 2.x, the branch is named 'release2x-maint'. For example, the branch for the 2.3 maintenance releases is release23-maint Procedure The process for managing patch releases is modeled in part on the cl Tsystem [1]. The Patch Czar is the counterpart to the BDFL for patch releases. However, the BDFL and designated appointees retain veto power over individual patches. As individual patches get contributed to the feature release fork, each patch contributor is requested to consider whether the patch is a bug fix suitable for inclusion in a patch release. If the patch is considered suitable, the patch contributor will mail the SourceForge patch (bug fix?) number to the maintainers' mailing list. In addition, anyone from the Python community is free to suggest patches for inclusion. Patches may be submitted specifically for patch releases; they should follow the guidelines in PEP 3 [2]. In general, though, it's probably better that a bug in a specific release also be fixed on the HEAD as well as the branch. The Patch Czar decides when there are a sufficient number of patches to warrant a release. The release gets packaged up, including a Windows installer, and made public. If any new bugs are found, they must be fixed immediately and a new patch release publicized (with an incremented version number). Bug fix releases are expected to occur at an interval of roughly six months. This is only a guideline, however - obviously, if a major bug is found, a bugfix release may be appropriate sooner. In general, only the N-1 release will be under active maintenance at any time. That is, during Python 2.4's development, Python 2.3 gets bugfix releases. Patch Czar History Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4. Barry Warsaw is the Patch Czar for 2.2.3. Guido van Rossum is the Patch Czar for 2.2.2. Michael Hudson is the Patch Czar for 2.2.1. Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3. Thomas Wouters is the Patch Czar for 2.1.1. Moshe Zadka is the Patch Czar for 2.0.1. History This PEP started life as a proposal on comp.lang.python. The original version suggested a single patch for the N-1 release to be released concurrently with the N release. The original version also argued for sticking with a strict bug fix policy. Following feedback from the BDFL and others, the draft PEP was written containing an expanded patch release cycle that permitted any previous feature release to obtain patches and also relaxed the strict bug fix requirement (mainly due to the example of PEP 235 [3], which could be argued as either a bug fix or a feature). Discussion then mostly moved to python-dev, where BDFL finally issued a proclamation basing the Python patch release process on Tcl's, which essentially returned to the original proposal in terms of being only the N-1 release and only bug fixes, but allowing multiple patch releases until release N is published. Anthony Baxter then took this PEP and revised it, based on lessons from the 2.3 release cycle. References [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html [2] PEP 3, Guidelines for Handling Bug Reports, Hylton http://www.python.org/peps/pep-0003.html [3] PEP 235, Import on Case-Insensitive Platforms, Peters http://www.python.org/peps/pep-0235.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End:

3 2

Re: [Python-Dev] Decorators: vertical bar syntax
by Simon Percivall 07 Aug '04

07 Aug '04

On 2004-08-06, at 21.34, Raymond Hettinger wrote: >> | just isn't a good sign. > > How about the exclamation point? > > > Raymond > > If "@" is controversial enough to be a no-no, "!" gets +1 from me.

1 0

PEP 0008 confusion - here it is, but don't use it?
by Skip Montanaro 07 Aug '04

07 Aug '04

>From Raymond's checkin: Programming Recommendations - Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Pyrex, Psyco, and such). For example, do not rely on CPython's efficient implementation of in-place string concatenation for statements in the form a+=b or a=a+b. Those statements run more slowly in Jython. In performance sensitive parts of the library, the ''.join() form should be used instead. This will assure that concatenation occurs in linear time across various implementations. I'm a bit confused. Why bother to speed up s+=t if we aren't supposed to use it? Skip

6 6

Another decorator syntax idea
by barnesc＠engr.orst.edu 07 Aug '04

07 Aug '04

Another decorator syntax idea Using Guido's example: -------------------- @ Symbols -------------------- class C(object): @staticmethod @funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]", \ status="experimental", author="BDFL") def longMethodNameForEffect(longArgumentOne=None, longArgumentTwo=42): """This method blah, blah. It supports the following arguments: - longArgumentOne -- a string giving ... - longArgumentTwo -- a number giving ... blah, blah. """ raise NotYetImplemented -------------------- decorate keyword -------------------- class C(object): def longMethodNameForEffect(longArgumentOne=None, longArgumentTwo=42): decorate: staticmethod funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]", \ status="experimental", author="BDFL")] """This method blah, blah. It supports the following arguments: - longArgumentOne -- a string giving ... - longArgumentTwo -- a number giving ... blah, blah. """ raise NotYetImplemented Pros: - Doesn't hide the function name behind @ garbage. - 'decorate' is easier to look at than '@'. - 'decorate' is more meaningful to most readers than '@'. - Block structure isolates decorators from surrounding code, making them more readable. - Indentation rules are consistent with the rest of Python. Cons: - Not pear shaped. - Connelly

1 0

318: Annotation background
by Neil Hodgson 06 Aug '04

06 Aug '04

It appears from the discussion and PEP that there has not been a lot of experience here with the Java and C# analogues of decorators. In Java, especially server edition features like Entity Java Beans, there is a requirement for large volumes of supporting files for a system. Some of these are Java files defining a set of related classes and some are XML files defining how these can be used. For example, say I have two database tables, Master and Detail, defined as expected. These will need to be defined as Java classes, with fields corresponding to the database columns. Extra fields will be needed for transient attributes, some of which will be defined by the developer and others by the infrastructure such as dirty bits, transaction IDs, and remote connection handles. As well as the main class, there is a need for derived classes such as a remote interface that looks like the class, a value class that contains the fields (or a subset of the fields) that can be sensibly copied together to a remote system, and views of the data that turn relational artifacts like keys into a more object-oriented form, such as providing a pointer from a Detail to a Master or having the Detail records appear to be a list on the Master object. Maintaining all these files requires far too much work and you will always be coping with updates that forgot one file. Then along came XDoclet [1]. XDoclet uses doc comment tags to move the information about associated source and XML files into the main class file. For example, /** * @ejb.bean * type="CMP" * name="Master" */ public abstract class MasterEJB implements EntityBean { /** * @ejb.value-object * aggregate="example.vo.DetailValue" * aggregate-name="Details" * type="Collection" * @ejb.relation * name="Master-Detail" */ public abstract Collection getDetails(); public abstract void setDetails(Collection details); However, comments should be for documentation, not implementation code, and these 'comments' are now some of the most important and most difficult to maintain parts of the source. So there was a desire to move this into the main language where there could be more consistency and earlier checking for correctness. This has led to JSR 175 [2] which allows @ annotations to be applied directly to identifiers rather than indirectly through preceding comments. [1] http://xdoclet.sourceforge.net/xdoclet/index.html [2] http://www.jcp.org/aboutJava/communityprocess/review/jsr175/ Neil

1 0

Would like to add Edward Loper as a Python developer
by Tim Peters 06 Aug '04

06 Aug '04

Edward Loper runs the Natural Language Toolkit project on SF: http://nltk.sourceforge.net/ and the Epydoc project: http://epydoc.sourceforge.net/ More importantly <wink>, he's a heavy doctest user and has lots of ideas for improving it. doctest's implementation has grown unwieldy, and is in need of refactoring. Jim (Fulton), Edward and I intend to do a lot there over the coming two weeks, and giving Edward commit privileges would simplify and speed the process. This is intended to be limited to doctest changes. Are there objections? If anyone else is interested in contributing to doctest surgery, let me know. A Wiki area might be a decent way to coordinate. Ideas already on the table include restructuring for plugability (e.g., there's no sane way for you to take over doctest error reporting now, but restructuring to do much more via (overridable) class methods is a sane alternative); new gimmicks like notation for "there's a blank line here in this expected output"; a sane way to get into the debugger upon a doctest failure (right now, if you try, doctest is still swallowing stdout, so you can't see what you're doing! Jeremy did some quick hacks around that for Zope3 already); better support for writing "whole file" doctests (tutorial narratives liberally illustrated with Python examples -- Zope3 is finding these very helpful); and documenting all the additions that snuck into Python 2.3.

5 5

Re: Call for defense of @decorators
by Andrew Durdin 06 Aug '04

06 Aug '04

(This is a repeat of a message on python-list/c.l.p in the "Tweaking @decorator syntax" thread, but I thought it was applicable to post it here, based on how I understand Guido's message. However, this is not a defense but an attack on @decorators, and based not on whether it looks ugly or not but that it is unclear.) On 5 Aug 2004 16:04:00 -0700, Sandy Norton <sandskyfly(a)hotmail.com> wrote in c.l.p, thread "Tweaking @decorator syntax": > Here are some more variations. > > Please copy/paste the code below into your favourite python editor and see > how each syntactical variation of the decorator code reads, and how quickly > you grok its structure and meaning. *snip examples* Of the examples above, I find the "Nested, 'decorate' keyword syntax" by far the most clear. It has the following features (in no particular order) which I find attractive: 1. The nesting makes it abundantly clear what the decoration applies to, namely the function definitions at the next indentation level. And the colon at the end of the "decorate" line is consistent with all other Python keywords which result in another indentation level (def, if, class, etc.) -- which is one reason why I dislike the "nested @decorator" and "nested |decorator|" options. The "Nested, minimal decorator syntax" has indentation, but lacks clarity: it appears merely to be one or a sequence of function calls followed inexplicably by a nested block. 2. The nesting makes it convenient to apply the same decoration to multiple functions, which I guess will be fairly common wherever decorators are used. 3. It doesn't involve adding any additional punctuation to the language. I strongly believe that the general lack of punctuation contributes greatly towards Python's readability. 4. The comma-separated list of decorators allows for more compactness without sacrificing legibility when multiple decorators are used. Whereas I quite dislike the @ syntax, for almost opposite reasons: 5. In appearance it looks like a special kind of statement; and it is not at all obvious to me that it is rather a kind of attribute or modifier of the following function definition. I don't know of any other construction in Python that performs a similar, unmarked (i.e. non-explicit) modification of the following statement. So to me the @syntax comes across as extremely un-Pythonic (by that I mean radically inconsistent with the conventions of the rest of the language). For this same reason, I dislike all the proposed syntaxes which involve placing something before the "def" without a subsequent indented block. 6. When using the same sets of decorators for multiple functions/methods in the same module/class, the @ syntax is inconvenient, as the decorators need to be repeated for each function. (Of course, the current (2.3) syntax to achieve the same result is similarly inconvenient; the @ syntax adds no benefit in this regard, but the "decorate" syntax does). 7. The @ syntax adds more punctuation to Python's syntax: a Bad Thing. Despite the risk of breaking compatibility with some older programs, I firmly believe that adding new keywords is a much better idea in general than adding new punctuation, because (a) keywords are more readable (especially to those unfamiliar with them), and (b) there is a very limited supply of punctuation marks on the keyboard, but a very large supply of words. 8. When using multiple decorators, each appears on a separate line. This not only confuses things with respect to point 5 above (e.g. does the first decorator somehow decorate the second, or do both apply to the function?), but also is IMO unnecessarily lengthy, as each line has the same basic purpose; In analogy, the latter is similar to the difference between x = 1 y = 2 z = 3 and x, y, z = 1, 2, 3 where a compact representation is possible and suitable where the three variables are relating to the same purpose within the program. -- Andrew Durdin

5 5

Re: [Python-Dev] Questions about '@' in pep 318
by Roman Suzi 06 Aug '04

06 Aug '04

Hello, I think @ before def are unacceptable because they aren't too Pythonic and thus break style and aestetics of Python. If we absolutely need those decorators, I propose to use existing construct which has some resemblance with other places of Python: def func(x, y, z) % decorator: ... and def func(x, y, z) % (decorator1, decorator2, ...): ... this has a meaning of "applying" decorators to the function (method). And it has minimal impact on readability. Sincerely yours, Roman A.Suzi -- - Petrozavodsk - Karelia - Russia - mailto:rnd@onego.ru -

5 6

Merging Python and Gtk...
by Paul Sheer 06 Aug '04

06 Aug '04

Now that Gtk is supported on Windows, X, and framebuffers, would it not be worthwhile to consider packaging Python and Gtk together? Python+Gtk is a killer combination, and I see the only argument against Python's mainstream adoption to be its lack of a standardized widget library as portable and eligant as Python itself. If Python and Gtk installed as one package, this requirement would be met. At the moment, getting Python to work with Gtk on an arbitrary Unix system requires compiling no less than 14 tar balls from source. There are also huge overlaps in functionality, like Python and Gtk image support (jpeg etc.) comments? -paul Paul Sheer . . . . . . . . . . . . . . . . . Tel . . +27 (0)21 6869634 Email . . . http://2038bug.com/email.gif . . . . . . . . . . . . . . . . http://www.icon.co.za/~psheer . . . . . . . . . http://rute.2038bug.com L I N U X . . . . . . . . . . . . . . . . The Choice of a GNU Generation

3 2