Mailman 3 January 2002 - Python-Dev

Stale CVS lock
by Tim Peters 30 Jan '02

30 Jan '02

There appears to be a stale anoncvs lock in the Misc directory preventing checkins there (like NEWS); have opened an SF support request: http://sf.net/tracker/?func=detail&aid=510555&group_id=1&atid=200001

1 0

Stevens - still best for Unix system call programming?
by Skip Montanaro 29 Jan '02

29 Jan '02

Sorry for the off-topic post. I'm starting in on a little project to create an analog to fopen(3) and friends that provides the illusion of large file support even on systems that don't support large files, so I'm doing more fiddling with Unix system calls than I've done in awhile, and am looking for a little hardcover help. Is Richard Stevens' "Advanced Programming in the UNIX Environment" still the _sine qua non_ in this area? Thx, Skip P.S. OPN: it will have a Python binding...

2 1

release22-maint branch strangeness
by Fred L. Drake, Jr. 29 Jan '02

29 Jan '02

I've noticed some strangeness with the release22-maint branch. I made a documentation change there this morning, and CVS gave the change a really weird version number when I checked it in. Looking further, it looks like the previous checkin for that file (Doc/tut/tut.tex) has some strangeness as well. The branching tags are also pretty whacked. This is an excerpt of the "cvs log" for the file: ------------------------------------------------------------------------ RCS file: /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v Working file: tut.tex head: 1.158 branch: locks: strict access list: symbolic names: r212: 1.133.2.5 r212c1: 1.133.2.5 release22-mac: 1.156.4.1 release22-maint: 1.156.4.1.0.2 release22: 1.156.4.1 release22-branch: 1.156.0.4 release22-fork: 1.156 ------------------------------------------------------------------------ Note the revision number for release22-maint; it looks like it's a branch created from a branch created from a tag on a branch(!). All the while, I've been thinking that branches, once created, are independent (identified by the third component of the revision number for any given file). I still think they're supposed to be. Using a checkout created with the "-r release22-maint" options, I made two checkins, and the revision numbers & other metadata seem seriously strange: ------------------------------------------------------------------------ revision 1.156.4.1 date: 2001/12/21 03:48:33; author: fdrake; state: Exp; lines: +2 -2 branches: 1.156.4.1.2; Fix up some examples in the tutorial so we don't contradict our own advice on docstrings. This fixes SF bug #495601. ---------------------------- revision 1.156.4.1.2.1 date: 2002/01/29 14:54:18; author: fdrake; state: Exp; lines: +8 -1 Revise cheeseshop example so that the order of the keyword output is completely determined by the example; dict insertion order and the string hash algorithm no longer affect the output. This fixes SF bug #509281. ------------------------------------------------------------------------ For revision 1.156.4.1, note the strange branch number (1.156.4.1.2 -- too many components), and for revision 1.156.4.1.2.1 (too many components again!). The strange branch number on the first indicates that a branch was created from that revision (itself part of the release22-branch branch). Does anyone remember who created these branches? Or what commands were used to create them (using which branch/tag as the source of the working copy being used?)? This pretty much has Barry & I stumped at the moment, and we'd like to get this straightened out. The suspect branches are release22-maint, release22-mac. Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

2 1

Re: [Python-Dev] release22-maint branch strangeness
by Michael Hudson 29 Jan '02

29 Jan '02

"Fred L. Drake, Jr." <fdrake(a)acm.org> writes: > I've noticed some strangeness with the release22-maint branch. I made > a documentation change there this morning, and CVS gave the change a > really weird version number when I checked it in. Looking further, it > looks like the previous checkin for that file (Doc/tut/tut.tex) has > some strangeness as well. The branching tags are also pretty > whacked. This is an excerpt of the "cvs log" for the file: Looks to me like the release22 tag for Doc/tut/tut.tex was set on the release22-branch, not the trunk. This is not what happened for, e.g. configure.in. Quite how this happened, or what (if anything) we should do about it, is another question entirely. cvs status -v is quite handy here. $ cvs status -v Doc/tut/tut.tex | head -n 20 =================================================================== File: tut.tex Status: Needs Patch Working revision: 1.157 Repository revision: 1.158 /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: r212 (revision: 1.133.2.5) r212c1 (revision: 1.133.2.5) release22-mac (revision: 1.156.4.1) release22-maint (branch: 1.156.4.1.2) release22 (revision: 1.156.4.1) release22-branch (branch: 1.156.4) release22-fork (revision: 1.156) r22c1-mac (revision: 1.156) r22c1 (revision: 1.156) r22rc1-branch (branch: 1.156.2) $ cvs status -v configure.in | head -n 20 =================================================================== File: configure.in Status: Up-to-date Working revision: 1.289 Repository revision: 1.289 /cvsroot/python/python/dist/src/configure.in,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: r212 (revision: 1.215.2.7) r212c1 (revision: 1.215.2.7) release22-mac (revision: 1.288) release22-maint (branch: 1.288.6) release22 (revision: 1.288) release22-branch (branch: 1.288.4) release22-fork (revision: 1.288) r22c1-mac (revision: 1.288) r22c1 (revision: 1.288) r22rc1-branch (branch: 1.288.2) Did different people create the release22 tags in different bits of the tree? Cheers, M. -- The "of course, while I have no problem with this at all, it's surely too much for a lesser being" flavor of argument always rings hollow to me. -- Tim Peters, 29 Apr 1998

2 1

Ann: Stackless 2.2 pre-alpha is ready!
by Christian Tismer 29 Jan '02

29 Jan '02

Dear Python community, Stackless Python 2.2 is alive! This is the first alpha version. It does not have any relevant changes to the interpreter. It does not have any limitation on switching. Support code for uthreads and coroutines is already implemented. And as announced, it is completely platform dependant. This version works on MS Win32 only. I'm going to support other platforms if I can find some sponsors. Let me say, it works great! There is no single problem. This technique can be applied to any software, any interpreter, provided I can support the platform. *** This is a critical phase for Stackless! *** *** I Am Asking For Corporate Sponsorships. *** I don't know how things should go on. I could turn it into a commercial product, Stackless is enabled enough for this. Or I could continue to keep it open-sourced, provided there is enough sponsorship. This decision has to be discussed in the next two weeks, after that I will decide. Anyway: Please check it out of CVS and have a look, it is sooo small code now. cvs -d :pserver:anonymous@tismer.com:/home/cvs co stackless/src You might want to add -z9 since this is a full Python 2.2 checkout. In this state, I don't prepare a distribution. You can build Stackless from CVS. I also put a copy of my python22.dll here for testing: http://www.stackless.com/slpython22.zip It is just almost 2 percent slower on my W2k machine. The trick is to avoid stack switching as much as possible. I do it only on every 8th recursion level, which is more than what's usual. >>> def f(n): ... if n:f(n-1) ... >>> import sys >>> sys.setrecursionlimit(100000+10) >>> f(100000) >>> ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net/ 14163 Berlin : PGP key -> http://wwwkeys.pgp.net/ PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com/ _______________________________________________ Stackless mailing list Stackless(a)www.tismer.com http://www.tismer.com/mailman/listinfo/stackless

2 2

Using LXR for Python CVS Source Code ?
by M.-A. Lemburg 26 Jan '02

26 Jan '02

Browing the Mozilla web-site I came across I nice utility which enables cross-referenced source code browsing: LXR http://lxr.mozilla.org/mozilla/source/webtools/lxr/ For example, see e.g. http://lxr.mozilla.org/mozilla/source/expat/xmlparse/hashtable.c I suppose setting this up on python.org would ease referencing Python C sources a lot and also provide a nice tool for learning to understand the internal structures of the interpreter. What do you think ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

4 5

Nouvelles acquisitions / New online
by AaZbooks.com 25 Jan '02

25 Jan '02

Chers bibliophiles, Cette semaine nous vous proposons nos nouvelles acquisitions (plus de 500). Vous y trouverez par exemple: SAINTE BEUVE C.A. MADAME DESBORDES VALMORE SA VIE ET SA CORRESPONDANCE Edition originale (rare). Ouvrage contenant un catalogue de Michl Lévy, libraire éditeur, de 36 p.Broché.IN8. LEVY Paris 1870 Réf.: 18337 (107,00 ) ou bien encore: FALLET RENE BANLIEUE SUD EST Roman. Edition originale (rare). DOMAT Paris 1947 Réf.: 18313 (45,00 ) En vous souhaitant bonne lecture Toute l'équipe de AaZbooks.com ------------------------------------------------------- Dear bibliophiles, This week new online 500 books, for example: SAINTE BEUVE C.A. MADAME DESBORDES VALMORE SA VIE ET SA CORRESPONDANCE Edition originale (rare). Ouvrage contenant un catalogue de Michl Lévy, libraire éditeur, de 36 p.Broché.IN8. LEVY Paris 1870 Réf.: 18337 (107,00 ) FALLET RENE BANLIEUE SUD EST Roman. Edition originale (rare). DOMAT Paris 1947 Réf.: 18313 (45,00 ) Regards AaZbooks' Team ---------------------------------------------------------- AaZbooks.com - BP N°1 - La grande Bruyère - F72320 St-Maixent Tel.: +33 (0)2 43 71 00 70 - Fax: +33 (0)2 43 71 29 16 http://www.aazbooks.com ---------------------------------------------------------- Pour vous désinscrire cliquez ci-dessous http://www.aazbooks.com\lnews\desinscription.php

1 0

Re: [Python-Dev] Unicode strings as filenames
by Neil Hodgson 24 Jan '02

24 Jan '02

[Replacing the other mail destinations as I didn't do a reply all last time so python-dev dropped off. You may want to resend your last mail to python-dev.] > I don't think we can drop W9x support for Python 2.3, although I'm > still waiting for comments on dropping W3.1 support... I wouldn't want to drop either. > > Sounds good to me. I'm moving back towards not using the 'utf-8' system > > encoding but rather checking of Unicode arguments and handling them > > explicitly even at the cost of code expansion. > > That is very good. I don't know what is best for the file name; > perhaps it is acceptable to encode it with the file system default > encoding (even if it ends up having question marks in it). Programs > relying on the file name to be correct are broken, IMO. My thinking now is that there are two modules here, fileobject and posixmodule which should be handled differently. posixmodule is just a library with calls and no state. IIRC there used to be multiple modules, one per OS, and the correct one was chosen and called os. I think it is perfectly reasonable for there to be an extra 'ntos' module that just works on NT that treats all arguments as Unicode (coercing up using the current locale when given narrow strings) and always calling the wide APIs. It would contain the same methods (when available) as os. NT specific code can use it directly and sufficiently interested portable client code could say something like if nt: filesys = ntos else: filesys = os This hides away all the code bloat from posix code, ensures there are no regressions in posix while developing and debugging ntos, and allows ntos to just convert all arguments into wide strings without worrying about 9x. Maybe call the module osu if there may be implementations on other OS's like OS X. Could have an enquiry method in the module if osu.working: filesys = osu else: filesys = os fileobject is more complex because it holds two strings as state. The mode can probably be assumed to be ASCII so can be left as a narrow string (although it does have to be widened to call _wfopen) but the name is more complex as some client code may just know that it is always a narrow string and thus die if given a file with a wide name. > Looks very good indeed. When producing patches, you might want to > check line endings: currently, your files are a mix of LF only (which > was there before) and CRLF. OK. > In open_the_file, you are still checking for utf-8; that should be > removed also. It seems that open_the_file will always get an > initialized filed, so passing name does not seem to be necessary: one > could look at f_name. OK. So why are the name and mode passed when they are already available? > I suggest that f_name stays as a byte string for the moment, and > open_the_file gets an optional "original name" or "unicode name" > argument, whatever is more convenient. If that is given, open_the_file > should consider it, else it should fall back to f_name. If this is done then the unicode name should also be available as a field of the object as those mangled "z??.html" strings are totally useless. I'm feeling more like making f_name be wide now but I'd expect some opposition now from backwards compatibility advocates. > In posixmodule, I cannot see the move towards passing Unicode objects > directly, either - I guess you were talking about a future plan, > above. Yes, I'm thinking ahead of the coding. Seeing where I'm already going or about to go wrong. > I cannot see the rationale for wfuncNull - wouldn't passing > passing NULL as a function pointer be sufficient as well? Yes, must get used to thinking in C again. I don't think I have written C for 8 years. WTF can't I declare variables just when I need them <incoherent cursing and mumbling...> Neil

6 36

VERBOSE and DEBUG conventions.
by Steven Majewski 24 Jan '02

24 Jan '02

Py_DebugFlag is used for debugging the Python parser. Py_VerboseFlag is used for debugging and tracing imports. (and in some places it wants Py_VerboseFlag > 1 (more than one "-v") for output) Are there any conventions on which to use for other debugging output? (Or did Guido have any particular conventions in mind when he added them? ) Right now, I'm using Py_VerboseFlag to also trigger logging of message sends in pyobjc. Stealing this flag for another use isn't a problem here because [1] the logging goes to a /tmp file, so I don't have to turn off import tracing -- the two logging streams don't get mixed together, and [2] it only functions when you import pyobjc, so it's not going to get in someone else's use. But I may need to add other debug and log output to my module and I'ld like to do it in the least suprising manner if possible. -- Steve Majewski

4 6

largeint.h and ver.h gone from VS.NET
by David Ascher 24 Jan '02

24 Jan '02

As mentioned in: http://groups.google.com/groups?q=largeint.h&hl=en&selm=epfeXXOYBHA.2060%40… largeint.h is gone from the VisualStudio compiler as of the VisualStudio.NET release. Python's build currently fails without the workaround mentioned in that posting. Furthermore, the file "ver.h" used in python_nt.rc appears to be gone as well. Not sure why we needed it. Gettinr dir fo it seems to have no ill effect =). Anyone remember what it's for? I'm having sre problems in the test suite though, which have pretty wide-ranging effects. Is someone else looking at the patches needed for VS.NET, or should I keep digging? --david

4 6