Mailman 3 March 2001 - Python-Dev

Release 2.0.1: Heads Up
by Moshe Zadka 26 Mar '01

26 Mar '01

Greetings, earthlings! As Guido said in the last conference, there is going to be a bugfix release of Python 2.0, Python 2.0.1. Originally meant to be only a license bugfix release, comments in the Python community have indicated a need for a real bugfix release. PEP 6[1] has been written by Aahz, which outlines a procedure for such releases. With Guido's blessing, I have volunteered to be the Patch Czar (see the PEP!) for the 2.0.1 release. In this job, I intend to be feared and hated throughout the Python community -- men will tremble to hear the sounds of my footsteps...err...sorry, got sidetracked. This is the first Python pure bugfix release, and I feel a lot of weight rests on my shoulders as to whether this experiment is successful. Since this is the first bugfix release, I intend to be ultra-super-conservative. I can live with a release that does not fix all the bug, I am very afraid of a release that breaks a single person's code. Such a thing will give Python bugfix releases a very bad reputation. So, I am going to be a very strict Czar. I will try to follow consistent rules about which patches to integrate, but I am only human. I will make all my decisions in the public, so they will be up for review of the community. There are a few rules I intend to go by 1. No fixes which you have to change your code to enjoy. (E.g., adding a new function because the previous API was idiotic) 2. No fixes which have not been applied to the main branch, unless they are not relevant to the main branch at all. I much prefer to get a pointer to an applied patch or cvs checkin message then a fresh patch. Of course, there are cases where this is impossible, so this isn't strict. 3. No fixes which have "stricter checking". Stricter checking is a good thing, but not in bug fix releases. 4. No fixes which have a reasonable chance to break someone's code. That means that if there's a bug people have a good change of counting on, it won't be fix. 5. No "improved documentation/error message" patches. This is stuff that gets in people's eyeballs -- I want bugfix upgrade to be as smooth as possible. 6. No "internal code was cleaned up". That's a good thing in the development branch, but not in bug fix releases. Note that these rules will *not* be made more lenient, but they might get stricter, if it seems such strictness is needed in order to make sure bug fix releases are smooth enough. However, please remember that this is intended to help you -- the Python using community. So please, let me know of bugfixes that you need or want in Python 2.0. I promise that I will consider every request. Note also, that the Patch Czar is given very few responsibilities --- all my decisions are subject to Guido's approval. That means that he gets the final word about each patch. I intend to post a list of patches I intend to integrate soon -- at the latest, this Friday, hopefully sooner. I expect to have 2.0.1a1 a week after that, and further schedule requirements will follow from the quality of that release. Because it has the dual purpose of also being a license bugfix release, schedule might be influenced by non-technical issues. As always, Guido will be the final arbitrator. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org

1 0

Re: [Python-Dev] test_coercion failing
by Jack Jansen 26 Mar '01

26 Mar '01

Well, it turns out that disabling fused-add-mul indeed fixes the problem. The CodeWarrior manual warns that results may be slightly different with and without fused instructions, but the example they give is with operations apparently done in higher precision with the fused instructions. No word about nonstandard behaviour for +0.0 and -0.0. As this seems to be a PowerPC issue, not a MacOS issue, it is something that other PowerPC porters may want to look out for too (does AIX still exist?). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

sandbox?
by Moshe Zadka 26 Mar '01

26 Mar '01

I remember there was the discussion here about sandbox, but I'm not sure I understand the rules. Checkin without asking permission to sandbox ok? Just make my private dir and checkin stuff? Anybody who feels he can speak with authority is welcome ;-) -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org

2 2

Re: [Python-Dev] Re: Alleged deprecation of shutils
by Jack Jansen 26 Mar '01

26 Mar '01

> > You say that now, but as such cross-system servers become more common, > > we should expect the tools to deal with them well, rather than > > complain "the other guy doesn't play by our rules". > > So, a goal for 2.2: getting moving/copying/deleting of files and > directories working properly (ie. using native APIs) on all major > supported platforms, with all the legwork that implies. Well, if we want to support the case Guido sketches, a machine on one platform being fileserver for another platform, things may well be bleak. For instance, most Apple-fileservers for Unix will use the .HSResource directory to store resource forks and the .HSancillary file to store mac file-info, but not all do. I didn't try it yet, but from what I've read MacOSX over NFS uses a different scheme. But, all that said, if we look only at a single platform the basic functionality of shutils should work. There's a Mac module (macostools) that has most of the functionality, but of course not all, and it has some extra as well, and not all names are the same (shutil compatibility wasn't a goal when it was written). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

WANTED: chairs for next Python conference
by Guido van Rossum 26 Mar '01

26 Mar '01

I'm looking for chairs for the next Python conference. At least the following positions are still open: BOF chair (new!), Application track chair, Tools track chair. (The Apps and Tools tracks are roughly what the Zope and Apps tracks were this year.) David Ascher is program chair, I am conference chair (again). We're in the early stages of conference organization; Foretec is looking at having it in a Southern city in the US, towards the end of February 2002. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: FW: FW: [Python-Dev] Simple generator implementation
by Uche Ogbuji 25 Mar '01

25 Mar '01

> [Uche Ogbuji] > > Quite interesting. I brought up this *exact* point at the > > Stackless BOF at IPC9. I mentioned that the immediate reason > > I was interested in Stackless was to supercharge the efficiency > > of 4XSLT. I think that a stackless 4XSLT could pretty much > > annihilate the other processors in the field for performance. > > Hmm. I'm interested in clarifying the cost/performance boundaries of the > various approaches. I don't understand XSLT (I don't even know what it is). > Do you grok the difference between full-blown Stackless and Icon-style > generators? To a decent extent, based on reading your posts carefully. > The correspondent I quoted believed the latter were on-target > for XSLT work, and given the way Python works today generators are easier to > implement than full-blown Stackless. But while I can speak with some > confidence about the latter, I don't know whether they're sufficient for what > you have in mind. Based on a discussion with Christian at IPC9, they are. I should have been more clear about that. My main need is to be able to change a bit of context and invoke a different execution path, without going through the full overhead of a function call. XSLT, if written "naturally", tends to involve huge numbers of such tweak-context-and-branch operations. > If this is some flavor of one-at-time tree-traversal algorithm, generators > should suffice. > > class TreeNode: > # with self.value > # self.children, a list of TreeNode objects > ... > def generate_kids(self): # pre-order traversal > suspend self.value > for kid in self.children: > for itskids in kid.generate_kids(): > suspend itskids > > for k in someTreeNodeObject.generate_kids(): > print k > > So the control-flow is thoroughly natural, but you can only suspend to your > immediate invoker (in recursive traversals, this "walks up the chain" of > generators for each result). With explicitly resumable generator objects, > multiple trees (or even general graphs -- doesn't much matter) can be > traversed in lockstep (or any other interleaving that's desired). > > Now decide <wink>. Suspending only to the invoker should do the trick because it is typically a single XSLT instruction that governs multiple tree-operations with varied context. At IPC9, Guido put up a poll of likely use of stackless features, and it was a pretty clear arithmetic progression from those who wanted to use microthreads, to those who wanted co-routines, to those who wanted just generators. The generator folks were probably 2/3 of the assembly. Looks as if many have decided, and they seem to agree with you. -- Uche Ogbuji Principal Consultant uche.ogbuji(a)fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python

10 11

distutils change breaks code, Pyfort
by Martin v. Loewis 24 Mar '01

24 Mar '01

> The requirement of a version argument to the distutils command > breaks Pyfort and many of my existing packages. These packages are > not intended for use with the distribution commands and a package > version number would be meaningless. So this is clearly an incompatible change. According with the procedures in PEP 5, there should be a warning issued before aborting setup. Later (major) releases of Python, or distutils, could change the warning into an error. Nevertheless, I agree with the change in principal. Distutils can and should enforce a certain amount of policy; among this, having a version number sounds like a reasonable requirement - even though its primary use is for building (and uploading) distributions. Are you saying that Pyfort does not have a version number? On SF, I can get version 6.3... Regards, Martin

3 2

RFC: PEP243: Module Repository Upload Mechanism
by Sean Reifschneider 24 Mar '01

24 Mar '01

Included below is the version of PEP243 after it's initial round of review. I welcome any feedback. Thanks, Sean ============================================================================ PEP: 243 Title: Module Repository Upload Mechanism Version: $Revision$ Author: jafo-pep(a)tummy.com (Sean Reifschneider) Status: Draft Type: Standards Track Created: 18-Mar-2001 Python-Version: 2.1 Post-History: Discussions-To: distutils-sig(a)python.org Abstract For a module repository system (such as Perl's CPAN) to be successful, it must be as easy as possible for module authors to submit their work. An obvious place for this submit to happen is in the Distutils tools after the distribution archive has been successfully created. For example, after a module author has tested their software (verifying the results of "setup.py sdist"), they might type "setup.py sdist --submit". This would flag Distutils to submit the source distribution to the archive server for inclusion and distribution to the mirrors. This PEP only deals with the mechanism for submitting the software distributions to the archive, and does not deal with the actual archive/catalog server. Upload Process The upload will include the Distutils "PKG-INFO" meta-data information (as specified in PEP-241 [1]), the actual software distribution, and other optional information. This information will be uploaded as a multi-part form encoded the same as a regular HTML file upload request. This form is posted using ENCTYPE="multipart/form-data" encoding [RFC1867]. The upload will be made to the host "modules.python.org" on port 80/tcp (POST http://modules.python.org:80/swalowpost.cgi). The form will consist of the following fields: distribution -- The file containing the module software (for example, a .tar.gz or .zip file). distmd5sum -- The MD5 hash of the uploaded distribution, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). pkginfo (optional) -- The file containing the distribution meta-data (as specified in PEP-241 [1]). Note that if this is not included, the distribution file is expected to be in .tar format (gzipped and bzipped compreesed are allowed) or .zip format, with a "PKG-INFO" file in the top-level directory it extracts ("package-1.00/PKG-INFO"). infomd5sum (required if pkginfo field is present) -- The MD5 hash of the uploaded meta-data, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). platform (optional) -- A string representing the target platform for this distribution. This is only for binary distributions. It is encoded as "<os_name>-<os_version>-<platform architecture>-<python version>". signature (optional) -- A OpenPGP-compatible signature [RFC2440] of the uploaded distribution as signed by the author. This may be used by the cataloging system to automate acceptance of uploads. protocol_version -- A string indicating the protocol version that the client supports. This document describes protocol version "1". Return Data The status of the upload will be reported using HTTP non-standard ("X-*)" headers. The "X-Swalow-Status" header may have the following values: SUCCESS -- Indicates that the upload has succeeded. FAILURE -- The upload is, for some reason, unable to be processed. TRYAGAIN -- The server is unable to accept the upload at this time, but the client should try again at a later time. Potential causes of this are resource shortages on the server, administrative down-time, etc... Optionally, there may be a "X-Swalow-Reason" header which includes a human-readable string which provides more detailed information about the "X-Swalow-Status". If there is no "X-Swalow-Status" header, or it does not contain one of the three strings above, it should be treated as a temporary failure. Example: >>> f = urllib.urlopen('http://modules.python.org:80/swalowpost.cgi') >>> s = f.headers['x-swalow-status'] >>> s = s + ': ' + f.headers.get('x-swalow-reason', '<None>') >>> print s FAILURE: Required field "distribution" missing. Sample Form The upload client must submit the page in the same form as Netscape Navigator version 4.76 for Linux produces when presented with the following form: <H1>Upload file</H1> <FORM NAME="fileupload" METHOD="POST" ACTION="swalowpost.cgi" ENCTYPE="multipart/form-data"> <INPUT TYPE="file" NAME="distribution"><BR> <INPUT TYPE="text" NAME="distmd5sum"><BR> <INPUT TYPE="file" NAME="pkginfo"><BR> <INPUT TYPE="text" NAME="infomd5sum"><BR> <INPUT TYPE="text" NAME="platform"><BR> <INPUT TYPE="text" NAME="signature"><BR> <INPUT TYPE="hidden" NAME="protocol_version" VALUE="1"><BR> <INPUT TYPE="SUBMIT" VALUE="Upload"> </FORM> Platforms The following are valid os names: aix beos debian dos freebsd hpux mac macos mandrake netbsd openbsd qnx redhat solaris suse windows yellowdog The above include a number of different types of distributions of Linux. Because of versioning issues these must be split out, and it is expected that when it makes sense for one system to use distributions made on other similar systems, the download client will make the distinction. Version is the official version string specified by the vendor for the particular release. For example, "2000" and "nt" (Windows), "9.04" (HP-UX), "7.0" (RedHat, Mandrake). The following are valid architectures: alpha hppa ix86 powerpc sparc ultrasparc Status I currently have a proof-of-concept client and server implemented. I plan to have the Distutils patches ready for the 2.1 release. Combined with Andrew's PEP-241 [1] for specifying distribution meta-data, I hope to have a platform which will allow us to gather real-world data for finalizing the catalog system for the 2.2 release. References [1] Metadata for Python Software Package, Kuchling, http://python.sourceforge.net/peps/pep-0241.html [RFC1867] Form-based File Upload in HTML http://www.faqs.org/rfcs/rfc1867.html [RFC2440] OpenPGP Message Format http://www.faqs.org/rfcs/rfc2440.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: -- A smart terminal is not a smart*ass* terminal, but rather a terminal you can educate. -- Rob Pike Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

1 0

test_minidom crash
by Moshe Zadka 24 Mar '01

24 Mar '01

The bug is in Lib/xml/__init__.py __version__ = "1.9".split()[1] I don't know what it was supposed to be, but .split() without an argument splits on whitespace. best guess is "1.9".split('.') ?? -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org

4 12

test_minidom crash
by Martin v. Loewis 24 Mar '01

24 Mar '01

[Moshe] > I just went through the core grepping for '$Revision' and it seems > this is the only place this happens -- all the other places either > put the default version (RCS cruft and all), or are smart about > handling it. You have not search carefully enough. pyexpat.c has char *rev = "$Revision: 2.44 $"; ... PyModule_AddObject(m, "__version__", PyString_FromStringAndSize(rev+11, strlen(rev+11)-2)); > I haven't seen *any* complaints about this, so is it possible that > they don't mind having the $Revision: ... $ strings in there? The problem is that they don't know the problems they run into (yet). E.g. if they import pyexpat.c into their tree, they get 1.1.1.1; even after later imports, they still get 1.x. Now, PyXML currently decides that the Python pyexpat is not good enough if it is older than 2.39. In turn, they might get different code being used when installing out of their CVS as compared to installing from the source distributions. That all shouldn't cause problems, but it would probably help if source releases continue to use -kv; then likely every end-user will get the same sources. I'd volunteer to review the core sources (and produce patches) if that is desired. Regards, Martin

2 1