From guido@python.org Sun Oct 1 06:31:43 2000 From: guido@python.org (Guido van Rossum) Date: Sun, 01 Oct 2000 00:31:43 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> I'm considering to issue a release candidate before the final 2.0 release. I'd like to poll opinions about this (we haven't had a PythonLabs group meeting about this yet). The importance of a release candidate (RC) is twofold: we announce it widely so it (hopefully) gets a lot of testing -- necessary since a lot of things have changed again since beta2; and we impose a checkin stop once the RC is out, with exceptions only allowed by the release manager to fix showstopper bugs found in the RC. This will hopefully avoid a disaster like we had with the buggy last-minute changes in beta2 (for which I take full responsibility). If the idea of a RC sounds okay, I'd like to propose to release it on October 5. The final release would still be on October 10, or perhaps 1-2 days later. Much less than a week between the RC and the final release is not good because it doesn't give testers enough time to try out the RC; much more than a week is bad because the developers get antsy when they can't check in their changes! This means that any current bug reports and patches that aren't in the RC, WON'T BE FIXED in the final release! Think about it. This is a good thing, so we won't be able to screw up the final release at the last moment. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Sun Oct 1 13:06:48 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 1 Oct 2000 14:06:48 +0200 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500 References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <20001001140648.A12812@xs4all.nl> On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote: > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for some lunch/breakfast ;) I would be in favor if the str() output were only used to display something to a user, but that's not the case. And too many people are under the impression that the 'print' handler is the same as the 'str' handler to make that distinction now, I'm afraid. My main gripe with this change is that it makes str() for container objects unreliable... Strings are a special case, but class-instances are not -- so something like UserString will be displayed without quotes. I don't like the idea of sometimes doing 'str' and sometimes doing 'repr'. I understand what it's trying to solve, but I don't think that's a worse inconsistency than the one this change introduces. It's also easy to explain: 'str(list or dict) is the same as repr(list or dict)'. The new phrase would be something like 'str(list or dict) calls str() on the objects it contains, except for string and unicode objects.'. And even that breaks when you mix in instances that wrap a container. A list containing a UserList containing a set of (unicode-)strings would display the strings without quotes. And you can't see that the second container is a UserList. I also don't think this change should be made between the final beta and 2.0. Jeremy, don't let him ruin your feature freeze! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jim@digicool.com Sun Oct 1 15:32:27 2000 From: jim@digicool.com (Jim Fulton) Date: Sun, 01 Oct 2000 10:32:27 -0400 Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR) Message-ID: <39D74AFB.322E5187@digicool.com> If a select-based (or, presumably, poll-based) server wants to use signals for anything other than shutdown (e.g. closing and reopening log files, rereading configs, etc.), then, on some platforms, a select call can fail with an "interrupted system call" (EINTR) error that should be ignored. The asyncore main loop should check for this error in it's select call and the select module should make this error easier to check for. In Python 1.5.2, the medusa select call can be changed from r,w,e = select.select (r,w,e, timeout) to: while 1: try: r,w,e = select.select (r,w,e, timeout) except select.error, v: if v[0] != EINTR: raise else: break I presume that this works in Python 1.6/2.0, but I haven't tried it yet? This depends on the structure of select.error values and requires that we get EINTR from somewhere. (What should the value be on NT?) I wonder if there should be an InterruptedSystemCall exception somewhere that select raises in this case? At a minimum, code like the above should be added to asyncore. Thoughts? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From rushing@nightmare.com Sun Oct 1 20:07:59 2000 From: rushing@nightmare.com (Sam Rushing) Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT) Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR) In-Reply-To: <39D74AFB.322E5187@digicool.com> References: <39D74AFB.322E5187@digicool.com> Message-ID: <14807.35727.423642.721873@seattle.nightmare.com> Jim Fulton writes: > The asyncore main loop should check for this error in it's select > call and the select module should make this error easier to check > for. It might go better into the event_loop function, which I think of as a more user-serviceable part. [for example, the default loop vs. the one in medusa/event_loop.py that supports schedulable events] > I presume that this works in Python 1.6/2.0, but I > haven't tried it yet? > > This depends on the structure of select.error values > and requires that we get EINTR from somewhere. (What > should the value be on NT?) If it's a big problem, I guess we could use a different default event_loop() function for win32 vs. unix. > At a minimum, code like the above should be added to asyncore. > > Thoughts? This has been asked for several times, I agree it'd be nice to have at least a note in the docs.. -Sam From loewis@informatik.hu-berlin.de Sun Oct 1 20:13:41 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> > I'd like to poll opinions about this (we haven't had a PythonLabs > group meeting about this yet). YES! I was hoping somebody would propose such a thing; I was quite concerned that check-in procedures are still that liberate. To report how similar projects operate: In gcc, a CVS release branch is created at some point in time (usually months before the release). When the code is declared frozen, all changes to the release branch have to go through the release manager. After the release, "important" changes to the mainline branch are manually propagated to the release branch for subminor releases. Regards, Martin From dkwolfe@pacbell.net Sun Oct 1 22:23:03 2000 From: dkwolfe@pacbell.net (Dan Wolfe) Date: Sun, 01 Oct 2000 14:23:03 -0700 Subject: [Python-Dev] FW: regarding the Python Developer posting... Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net> >> [commented out code that was causing seg fault in test_sre.py] >you could try adding a Mac OS clause to the recursion limit stuff >in Modules/_sre.c: > >#if !defined(USE_STACKCHECK) >#if defined(...whatever's needed to detect Max OS X...) [....] > >replace "...whatever...", and try larger values than 5000 (or smaller, >if necessary. 10000 is clearly too large for your platform). > >(alternatively, you can increase the stack size. maybe it's very small >by default?) the stack size is quite small by default - 512K. After some testing I was able to figure out that it fails around 440 recursions... probably a bit too small in comparison to the other *nixes.... but then I'll defer to the experts in sre. I was reading the August developer archives on the getrlimit and since that seem to be available, it's probably the right way to implement the stack check on Mac OS X. Sure I can increase the default stack size - just a simple limit -h before running it in the shell... I let it run until about 7K recursions... even then it was only about 11MB and bumping the stack up by 30K or so per recursion... and I still had nearly 100MB free... and places to go. :-) I'm going to write a bug report against Mac OS X and we'll see what happens. In the meantime, you can hard code it to 440 and it will pass the test... I've placed a patch on sourceforge that give the initial support for detecting Mac OS X as part of the make file but I still have to figure out how/where you defined MS_WIN64.... - Dan From barry@scottb.demon.co.uk Sun Oct 1 23:19:21 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 1 Oct 2000 23:19:21 +0100 Subject: [Python-Dev] Patch to avoid conflict with older versions of Python. In-Reply-To: Message-ID: <000b01c02bf5$a5edf070$060210ac@private> I still think that Python needs to fix the problem with the API between the core and the extensions. That way all the version checking would work for Windows and Unix. But since that approach has been rejected I'd take any change to python that reduces support calls. BArry > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Mark Hammond > Sent: 29 September 2000 02:36 > To: python-dev@python.org > Subject: [Python-Dev] Patch to avoid conflict with older versions of > Python. > > > Hi all, > I'd like some feedback on a patch assigned to me. It is designed to > prevent Python extensions built for an earlier version of Python from > crashing the new version. > > I haven't actually tested the patch, but I am sure it works as advertised > (who is db31 anyway?). > > My question relates more to the "style" - the patch locates the new .pyd's > address in memory, and parses through the MS PE/COFF format, locating the > import table. If then scans the import table looking for Pythonxx.dll, and > compares any found entries with the current version. > > Quite clever - a definite plus is that is should work for all old and > future versions (of Python - dunno about Windows ;-) - but do we want this > sort of code in Python? Is this sort of hack, however clever, going to > some back and bite us? > > Second related question: if people like it, is this feature something we > can squeeze in for 2.0? > > If there are no objections to any of this, I am happy to test it and check > it in - but am not confident of doing so without some feedback. > > Thanks, > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From mal@lemburg.com Mon Oct 2 08:36:49 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:36:49 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <39D83B11.C1DE9EE8@lemburg.com> Martin von Loewis wrote: > > > I'd like to poll opinions about this (we haven't had a PythonLabs > > group meeting about this yet). > > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. > > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. +1 I think this is very good approach to the problem which we should consider to apply to Python too. BTW, could the nightly snapshots of the CVS tree that Jeremy installed be made official ? This would be a great way to attract more beta-tester since not everyone is willing to first set CVS on their machine just to download the current Python development version. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin@loewis.home.cs.tu-berlin.de Mon Oct 2 08:39:09 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:39:09 +0200 Subject: [Python-Dev] What is --with-next-framework Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> I've been trying to understand how --with-next-framework is supposed to work, and on what systems it is supposed to work - with little success. =46rom what I understand, it will create a python2.0.dylib, and it will pass that to the linker when linking extension modules. Fine. What confuses me is the snippet in Modules/getpath.c, where it somehow assumes that the Python library will live in an unversioned lib directory relative to the location of the Python framework. How is that supposed to work? Is anybody here willing to claim that this code is not entirely broken? Regards, Martin From mal@lemburg.com Mon Oct 2 08:51:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:51:37 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <39D83E89.62F57D79@lemburg.com> Guido van Rossum wrote: > > When we changed floats to behave different on repr() than on str(), we > briefly discussed changes to the container objects as well, but > nothing came of it. > > Currently, str() of a tuple, list or dictionary is the same as repr() > of those objects. This is not very consistent. For example, when we > have a float like 1.1 which can't be represented exactly, str() yields > "1.1" but repr() yields "1.1000000000000001". But if we place the > same number in a list, it doesn't matter which function we use: we > always get "[1.1000000000000001]". > > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. > > Is it too late to check this in? Another negative consequence would > be that for user-defined or 3rd party extension objects that have > different repr() and str(), like NumPy arrays, it might break some > code -- but I think this is not very likely. -1 I don't think that such a change is really worth breaking code which relies on the current output of repr(list) or str(list). As the test script from Fredrik for the Unicode database showed there are some very subtle implications to changes in str() and repr() -- e.g. in the mentioned case the hash value would change. Also, if I understand the patch correctly, str(list) would be almost the same as '[' + ', '.join(map(str, entries)) + ']' and '[' + ', '.join(map(repr, entries)) + ']' for repr(). While this may seem more transparent, I think it will cause problems in practice: e.g. for large data buffers, str(list) would now return the contents of the buffers rather than just an abstract note about a buffer containing the memory mapped data of file xyz.txt. As consequence, you'd suddenly get a few MBs of output instead of a 100 char string... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin@loewis.home.cs.tu-berlin.de Mon Oct 2 08:48:37 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:48:37 +0200 Subject: [Python-Dev] Usage of --with- configure options Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> I noticed that Python's configure.in does not follow the autoconf style for using --enable- options. The autoconf documentation says # Some packages require, or can optionally use, other software packages # which are already installed. The user can give `configure' command # line options to specify which such external software to use. The # options have one of these forms: # # --with-PACKAGE[=ARG] # --without-PACKAGE ... # If a software package has optional compile-time features, the user # can give `configure' command line options to specify whether to compile # them. The options have one of these forms: # # --enable-FEATURE[=ARG] # --disable-FEATURE So --with- options should be used for integrating 3rd party libraries, --enable- options for features that that can be independently turned on or off. I'd conclude that the following options are provided incorrectly in Python 2.0: --with-pydebug (should be --enable-pydebug), --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something that should change? Regards, Martin From guido@python.org Mon Oct 2 12:30:45 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:30:45 -0500 Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200." <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com> > I noticed that Python's configure.in does not follow the autoconf > style for using --enable- options. The autoconf documentation says > > # Some packages require, or can optionally use, other software packages > # which are already installed. The user can give `configure' command > # line options to specify which such external software to use. The > # options have one of these forms: > # > # --with-PACKAGE[=ARG] > # --without-PACKAGE > ... > # If a software package has optional compile-time features, the user > # can give `configure' command line options to specify whether to compile > # them. The options have one of these forms: > # > # --enable-FEATURE[=ARG] > # --disable-FEATURE > > So --with- options should be used for integrating 3rd party libraries, > --enable- options for features that that can be independently turned > on or off. > > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? I noticed that too. (Arguably also for --with-thread?) I think it's a forgiveable sin against the autoconf style guide, and not worth the work of fixing it. Either way the autoconf --with- or --enable- syntax is stupid because it doesn't check for spelling errors in the options. The rationale for that is that some folks like to pass in unsupported options to a whole tree of configure scripts. I think that stinks, but what can I do. This would make the fix even more work, because we would have to trap --with*-pydebug and --with*-cycle-gc to give an error message, else developers used to the old syntax would never notice the change. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Mon Oct 2 12:35:40 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:35:40 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200." <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com> > I've been trying to understand how --with-next-framework is supposed > to work, and on what systems it is supposed to work - with little > success. > > From what I understand, it will create a python2.0.dylib, and it will > pass that to the linker when linking extension modules. Fine. > > What confuses me is the snippet in Modules/getpath.c, where it somehow > assumes that the Python library will live in an unversioned lib > directory relative to the location of the Python framework. How is > that supposed to work? Is anybody here willing to claim that this code > is not entirely broken? It's most likely broken. Which suggests that nobody has tried it in a *looooooong* time. I have no idea what the --with-next-framework option does, and I have no idea what a NeXT framework is. Why are we still trying to support NeXT? Isn't it completely obsolete? I propose to rip out --with-next-framework and be done with it. If you feel --with-next-framework is worth having, feel free to propose platform-specific fixes to getpathp.c. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Mon Oct 2 14:22:19 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT) Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? Yes, if only to make it more consistent with existing practice. A harder one to change would be --enable-threads, because we've used that for so long already. Perhaps --enable-threads should be added, and use that in the README instead of --with-threads. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fredrik@pythonware.com Mon Oct 2 14:41:21 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 15:41:21 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF> guido wrote: > If the idea of a RC sounds okay Sure does. > I'd like to propose to release it on October 5. Hmm. My plan was to to work on the remaining SRE issues on Saturday, leaving Sunday-Tuesday for final "burn-in"... From petrilli@amber.org Mon Oct 2 15:14:23 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 10:14:23 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> Message-ID: <20001002101423.A18958@trump.amber.org> Guido van Rossum [guido@python.org] wrote: > > I've been trying to understand how --with-next-framework is supposed > > to work, and on what systems it is supposed to work - with little > > success. > > > > From what I understand, it will create a python2.0.dylib, and it will > > pass that to the linker when linking extension modules. Fine. > > > > What confuses me is the snippet in Modules/getpath.c, where it somehow > > assumes that the Python library will live in an unversioned lib > > directory relative to the location of the Python framework. How is > > that supposed to work? Is anybody here willing to claim that this code > > is not entirely broken? > > It's most likely broken. Which suggests that nobody has tried it in a > *looooooong* time. I have no idea what the --with-next-framework > option does, and I have no idea what a NeXT framework is. A NeXT Framework is a way of building software on NeXTstep/OpenStep machines, and as far as I can tell, it continues largely unmodified on MacOS X (which is more OpenStep than MacOS at many layers). We just got our development copies of MacOS X here at Digital Creations, so we can take a look, but... as I recall, Jeffrey Shell wasn't able to get Python running without using these options. > Why are we still trying to support NeXT? Isn't it completely > obsolete? I know of a few dozen large organizations still on OpenStep, and with MacOS X I'd say it's far frrom obsolete, if anything it's more likely than ever to be a"strong platform". > I propose to rip out --with-next-framework and be done with it. If > you feel --with-next-framework is worth having, feel free to propose > platform-specific fixes to getpathp.c. I think it should be auto-detected, there's just no reason not to. The uname of a MacOS X box is quite different than a Mac OX 9 box (which has no uname :-). Hopefully we can get a chance to look at this at work this week. Chris -- | Christopher Petrilli | petrilli@amber.org From thomas@xs4all.net Mon Oct 2 18:23:19 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 2 Oct 2000 19:23:19 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700 References: <200010021553.IAA01251@slayer.i.sourceforge.net> Message-ID: <20001002192319.C12812@xs4all.nl> On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200 > Modified Files: > readline.c > Log Message: > Supporting rl_library_version is more trouble than it's worth -- > readline doesn't have it before readline 2.2 and there's no > compile-time way to find out which readline version is in use. But we can detect whether readline has rl_library_version during runtime, and #ifdef it ;) I think the readline version info is useful enough to warrant the extra #define and #ifdef... I can whip it up tonight, if the autoconf check is desired ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@python.org Mon Oct 2 19:54:31 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 13:54:31 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400." <20001002101423.A18958@trump.amber.org> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com> [Argument for the continued viability of OpenStep noted.] > I think it should be auto-detected, there's just no reason not to. > The uname of a MacOS X box is quite different than a Mac OX 9 box > (which has no uname :-). Hopefully we can get a chance to look at > this at work this week. Hm... That might not get there in time for the 2.0 Release Candidate, and after that it's an absolute code freeze (with exceptions only for showstopper bugfixes) until 2.0 is released. I guess MacOS X itself is still in beta, so we can afford to require the creation of additional patches to fully support it after 2.0 is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From petrilli@trump.amber.org Mon Oct 2 18:56:03 2000 From: petrilli@trump.amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 13:56:03 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com> Message-ID: <20001002135603.C18958@trump.amber.org> Guido van Rossum [guido@python.org] wrote: > [Argument for the continued viability of OpenStep noted.] > > > I think it should be auto-detected, there's just no reason not to. > > The uname of a MacOS X box is quite different than a Mac OX 9 box > > (which has no uname :-). Hopefully we can get a chance to look at > > this at work this week. > > Hm... That might not get there in time for the 2.0 Release Candidate, > and after that it's an absolute code freeze (with exceptions only for > showstopper bugfixes) until 2.0 is released. > > I guess MacOS X itself is still in beta, so we can afford to require > the creation of additional patches to fully support it after 2.0 is > released. MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's a 2.1 planned sometime around there, which I believe there is, then it'd be fine to roll it into that level in my opinion. Chris -- | Christopher Petrilli | petrilli@amber.org From guido@python.org Mon Oct 2 20:15:37 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:15:37 -0500 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200." <20001001140648.A12812@xs4all.nl> References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com> I guess Thomas has settled the fate of my str() patch -- UserString won't be dealt with properly. I hereby withdraw the patch. (I'm not sure what Marc-Andre means by buffer objects whose str() is long but whose repr() is short, but it's probably a similar issue.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Mon Oct 2 20:19:24 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:19:24 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200." <200010011913.VAA01107@pandora.informatik.hu-berlin.de> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com> > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. Good. We will have a release candidate then. > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. I am reluctant to use CVS branches (my experience with the branch for 1.6 suggests again that this is not at all smooth). About the timing for the release candidate (RC): I think we need a week +/- two days between the RC and the final release; this is needed to make sure that the RC is actually tried out by enough people and that the bug reports (if any) have been processed. I believe we can refrain from checkin in for a week but not much longer. Fredrik Lundh mentions that he can't get his final batch of SRE patches in before Saturday. So the only realistic timing is to do the RC on Monday (Oct 9) and the final release a week later (Oct 16). Everybody okay with this? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Mon Oct 2 19:35:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 20:35:27 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com> Message-ID: <39D8D56F.F279B9E5@lemburg.com> Guido van Rossum wrote: > > I guess Thomas has settled the fate of my str() patch -- UserString > won't be dealt with properly. I hereby withdraw the patch. > > (I'm not sure what Marc-Andre means by buffer objects whose str() is > long but whose repr() is short, but it's probably a similar issue.) > Example for the record: >>> b = buffer('long string') >>> b >>> l = [b] >>> l [] >>> [str(b)] ['long string'] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nas@arctrix.com Mon Oct 2 12:48:59 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 04:48:59 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> Message-ID: <20001002044859.A9639@glacier.fnational.com> On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote: > So the only realistic timing is to do the RC on Monday (Oct 9) > and the final release a week later (Oct 16). > > Everybody okay with this? What is going to be the fate of the GC? There are currently two reported bugs which I have been unable to reproduce. If its going to be disabled for 2.0 then it should be disabled in the beta release. Neil From Fredrik Lundh" Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > Details: Split gives TypeError when called as a method of compiled > regular expression object with maxsplit as keyword argument. > This error is only in sre, pre is OK. > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > >>> import re > >>> patt = re.compile(' ') > >>> list = patt.split("a b c",50) # OK > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > >>> list = patt.split("a b c",maxsplit=50) # ERROR > Traceback (most recent call last): > File "", line 1, in ? > TypeError: this function takes no keyword arguments > > >>> import pre > >>> patt = pre.compile(' ') > >>> list = patt.split("a b c",maxsplit=50) # OK is this really a bug? should users expect to be able to use keyword arguments anywhere? From guido@python.org Mon Oct 2 21:09:32 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:09:32 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200." <20001002192319.C12812@xs4all.nl> References: <200010021553.IAA01251@slayer.i.sourceforge.net> <20001002192319.C12812@xs4all.nl> Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com> > But we can detect whether readline has rl_library_version during runtime, > and #ifdef it ;) I think the readline version info is useful enough to > warrant the extra #define and #ifdef... I can whip it up tonight, if the > autoconf check is desired ;P Actually, I'm not sure what difference the readline version makes -- why would you need it? Also, I'm not sure that the configure check is enough -- it's possible that readline lives in a non-standard place where configure can't find it but ppointed to by the Setup file. I think it's just not worth it. Please don't. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Mon Oct 2 21:18:57 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:18:57 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200." <003e01c02ca4$a7e2ef20$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com> > http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > > > Details: Split gives TypeError when called as a method of compiled > > regular expression object with maxsplit as keyword argument. > > This error is only in sre, pre is OK. > > > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > > >>> import re > > >>> patt = re.compile(' ') > > >>> list = patt.split("a b c",50) # OK > > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > > >>> list = patt.split("a b c",maxsplit=50) # ERROR > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: this function takes no keyword arguments > > > > >>> import pre > > >>> patt = pre.compile(' ') > > >>> list = patt.split("a b c",maxsplit=50) # OK > > is this really a bug? should users expect to be able to use > keyword arguments anywhere? Unclear, but the names were documented, and it worked before (when pattern objects were Python instances) -- so who knows how much code there's lying around that assumes this. Well, we know it's more than zero, because the bug report came from soemone who ran into this. :-) Can we at PythonLabs help by adding keyword arguments to all of the _sre.c functions? I presume it's a pretty straightforward change. --Guido van Rossum (home page: http://www.python.org/~guido/) From Fredrik Lundh" <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid> > Can we at PythonLabs help by adding keyword arguments to all of the > _sre.c functions? I presume it's a pretty straightforward change. if anyone can post (or point me to) an example showing how to use the keyword API, I can take if from there. From guido@python.org Mon Oct 2 22:06:00 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 16:06:00 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200." <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com> > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. Grep the Modules directory for PyArg_ParseTupleAndKeywords. It's used in the mmap, parser, pyexpat and sha modules. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Mon Oct 2 21:04:30 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. This is documented in the Extending & Embedding manual. The parser module (Modules/parsermodule.c) uses this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH@ActiveState.com Mon Oct 2 23:37:13 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Tue, 3 Oct 2000 09:37:13 +1100 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF> Message-ID: > guido wrote: > > If the idea of a RC sounds okay > > Sure does. > > > I'd like to propose to release it on October 5. > > Hmm. My plan was to to work on the remaining SRE issues on > Saturday, leaving Sunday-Tuesday for final "burn-in"... Also FYI, I intend applying the previous-version-crash patch tomorrow (or late today), so those extra few days for /F would also prevent this patch going out _too_ green... Mark. From fdrake@beopen.com Tue Oct 3 01:23:13 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT) Subject: [Python-Dev] Development HTML docs online Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com> I've set things up so I can easily "publish" the Python documentation online without actually building a release. It's not entirely automatic, but I can push it online easily, so you'll be able to see what I'm doing. It can include more than just what's in CVS, but I try not to have too much waiting to checkin at once. Check it out: ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Tue Oct 3 03:36:03 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 21:36:03 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST." <20001002044859.A9639@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com> > What is going to be the fate of the GC? There are currently two > reported bugs which I have been unable to reproduce. If its > going to be disabled for 2.0 then it should be disabled in the > beta release. Good point. I see only the one that's assigned to you (reported by Rob Hooft): http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341 What's the other? Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe that's a clue? Does he also use threads? Is he willing to send his entire program over? (If you don't have time, we may have time at PythonLabs!) Anyway, I'm not yet ready to disable GC by default -- that's sensible but also defeats the purpose... --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@python.net Tue Oct 3 05:08:45 2000 From: gward@python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: <20001003000845.A1812@beelzebub> Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ And now for something completely different. From fredrik@pythonware.com Tue Oct 3 09:52:37 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 10:52:37 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <200010030832.BAA05615@slayer.i.sourceforge.net> Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF> > Change first line to #!/usr/bin/env python (really just to test check-in). hmm. cgi.py is a CGI script. according to the Python FAQ, CGI scripts should use an explicit path, not /usr/bin/env: "Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter." (since this comes up over and over again, maybe someone should add a comment to the file?) From ping@lfw.org Tue Oct 3 11:15:13 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: On Tue, 3 Oct 2000, Fredrik Lundh wrote: > > Change first line to #!/usr/bin/env python (really just to test check-in). > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > scripts should use an explicit path, not /usr/bin/env: > > "Note -- *don't* do this for CGI scripts. The $PATH variable > for CGI scripts is often very minimal, so you need to use the > actual absolute pathname of the interpreter." The $PATH variable for CGI scripts may be minimal, but minimal as it is, Python should still be on it. Using /usr/bin/python works for half the people and /usr/local/bin/python works for the other half... /usr/bin/env is supposed to work for everyone. If this has already been argued soundly to death, i'm happy to back out the change and add a comment. It was a meaningless change for me anyway. Oh well. Anyway, i'm glad CVS commit *finally* works for me. Sorry for the extra hassle. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From nas@arctrix.com Tue Oct 3 07:41:18 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 23:41:18 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001002234118.A11108@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > What's the other? Some people from Origin Systems have reported a crash. They are using Python in a large application (probably related to the Ultima Online game). I will put the bug report in the database today. They are using a custom version of cPickle that may be causing the problem. It is an instance object which is causing the trouble. My malloc() == NULL patch for classobject.c did not fix things. They still haven't reported back regarding the cPickle fix. > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. > Maybe that's a clue? I don't think _tkinter does anything special (unlike cPickle and new). > Does he also use threads? His interpreter has threads enabled it seems. Maybe I should get him to test without threads, assuming he doesn't require them. > Is he willing to send his entire program over? From his bug report I understood that he was unwilling to make it available. New that I re-read the report I see that he did not say that. I will ask him. > Anyway, I'm not yet ready to disable GC by default -- that's sensible > but also defeats the purpose... Okay. I think I've found a possible problem. When I set threshold0 to 1 in the C code, weird things start happening. I'm looking into it. Neil From bwarsaw@beopen.com Tue Oct 3 14:49:23 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: <14809.58339.707476.273418@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> The $PATH variable for CGI scripts may be minimal, but minimal KY> as it is, Python should still be on it. Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes $PATH from the environment before calling python with a compiled in absolute path. Which leads me to ask: how often are you calling cgi.py directly anyway? That'll just run the text() function which isn't terribly useful other than to debug your cgi setup. Usually you're calling some other module that imports cgi, and in that case this line won't have any effect. And besides, it's not very safe to call a script directly so I'd recommend a wrapper program anyway. I'd say this one is rather harmless. -Barry From guido@python.org Tue Oct 3 15:58:00 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 09:58:00 -0500 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST." References: Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com> > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > > scripts should use an explicit path, not /usr/bin/env: > > > > "Note -- *don't* do this for CGI scripts. The $PATH variable > > for CGI scripts is often very minimal, so you need to use the > > actual absolute pathname of the interpreter." > > The $PATH variable for CGI scripts may be minimal, but minimal > as it is, Python should still be on it. Using /usr/bin/python > works for half the people and /usr/local/bin/python works for > the other half... /usr/bin/env is supposed to work for everyone. No. On a typical Unix system (Linux perhaps excluded), /usr/local/bin is not on the default $PATH. > If this has already been argued soundly to death, i'm happy to > back out the change and add a comment. It was a meaningless > change for me anyway. I backed it out for you. It really has been argued to death. Glad CVS works for you! --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Tue Oct 3 16:37:21 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT) Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <20001002234118.A11108@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001002234118.A11108@glacier.fnational.com> Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: [GvR writes:] >> Anyway, I'm not yet ready to disable GC by default -- that's >> sensible but also defeats the purpose... NS> Okay. I think I've found a possible problem. When I set NS> threshold0 to 1 in the C code, weird things start happening. NS> I'm looking into it. I agree that it isn't too useful to ship the garbage collector, but have it turned off. On the other hand, we're going to get a lot of unhappy users if GC bugs cause inexplicable crashes in large programs. It would be hard to sell Python for important applications, e.g. long-running server processes, if there was a small possibility that the program could crash through no fault of its own. Jeremy From bwarsaw@beopen.com Tue Oct 3 16:39:19 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in Message-ID: <14809.64935.157146.681813@anthem.concentric.net> I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with the zlib rpm installed, all I need to enable this module is the following line: zlib zlibmodule.c -lz but Setup.in has this suggestion, which I think is too hard for people to figure out what to do: zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz The standard build options will already include the right -I and -L flags for this to Just Work. I suggest we make the common case (Linux?) simple, and let others figure out what the right -I and -L flags are. I submit that even if they /do/ have to handcraft -I and -L, the defaults in Setup.in are pretty meaningless. A worthy change? For 2.0 final? -Barry From guido@python.org Tue Oct 3 18:31:47 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 12:31:47 -0500 Subject: [Python-Dev] Canvas.Canvas.bbox() return value Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com> Hi Fredrik, Re this bug report: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 I can take care of the Canvas issues, but I need your advice on bbox(). He's right that the bbox() method the Canvas class in the Canvas module is different from all other bbox() methods: it returns a tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple (x,y1,x2,y2). Do you think it's worth not breaking existing code here??? --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@beopen.com Tue Oct 3 17:34:51 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c Message-ID: <14810.2731.466997.243906@anthem.concentric.net> I've found a small memory leak in unicodeobject.c, in the way _PyUnicode_Fini() shuts down. Take a loop such as: -------------------- snip snip -------------------- #include "Python.h" int main(int argc, char** argv) { int i; while (1) { Py_Initialize(); Py_Finalize(); } return 0; } -------------------- snip snip -------------------- and you'll find that unicode_empty leaks. This is because, while _PyUnicode_Fini() decrefs unicode_empty, it never actually gets freed. Instead it gets placed on the already freed unicode_freelist! See _PyUnicode_Free() for why. I've come up with the following nasty hack to force unicode_empty to really be freed in _PyUnicode_Fini(). Maybe there's a better way to do this. Note that moving the decref of unicode_empty to above the freeing of unicode_freelist didn't plug the memory leak for me (but I'm quite tired so maybe I missed something! ;} ). Below is the proposed patch. -Barry -------------------- snip snip -------------------- Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -u -r2.64 unicodeobject.c --- unicodeobject.c 2000/09/26 05:46:01 2.64 +++ unicodeobject.c 2000/10/03 16:31:32 @@ -5234,7 +5234,11 @@ PyObject_DEL(v); } unicode_freelist = NULL; - unicode_freelist_size = 0; + /* XXX This is a hack to force the freeing of unicode_empty's memory. + * Otherwise, it'll get placed on the already freed free list. + */ + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; Py_XDECREF(unicode_empty); unicode_empty = NULL; + unicode_freelist_size = 0; } From Fredrik Lundh" Message-ID: <001801c02d5c$801d0300$766940d5@hagrid> > Hi Fredrik, > > Re this bug report: > > http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 > > I can take care of the Canvas issues, but I need your advice on > bbox(). He's right that the bbox() method the Canvas class in the > Canvas module is different from all other bbox() methods: it returns a > tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple > (x,y1,x2,y2). > > Do you think it's worth not breaking existing code here??? no idea -- I don't think I've ever used that module (!). (I'd deprecate the entire module if I were in charge -- there are better ways to put objects on the canvas) but in case someone's using it, it's probably best to leave things as they are... From thomas@xs4all.net Tue Oct 3 18:07:11 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 3 Oct 2000 19:07:11 +0200 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400 References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <20001003190711.D12812@xs4all.nl> On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote: > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > A worthy change? For 2.0 final? What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by default, for all modules, if those directories already exist ? Because zlib is not the only module that has this problem. On BSDI and Solaris, the same problem exists for curses, readline and gdbm, at least. If you are installing in a completely separate tree, for whatever reason, either those include/lib directories won't exist, they won't contain anything useful, or they will contain the actual libraries you want to link with, anyway ;-P And if you are installing in a 'standard' tree, like /usr, /usr/local, /usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be there, too. If you don't fall under any of these cases, you'll have to do what you have to do now, figure it out by hand. I don't think changing the zlib line alone is going to matter much; it stops working 'out of the box' for the slightly-less common case of non-linux platforms (and not even all linux platforms ! There is no reason why a distribution would install zlib in /usr.) I would prefer adding a comment that clarifies the -I/-L lines, over removing them altogether, if we aren't including $prefix/include and $exec_prefix/lib by default. I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Tue Oct 3 18:13:39 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5 In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net> References: <200010031651.JAA06853@slayer.i.sourceforge.net> Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net> Thomas, Thanks for taking care of this. One nit on the checkin procedure, pleae reference the SF bug number when you're fixing a bug. Also, report the revision number of the changed file when you close the bug. Thanks, Jeremy From fdrake@beopen.com Tue Oct 3 18:08:06 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > A worthy change? For 2.0 final? This is good; even better would be the configure magic to make it work automatically, similar to what we have for bsddb. Given the short time frame, your approach is good. There may be other modules that need similar adjustments in Setup.in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Tue Oct 3 18:13:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 19:13:40 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <39DA13C4.B1855D9A@lemburg.com> "Barry A. Warsaw" wrote: > > I've found a small memory leak in unicodeobject.c, in the way > _PyUnicode_Fini() shuts down. Take a loop such as: > > -------------------- snip snip -------------------- > #include "Python.h" > > int main(int argc, char** argv) > { > int i; > > while (1) { > Py_Initialize(); > Py_Finalize(); > } > return 0; > } > -------------------- snip snip -------------------- > > and you'll find that unicode_empty leaks. This is because, while > _PyUnicode_Fini() decrefs unicode_empty, it never actually gets > freed. Instead it gets placed on the already freed unicode_freelist! > See _PyUnicode_Free() for why. > > I've come up with the following nasty hack to force unicode_empty to > really be freed in _PyUnicode_Fini(). Maybe there's a better way to > do this. Note that moving the decref of unicode_empty to above the > freeing of unicode_freelist didn't plug the memory leak for me (but > I'm quite tired so maybe I missed something! ;} ). It would be easier to simply move the Py_DECREF() in front of the cleanup code for the free list. That way, unicode_empty would be placed on the free list, but then immedialtely cleaned up by the following code. Should I check in such a patch ? > Below is the proposed patch. > -Barry > > -------------------- snip snip -------------------- > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Tue Oct 3 19:28:08 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:28:08 -0500 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400." <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com> > I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with > the zlib rpm installed, all I need to enable this module is the > following line: > > zlib zlibmodule.c -lz > > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > > A worthy change? For 2.0 final? Check it in right now. --Guido van Rossum (home page: http://www.python.org/~guido/) From Fredrik Lundh" <14810.5059.445654.876073@bitdiddle.concentric.net> Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid> > Thanks for taking care of this. One nit on the checkin procedure, > pleae reference the SF bug number when you're fixing a bug. Also, > report the revision number of the changed file when you close the bug. do you really need both? the former is easy, the latter is more of a PITA, at least with the CVS setup I'm using here... From guido@python.org Tue Oct 3 19:58:20 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:58:20 -0500 Subject: [Python-Dev] Small memory leak in unicodeobject.c In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400." <14810.2731.466997.243906@anthem.concentric.net> References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com> > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } Doesn't it make more sense to decref unicode_empty sooner? The loop over the free list won't touch it: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -c -r2.64 unicodeobject.c *** unicodeobject.c 2000/09/26 05:46:01 2.64 --- unicodeobject.c 2000/10/03 17:55:34 *************** *** 5225,5230 **** --- 5225,5232 ---- { PyUnicodeObject *u = unicode_freelist; + Py_XDECREF(unicode_empty); + unicode_empty = NULL; while (u != NULL) { PyUnicodeObject *v = u; u = *(PyUnicodeObject **)u; *************** *** 5235,5240 **** } unicode_freelist = NULL; unicode_freelist_size = 0; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; } --- 5237,5240 ---- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Tue Oct 3 19:02:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 20:02:39 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com> Message-ID: <39DA1F3F.9EFA41EB@lemburg.com> Guido van Rossum wrote: > > > Index: unicodeobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > > retrieving revision 2.64 > > diff -u -r2.64 unicodeobject.c > > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > > +++ unicodeobject.c 2000/10/03 16:31:32 > > @@ -5234,7 +5234,11 @@ > > PyObject_DEL(v); > > } > > unicode_freelist = NULL; > > - unicode_freelist_size = 0; > > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > > + * Otherwise, it'll get placed on the already freed free list. > > + */ > > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > > Py_XDECREF(unicode_empty); > > unicode_empty = NULL; > > + unicode_freelist_size = 0; > > } > > Doesn't it make more sense to decref unicode_empty sooner? Right. That's the change I proposed to Barry in my last mail. Please check this in. Thanks, Marc-Andre > The loop > over the free list won't touch it: > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -c -r2.64 unicodeobject.c > *** unicodeobject.c 2000/09/26 05:46:01 2.64 > --- unicodeobject.c 2000/10/03 17:55:34 > *************** > *** 5225,5230 **** > --- 5225,5232 ---- > { > PyUnicodeObject *u = unicode_freelist; > > + Py_XDECREF(unicode_empty); > + unicode_empty = NULL; > while (u != NULL) { > PyUnicodeObject *v = u; > u = *(PyUnicodeObject **)u; > *************** > *** 5235,5240 **** > } > unicode_freelist = NULL; > unicode_freelist_size = 0; > - Py_XDECREF(unicode_empty); > - unicode_empty = NULL; > } > --- 5237,5240 ---- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@beopen.com Tue Oct 3 21:35:10 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17150.777092.128211@anthem.concentric.net> >>>>> "M" == M writes: M> It would be easier to simply move the Py_DECREF() in front of M> the cleanup code for the free list. That way, unicode_empty M> would be placed on the free list, but then immedialtely cleaned M> up by the following code. I know that's the obvious fix -- and it was the first thing I tried, but it doesn't work! (I thought I mentioned that in my original message). Verifying after a cvs up still shows unicode_empty leaking (I loop through the Py_Initialize/Py_Finalize loop 10 times): -------------------- snip snip -------------------- 240 bytes 10 chunks allocated at unicodeobject.c, 227 malloc() _PyUnicode_New() unicodeobject.c, 227 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() 30 bytes 10 chunks allocated at unicodeobject.c, 230 malloc() _PyUnicode_New() unicodeobject.c, 230 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() -------------------- snip snip -------------------- So let me step through the code and figure out what's wrong... -Barry From loewis@informatik.hu-berlin.de Tue Oct 3 21:39:06 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de> > It would be hard to sell Python for important applications, > e.g. long-running server processes, if there was a small possibility > that the program could crash through no fault of its own. There is always a small possibility that the program could crash through no faults of its own - i.e. I don't believe that Python is bug free without gc. I'd agree that bugs in the gc are more serious than other bugs. If it turns out that there are serious bugs in 2.0 (whether in the gc or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they get fixed. Regards, Martin From bwarsaw@beopen.com Tue Oct 3 21:42:25 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17585.567814.278594@anthem.concentric.net> Oh the problem is obvious. You have to initialize the local variable `u' /after/ unicode_empty is freed otherwise it doesn't point to the proper start of the free list. I'll check that change in. -Barry From MarkH@ActiveState.com Tue Oct 3 23:58:14 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 09:58:14 +1100 Subject: [Python-Dev] pep42 procedure? Message-ID: Please excuse my ignorance... I am in the process of applying the patch to prevent 1.5/1.6 extensions crashing 2.0 under Windows. Based on the feedback here (ie, "this should be a short term patch"), the various other patches that try to do the same thing, and the belief by some that we should be more like Unix anyway, I believe we should try and capture this entire issue in a more formal manner. The 2 logical places would be as a bug, and in pep42. However, after applying this patch, it doesnt really qualify as a bug! Putting it in pep42 is slightly suspect, as it is not a thought-out feature request yet - however, I believe capturing it there, with links to the relevant patches and discussions would be valuable. So, assuming this sounds reasonable - a bug, or pep42? If pep42, what is the procedure for changing it? I couldnt find it (or any pep) in the CVS repository, and the source-force pages would show me the peps, but not their source. I do remember seeing this mentioned some time ago, but can't locate that mail either... Thanks, Mark. From trentm@ActiveState.com Wed Oct 4 00:08:09 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:08:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows Message-ID: <20001003160809.A18387@ActiveState.com> Fred's checkin: http://www.python.org/pipermail/python-checkins/2000-September/008355.html breaks test_popen2.py on windows. This is because test_popen2.py attempts to refer to popen2's internal '_active' variable, which is now explicitly deleted on Windows platforms. test_popen2.py should be updated for the new popen2 semantics. sorry-no-patch-ly yours, Trent -- Trent Mick TrentM@ActiveState.com From trentm@ActiveState.com Wed Oct 4 00:10:09 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:10:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700 References: <20001003160809.A18387@ActiveState.com> Message-ID: <20001003161009.B18387@ActiveState.com> On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote: > > Fred's checkin: > http://www.python.org/pipermail/python-checkins/2000-September/008355.html > breaks test_popen2.py on windows. > > This is because test_popen2.py attempts to refer to popen2's internal > '_active' variable, which is now explicitly deleted on Windows platforms. > > test_popen2.py should be updated for the new popen2 semantics. > Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my email but before my email made it to python-dev!) Trent -- Trent Mick TrentM@ActiveState.com From skip@mojam.com (Skip Montanaro) Wed Oct 4 01:54:55 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT) Subject: [Python-Dev] pep42 procedure? In-Reply-To: References: Message-ID: <14810.32735.229954.547385@beluga.mojam.com> Mark> So, assuming this sounds reasonable - a bug, or pep42? I think neither. This topic seems to have generated a lot of discussion. I think it deserves a bit more elaboration than what you'd find reasonable for pep42. Also, it would be kinda nice to add it to the Python FAQ with a reference to a specific pep for all the gory details of the problem and solution(s). Skip From MarkH@ActiveState.com Wed Oct 4 04:58:25 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 14:58:25 +1100 Subject: [Python-Dev] pep42 procedure? In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: > I think neither. This topic seems to have generated a lot of > discussion. I > think it deserves a bit more elaboration than what you'd find > reasonable for > pep42. Also, it would be kinda nice to add it to the Python FAQ with a > reference to a specific pep for all the gory details of the problem and > solution(s). That would be a great idea, if only we had a PEP author. To be honest, I really dont care too much about this issue, and have been doing my level best to avoid it. But Tim knows that, and delights in assigning related patches to me ;-) I certainly don't care enough to own a pep on it. The way things stand, I have a checkin ready to go, and am unwilling to commit to any sort of pep in the short or medium term. The best I could do is to add links to the 3 or 4 other patches submitted for the same thing, and pep42 seemed ideal. So given this, what should I do - just check it in, and leave it to the collective memory? ;-) Mark. From tim_one@email.msn.com Wed Oct 4 05:58:46 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 4 Oct 2000 00:58:46 -0400 Subject: [Python-Dev] CIV Message-ID: No, that's not 104, it's a Call for Indentation Volunteers! An item that mistakenly got dropped on the floor before 2.0b1 was to ensure that the standard Python libraries follow the recommended "4-space indents, no hard tabs" guideline. Since 100s of files (especially older ones in oddball directories) are affected, I moved that it into PEP42 rather than risk destabilizing the release after 2.0b1. So it will happen instead soon after 2.0final is released. I looked at existing tools for doing this, and found they all left way too much manual fiddling to bear, too prone to screw up on comment lines (e.g., try running your favorite tool over pindent.py: does the output bear any resemblance to the input?! The Emacs pymode does OK there because pindent comments match its conventions for "indenting comment lines", but nothing else even gets close; OTOH, if 1: # some insane people like # writing comments # like this too and nobody knows what to do about that). Attached is a new tool that tries much harder to get perverse comments right (everything else is easy). Try it and gripe at will. Since I wrote it while on vacation, it's public domain <0.5 wink>. regularly y'rs - tim #! /usr/bin/env python # Released to the public domain, by Tim Peters, 03 October 2000. """reindent [-d][-r][-v] path ... -d Dry run. Analyze, but don't make any changes to, files. -r Recurse. Search for all .py files in subdirectories too. -v Verbose. Print informative msgs; else no output. Change Python (.py) files to use 4-space indents and no hard tab characters. Also trim excess whitespace from ends of lines, and empty lines at the ends of files. Ensure the last line ends with a newline. Pass one or more file and/or directory paths. When a directory path, all .py files within the directory will be examined, and, if the -r option is given, likewise recursively for subdirectories. Overwrites files in place, renaming the originals with a .bak extension. If reindent finds nothing to change, the file is left alone. If reindent does change a file, the changed file is a fixed-point for reindent (i.e., running reindent on the resulting .py file won't change it again). The hard part of reindenting is figuring out what to do with comment lines. So long as the input files get a clean bill of health from tabnanny.py, reindent should do a good job. """ import tokenize import os import sys verbose = 0 recurse = 0 dryrun = 0 def errprint(*args): sep = "" for arg in args: sys.stderr.write(sep + str(arg)) sep = " " sys.stderr.write("\n") def main(): import getopt global verbose, recurse, dryrun try: opts, args = getopt.getopt(sys.argv[1:], "drv") except getopt.error, msg: errprint(msg) return for o, a in opts: if o == '-d': dryrun += 1 elif o == '-r': recurse += 1 elif o == '-v': verbose += 1 if not args: errprint("Usage:", __doc__) return for arg in args: check(arg) def check(file): if os.path.isdir(file) and not os.path.islink(file): if verbose: print "listing directory", file names = os.listdir(file) for name in names: fullname = os.path.join(file, name) if ((recurse and os.path.isdir(fullname) and not os.path.islink(fullname)) or name.lower().endswith(".py")): check(fullname) return if verbose: print "checking", file, "...", try: f = open(file) except IOError, msg: errprint("%s: I/O Error: %s" % (file, str(msg))) return r = Reindenter(f) f.close() if r.run(): if verbose: print "changed." if dryrun: print "But this is a dry run, so leaving it alone." if not dryrun: bak = file + ".bak" if os.path.exists(bak): os.remove(bak) os.rename(file, bak) if verbose: print "renamed", file, "to", bak f = open(file, "w") r.write(f) f.close() if verbose: print "wrote new", file else: if verbose: print "unchanged." class Reindenter: def __init__(self, f): self.find_stmt = 1 # next token begins a fresh stmt? self.level = 0 # current indent level # Raw file lines. self.raw = f.readlines() # File lines, rstripped & tab-expanded. Dummy at start is so # that we can use tokenize's 1-based line numbering easily. # Note that a line is all-blank iff it's "\n". self.lines = [line.rstrip().expandtabs() + "\n" for line in self.raw] self.lines.insert(0, None) self.index = 1 # index into self.lines of next line # List of (lineno, indentlevel) pairs, one for each stmt and # comment line. indentlevel is -1 for comment lines, as a # signal that tokenize doesn't know what to do about them; # indeed, they're our headache! self.stats = [] def run(self): tokenize.tokenize(self.getline, self.tokeneater) # Remove trailing empty lines. lines = self.lines while lines and lines[-1] == "\n": lines.pop() # Sentinel. stats = self.stats stats.append((len(lines), 0)) # Map count of leading spaces to # we want. have2want = {} # Program after transformation. after = self.after = [] for i in range(len(stats)-1): thisstmt, thislevel = stats[i] nextstmt = stats[i+1][0] have = getlspace(lines[thisstmt]) want = thislevel * 4 if want < 0: # A comment line. if have: # An indented comment line. If we saw the same # indentation before, reuse what it most recently # mapped to. want = have2want.get(have, -1) if want < 0: # Then it probably belongs to the next real stmt. for j in xrange(i+1, len(stats)-1): jline, jlevel = stats[j] if jlevel >= 0: if have == getlspace(lines[jline]): want = jlevel * 4 break if want < 0: # Maybe it's a hanging # comment like this one, # in which case we should shift it like its base # line got shifted. for j in xrange(i-1, -1, -1): jline, jlevel = stats[j] if jlevel >= 0: want = have + getlspace(after[jline-1]) - \ getlspace(lines[jline]) break if want < 0: # Still no luck -- leave it alone. want = have else: want = 0 assert want >= 0 have2want[have] = want diff = want - have if diff == 0 or have == 0: after.extend(lines[thisstmt:nextstmt]) else: for line in lines[thisstmt:nextstmt]: if diff > 0: if line == "\n": after.append(line) else: after.append(" " * diff + line) else: remove = min(getlspace(line), -diff) after.append(line[remove:]) return self.raw != self.after def write(self, f): f.writelines(self.after) # Line-getter for tokenize. def getline(self): if self.index >= len(self.lines): line = "" else: line = self.lines[self.index] self.index += 1 return line # Line-eater for tokenize. def tokeneater(self, type, token, (sline, scol), end, line, INDENT=tokenize.INDENT, DEDENT=tokenize.DEDENT, NEWLINE=tokenize.NEWLINE, COMMENT=tokenize.COMMENT, NL=tokenize.NL): if type == NEWLINE: # A program statement, or ENDMARKER, will eventually follow, # after some (possibly empty) run of tokens of the form # (NL | COMMENT)* (INDENT | DEDENT+)? self.find_stmt = 1 elif type == INDENT: self.find_stmt = 1 self.level += 1 elif type == DEDENT: self.find_stmt = 1 self.level -= 1 elif type == COMMENT: if self.find_stmt: self.stats.append((sline, -1)) # but we're still looking for a new stmt, so leave # find_stmt alone elif type == NL: pass elif self.find_stmt: # This is the first "real token" following a NEWLINE, so it # must be the first token of the next program statement, or an # ENDMARKER. self.find_stmt = 0 if line: # not endmarker self.stats.append((sline, self.level)) # Count number of leading blanks. def getlspace(line): i, n = 0, len(line) while i < n and line[i] == " ": i += 1 return i if __name__ == '__main__': main() From bwarsaw@beopen.com Wed Oct 4 07:06:14 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT) Subject: [Python-Dev] pep42 procedure? References: Message-ID: <14810.51414.59852.855231@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> I couldnt find it (or any pep) in the CVS repository, and the MH> source-force pages would show me the peps, but not their MH> source. The PEPs are located in the nondist directory, under nondist/peps! -Barry From bwarsaw@beopen.com Wed Oct 4 07:07:06 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com Message-ID: <14810.51466.486982.938180@anthem.concentric.net> Return-Path: Delivered-To: bwarsaw@mail.wooz.org Received: from ns1.beopen.com (unknown [208.185.174.104]) by mail.wooz.org (Postfix) with ESMTP id 02DB0D37D5 for ; Tue, 3 Oct 2000 19:28:09 -0400 (EDT) Received: from mail2.panix.com (mail2.panix.com [166.84.0.213]) by ns1.beopen.com (8.9.3/8.9.3) with ESMTP id QAA66074 for ; Tue, 3 Oct 2000 16:28:36 -0700 (PDT) (envelope-from aahz@panix.com) Received: from panix6.panix.com (panix6.panix.com [166.84.0.231]) by mail2.panix.com (Postfix) with ESMTP id 4CD318F00 for ; Tue, 3 Oct 2000 19:26:33 -0400 (EDT) Received: (from aahz@localhost) by panix6.panix.com (8.8.8/8.7.1/PanixN1.0) id TAA27108 for bwarsaw@beopen.com; Tue, 3 Oct 2000 19:26:33 -0400 (EDT) Message-Id: <200010032326.TAA27108@panix6.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: aahz@panix.com To: bwarsaw@beopen.com Subject: htmllib.HTMLescape() Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT) X-Mailer: ELM [version 2.5 PL3] Reply-To: aahz@pobox.com Someone just pointed out on c.l.py that we need an HTMLescape() function that takes a string and converts special characters to entities. I'm not on python-dev, so could you please forward this and find out whether I need to run a PEP? -- --- Aahz (Copyright 2000 by aahz@pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 There's a difference between a person who gets shit zie doesn't deserve and a person who gets more shit than zie deserves. --Aahz From thomas@xs4all.net Wed Oct 4 07:16:58 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 08:16:58 +0200 Subject: [Python-Dev] pep42 procedure? In-Reply-To: ; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100 References: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: <20001004081658.E12812@xs4all.nl> On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote: [ Mark wants to apply a patch that prevents crashes on windows when loading extentions linked with old Python DLLs, but doesn't know where to document it: PEP 42 or the bug report(s) ] [ Skip proposes a separate PEP ] [ Mark doesn't have time to write a PEP ] > So given this, what should I do - just check it in, and leave it to the > collective memory? ;-) PEP 42 is the meaning of life PEP, meaning that it's everything that needs to be done before python-dev can rest in pieces. I don't think that a solved issue is in its place there, even if it had such a section. A PEP on its own would probably be the best spot, because even if it's a 'temporary' solution now, we or someone else might need the info later. And a PEP doesn't have to be that hard to write ;) And besides, you don't have to be the person to write the PEP, someone else can. And if noone suitable volunteers, perhaps a checkin-message giving 'full' documentation, the necessary sourcecode comments and a reference to both in the bugreport message will suffice... But I'm willing to PEPify whatever docs or comments you write on this issue, Mark. I will need some guidance on what exactly is the issue, but I'm sure I'll get that from one of you Windows lovers ! :-) And no, I don't think Python should be more like UNIX. Windows, yes, but it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides, that would only alienate the Windows users with Uni(x)fobia. Unix-unix-unix-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping@lfw.org Wed Oct 4 12:02:51 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT) Subject: [Python-Dev] Installing python in /usr/bin Message-ID: The cgi.py discussion brought my attention to this comment from Guido: > No, no, no! The /usr/bin/env form *fails* on most platforms (except > Linux) because Python is not installed in any of the default "bin" > directories -- /usr/local/bin is the standard install place and that's > not in the default path. So the natural question to ask is -- why not install Python in /usr/bin like everyone else? Perhaps a while ago Python wasn't popular enough to belong in /usr/bin and decided to modestly stay out of the way in /usr/local/bin instead? But by now, i think it's quite qualified to take its seat in /usr/bin along with all the other standard Unix binaries like /usr/bin/vi, /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default binary directory. Your thoughts? -- ?!ng From thomas@xs4all.net Wed Oct 4 12:35:28 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 13:35:28 +0200 Subject: [Python-Dev] Installing python in /usr/bin In-Reply-To: ; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700 References: Message-ID: <20001004133528.G12812@xs4all.nl> On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote: > So the natural question to ask is -- why not install Python in /usr/bin > like everyone else? > Perhaps a while ago Python wasn't popular enough to belong in /usr/bin > and decided to modestly stay out of the way in /usr/local/bin instead? The only reason is the hysterical one: it's always been that way. Traditionally, /usr/local/bin was the place for user-installed binaries. This sets them apart from the the vendor-supplied binaries (commonly in /bin and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and /usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.) > But by now, i think it's quite qualified to take its seat in /usr/bin > along with all the other standard Unix binaries like /usr/bin/vi, > /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default > binary directory. Perl only resides in /usr/bin if the vendor (or distribution-maker, in the case of the Free OSes) put it there. The default for Perl is /usr/local as well. In fact, almost all source packages default to /usr/local; I have yet to see a package that uses autoconf and does not have /usr/local as the default prefix, for instance. I think the best solution is just for every OS to put /usr/local/bin in their path, and not pretend they delivered the Definitive Collection of Useful Programs. Installing Python in /usr can do more damage than good -- think of all the people that are used to have it installed in /usr/local, don't specify a prefix because they 'know' it's /usr/local by default, and end up filling up their minimal /usr partition with Python ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward@python.net Tue Oct 3 05:08:45 2000 From: gward@python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ And now for something completely different. From bwarsaw@beopen.com Wed Oct 4 14:44:40 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT) Subject: [Python-Dev] Installing python in /usr/bin References: <20001004133528.G12812@xs4all.nl> Message-ID: <14811.13384.137080.196973@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> The only reason is the hysterical one: it's always been that TW> way. Traditionally, /usr/local/bin was the place for TW> user-installed binaries. Yes exactly. And in fact on my RH6.1 system, I have Python in both /usr/bin and /usr/local/bin. RedHat sticks its rpms in /usr/bin, and right now, 1.5.2 resides there. My dev copy gets installed from source into /usr/local/bin, and that's the current CVS snapshot. This is as it should be and all is right in the world. The rule is -- and ought to be -- that the default install location in a build-from-source distro is /usr/local. rpms or other package installs can install where ever is appropriate for that platform (e.g. if someone were to build a Solaris pkg distro, it probably ought to install to /opt by default). if-it-ain't-broke...-ly y'rs, -Barry From nas@arctrix.com Wed Oct 4 10:46:36 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 02:46:36 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700 References: <200010041622.JAA17363@slayer.i.sourceforge.net> Message-ID: <20001004024636.A13475@glacier.fnational.com> On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules > > Modified Files: > cPickle.c > Log Message: > - Fix a GC bug caused by PyDict_New() failing. > > > Index: cPickle.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v > retrieving revision 2.52 > retrieving revision 2.53 > diff -C2 -r2.52 -r2.53 > *** cPickle.c 2000/09/07 14:35:37 2.52 > --- cPickle.c 2000/10/04 16:22:26 2.53 > *************** > *** 2876,2880 **** > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! Py_DECREF(inst); > goto err; > } > --- 2876,2881 ---- > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! inst = (PyInstanceObject *) PyObject_AS_GC(inst); > ! PyObject_DEL(inst); > goto err; > } I aways seem to think harder when reviewing a commit message than a diff. :( I just realized that this commit subtly modifies cPickle's behavior. Before the change instances __del__ methods would be called if allocating __dict__ failed. After the change they are not. I think the new behavior is better but the question is will it break existing code? I think probably not. BTW, pickle seems to follow the new behavior. Neil From esr@snark.thyrsus.com Wed Oct 4 18:17:39 2000 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 13:17:39 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010041717.NAA03509@snark.thyrsus.com> In the course of maintaining fetchmail, I've developed effective techniques for integrating RPM and lsm generation into the release machinery of a package. I'm willing to do this for Python; it will involve adding a makefile production and a couple of scripts to the distribution. The benefit would be that we could generate correct RPMs automatically and ship them with each release. I think RPM is a sufficiently important distribution format to justify this effort. Comments? -- Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 From Fredrik Lundh" Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid> eric wrote: > In the course of maintaining fetchmail, I've developed effective > techniques for integrating RPM and lsm generation into the release machinery > of a package. I'm willing to do this for Python; it will involve > adding a makefile production and a couple of scripts to the > distribution. > > The benefit would be that we could generate correct RPMs automatically > and ship them with each release. I think RPM is a sufficiently > important distribution format to justify this effort. Comments? isn't this a distutils thing? see: ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html (lazy programmers just press the "deploy" button, of course ;-) From akuchlin@mems-exchange.org Wed Oct 4 19:02:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 4 Oct 2000 14:02:19 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: >isn't this a distutils thing? see: >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html >(lazy programmers just press the "deploy" button, of course ;-) It's not immediately obvious that the Distutils 1.0, which after all mostly aims to support installing Python modules, can be applied to installing Python itself, what with all the libraries and scripts and such that Python needs. It certainly is something to aim for, and I intend to work on this some more after 2.0, but the attempt might run into missing Distutil features. Whether it's worth adding rules for RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or -0, just 0 -- a Nirvana-like state of utter unconcern.) --amk From gward@mems-exchange.org Wed Oct 4 19:13:01 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:13:01 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us> On 04 October 2000, Fredrik Lundh said: > isn't this a distutils thing? see: > > ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html But the Distutils brag line is: The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. If that first sentence were instead The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python. then you'd have a point. What a difference one little word can make... Greg From gward@mems-exchange.org Wed Oct 4 19:16:20 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:16:20 -0400 Subject: [Python-Dev] Adding a section to PEP 0042 Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us> I need to add an entry to PEP 0042 about the lack of cross-compilation support, because that's a bug report that was assigned to me, and needs to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems to me that I should just add a section on "Build/Installation" to the PEP -- anyone disagree? This might also be a good place to gather other gripes about Python's build/installation machinery... Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From Fredrik Lundh" <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us> Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid> greg wrote: > If that first sentence were instead > > The Python Distribution Utilities, or Distutils for short, are a > collection of modules that aid in the development, distribution, and > installation of Python. > > then you'd have a point. > > What a difference one little word can make... so why not fix it? cannot be too hard to remove one little word, can it? ;-) From loewis@informatik.hu-berlin.de Wed Oct 4 21:31:23 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> > Someone just pointed out on c.l.py that we need an HTMLescape() > function that takes a string and converts special characters to > entities. I'm not on python-dev, so could you please forward this > and find out whether I need to run a PEP? Doesn't xml.sax.saxutils.escape do what you want (together with htmlentitydefs)? I was going to say that this is quite a small change to warrant a PEP - but there are two obvious approaches (working from scratch, or working on top of xml.sax.saxutils.escape - perhaps modifying and relocating that function), so *some* design probably needs to be recorded in a PEP. Regards, Martin From trentm@ActiveState.com Wed Oct 4 22:17:37 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed, 4 Oct 2000 14:17:37 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails Message-ID: <20001004141737.A16659@ActiveState.com> I did not follow the discussion a while back regarding the implementation and use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results in this test: test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) in test_sre.py failing on Win64. This is because PyOS_CheckStack seem to *never* fail on Win64. Three possibilites: (1) I don't understand the PyOS_CheckStack code or I am misintepreting the problem. (2) The semantics of _alloca() has changed for Win64 such that a stack overflow exception is no longer thrown if space cannot be allocated. NOTE: I changed the number of pointers allocated in PyOS_CheckStack from 2048 to over 1 *Tera*byte and it *still* did not fail. (3) I am stoopid. In any case, I would like to *not* define USE_STACKCHECK on Win64 for the time being (and for 2.0, unless a Win64 angel comes to me in the next couple of days). Does anybody have a problem with me checking this in? *** Include\pythonrun.h~ Wed Oct 04 14:18:00 2000 --- Include\pythonrun.h Wed Oct 04 13:17:17 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif Thanks, Trent -- Trent Mick TrentM@ActiveState.com From Fredrik Lundh" Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid> trent wrote: > I did not follow the discussion a while back regarding the implementation and > use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) > instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results > in this test: > test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) > in test_sre.py failing on Win64. note that the test assumes that 50000 iterations would be enough to hit the stack limit. maybe Win64 has a *huge* stack? what does this little program do: import sre sre.match(r'(x)*', 50000*'x').span() if it prints (0, 50000), all is well, and the *test* should be disabled (or modified) on Win64... From jeremy@beopen.com Wed Oct 4 22:35:26 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com> References: <200010041717.NAA03509@snark.thyrsus.com> Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> In the course of maintaining fetchmail, I've developed ESR> effective techniques for integrating RPM and lsm generation ESR> into the release machinery of a package. I'm willing to do ESR> this for Python; it will involve adding a makefile production ESR> and a couple of scripts to the distribution. ESR> The benefit would be that we could generate correct RPMs ESR> automatically and ship them with each release. I think RPM is ESR> a sufficiently important distribution format to justify this ESR> effort. Comments? We are now distributing RPMs for RH 6 with Python and have plans to support other distributions we have access to, namely those available on the SF compile farm. This page has the RPMs: http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html Can you compare this approach to using a hand-crafted .spec file for the RPMs? It took a little while to figure out how to generate the .spec, but now that it has been created it does not seem hard to maintain. I imagine, without knowing any details of what you propose, that this is primarily beneficial for people who do not know how to build RPMs. Jeremy From Fredrik Lundh" Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid> trent wrote: > This is because PyOS_CheckStack seem to *never* fail on Win64. Three > possibilites: > (1) I don't understand the PyOS_CheckStack code or I am misintepreting the > problem. > (2) The semantics of _alloca() has changed for Win64 such that a stack > overflow exception is no longer thrown if space cannot be allocated. > NOTE: I changed the number of pointers allocated in PyOS_CheckStack > from 2048 to over 1 *Tera*byte and it *still* did not fail. me again: didn't read the note carefully enough, so I didn't quite figure out what you said... ::: what happens if you run this program (on my win95 box, it counts up to 8, and stops). #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ::: if it goes on and on and on, check the assembler output from this program. (maybe the win64 compiler is smarter than I -- if it realizes that I don't actually use the return value from _alloca, it may of course remove the entire thing...) From esr@thyrsus.com Wed Oct 4 22:56:38 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 17:56:38 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> Message-ID: <20001004175638.A4423@thyrsus.com> Jeremy Hylton : > We are now distributing RPMs for RH 6 with Python and have plans to > support other distributions we have access to, namely those available > on the SF compile farm. > > This page has the RPMs: > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > Can you compare this approach to using a hand-crafted .spec file for > the RPMs? It took a little while to figure out how to generate the > .spec, but now that it has been created it does not seem hard to > maintain. > > I imagine, without knowing any details of what you propose, that this > is primarily beneficial for people who do not know how to build RPMs. Actually, the point of my approach is *not* to hand-craft the spec file. What I normally do is write a specfile generator script in shell, which takes the release version as an argument. Most of the point of the generator script is so the file list part of the specfile never has to be handhacked. So, for example, a specfile generator script for Python would know that for each library file foo.py in the Python X.Y release tree, it needs to generate a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is added to the library it will automatically ripple through to the RPM. Then I embed something like this in the Makefile: # Make RPMs. You need to be root to make this work RPMROOT=/usr/src/redhat RPM = rpm RPMFLAGS = -ba rpm: dist cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES; $(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir) cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir) Hey presto! Instant RPMs. I use this approach for several of my projects. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From nas@arctrix.com Wed Oct 4 17:12:04 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 09:12:04 -0700 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> Message-ID: <20001004091204.A787@glacier.fnational.com> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > Jeremy Hylton : > > Can you compare this approach to using a hand-crafted .spec file for > > the RPMs? It took a little while to figure out how to generate the > > .spec, but now that it has been created it does not seem hard to > > maintain. > Actually, the point of my approach is *not* to hand-craft the spec file. Okay, but we already have the spec file. Why is your approach better? Is your script that generates the the spec easier to maintain then the spec file itself? Is it just as flexible? If so then Red Hat screwed up designing RPM. I can see the utility of such as script but I don't see how it helps in this situation. Neil From esr@thyrsus.com Thu Oct 5 03:23:18 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 22:23:18 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com> Message-ID: <20001004222318.E4742@thyrsus.com> Neil Schemenauer : > On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > > Jeremy Hylton : > > > Can you compare this approach to using a hand-crafted .spec file for > > > the RPMs? It took a little while to figure out how to generate the > > > .spec, but now that it has been created it does not seem hard to > > > maintain. > > Actually, the point of my approach is *not* to hand-craft the spec file. > > Okay, but we already have the spec file. Why is your approach > better? Is your script that generates the the spec easier to > maintain then the spec file itself? Is it just as flexible? If > so then Red Hat screwed up designing RPM. I can see the utility > of such as script but I don't see how it helps in this situation. The main thing a specfile generator can accomplish is to automate the generation of the file list so that (for example) when we add a new library module the specfile doesn't have to be hand-edited. -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 From nas@arctrix.com Wed Oct 4 22:43:50 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 14:43:50 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001004144350.A434@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > that's a clue? Rob was kind enough to send me some code to trigger the bug. The winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's program seems to work fine. I think Pmw uses lots of tuples. Looking closely at the code I see that _PyTuple_Resize is almost certainly buggy. I think something is wrong with PyTuple_New as well. I'll have to come up with a patch later as it is much to late now for me to fully understand such hairy code. :( Neil From pf@artcom-gmbh.de Thu Oct 5 06:55:19 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000 3:40:33 pm" Message-ID: Hi, Barry Warsaw : > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669 > > Added Files: > pep-0004.txt > Log Message: > Added PEP 4, Deprecation of Standard Modules, Martin von Loewis > > > ***** Error reading new file: (2, 'No such file or directory') Whenever Barry adds a new file to the CVS, its initial content is invisible on the checkins mailing list due to the error message above. However if for example fdrake adds a new file (for example the support.py recently added to the doc subtree) then this doesn't happen. Is there anybody out there able to fix this for future checkins-mails? Regards, Peter From fdrake@beopen.com Thu Oct 5 07:23:10 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: References: <200010042240.PAA14714@slayer.i.sourceforge.net> Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Peter Funk writes: > Whenever Barry adds a new file to the CVS, its initial content > is invisible on the checkins mailing list due to the error message > above. However if for example fdrake adds a new file (for example the > support.py recently added to the doc subtree) then this doesn't happen. > Is there anybody out there able to fix this for future checkins-mails? Wow! I had noticed the bolluxed messages, but hadn't tied it to Barry! But I just checked the added files for this month and spot-checked the ones from last month, and Barry's all exhibit this problem, and no one else's do. I wonder if something is wrong with his SourceForge account? Barry, check your group memberships, please! If nothing obvious is wrong, submit a support request, because this is definately annoying. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Oct 5 08:09:20 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:20 -0400 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003161009.B18387@ActiveState.com> Message-ID: [Trent Mick, pointing out that test_popen2 was busted on Windows] > Geez, you are fast Tim! (for others: he patched test_popen.py > after I sent my email but before my email made it to python-dev!) I hate to be honest, but I actually pointed out the test_popen2 failure on Python-Dev last week. However, I was On Vacation(tm) then, so thought merely mentioning it would shame someone else into fixing it. At this point, I'll happily settle for that somebody else eventually *noticed* it! our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs - tim From tim_one@email.msn.com Thu Oct 5 08:09:17 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:17 -0400 Subject: [Python-Dev] pep42 procedure? In-Reply-To: Message-ID: [Mark Hammond] > That would be a great idea, if only we had a PEP author. To be honest, > I really dont care too much about this issue, and have been doing my > level best to avoid it. But Tim knows that, and delights in assigning > related patches to me ;-) I certainly don't care enough to own a pep > on it. ... I assign them to you because there's barely a line of Windows startup code you didn't write, and you gave Windows the notion of naming the main DLL differently across (some) different releases thus creating the possibility for the problem these patches are trying to solve . That's not to say it's "your problem", but is to say you've thought more about "stuff like this" than anyone else, and have very particular ideas about how you want "stuff like this" done: you're the best qualified. That said, the subject of the PEP shouldn't be competing hacks to worm around Windows-specific startup problems, it should be an actual design for binary compatibility across iterations of the C API, or at least a reliable way for extensions to *know* they're not getting a version of the Python core they can use. we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs - tim From martin@loewis.home.cs.tu-berlin.de Thu Oct 5 08:44:52 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 5 Oct 2000 09:44:52 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> > The main thing a specfile generator can accomplish is to automate > the generation of the file list so that (for example) when we add a > new library module the specfile doesn't have to be hand-edited. That sounds similar to the rationale for having automatically generated dependency files for make, e.g. by gcc -MM. Many projects use this as a convenience, and it kind-of works. However, I still like it better to have dependencies explicitly recorded in the Makefiles. That requires more discipline, but is easier to understand, and the behaviour is more reproducable. So given the option of using an existing hand-written spec file, and having some magic generate one for me, I'd always use the hand-written one. The magic is only good if there is no hand-written one. Regards, Martin From fredrik@pythonware.com Thu Oct 5 08:50:37 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 09:50:37 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> neil wrote: > On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > > that's a clue? > > Rob was kind enough to send me some code to trigger the bug. The > winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's > program seems to work fine. I think Pmw uses lots of tuples. The new version of Tkinter contains a _flatten function written in C, which uses PyTuple_Resize extensively. To check if Rob's program works better without it, you can comment out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or so, iirc). From larsga@garshol.priv.no Thu Oct 5 09:36:33 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 05 Oct 2000 10:36:33 +0200 Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: * Martin von Loewis | | Doesn't xml.sax.saxutils.escape do what you want (together with | htmlentitydefs)? I was going to say that this is quite a small | change to warrant a PEP - but there are two obvious approaches | (working from scratch, or working on top of xml.sax.saxutils.escape | - perhaps modifying and relocating that function), so *some* design | probably needs to be recorded in a PEP. It would probably help, but now that Python has Unicode support there should be some way to convert string data to a legacy encoding and represent all characters not available in that encoding using numeric character references. This would be very useful for both XML and HTML. The difficulty, I assume, lies in figuring out which encodings support what characters. --Lars M. From nas@arctrix.com Thu Oct 5 06:59:38 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 22:59:38 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> Message-ID: <20001004225938.A802@glacier.fnational.com> On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote: > The new version of Tkinter contains a _flatten function written in C, > which uses PyTuple_Resize extensively. > > To check if Rob's program works better without it, you can comment > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > so, iirc). That fixes the crash as well. Neil From bwarsaw@beopen.com Thu Oct 5 14:33:53 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) References: <200010042240.PAA14714@slayer.i.sourceforge.net> <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Message-ID: <14812.33601.730022.889777@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Wow! I had noticed the bolluxed messages, but hadn't tied Fred> it to Barry! But I just checked the added files for this Fred> month and spot-checked the ones from last month, and Barry's Fred> all exhibit this problem, and no one else's do. I wonder if Fred> something is wrong with his SourceForge account? Barry, Fred> check your group memberships, please! If nothing obvious is Fred> wrong, submit a support request, because this is definately Fred> annoying. I don't understand why this is happening, esp. just for me! My primary group is users and I'm definitely in the python group as well. Why would it be a permission problem anyway, since that's not what the error message is saying? Better log messages in syncmail would help diagnose this, but I haven't got the time right now to hack on that. -Barry From pf@artcom-gmbh.de Thu Oct 5 14:54:58 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000 9:33:53 am" Message-ID: Hi, Barry A. Warsaw: > > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Wow! I had noticed the bolluxed messages, but hadn't tied > Fred> it to Barry! But I just checked the added files for this > Fred> month and spot-checked the ones from last month, and Barry's > Fred> all exhibit this problem, and no one else's do. I wonder if > Fred> something is wrong with his SourceForge account? Barry, > Fred> check your group memberships, please! If nothing obvious is > Fred> wrong, submit a support request, because this is definately > Fred> annoying. > > I don't understand why this is happening, esp. just for me! My > primary group is users and I'm definitely in the python group as > well. Why would it be a permission problem anyway, since that's not > what the error message is saying? > > Better log messages in syncmail would help diagnose this, but I > haven't got the time right now to hack on that. Just speculating: it has something todo with the current directory where the cvs commit command is executed in or it depends on the difference that the PEPs are under nondist and Freds files were under dist. Possible ugly workaround for Barry: for new files first commit an empty file and then the real file just a moment later. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From jeremy@beopen.com Thu Oct 5 15:42:31 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT) Subject: [Python-Dev] Release candidate schedule Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net> There are still a number of open bugs that need to be addressed before we can issue a release candidate. We plan to issue the release candidate on Monday and the final release a week later. According to the Sourceforge bug report -- http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1 -- the following people still have open bugs: akuchlin (3) bwarsaw (3) dcjim (2) effbot (5) fdrake (4) gvanrossum (12) gward (1) jackjansen (1) jhylton (8) lemburg (2) mhammond (5) nascheme (3) tim_one (5) I don't expect that every bug will be closed before 2.0 final, but there are some open bugs about test failures and build problems with 2.0 beta releases. We should address these if at all possible. Please review your open bugs and make sure you aren't forgetting about something. If you have bugs that will not be fixed for 2.0, make sure they have a fairly low priority. If you have bugs you will not be able to address, assign them to me. Jeremy From Fredrik Lundh" <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002501c02edc$1302b040$766940d5@hagrid> what's the current release schedule, btw? is the repository frozen, or do we still have a chance to fix the GC tuple problem and SRE's "nothing to repeat" bug? From Fredrik Lundh" <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid> > > To check if Rob's program works better without it, you can comment > > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > > so, iirc). > > That fixes the crash as well. in other words, _PyTuple_Resize needs some work... (or does _flatten do something wrong? it starts by creating a tuple, and if it needs more space, it doubles the size one or more times, and ends by calling Resize again to set the final size...) ::: btw, the start of Resize looks a bit strange: should that DECREF really be there? should least be an XDECREF, or am I missing something? if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { *pv = 0; Py_DECREF(v); /* really? what if v is NULL? */ PyErr_BadInternalCall(); return -1; } From mal@lemburg.com Thu Oct 5 16:00:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 05 Oct 2000 17:00:12 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> Message-ID: <39DC977C.89D14AB1@lemburg.com> Andrew Kuchling wrote: > > On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: > >isn't this a distutils thing? see: > >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html > >(lazy programmers just press the "deploy" button, of course ;-) > > It's not immediately obvious that the Distutils 1.0, which after all > mostly aims to support installing Python modules, can be applied to > installing Python itself, what with all the libraries and scripts and > such that Python needs. It certainly is something to aim for, and I > intend to work on this some more after 2.0, but the attempt might run > into missing Distutil features. Whether it's worth adding rules for > RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or > -0, just 0 -- a Nirvana-like state of utter unconcern.) distutils is not useful for installing Python (it needs Python to start with), but it does a pretty good job at finding the needed files and can generate RPMs which can be used without distutils or Python. It even allows adding handcrafted sections to the resulting RPM. If anybody plans to help in this direction, I'd suggest to add those efforts to the build_rpm command in distutils (and the build_deb command for that matter). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Thu Oct 5 16:24:32 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 5 Oct 2000 11:24:32 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com> Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us> On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote: >distutils is not useful for installing Python (it needs Python >to start with), ... Note that the Distutils doesn't need many C-based modules: _sre, posix, and string are about it. So those modules could be automatically compiled into the Python binary (perhaps being moved from Modules/ into Python/ to signify their new importance) and the resulting binary should have enough marbles to run a setup.py script that would build everything else in Modules/. The downside is that you could no longer compile those 3 modules as dynamically loadable, but the upside is that the setup.py could be smarter about detecting which libraries are available on the system, and compiling everything which can be. This would, one hopes, make Setup file hacking a thing of the past... --amk From tismer@appliedbiometrics.com Thu Oct 5 15:33:54 2000 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 05 Oct 2000 17:33:54 +0300 Subject: [Python-Dev] Stackless Python Mailing List Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com> Hi Pythoneers (without or not without Stack (yet:)) there have been a couple of interviews, and some articles on Stackless Python are published or in preparation. I recognize an increasing number of individual emails concerning Stackless Python. This lets me take the opportunity to start a mailing list on Stackless Python, an overdue task. The goal of this list is two-fold: On the one hand, people should have a forum to discuss their use of SLP, its further development, concurrency in general, and more. The other reason is to increase the support for SLP, with the final goal to get it merged into Standard Python. There are a couple of ways to help me with that, see http://starShip.python.net/mailman/listinfo/stackless Everybody who is interested in Stackless Python and all the related topics may feel invited to join this discussion group. cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : 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 From nas@arctrix.com Thu Oct 5 09:40:28 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 5 Oct 2000 01:40:28 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> Message-ID: <20001005014028.A1055@glacier.fnational.com> On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote: > in other words, _PyTuple_Resize needs some work... Yup. I've attached a patch which I believe fixes some GC bugs in addition to making it simpler. > btw, the start of Resize looks a bit strange: should that > DECREF really be there? should least be an XDECREF, or > am I missing something? > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > *pv = 0; > Py_DECREF(v); /* really? what if v is NULL? */ > PyErr_BadInternalCall(); > return -1; > } I think your right. Here's a fun little program: from _tkinter import _flatten import random # don't ask me why for x in xrange(10000): print x t = _flatten([(0,)*x]*x) It gives: 0 1 2 3 4 5 Segmentation fault on the two Linux machines I've tested it on. It also crashes with GC disabled. Neil *** Objects/tupleobject.c Thu Oct 5 11:31:30 2000 --- tupleobject.c Thu Oct 5 10:47:44 2000 *************** *** 500,531 **** } else #endif { ! #ifdef WITH_CYCLE_GC ! PyGC_Head *g = PyObject_AS_GC((PyObject *)v); ! PyObject_GC_Fini((PyObject *)v); ! g = (PyGC_Head *) ! PyObject_REALLOC((char *)g, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! if (g == NULL) { ! sv = NULL; ! } else { ! sv = (PyTupleObject *)PyObject_FROM_GC(g); ! } ! #else sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! #endif ! *pv = (PyObject *) sv; if (sv == NULL) { ! PyObject_GC_Init((PyObject *)v); ! v = (PyTupleObject *) PyObject_AS_GC(v); PyObject_DEL(v); PyErr_NoMemory(); return -1; } } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) --- 500,519 ---- } else #endif { ! PyObject_GC_Fini(v); ! v = (PyObject *) PyObject_AS_GC(v); sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); if (sv == NULL) { ! *pv = NULL; PyObject_DEL(v); PyErr_NoMemory(); return -1; } + sv = (PyTupleObject *) PyObject_FROM_GC(sv); + *pv = (PyObject *) sv; } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) From guido@python.org Thu Oct 5 19:22:49 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:22:49 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400." <14810.51466.486982.938180@anthem.concentric.net> References: <14810.51466.486982.938180@anthem.concentric.net> Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> [Aahz] > Someone just pointed out on c.l.py that we need an HTMLescape() function > that takes a string and converts special characters to entities. I'm > not on python-dev, so could you please forward this and find out whether > I need to run a PEP? Has someone pointed out yet that this is done by cgi.escape()? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 5 19:24:20 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:24:20 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST." <20001004024636.A13475@glacier.fnational.com> References: <200010041622.JAA17363@slayer.i.sourceforge.net> <20001004024636.A13475@glacier.fnational.com> Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com> > I aways seem to think harder when reviewing a commit message than > a diff. :( I just realized that this commit subtly modifies > cPickle's behavior. Before the change instances __del__ methods > would be called if allocating __dict__ failed. After the change > they are not. I think the new behavior is better but the > question is will it break existing code? I think probably not. This is goodness. Don't worry about breaking code -- it probably *fixes* code. Most __del__ methods don't know what to do when the instance variables haven't been defined yet! > BTW, pickle seems to follow the new behavior. Even better. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 5 19:29:27 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:29:27 -0500 Subject: [Python-Dev] Adding a section to PEP 0042 In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400." <20001004141620.A31293@ludwig.cnri.reston.va.us> References: <20001004141620.A31293@ludwig.cnri.reston.va.us> Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com> > I need to add an entry to PEP 0042 about the lack of cross-compilation > support, because that's a bug report that was assigned to me, and needs > to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems > to me that I should just add a section on "Build/Installation" to the > PEP -- anyone disagree? This might also be a good place to gather > other gripes about Python's build/installation machinery... +1 (I think the "Library" section is growing too big and may be split in "Lib" and "Modules" sections.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 5 19:33:47 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:33:47 -0500 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200." <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Whatever the outcome of this discussion, this is too late for 2.0. But I tend to side with Jeremy and Martin -- "explicit is better". I do want Jeremy to check his RPM generation scripts in, so they can be improved in a truly open source project. (Maybe in Tools/rpm?) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 5 19:43:30 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:43:30 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200." <002501c02edc$1302b040$766940d5@hagrid> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002501c02edc$1302b040$766940d5@hagrid> Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com> > what's the current release schedule, btw? Let me give that a shot... - Feature Freeze Now. I.e. it's too late for anything even vaguely resembling a feature -- even if it's been discussed to death. - Bugfix Checkin Freeze Saturday (Oct 7) Starting Saturday, all checkins must be coordinated with the releasemeister (still Jeremy). - Release Candidate Monday (Oct 9) - Final Release Monday week (Oct 16) Between the Release Candidate and the Final Release, all checkins must fix bugs and must be approved by the releasemeister. > is the repository frozen, or do we still have a chance to fix > the GC tuple problem and SRE's "nothing to repeat" bug? Simple bugfixes are okay till Saturday. Bugfixes that are complex and may break other stuff should be discussed with the releasemeister, possibly cc'ing python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From Fredrik Lundh" <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com> Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid> neil wrote: > Yup. I've attached a patch which I believe fixes some GC bugs in > addition to making it simpler. don't have the slightest idea how the GC stuff works, but it sure looks right: just go ahead and check it in... > > btw, the start of Resize looks a bit strange: should that > > DECREF really be there? should least be an XDECREF, or > > am I missing something? > > > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > > *pv = 0; > > Py_DECREF(v); /* <- really? what if v is NULL? */ > > PyErr_BadInternalCall(); > > return -1; > > } > > I think your right. Here's a fun little program: > > from _tkinter import _flatten > import random # don't ask me why > for x in xrange(10000): > print x > t = _flatten([(0,)*x]*x) > > It gives: > > 0 > 1 > 2 > 3 > 4 > 5 > Segmentation fault guido? From jim@digicool.com Thu Oct 5 19:10:42 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 05 Oct 2000 14:10:42 -0400 Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR) References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com> Message-ID: <39DCC422.90E4D0D5@digicool.com> Sam Rushing wrote: > > Jim Fulton writes: > > The asyncore main loop should check for this error in it's select > > call and the select module should make this error easier to check > > for. > > It might go better into the event_loop function, which I think of as a > more user-serviceable part. [for example, the default loop vs. the > one in medusa/event_loop.py that supports schedulable events] Don't you think anyone using select on Unix would want this? This isn't really an application-specific thing is it? > > I presume that this works in Python 1.6/2.0, but I > > haven't tried it yet? > > > > This depends on the structure of select.error values > > and requires that we get EINTR from somewhere. (What > > should the value be on NT?) > > If it's a big problem, I guess we could use a different default > event_loop() function for win32 vs. unix. Or we could put this in the poll function and reraise the error on NT, as my change does. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From aahz@pobox.com Thu Oct 5 20:52:47 2000 From: aahz@pobox.com (aahz@pobox.com) Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM Message-ID: <200010051952.PAA05883@panix6.panix.com> > [Aahz] >> Someone just pointed out on c.l.py that we need an HTMLescape() function >> that takes a string and converts special characters to entities. I'm >> not on python-dev, so could you please forward this and find out whether >> I need to run a PEP? > > Has someone pointed out yet that this is done by cgi.escape()? Yeah, I missed that earlier. But after thinking some more, there are a fair number of browser-like bits of software that fail to render many of the special characters correctly (e.g. trademark). This is frequently due to character set issues; entities almost always render correctly, though. Therefore a general translation routine is probably handy. cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape ought to be expanded to handle all characters or a new routine should be added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I have zero familiarity with XML and am waiting for 2.0final. Perhaps this should be taken off-line? -- --- Aahz (Copyright 2000 by aahz@pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 There's a difference between a person who gets shit zie doesn't deserve and a person who gets more shit than zie deserves. --Aahz From skip@mojam.com (Skip Montanaro) Thu Oct 5 20:54:56 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net> References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <14812.56464.380651.537610@beluga.mojam.com> Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty Barry> string always returns true. This closes SF bug #115392. There was a big thread recently on the tramp mailing list (similar to efs for remote file editing in Emacs, but uses ssh/scp instead) about trying to find a portable way to test for the existence of a file. After trying all sorts of stuff, the final result was pretty ugly, as I recall. -- Skip Montanaro (skip@mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From guido@python.org Thu Oct 5 22:07:29 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 16:07:29 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST." <200010051952.PAA05883@panix6.panix.com> References: <200010051952.PAA05883@panix6.panix.com> Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com> > Yeah, I missed that earlier. But after thinking some more, there are a > fair number of browser-like bits of software that fail to render many of > the special characters correctly (e.g. trademark). This is frequently > due to character set issues; entities almost always render correctly, > though. Therefore a general translation routine is probably handy. But character set issues also make it impossible to provide such a translation routine: the current party line is that the encoding of 8-bit strings is unknown and that only ASCII can be assumed. > cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape > ought to be expanded to handle all characters or a new routine should be > added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I > have zero familiarity with XML and am waiting for 2.0final. Perhaps > this should be taken off-line? xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read the source (Lib/xml/sax/saxutils.py). It allows you to specify additional things to be replaced by entities by passing in a dictionary mapping chars (or strings) to entities. If you know that you are dealing with Latin-1, you could use the table in htmlentitydefs.py to construct a table. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Thu Oct 5 21:13:34 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051952.PAA05883@panix6.panix.com> References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> <200010051952.PAA05883@panix6.panix.com> Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net> >>>>> "AM" == aahz writes: >> [Aahz] >>> Someone just pointed out on c.l.py that we need an HTMLescape() >>> function that takes a string and converts special characters to >>> entities. I'm not on python-dev, so could you please forward >>> this and find out whether I need to run a PEP? >> >> Has someone pointed out yet that this is done by cgi.escape()? AM> Yeah, I missed that earlier. But after thinking some more, AM> there are a fair number of browser-like bits of software that AM> fail to render many of the special characters correctly AM> (e.g. trademark). This is frequently due to character set AM> issues; entities almost always render correctly, though. AM> Therefore a general translation routine is probably handy. AM> cgi.escape() only handles "&", "<", ">". I'm not sure whether AM> cgi.escape ought to be expanded to handle all characters or a AM> new routine should be added. Martin van Loewis suggested AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML AM> and am waiting for 2.0final. Perhaps this should be taken AM> off-line? Perhaps we should take it to python-list -- or maybe we should form a web-sig and work on it there. There are definitely some tricky issues to work out. I attempted to work out some of the same issues for internationalization support in Mailman's pipermail archives. The escape function in cgi should stay minimal, because it deals with the only truly essential characters. If the browser interprets an HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are going to be rendered properly. You can add an explicit meta tag to the HTML page and the server will return the charset in the headers. This seems quite a bit simpler than trying to escape all characters > chr(127), except if you have to deal with old browsers that don't support the charset specified by the HTTP header. Jeremy From thomas@xs4all.net Thu Oct 5 22:40:22 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 5 Oct 2000 23:40:22 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700 References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <20001005234022.I12812@xs4all.nl> On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007 > Modified Files: > configure configure.in > Log Message: > Change all occurances of > > test -d "$directory" > to > test ! -z "directory" -a -d "directory" > Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string > always returns true. This closes SF bug #115392. > --- 3103,3110 ---- > USE_THREAD_MODULE="#" > else > ! if test ! -z $with_threads -a -d $with_threads > then LDFLAGS="$LDFLAGS -L$with_threads" > fi > ! if test ! -z $withval -a -d $withval > then LDFLAGS="$LDFLAGS -L$withval" > fi Is this really going to work ? I always see 'portable' shell code do something like if [ "X${spam}" != "X" ] ... instead of 'test -z', eventhough even BSDI test has -z. (The portable code I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is minimal, compared to modern day equivalents.) My /bin/sh-knowledge is decidedly less impressive than my Python knowledge, but I thought something like if test ! -z $withval -a -d $withval where $withval is empty, would be parsed as if test ! -z -a -d which would be, uhm, wrong ? But like I said, I don't really know what I'm talking about here, there could be another perfectly valid reason for BSDI to use the roundabout way, instead of using -z. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Thu Oct 5 23:12:09 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net> >>>>> "GvR" =3D=3D Guido van Rossum writes: GvR> Whatever the outcome of this discussion, this is too late for GvR> 2.0. But I tend to side with Jeremy and Martin -- "explicit is GvR> better". I do want Jeremy to check his RPM generation scripts GvR> in, so they can be improved in a truly open source project. GvR> (Maybe in Tools/rpm?) I don't actually use a script to generate the RPM. I wrote a .spec file by hand and use it to generate the RPMs using the rpm command. I could check in the spec file, which I would end up changing every time we do a release -- to update the version number, change the Setup.in patch, etc. I should probably also include the patch file along with the .spec file. I also wrote a smal distutils setup script for 2.0b2, which I should check in somewhere. Not sure where... BTW, I've attached the spec file below. You can get it from the .src.rpm on pythonlabs.com, but that's pretty inconvenient if you're merely curious. Jeremy %define name BeOpen-Python %define version 2.0b2 %define release 1 %define __prefix /usr/local Summary: An interpreted, interactive, object-oriented programming langu= age. Name: %{name} Version: %{version} Release: %{release} Copyright: Modified CNRI Open Source License Group: Development/Languages Source: %{name}-%{version}.tar.bz2 Source1: html-%{version}.tar.bz2 Patch0: %{name}-%{version}-Setup.patch BuildRoot: /var/tmp/%{name}-%{version}-root Prefix: %{__prefix} URL: http://www.pythonlabs.com/ Vendor: BeOpen PythonLabs Packager: Jeremy Hylton %description Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very hi= gh level dynamic data types, and classes. Python combines remarkable power= with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C= or C++. It is also usable as an extension language for applications that n= eed a programmable interface. Finally, Python is portable: it runs on many= brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the Mac. %changelog * Thu Oct 5 2000 Jeremy Hylton - added bin/python2.0 to files list (suggested by Martin v. L=F6wis) * Tue Sep 26 2000 Jeremy Hylton - updated for release 1 of 2.0b2 - use .bz2 version of Python source * Tue Sep 12 2000 Jeremy Hylton - Version 2 of 2.0b1 - Make the package relocatable. Thanks to Suchandra Thapa. - Exclude Tkinter from main RPM. If it is in a separate RPM, it is easier to track Tk releases. %prep %setup -n Python-%{version} %patch0=20 %setup -D -T -a 1 -n Python-%{version} # This command drops the HTML files in the top-level build directory. # That's not perfect, but it will do for now. %build ./configure make %install [ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{__prefix} make prefix=3D$RPM_BUILD_ROOT%{__prefix} install %clean rm -fr $RPM_BUILD_ROOT %files %defattr(-, root, root) %{__prefix}/bin/python %{__prefix}/bin/python2.0 %{__prefix}/man/man1/python.1 %doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Portin= g %doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS %doc index.html modindex.html api dist doc ext inst lib mac ref tut ico= ns %dir %{__prefix}/include/python2.0 %{__prefix}/include/python2.0/*.h %dir %{__prefix}/lib/python2.0/ %{__prefix}/lib/python2.0/*.py* %{__prefix}/lib/python2.0/pdb.doc %{__prefix}/lib/python2.0/profile.doc %dir %{__prefix}/lib/python2.0/config %{__prefix}/lib/python2.0/config/Makefile %{__prefix}/lib/python2.0/config/Makefile.pre.in %{__prefix}/lib/python2.0/config/Setup %{__prefix}/lib/python2.0/config/Setup.config %{__prefix}/lib/python2.0/config/Setup.local %{__prefix}/lib/python2.0/config/config.c %{__prefix}/lib/python2.0/config/config.c.in %{__prefix}/lib/python2.0/config/install-sh %{__prefix}/lib/python2.0/config/libpython2.0.a %{__prefix}/lib/python2.0/config/makesetup %{__prefix}/lib/python2.0/config/python.o %dir %{__prefix}/lib/python2.0/curses %{__prefix}/lib/python2.0/curses/*.py* %dir %{__prefix}/lib/python2.0/distutils %{__prefix}/lib/python2.0/distutils/*.py* %{__prefix}/lib/python2.0/distutils/README %dir %{__prefix}/lib/python2.0/distutils/command %{__prefix}/lib/python2.0/distutils/command/*.py* %{__prefix}/lib/python2.0/distutils/command/command_template %dir %{__prefix}/lib/python2.0/encodings %{__prefix}/lib/python2.0/encodings/*.py* %dir %{__prefix}/lib/python2.0/lib-dynload %dir %{__prefix}/lib/python2.0/lib-tk %{__prefix}/lib/python2.0/lib-tk/*.py* %{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so %{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so %{__prefix}/lib/python2.0/lib-dynload/_localemodule.so %{__prefix}/lib/python2.0/lib-dynload/arraymodule.so %{__prefix}/lib/python2.0/lib-dynload/binascii.so %{__prefix}/lib/python2.0/lib-dynload/cPickle.so %{__prefix}/lib/python2.0/lib-dynload/cStringIO.so %{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so %{__prefix}/lib/python2.0/lib-dynload/errnomodule.so %{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so %{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so %{__prefix}/lib/python2.0/lib-dynload/grpmodule.so %{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so %{__prefix}/lib/python2.0/lib-dynload/mathmodule.so %{__prefix}/lib/python2.0/lib-dynload/md5module.so %{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so %{__prefix}/lib/python2.0/lib-dynload/newmodule.so %{__prefix}/lib/python2.0/lib-dynload/operator.so %{__prefix}/lib/python2.0/lib-dynload/parsermodule.so %{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so %{__prefix}/lib/python2.0/lib-dynload/pyexpat.so %{__prefix}/lib/python2.0/lib-dynload/readline.so %{__prefix}/lib/python2.0/lib-dynload/resource.so %{__prefix}/lib/python2.0/lib-dynload/rotormodule.so %{__prefix}/lib/python2.0/lib-dynload/selectmodule.so %{__prefix}/lib/python2.0/lib-dynload/shamodule.so %{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so %{__prefix}/lib/python2.0/lib-dynload/stropmodule.so %{__prefix}/lib/python2.0/lib-dynload/structmodule.so %{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so %{__prefix}/lib/python2.0/lib-dynload/termios.so %{__prefix}/lib/python2.0/lib-dynload/timemodule.so %{__prefix}/lib/python2.0/lib-dynload/ucnhash.so %{__prefix}/lib/python2.0/lib-dynload/unicodedata.so %{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so %dir %{__prefix}/lib/python2.0/lib-old %{__prefix}/lib/python2.0/lib-old/*.py* %dir %{__prefix}/lib/python2.0/plat-linux2 %{__prefix}/lib/python2.0/plat-linux2/*.py* %{__prefix}/lib/python2.0/plat-linux2/regen %dir %{__prefix}/lib/python2.0/site-packages %{__prefix}/lib/python2.0/site-packages/README %dir %{__prefix}/lib/python2.0/test %{__prefix}/lib/python2.0/test/*.py* %{__prefix}/lib/python2.0/test/README %{__prefix}/lib/python2.0/test/audiotest.au %{__prefix}/lib/python2.0/test/greyrgb.uue %{__prefix}/lib/python2.0/test/test.xml %{__prefix}/lib/python2.0/test/testimg.uue %{__prefix}/lib/python2.0/test/testimgr.uue %{__prefix}/lib/python2.0/test/testrgb.uue %dir %{__prefix}/lib/python2.0/test/output %{__prefix}/lib/python2.0/test/output/test_* %dir %{__prefix}/lib/python2.0/xml %{__prefix}/lib/python2.0/xml/*.py* %dir %{__prefix}/lib/python2.0/xml/dom %{__prefix}/lib/python2.0/xml/dom/*.py* %dir %{__prefix}/lib/python2.0/xml/sax %{__prefix}/lib/python2.0/xml/sax/*.py* From fdrake@beopen.com Fri Oct 6 01:14:20 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> --uThC8vgBh0 Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit I just got this message from the gcc-announce list. We've seen bug reports related to GCC 2.96 (which may or may not be the problem). We need to be aware that these releases are out there and can be a problem. I've noticed that the version of GCC shipped with Mandrake 7.1 is "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much confidence either. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --uThC8vgBh0 Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Received: by ns1.beopen.com (mbox fdrake) (with Cubic Circle's cucipop (v1.31 1998/05/13) Thu Oct 5 17:12:18 2000) X-From_: gcc-announce-return-24-fdrake=acm.org@gcc.gnu.org Thu Oct 5 17:07:40 2000 Return-Path: Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by ns1.beopen.com (8.9.3/8.9.3) with ESMTP id RAA90031 for ; Thu, 5 Oct 2000 17:07:39 -0700 (PDT) (envelope-from gcc-announce-return-24-fdrake=acm.org@gcc.gnu.org) Received: from sourceware.cygnus.com (sourceware.cygnus.com [205.180.83.71]) by mail.acm.org (8.9.3/8.9.3) with SMTP id UAA45682 for ; Thu, 5 Oct 2000 20:05:32 -0400 Received: (qmail 23247 invoked by alias); 6 Oct 2000 00:03:53 -0000 Mailing-List: contact gcc-announce-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Archive: List-Post: List-Help: Delivered-To: mailing list gcc-announce@gcc.gnu.org Delivered-To: moderator for gcc-announce@gcc.gnu.org Received: (qmail 20621 invoked from network); 5 Oct 2000 23:58:16 -0000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Gerald Pfeifer Sender: gcc-announce-owner@gcc.gnu.org To: gcc-announce@gcc.gnu.org Subject: GCC 2.96 Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST) It has come to our attention that some GNU/Linux distributions are currently shipping with ``GCC 2.96''. We would like to point out that GCC 2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code- name for our development branch that will eventually become GCC 3.0. Current snapshots of GCC, and any version labeled 2.96, produce object files that are not compatible with those produced by either GCC 2.95.2 or the forthcoming GCC 3.0. Therefore, programs built with these snapshots will not be compatible with any official GCC release. Actually, C and Fortran code will probably be compatible, but code in other languages, most notably C++ due to incompatibilities in symbol encoding (``mangling''), the standard library and the application binary interface (ABI), is likely to fail in some way. Static linking against C++ libraries may make a binary more portable, at the cost of increasing file size and memory use. To avoid any confusion, we have bumped the version of our current development branch to GCC 2.97. Please note that both GCC 2.96 and 2.97 are development versions; we do not recommend using them for production purposes. Binaries built using any version of GCC 2.96 or 2.97 will not be portable to systems based on one of our regular releases. If you encounter a bug in a compiler labeled 2.96, we suggest you contact whoever supplied the compiler as we can not support 2.96 versions that were not issued by the GCC team. Please see http://gcc.gnu.org/snapshots.html if you want to use our latest snapshots. We suggest you use 2.95.2 if you are uncertain. The GCC Steering Committee --uThC8vgBh0-- From thomas@xs4all.net Fri Oct 6 01:29:11 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 6 Oct 2000 02:29:11 +0200 Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400 References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> Message-ID: <20001006022910.J12812@xs4all.nl> On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote: > I just got this message from the gcc-announce list. We've seen bug > reports related to GCC 2.96 (which may or may not be the problem). We > need to be aware that these releases are out there and can be a > problem. > I've noticed that the version of GCC shipped with Mandrake 7.1 is > "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much > confidence either. ;( The 'unstable' branch of Debian currently ships with: gcc version 2.95.2 20000220 (Debian GNU/Linux) and it seems to be working fine. I did notice a problem, but it was related to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have caught that one, but I found it on my machine before he checked in that fix ;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h include file: /* Number of bits in a word of type ong int'. */ #if LONG_MAX == 2147483647 # define LONG_BIT 32 #else /* Safe assumption. */ # define LONG_BIT 64 #endif where LONG_MAX was not defined (yet). I fixed it 'manually' for more than just Python by adding #ifndef LONG_MAX #define LONG_MAX 2147483647 #endif above it. I had to laugh, though, when I saw that assuming longs had 64 bits is considered 'a safe assumption'. I guess most people use 64 bit machines nowadays ? :-) I'm not complaining about this, though. Woody (Debian's current unstable tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm also wondering where to send my bugreport, but I think I'll read some documentation before I do that, first ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Fri Oct 6 02:37:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <20001006022910.J12812@xs4all.nl> References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> <20001006022910.J12812@xs4all.nl> Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > The 'unstable' branch of Debian currently ships with: > gcc version 2.95.2 20000220 (Debian GNU/Linux) > > and it seems to be working fine. I did notice a problem, but it was related I understand this to be the latest "stable" version of GCC, and it appearantly it has been accepted as such for a while now. > above it. I had to laugh, though, when I saw that assuming longs had 64 bits > is considered 'a safe assumption'. I guess most people use 64 bit machines > nowadays ? :-) Hey, my machine is 4294967296 bits! Forget those ancient 64 bit machines! ;-) > I'm not complaining about this, though. Woody (Debian's current unstable > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm I'm less concerned about people who know they're deliberatly putting themselves on the bleeding edge than the people that pick up the latest version of some Linux distribution and find they have a buggy compiler because the distribution builders weren't as careful as perhaps they should have been. Putting together a professional grade Linux distro is still a very hard thing. There's no such thing as enough testing here! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH@ActiveState.com Fri Oct 6 04:52:13 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Fri, 6 Oct 2000 14:52:13 +1100 Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c In-Reply-To: Message-ID: [Me, responding to Jeremy's request I look for potential buffer exploits on Windows...] > I will be happy to look into this. And was :-) If anyone has time over the next day or 2, any holes I either missed, or added(!) in http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547 0 would be appreciated! Thanks, Mark. From thomas.heller@ion-tof.com Fri Oct 6 08:20:56 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri, 6 Oct 2000 09:20:56 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> > I don't actually use a script to generate the RPM. I wrote a .spec > file by hand and use it to generate the RPMs using the rpm command. > I could check in the spec file, which I would end up changing every > time we do a release -- to update the version number, change the > Setup.in patch, etc. I should probably also include the patch file > along with the .spec file. > > I also wrote a smal distutils setup script for 2.0b2, which I should > check in somewhere. Not sure where... > Could you post this script? Thomas From loewis@informatik.hu-berlin.de Thu Oct 5 20:49:26 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST) Subject: [Python-Dev] PEP 4: Deprecation of standard modules Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de> I just finished a first draft of a PEP on deprecating (and eventually removing) modules from the standard Python library; it is available from http://python.sourceforge.net/peps/pep-0004.html If you have comments or suggestions on the proposed procedures, or the wording of the text, please send me a message. According to the PEP procedures (PEP 1), this is the preferred way of progressing this PEP (rather than discussing it on these lists), at least initially. Regards, Martin From loewis@informatik.hu-berlin.de Fri Oct 6 13:39:05 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de> > The difficulty, I assume, lies in figuring out which encodings > support what characters. It's not that difficult to write a set of new codecs; with the module below, I can do >>> import xmlenc >>> u'\u0416'.encode('latin-1-xml') 'Ж' >>> unicode('XɅY','latin-1-xml') u'X\u0245Y' The difficulty is that the algorithm is not very efficient if there are many unsupported characters in a string. Regards, Martin # Module implementing a set of new encodings of the form -xml # Copyright Martin v. Löwis # It currently supports hex character references only import codecs class CodecWrapper: def __init__(self,encoder,decoder): self.encoder = encoder self.decoder = decoder def encode(self,input,errors='strict'): try: return self.encoder(input,"strict") except ValueError: l = len(input) if l==1: return "&#x%x;" % ord(input), 1 s1,l1 = self.encode(input[:l/2]) s2,l2 = self.encode(input[l/2:]) return s1+s2,l1+l2 def decode(self,input,errors='strict'): input = str(input) # might be buffer object pos = input.find("&#x") if pos == -1: return self.decoder(input,errors) r1,l1 = self.decode(input[:pos],errors) end = input.find(";",pos) try: if end==-1: raise ValueError # goto failure code below val = int(input[pos+3:end],16) r2,l2 = self.decode(input[end+1:],errors) return r1+unichr(val)+r2,l1+end-pos+l2 except ValueError: # how to deal with errors in decode? r2,l2 = self.decode(input[pos+2:],errors) return r1+"&#x"+r2,l1+3+l2 def mkreader(self): r = codecs.StreamReader() r.decode = self.decode r.encode = self.encode return r def mkwriter(self): r = codecs.StreamWriter() r.decode = self.decode r.encode = self.encode return r def search_function(encoding): if not encoding.endswith("-xml"): return None enc,dec,reader,writer = codecs.lookup(encoding[:-4]) c = CodecWrapper(enc,dec) return c.encode,c.decode,c.mkreader,c.mkwriter codecs.register(search_function) From jeremy@beopen.com Fri Oct 6 15:54:03 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> <003d01c02f65$fb409550$4500a8c0@thomasnotebook> Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net> --cQL1MOyU0I Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here is the setup script I used to build the Tk RPMs. The name and version part is a mess and I would welcome suggestions on how to fix it. The problem is that Tkinter gets built against a particular version of Python and a particular version of Tcl/Tk. I want the name of the RPM to indiciate both versions, but didn't seem an obvious way to accomplish it. Thus, I put the Python version number in the name and the Tcl/Tk version number in the version. Otherwise, I think this is pretty straightforward distutils stuff (although the documentation was out of date last I checked). I've attached three files. I wrote setup.py and setup.cfg. Distutils created MANIFEST. Jeremy --cQL1MOyU0I Content-Type: text/plain Content-Disposition: inline; filename="setup.py" Content-Transfer-Encoding: 7bit #! /usr/bin/env python """Tkinter is the Python interface to the Tk GUI toolkit. Tk offers native look and feel on most major platforms, including Unix, Windows, and Macintosh. The Tkinter-2.0 RPM contains the Python C extension module for Python 2.0. The Python source files are distributed with the main Python distribution.""" from distutils.core import setup, Extension setup(name="Tkinter-2.0", version="8.0", description="Python interface to Tk GUI toolkit", author="Python development team", author_email="pythoneers@beopen.com", url="http://www.pythonlabs.com/products/python2.0/", licence="Modified CNRI Open Source License", ext_modules=[Extension("_tkinter", ["src/_tkinter.c", "src/tkappinit.c"], define_macros=[('WITH_APPINIT', None)], library_dirs=["/usr/X11R6/lib"], libraries=["tk8.0", "tcl8.0", "X11"], )], long_description = __doc__ ) --cQL1MOyU0I Content-Type: text/plain Content-Disposition: inline; filename="setup.cfg" Content-Transfer-Encoding: 7bit [bdist_rpm] packager = Jeremy Hylton vendor = BeOpen PythonLabs --cQL1MOyU0I Content-Type: text/plain Content-Disposition: inline; filename="MANIFEST" Content-Transfer-Encoding: 7bit setup.py src/_tkinter.c src/tkappinit.c --cQL1MOyU0I-- From jeremy@beopen.com Fri Oct 6 20:11:43 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net> I just fixed a number of major bugs in the undocumented linuxaudiodev module. I ended up spending about an hour reading the excellent Open Sound System (OSS) Programmer's Guide to figure out what the module was trying to do and why it wasn't working on my Linux box. After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python. I propose we develop a Python module for Python 2.1 and call it osslib. There is nothing at all that is Linux-specific about the interface being used. The OSS guide mentions a plethora of platforms that it supports. In the interim, I have fixed some of the most egregious problems. I would appreciate it if Linux users could try out the fixes and the new test case. On my machine it still sounds awful, but at least the sound can be heard. Jeremy From akuchlin@mems-exchange.org Fri Oct 6 20:17:39 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 6 Oct 2000 15:17:39 -0400 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400 References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >After reading the module and the OSS guide, it is clear to me that we >need a complete re-write. The module itself is just a wrapper around >a bunch of read, write, and ioctl calls. It could all be implemented >in pure Python. So, is there any point in releasing linuxaudiodev at all, then, if it needs a complete rewrite? --amk From DavidA@ActiveState.com Fri Oct 6 20:39:21 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: > I propose we develop a Python module for Python 2.1 and call it > osslib. There is nothing at all that is Linux-specific about the > interface being used. The OSS guide mentions a plethora of platforms > that it supports. Have you evaluated http://net.indra.com/~tim/ossmodule/ ? From jeremy@beopen.com Fri Oct 6 20:47:27 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <20001006151739.A31189@kronos.cnri.reston.va.us> Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >> After reading the module and the OSS guide, it is clear to me >> that we need a complete re-write. The module itself is just a >> wrapper around a bunch of read, write, and ioctl calls. It could >> all be implemented in pure Python. AMK> So, is there any point in releasing linuxaudiodev at all, then, AMK> if it needs a complete rewrite? I would be include to chuck it, except that it also shipped with 1.6. I would hestitate to deprecate it so far into the release process. jeremy From jeremy@beopen.com Fri Oct 6 20:47:48 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net> I had no idea it existed. Jeremy From jeremy@beopen.com Fri Oct 6 20:54:35 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net> >>>>> "DA" == David Ascher writes: DA> Have you evaluated http://net.indra.com/~tim/ossmodule/ Okay. I took a quick look. It's really old (July 1997). It looks like a more reasonable wrapping than linuxaudiodev, although I would want to review it more carefully against the OSS programmer's guide. I would prefer a pure Python solution, because the code would be shorter and easier to read and maintain. It may be, however, that the ossmodule is still up-to-date; if so, it may be easier to use it than to rewrite it. Jeremy From ping@lfw.org Fri Oct 6 22:13:39 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > After reading the module and the OSS guide, it is clear to me that we > need a complete re-write. The module itself is just a wrapper around > a bunch of read, write, and ioctl calls. It could all be implemented > in pure Python. True. I think your osslib is a good idea. I wanted to take on this sort of project myself a few weeks ago but never had the time to really get started. From playing with the test script, i think all we care about having in C is audioop (and that's just for ulaw conversion). I would like to fix audioop so we can expect it to be present as a standard module; then we can have a module written in Python that provides uniform sound support for all platforms. > On my machine it still sounds awful, but at least the > sound can be heard. It should not sound awful. If it sounds too loud and scratchy, then maybe you need to use audioop to convert from Sun .au (ulaw) to raw samples first. This was the case with the Spanish inquisition clip. -- ?!ng From jeremy@beopen.com Fri Oct 6 23:28:57 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: >> On my machine it still sounds awful, but at least the sound can >> be heard. KPY> It should not sound awful. If it sounds too loud and scratchy, KPY> then maybe you need to use audioop to convert from Sun .au KPY> (ulaw) to raw samples first. This was the case with the KPY> Spanish inquisition clip. I don't think I know how to do that. I tried using sox to convert audiotest.au to audiotest.raw and it sounded just as bad on my machine. Perhaps I have my machine configured incorrectly, although CDs and Real Audio sound fine. Have you tried the new code, BTW? Does the test work on your machine? Jeremy From tim_one@email.msn.com Fri Oct 6 23:28:53 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 6 Oct 2000 18:28:53 -0400 Subject: [Python-Dev] test_StringIO broken Message-ID: test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' 1 test failed: test_StringIO This on Win98SE, broke sometime late this afternoon (EDT). Working elsewhere? From jeremy@beopen.com Fri Oct 6 23:59:41 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: References: Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net> The test was changed in a number of ways, but whoever checked it in didn't actually run the regression test! Also, the last messsage I see printed is: Failed to catch ValueError writing to closed StringIO. This ain't a case of forgetting to generate new output. This is just plain wrong. Jeremy From thomas@xs4all.net Fri Oct 6 23:56:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:56:08 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: ; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400 References: Message-ID: <20001007005608.K12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote: > test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' > 1 test failed: test_StringIO > This on Win98SE, broke sometime late this afternoon (EDT). Working > elsewhere? No. Fails the same way on my Linux box. And the problem is probably that the test was updated (two tests were uncommented) but the output file wasn't updated. Jim Fulton did the checkin, so he looks like the right person to fix it (and manually check that the generated output file is *correct*, of course ! ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA@ActiveState.com Sat Oct 7 00:01:37 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net> Message-ID: > Okay. I took a quick look. It's really old (July 1997). It looks > like a more reasonable wrapping than linuxaudiodev, although I would > want to review it more carefully against the OSS programmer's guide. > > I would prefer a pure Python solution, because the code would be > shorter and easier to read and maintain. It may be, however, that the > ossmodule is still up-to-date; if so, it may be easier to use it than > to rewrite it. Absolutely. I just remember some announcement about it. I suspect that what I remember is not that old, so it may make sense to do a little more digging than I did in the archives... --david From thomas@xs4all.net Fri Oct 6 23:58:19 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:58:19 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400 References: <14814.22877.882280.651958@bitdiddle.concentric.net> Message-ID: <20001007005819.L12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: > Also, the last messsage I see printed is: > Failed to catch ValueError writing to closed StringIO. > This ain't a case of forgetting to generate new output. This is just > plain wrong. Hm, are you sure you re-built your modules before doing that ? The output looks okay on my linux box, in any case. The last message is 'Caught expected ValueError writing to closed StringIO: I/O operation on closed file', for me. If you recompiled cStringIO, something odd is going on ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Sat Oct 7 00:06:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: <20001007005819.L12812@xs4all.nl> References: <14814.22877.882280.651958@bitdiddle.concentric.net> <20001007005819.L12812@xs4all.nl> Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: >> Also, the last messsage I see printed is: Failed to catch >> ValueError writing to closed StringIO. >> This ain't a case of forgetting to generate new output. This is >> just plain wrong. TW> Hm, are you sure you re-built your modules before doing that ? This is probably what went wrong for me. Jeremy From guido@python.org Sat Oct 7 14:51:12 2000 From: guido@python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 08:51:12 -0500 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST." <200010062309.QAA32052@slayer.i.sourceforge.net> References: <200010062309.QAA32052@slayer.i.sourceforge.net> Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> > Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE). The > parsing functions in support of auto-indent weren't expecting Unicode > strings, but text.get() can now return them (although it remains muddy as > to exactly when or why that can happen). Fixed that with a Big Hammer. I apologize, I should have explained when text.get() returns Unicode: Any string returned from Tcl/Tk that contains a byte with the 8th bit set is translated from UTF-8 into Unicode, unless the translation fails (in which case the original raw 8-bit string is returned as a fallback). This *should* be correct because Tcl/Tk always uses UTF-8 internally. (Even though it is "lenient" when receiving strings -- if a sequence of characters has no valid Unicode representation, it appears to falls back to Latin-1; I don't know the details of this algorithm.) --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Sat Oct 7 19:43:55 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 7 Oct 2000 14:43:55 -0400 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> Message-ID: >> Fix for next iteration of SF bug 115690 (Unicode headaches in >> IDLE). ... [Guido] > I apologize, I should have explained when text.get() returns Unicode: > > Any string returned from Tcl/Tk that contains a byte with the 8th bit > set is translated from UTF-8 into Unicode, unless the translation > fails (in which case the original raw 8-bit string is returned as a > fallback). Except that's *why* it was muddy : in the specific case that popped up in the bug, text.get() appeared to return a Unicode string of length 1 containing only a newline. No high-bit byte appeared to be involved. However, that was an illusion I didn't unmask until later. All is clear now. > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > (Even though it is "lenient" when receiving strings -- if a sequence > of characters has no valid Unicode representation, it appears to falls > back to Latin-1; I don't know the details of this algorithm.) Dunno, but wouldn't be surprised if they had a notion of default encoding, and that it simply appears to be Latin-1 to us because American Windows uses a superset of Latin-1. If BeOpen would like to buy me a version of Chinese Windows, happy to lend it to you . as-american-as-they-come-ly y'rs - tim From guido@python.org Sun Oct 8 02:41:11 2000 From: guido@python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 20:41:11 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400." <14814.21033.195290.728159@bitdiddle.concentric.net> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com> I think I fixed the linuxaudio test -- see if it sounds reasonable now! The crux of the matter seemed to be that the last, optional argument to setparameters(), meaning "emulate the format if the sound card doesn't support it", is not supported right. It suppresses the error message, and the ioctl to set the format succeeds, but the emulation doesn't work (at least not on my system, or on Jeremy's). So I've used a subterfuge: assuming most sound cards support signed 16-bit native-endian format, I convert the data to that format, and use the appropriate format code: AFMT_S16_LE for little-endian machines, AFMT_S16_BE for big-endian machines. I've only tested little-endian. I use the new sys.byteorder variable to determine the endianness. I use the audioop module to do the conversion. Much simpler than sox! (Oh feeling of nostalgia... I wrote several of the file format handlers for sox, and fixed lots of bugs in it too... I even started the audio file formats FAQ, now maintained by Chris Bagwell, who also took over sox...) Downside: test_linuxaudiodev will now be skipped if you don't have the audioop enabled in your Setup file. But that's fixed easily. By the way -- the checkin freeze for the release candidate should go in just about now... --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Sun Oct 8 11:32:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 06:32:36 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: Blast from the past! [/F] > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) [Tim] > How about instead enhancing existing (?Ppattern) notation, to > set a new match object attribute to name if & when pattern matches? > Then arbitrary info associated with a named pattern can be gotten at > via dicts via the pattern name, & the whole mess should be more > readable. [/F Sent: Sunday, July 02, 2000 6:35 PM] > I just added "lastindex" and "lastgroup" attributes to the match object. > > "lastindex" is the integer index of the last matched capturing group, > "lastgroup" the corresponding name (or None, if the group didn't have > a name). both attributes are None if no group were matched. Reviewing this before 2.0 has been on my todo list for 3+ months, and finally got to it. Good show! I converted some of my by-hand scanners to use lastgroup, and like it a whole lot. I know you understand why this is Good, so here's a simple example of an "after" tokenizer for those who don't (this one happens to tokenize REXX-like PARSE stmts): import re _token = re.compile(r""" (?P \s+) | (?P [a-zA-Z_]\w*) | (?P \.) | (?P \d+) | (?P [-+=()]) | (?P " [^"\\\n]* (?: \\. [^"\\\n]*)* " | ' [^'\\\n]* (?: \\. [^'\\\n]*)* ' ) """, re.VERBOSE).match del re (T_SPACE, T_VAR, T_DONTCARE, T_NUMBER, T_PUNC, T_STRING, T_EOF, ) = range(7) # For debug output. _enum2name = ["T_SPACE", "T_VAR", "T_DONTCARE", "T_NUMBER", "T_PUNC", "T_STRING", "T_EOF", ] _group2action = { "space": (T_SPACE, None), "var": (T_VAR, None), "dontcare": (T_DONTCARE, None), "number": (T_NUMBER, int), "punc": (T_PUNC, None), "string": (T_STRING, eval), } def tokenize(s, tokeneater): i, n = 0, len(s) while i < n: m = _token(s, i) if not m: raise ParseError(s, i) group = m.lastgroup enum, action = _group2action[group] val = m.group(group) if action is not None: val = action(val) tokeneater(enum, val) i = m.end() tokeneater(T_EOF, None) The tokenize function here used to be a mass of if/elif stmts trying to figure out which group had matched. Now it's all table-driven: easier to write, reuse & maintain, and quicker to boot. +1. the-aged-may-be-slow-but-they-never-forget-ly y'rs - tim From Fredrik Lundh" Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid> guido: > > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > > (Even though it is "lenient" when receiving strings -- if a sequence > > of characters has no valid Unicode representation, it appears to falls > > back to Latin-1; I don't know the details of this algorithm.) Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but their 8-bit strings use UTF-8. When converting from external 8-bit strings to unicode, they convert valid UTF-8 sequences to unicode characters just like Python, but "a lead-byte not followed by enough trail-bytes represents itself." (in other words, it's cast from an unsigned char to an unsigned short). And the chance that any reasonable Latin-1 string would contain a UTF-8 lead bytes followed by the right number of UTF-8 trail bytes is close to zero... (in case anyone wonders, Python's codec thinks that "close to zero" isn't good enough, so it raises an exception instead) tim: > Dunno, but wouldn't be surprised if they had a notion of default encoding, > and that it simply appears to be Latin-1 to us because American Windows uses > a superset of Latin-1. They have a system encoding, but it's not used here -- it's just that Latin-1 is a subset of Unicode... From thomas@xs4all.net Sun Oct 8 12:14:33 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 8 Oct 2000 13:14:33 +0200 Subject: [Python-Dev] Release candidate Message-ID: <20001008131433.M12812@xs4all.nl> Is there any chance we can get the 'release candidate' released on the SF File Module thingy as well ? Mailman uses this for the betas, for instance, and I think it would attract that bit more attention to it. I believe the 'release' gets listed on various SF pages that way. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@scottb.demon.co.uk Sun Oct 8 15:36:45 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 8 Oct 2000 15:36:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000401c03135$2ebd4ec0$060210ac@private> Tim, Two requests: 1. Can you ship the .PDB files for the debug images so devo's do not need to build the python sources to debug extensions. And Yes I know the .ZIP will be huge. If you want a compromise only include the .PDB for python20_d.dll. 2. Place the files into libs, pyd etc dirs. I had to extract the groups into the right places which is a bit tedious and error prone. BArry > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Tim Peters > Sent: 27 September 2000 23:40 > To: PythonDev; Python list > Subject: [Python-Dev] Python 2.0b2 note for Windows developers > > > Since most Python users on Windows don't have any use for them, I trimmed > the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe > and .dll files. If you want them, they're available in a separate zip > archive; read the Windows Users notes at > > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > for info and a download link. If you don't already know *why* you might > want them, trust me: you don't want them . > > they-don't-even-make-good-paperweights-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From ping@lfw.org Sun Oct 8 19:19:51 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > > Have you tried the new code, BTW? Does the test work on your machine? Works okay (i updated after Guido's last edit). Sounds fine to me. But it bugs me that some of the descriptions say "audio" and others say "format". This seems arbitrary -- is there a reason? Excerpt of Modules/linuxaudiodev.c: { 8, »­­­­­AFMT_MU_LAW, "Logarithmic mu-law audio" }, { 8, »­­­­­AFMT_A_LAW, "Logarithmic A-law audio" }, { 8,»­­­­­­AFMT_U8, "Standard unsigned 8-bit audio" }, { 8, »­­­­­AFMT_S8, "Standard signed 8-bit audio" }, { 16, »­­­­­AFMT_U16_BE, "Big-endian 16-bit unsigned format" }, { 16, »­­­­­AFMT_U16_LE, "Little-endian 16-bit unsigned format" }, { 16, »­­­­­AFMT_S16_BE, "Big-endian 16-bit signed format" }, { 16, »­­­­­AFMT_S16_LE, "Little-endian 16-bit signed format" }, If you don't mind, i'd prefer something like: { 8, »­­­­­AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" }, { 8, »­­­­­AFMT_A_LAW, "logarithmic A-law 8-bit audio" }, { 8,»­­­­­­AFMT_U8, "linear unsigned 8-bit audio" }, { 8, »­­­­­AFMT_S8, "linear signed 8-bit audio" }, { 16, »­­­­­AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" }, { 16, »­­­­­AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" }, { 16, »­­­­­AFMT_S16_BE, "linear signed 16-bit big-endian audio" }, { 16, »­­­­­AFMT_S16_LE, "linear signed 16-bit little-endian audio" }, The above conforms to: "audio" where ::= "logarithmic" ("mu-law" | "A-law") | "linear" ("unsigned" | "signed") ::= "8-bit" | "16-bit" ("big-endian" | "little-endian") -- ?!ng "Simple, yet complex." -- Lenore Snell From tim_one@email.msn.com Sun Oct 8 20:28:55 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 15:28:55 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private> Message-ID: [Barry] > Two requests: > > 1. Can you ship the .PDB files for the debug images so devo's > do not need to build the python sources to debug extensions. > And Yes I know the .ZIP will be huge. If you want a > compromise only include the .PDB for python20_d.dll. Sure! Most .pdb files are highly compressible, and the zip size hit isn't anything to worry about. > 2. Place the files into libs, pyd etc dirs. I had to extract > the groups into the right places which is a bit tedious > and error prone. No. If you want a directory structure that doesn't match the actual build directory structure, I can't read your mind, and have no reason to believe that the specific artificial structure you have in mind is of use to anyone but you. Don't be so helpless : write a tiny Python script to move the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python themselves and just want to avoid jumping thru all the snaky hoops needed to compile the 3rd-party subprojects (from _tkinter to zlib). alphabetically y'rs - tim From guido@python.org Sun Oct 8 21:52:54 2000 From: guido@python.org (Guido van Rossum) Date: Sun, 08 Oct 2000 15:52:54 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST." References: Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com> > But it bugs me that some of the descriptions say "audio" and others say > "format". This seems arbitrary -- is there a reason? Okay, you're right. (But there are sooooo many other things wrong with the code still... E.g. the bogus reference to "ctl". :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Mon Oct 9 07:04:55 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 08 Oct 2000 23:04:55 -0700 Subject: [Python-Dev] A standard lexer? References: Message-ID: <39E16007.5F1DDF9A@prescod.net> Tim Peters wrote: > > ... > > Reviewing this before 2.0 has been on my todo list for 3+ months, and > finally got to it. Good show! I converted some of my by-hand scanners to > use lastgroup, and like it a whole lot. I know you understand why this is > Good, so here's a simple example of an "after" tokenizer for those who don't > (this one happens to tokenize REXX-like PARSE stmts): Is there a standard technique for taking a regexp like this and applying it to data fed in a little at a time? Other than buffering the data forever? That's something else I would like in a "standard Python lexer", if that's the goal. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido@beopen.com Thu Oct 5 14:16:14 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 5 Oct 2000 09:16:14 -0400 Subject: [Python-Dev] htmllib.HTMLescape() References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com> Note that cgi.escape() does this too. --Guido ----- Original Message ----- From: "Martin von Loewis" To: Cc: Sent: Wednesday, October 04, 2000 4:31 PM Subject: [Python-Dev] htmllib.HTMLescape() > > Someone just pointed out on c.l.py that we need an HTMLescape() > > function that takes a string and converts special characters to > > entities. I'm not on python-dev, so could you please forward this > > and find out whether I need to run a PEP? > > Doesn't xml.sax.saxutils.escape do what you want (together with > htmlentitydefs)? I was going to say that this is quite a small change > to warrant a PEP - but there are two obvious approaches (working from > scratch, or working on top of xml.sax.saxutils.escape - perhaps > modifying and relocating that function), so *some* design probably > needs to be recorded in a PEP. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From loewis@informatik.hu-berlin.de Mon Oct 9 15:01:10 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com> (guido@beopen.com) References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com> Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de> > Note that cgi.escape() does this too. Indeed. That justifies a PEP that proposes to concentrate the functionality in one place, deprecating the other places. One approach would be to enhance the codec facilites, so that "string".encode("iso-entities") becomes possible - but that is already in the middle of discussing the PEP. Regards, Martin From jeremy@beopen.com Mon Oct 9 15:35:48 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36 In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net> References: <200010091418.HAA08765@slayer.i.sourceforge.net> Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net> Thanks. I didn't get to it on Friday. Jeremy From trentm@ActiveState.com Mon Oct 9 23:56:00 2000 From: trentm@ActiveState.com (Trent Mick) Date: Mon, 9 Oct 2000 15:56:00 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200 References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid> Message-ID: <20001009155600.A27929@ActiveState.com> [Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py fail on the overflow checks] [Fredrik gives me a simple test C program to test PyOS_CHeckStack independently (The test program is included at the bottom of this email.)] SOrry I took so long to reply to this but I spent a little bit of time playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated. Here is what I found: - The simple test program shows that PyOS_CheckStack will fire as intended on both Win32 and Win64 with either Visual C's default optimization OR no optimization. - The simple test program will *not* fire as intended with the '-O2' optimization which Python *does* use for pythonrun.c (where PyOS_CheckStack lives). So, likely the '-O2' optimization will optimize-away the _alloca() call. Fine. But why then does it *not* get optimized away when pythonrun.c is compiled? Does the context around other code in the same file affect that optimization? - When I apply this patch to _sre.c on *Win32* (basically the same test as the test file that Fredrik gave me to try) the "callme(0)" call *never* returns -- infinite loop. Note that this happens on the Release *and* Debug builds so nothing is being optimized away. *************** *** 560,565 **** --- 560,569 ---- } #endif + + + void callme(int i); + LOCAL(int) SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level) { *************** *** 578,583 **** --- 582,588 ---- TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level)); #if defined(USE_STACKCHECK) + callme(0); if (level % 10 == 0 && PyOS_CheckStack()) return SRE_ERROR_RECURSION_LIMIT; #endif *************** *** 2337,2340 **** --- 2342,2357 ---- Py_InitModule("_" MODULE, _functions); } + void callme(int i) + { + char buf[100000]; + if (PyOS_CheckStack()) + return; + printf("%d\n", i); + memset(buf, 0, sizeof buf); + callme(i+1); + } + + + #endif /* !defined(SRE_RECURSIVE) */ - I am not smart enough and/or (you decide :) do not have the inclination to figure this out (i.e. start looking at assembly code) just so _sre can use stack checking instead of the existing RECURSION_LIMIT framework (albeit the limited general usefullness of this) on Win64 so that test_sre.py can pass. Would it be alright for me to apply: *** python/dist/src/Include/pythonrun.h Sat Sep 16 09:31:31 2000 --- python/dist/src/Include/pythonrun.h Sun Oct 8 10:20:02 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif to disable stack checking on Win64 until Win64 become more mainstream and others can bang away at this? The important thing, I would think, is getting the test suite passing for Python 2.0. ------- test file mentioned above -------------------------------- #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ----------------------------------------------------- -- Trent Mick TrentM@ActiveState.com From jeremy@beopen.com Tue Oct 10 01:26:27 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT) Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net> I have placed pre-release copies of the 2.0 release candidate 1 source tarballs at ftp://python.beopen.com/pub/python/2.0c1/. We reserve the right two change these without notice prior to the official release :-). Jeremy From nas@arctrix.com Mon Oct 9 20:06:08 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Mon, 9 Oct 2000 12:06:08 -0700 Subject: [Python-Dev] test_import failing Message-ID: <20001009120608.A13588@glacier.fnational.com> I assume the CVS sources are basicly the same as 2.0c1. Anyhow, test_import is failing on my Debian machine. The script is creating "@test.py" and then trying to import it. "." is not in sys.path for some reason. Neil From jeremy@beopen.com Tue Oct 10 03:17:31 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net> I assume that you are running the test some way other than using "make test." It seems that make test executes python this way -- PYTHONPATH= ./python -- which causes the current directory to be added to the path. If you run python without having the current directory on your path test_import file fail. Unless you are having a different problem, this isn't important enough to fix in 2.0c1, although it seems good to fix for 2.0 final. Jeremy PS We have left GC turned on by default in 2.0c1 and plan to do the same for 2.0 final. From fdrake@beopen.com Tue Oct 10 03:09:34 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT) Subject: [Python-Dev] test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > test_import is failing on my Debian machine. The script is > creating "@test.py" and then trying to import it. "." is not in > sys.path for some reason. Jeremy & I finally figured this out. "make test" runs python with PYTHONPATH set to '' (an empty string). This is decidedly different from running with PYTHONPATH unset (I consider this a bug that should be fixed in 2.1). The empty string is interpreted as the current directory (as expected), so running "make test" adds the current directory to sys.path, but running the regression test (test_import or regrtest) as a script does not. We decided not to fix this now, since it's too late to be sure it's the right change, and adjusting the test case also means a very late change. So whoever runs the tests is responsible for making sure the current directory is on sys.path. (*Really* bogus!) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Oct 10 03:20:11 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Unless you are having a different problem, this isn't important enough > to fix in 2.0c1, although it seems good to fix for 2.0 final. And it's questionable how many bugs are hiding here as well. I count two: - test_import.py assumes the current directory is on the path; this is just plain fragile, and should explicitly pick the directory off of test_support.TESTFN, and add it to sys.path for the duration of the test (which does indeed fix this bug) - Modules/getpath.c interprets an empty definition of $PYTHONPATH as adding '' to sys.path, where I assert it should not add anything to sys.path. Everywhere else I've recall seeing an environment variable used as a data source, the test is done like this: char *cp = getenv("VARIABLE"); if (cp != NULL && cp[0] != '\0') { ... } (with some spelling variations). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Jeremy Hylton Tue Oct 10 07:52:48 2000 From: Jeremy Hylton (Jeremy Hylton) Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT) Subject: [Python-Dev] Python 2.0 release candidate 1 Message-ID: <200010100652.XAA74600@python.beopen.com> Python 2.0c1 is released. The BeOpen PythonLabs and our cast of SourceForge volunteers have fixed many bugs since the beta releases last month. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There's a tarball, a Windows installer, RedHat RPMs, online documentation, and a long list of fixed bugs. The final release of Python 2.0 will be next week. We would appreciate feedback on the release candidate in order to fix any remaining bugs before the final release. Confirmation of build and test success on less common platforms is also helpful.n All major reported bugs have been fixed in the release candidate. We do not plan to make any changes between now and the final release, except to fix bugs reported in the next week. We encourage potential users of Python 2.0 to try the release candidate with their programs and report any remaining bugs. To report a new bug, use the SourceForge bug tracker http://sourceforge.net/bugs/?func=addbug&group_id=5470 Python 2.0 has many new features, including the following: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0, please see the article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: http://starship.python.net/crew/amk/python/writing/new-python/ -- Jeremy Hylton From tismer@appliedbiometrics.com Tue Oct 10 11:33:36 2000 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Tue, 10 Oct 2000 13:33:36 +0300 Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9 Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com> ANNOUNCING: Stackless Python 1.2 A Python Implementation That Does Not Use The C Stack * plus the real toy * Continuation Module 0.9 Continuations as First Class Objects with support for MicroThreads What is it? A plugin-replacement for core Python. It should run any program which runs under Python 1.5.2 . But it does not need space on the C stack. For further info, see the new site at http://www.stackless.com You might also want to join the mailing list at http://starship.python.net/mailman/listinfo/stackless Major changes in this release: Extra reference counting reduces continuation frame creation Better exception handling avoids cycles. Next to come: - A port to Python 2.0 will be the first thing to do. - Long-term project is a complete redesign and rewrite for inclusion with Python 2.1 ciao - Christian Tismer / Mission Impossible 5oftware Team

Stackless Python 1.2 + Continuations 0.9 - a version of Python 1.5.2 that does not need space on the C stack, first-class callable continuation objects for Python, and Microthread-support. (10-Oct-2000)

-- http://www.python.org/mailman/listinfo/python-list From guido@python.org Tue Oct 10 14:04:39 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:04:39 -0500 Subject: [Python-Dev] test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400." <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com> > Neil Schemenauer writes: > > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > > test_import is failing on my Debian machine. The script is > > creating "@test.py" and then trying to import it. "." is not in > > sys.path for some reason. > > Jeremy & I finally figured this out. "make test" runs python with > PYTHONPATH set to '' (an empty string). This is decidedly different > from running with PYTHONPATH unset (I consider this a bug that should > be fixed in 2.1). > The empty string is interpreted as the current directory (as > expected), so running "make test" adds the current directory to > sys.path, but running the regression test (test_import or regrtest) as > a script does not. > We decided not to fix this now, since it's too late to be sure it's > the right change, and adjusting the test case also means a very late > change. So whoever runs the tests is responsible for making sure the > current directory is on sys.path. (*Really* bogus!) Proper fix, which I will check in momentarily: put import sys sys.path.insert(0, os.curdir) in front of test_import.py; and add del sys.path[0] to the end. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Oct 10 14:06:54 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:06:54 -0500 Subject: [Python-Dev] Re: test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400." <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com> > And it's questionable how many bugs are hiding here as well. I > count two: > > - test_import.py assumes the current directory is on the path; this > is just plain fragile, and should explicitly pick the directory > off of test_support.TESTFN, and add it to sys.path for the > duration of the test (which does indeed fix this bug) I'll fix this. > - Modules/getpath.c interprets an empty definition of $PYTHONPATH as > adding '' to sys.path, where I assert it should not add anything > to sys.path. Everywhere else I've recall seeing an environment > variable used as a data source, the test is done like this: > > char *cp = getenv("VARIABLE"); > if (cp != NULL && cp[0] != '\0') { > ... > } > > (with some spelling variations). Agreed, but please *don't fix this in 2.0!* Who knows how many other hidden bugs (in 3rd party code) this will trigger... OK to fix it after 2.0final is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Tue Oct 10 13:58:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 14:58:09 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 Message-ID: <39E31261.166F1601@lemburg.com> I've just had a glance at the releas candidate 1. The file LICENSE has grown somewhat, but not as much as I feared... looking at the contents I find the following as only reference to the CNRI license (which holds all the surprises we talked about in the early beta stages): """ CNRI OPEN SOURCE LICENSE AGREEMENT ---------------------------------- Python 1.6 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6 may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1012. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1012. """ Such a note is nice and short, but not legally binding and confusing since it is not clear whether the "handle" for the document will always return the same license text or if it will return a license text at all. It would be more appropriate to include the original CNRI license text, IMHO. Or is there some hidden motivation behind using the handle ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Tue Oct 10 14:06:05 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:06:05 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> There has been some confusion about distutils, especially the bdist_wininst command. I hope I can clarify these things with this post. 1. The current Distutils version 1.0, which is also included in the Python 2.0 release candidate is perfectly usable apart from one bug: You should create windows installers (by running 'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst') ONLY with an external zip utility (info-zip would do). Using the zipfile module results in corrupted installations (all files are created with zero length). Details about the cause for this can be found in the patch I posted to SF. 2. I submitted a patch to SF http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 which corrects this bug. Normally I would have checked this code in immediately, because it is in _my_ code, and that's what my checkin rights are for ;-). I did not because I did not want to interfere with the release process of python 2.0 rc 1. 3. How does bdist_wininst work? bdist_wininst creates a self-extracting zipfile from two components: a stub program (wininst.exe) plus a zip-file containing the code to be distributed. Because I did not liked wininst.exe as binary file checked in into CVS, the actual bytes of this exe are included base64-encoded in the bdist_wininst.py module as string. I'm not sure whether this is a wise design or not, but that is a different topic. The downside of this design is that when the source to wininst.exe changes, it must be recompiled, and bdist_wininst.py must be regenerated. The context-diffs for bdist_wininst.py are so very large. 4. To understand the patch, you should know the following: Distutils is a separate toplevel module in the repository on sourceforge. Parts of this repository are symbolically linked somewhere into the python tree. Thus, this patch must be applied to the distutils _module_ in the repository. Distutils directory structure is as follows: distutils dd distutils command doc dist inst examples sample1 sample2 sample3 misc test text Relevant part of python directory structure: python dist src Lib distutils command The source code for wininst.exe is in CVS in the distutils/misc directory. The patch I posted to SF does not include the compiled wininst.exe, neither does it include the (regenerated) bdist_wininst.py module. 5. If nobody objects, I will check in the changes I made tomorrow, recompile the exe, regenerate the bdist_wininst.py, and everything should be fine again. Greg will then hopefully, when he is back, increase the distutils version number to 1.0.1 (or whatever) and this version will then be delivered with python 2.0 final. Sorry for the confusion. Cheers, Thomas From guido@python.org Tue Oct 10 15:36:57 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:36:57 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200." <39E31261.166F1601@lemburg.com> References: <39E31261.166F1601@lemburg.com> Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com> > I've just had a glance at the releas candidate 1. The file LICENSE > has grown somewhat, but not as much as I feared... Since when? It hasn't changed since it was first released, for 2.0b1. > looking > at the contents I find the following as only reference to the > CNRI license (which holds all the surprises we talked about in > the early beta stages): > > """ > CNRI OPEN SOURCE LICENSE AGREEMENT > ---------------------------------- > > Python 1.6 is made available subject to the terms and conditions in > CNRI's License Agreement. This Agreement together with Python 1.6 may > be located on the Internet using the following unique, persistent > identifier (known as a handle): 1895.22/1012. This Agreement may also > be obtained from a proxy server on the Internet using the following > URL: http://hdl.handle.net/1895.22/1012. > """ > > Such a note is nice and short, but not legally binding and > confusing since it is not clear whether the "handle" for the > document will always return the same license text or if it > will return a license text at all. Why do you say it's not legally binding? The CNRI license explicitly allows you to use this exact text instead of including the whole CNRI license. > It would be more appropriate to include the original CNRI license > text, IMHO. Or is there some hidden motivation behind using the > handle ? I was just trying to save space. ActivePython does the same thing as far as I remember. BTW, I haven't heard from CNRI in two weeks, but the last thing I heard from them was that their lawyers had talked to Stallman's lawyer and that they were optimistic about a successful resolution. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Oct 10 15:41:50 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:41:50 -0500 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200." <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Thomas, thanks for the explanation. I agree that you can check in the changes yourself as you proposed. There's one issue I still don't understand (not having the time to read the full distutils docs): how does a typical Windows developer decide whether to use an external zip utility or the zipfile module? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller@ion-tof.com Tue Oct 10 14:58:32 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:58:32 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook> > Thomas, thanks for the explanation. I agree that you can check in the > changes yourself as you proposed. > > There's one issue I still don't understand (not having the time to > read the full distutils docs): how does a typical Windows developer > decide whether to use an external zip utility or the zipfile module? I'm afraid it is not documented. Distutils first tries to spawn an external zip program, then tries the zipfile module, if nothing is found, a warning is issued. So, the windows developer currently _must_ install zip.exe somewhere in the path. (As often, the default is wrong, because a zip utility is not included in windows). Thomas From mal@lemburg.com Tue Oct 10 15:03:14 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 16:03:14 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> Message-ID: <39E321A2.2BD99E35@lemburg.com> Guido van Rossum wrote: > > > I've just had a glance at the releas candidate 1. The file LICENSE > > has grown somewhat, but not as much as I feared... > > Since when? It hasn't changed since it was first released, for 2.0b1. Since the old 1.5.2 LICENSE file. > > looking > > at the contents I find the following as only reference to the > > CNRI license (which holds all the surprises we talked about in > > the early beta stages): > > > > """ > > CNRI OPEN SOURCE LICENSE AGREEMENT > > ---------------------------------- > > > > Python 1.6 is made available subject to the terms and conditions in > > CNRI's License Agreement. This Agreement together with Python 1.6 may > > be located on the Internet using the following unique, persistent > > identifier (known as a handle): 1895.22/1012. This Agreement may also > > be obtained from a proxy server on the Internet using the following > > URL: http://hdl.handle.net/1895.22/1012. > > """ > > > > Such a note is nice and short, but not legally binding and > > confusing since it is not clear whether the "handle" for the > > document will always return the same license text or if it > > will return a license text at all. > > Why do you say it's not legally binding? The CNRI license explicitly > allows you to use this exact text instead of including the whole CNRI > license. Sure, but not including the verbatim text will produce an unpleasent feeling of not being sure about the completeness of the license text. In a law suit the above construct would certainly not hold, since URLs only describe the location of information and don't hold any information about the validity or origin of it. The situation would be a little better if CNRI had provided a PGP signature or fingerprint of the license, since this is (in some countries) a legally accepted way of determining those two criteria. Just a side note: the URL given for the license results in a redirect to a different URL - http://www.handle.net/python_licenses/python1.6_9-5-00.html (note the date !): this doesn't really give the impression of persistent unchangeable information. Not that there's much to fear about... but why add any extra areas of uncertainty ? > > It would be more appropriate to include the original CNRI license > > text, IMHO. Or is there some hidden motivation behind using the > > handle ? > > I was just trying to save space. ActivePython does the same thing as > far as I remember. Space?... the download is 3.9 Megs ;-) > BTW, I haven't heard from CNRI in two weeks, but the last thing I > heard from them was that their lawyers had talked to Stallman's lawyer > and that they were optimistic about a successful resolution. Great ! This would be really good news indeed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From just@letterror.com Tue Oct 10 16:47:00 2000 From: just@letterror.com (Just van Rossum) Date: Tue, 10 Oct 2000 16:47:00 +0100 Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9 In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com> Message-ID: In response to the new release of Stackless Python (see http://www.stackless.com/), here's a new stackless binary for MacPython 1.5.2: http://starship.python.net/~just/MacStacklessPython.sit.hqx (The archive contains a replacement for the PythonCore shared library) Just From guido@python.org Tue Oct 10 16:50:07 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 10:50:07 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200." <39E321A2.2BD99E35@lemburg.com> References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> <39E321A2.2BD99E35@lemburg.com> Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com> > > > Such a note is nice and short, but not legally binding and > > > confusing since it is not clear whether the "handle" for the > > > document will always return the same license text or if it > > > will return a license text at all. > > > > Why do you say it's not legally binding? The CNRI license explicitly > > allows you to use this exact text instead of including the whole CNRI > > license. > > Sure, but not including the verbatim text will produce an > unpleasent feeling of not being sure about the completeness > of the license text. > > > > In a law suit the above construct would > certainly not hold, since URLs only describe the location of > information and don't hold any information about the validity > or origin of it. The situation would be a little better if CNRI > had provided a PGP signature or fingerprint of the license, > since this is (in some countries) a legally accepted way of > determining those two criteria. > > Just a side note: the URL given for the license results in a > redirect to a different URL - > http://www.handle.net/python_licenses/python1.6_9-5-00.html > (note the date !): this doesn't really give the impression of > persistent unchangeable information. > > Funny... I agree that's not very confidence-inspiring. CNRI always advertises handles as better than URLs for long-term persistent documents, but it's clear that they didn't think of this! Or maybe (warning: fake conspiracy theory ahead :-) they intend to change the license terms after the fact... > Not that there's much to fear about... but why add any extra areas > of uncertainty ? Agreed. I'll add the full text back in. > > I was just trying to save space. ActivePython does the same thing as > > far as I remember. > > Space?... the download is 3.9 Megs ;-) I meant less text for the reader to wade through. But you've convinced me already. --Guido van Rossum (home page: http://www.python.org/~guido/) From bjorn@roguewave.com Tue Oct 10 19:35:15 2000 From: bjorn@roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 12:35:15 -0600 Subject: [Python-Dev] Re: Python 2.0 release candidate 1 References: <200010100652.XAA74600@python.beopen.com> Message-ID: <39E36163.33291FAB@roguewave.com> Are there any instructions on how to build this for Win64/itanium anywhere? -- bjorn Jeremy Hylton wrote: > > Python 2.0c1 is released. The BeOpen PythonLabs and our cast of > SourceForge volunteers have fixed many bugs since the beta releases > last month. Please pick up the new release at > > http://www.pythonlabs.com/products/python2.0/ > > There's a tarball, a Windows installer, RedHat RPMs, online > documentation, and a long list of fixed bugs. > > The final release of Python 2.0 will be next week. We would > appreciate feedback on the release candidate in order to fix any > remaining bugs before the final release. Confirmation of build and > test success on less common platforms is also helpful.n > > All major reported bugs have been fixed in the release candidate. We > do not plan to make any changes between now and the final release, > except to fix bugs reported in the next week. We encourage potential > users of Python 2.0 to try the release candidate with their programs > and report any remaining bugs. > > To report a new bug, use the SourceForge bug tracker > http://sourceforge.net/bugs/?func=addbug&group_id=5470 > > Python 2.0 has many new features, including the following: > > - Augmented assignment, e.g. x += 1 > - List comprehensions, e.g. [x**2 for x in range(10)] > - Extended import statement, e.g. import Module as Name > - Extended print statement, e.g. print >> file, "Hello" > - Collection of cyclical garbage > > For a fuller discussion of the changes in Python 2.0, please see the > article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: > http://starship.python.net/crew/amk/python/writing/new-python/ > > -- Jeremy Hylton > > -- > http://www.python.org/mailman/listinfo/python-list From trentm@ActiveState.com Tue Oct 10 20:51:55 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 12:51:55 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> Message-ID: <20001010125155.B3221@ActiveState.com> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > Are there any instructions on how to build this for Win64/itanium > anywhere? > Um... not really. I did/am doing the Win64 port but I have not really given the information required to build it, which, I agree, kind of sucks. I have not done so because: - the Python build system on Windows uses DevStudio project files - AFAIK there is no DevStudio yet for Win64 (if there were, building Python would be trivial, just setup a new configuration in DevStudio) - I am currently using a cross-compiler for Win64 provided by Intel (as part of a contract that ActiveState has to port Python to Win64 and other OSes for the IA-64 platform). I don't know if there is a publicly available compiler for Win64 (I haven't looked). - My method for building for Win64 involves: (1) exporting Win32 build makefile from the Python *.dsp files from within DevStudio. (2) running a hack script of my own to convert those to makefile to ones that will build for Win64 (these makefiles are extremely specific to my system, i.e. it is a hack) (3) run those makefiles I *could* checkin this hack script of mine and provide some documentation in Python's standard readme, if the other python-dev'ers would be ammenable to this. [Note: my files would be isolated to one directory, say PCbuild/win64.] As I said, I have not done this because I expected to just wait until DevStudio for Win64 came on the scene and then the build system for it would fit in smoothly to the current .dsp's. I would rather not become a separate provider of the Win64 build scripts because I don't want to support them outside of Python's mechanisms (i.e. through SourceForge). In other words, I'll check them into the Python core if others think that that is okay, otherwise I am afraid the answer is "please wait until DevStudio for Win64 comes along". Trent -- Trent Mick TrentM@ActiveState.com From bjorn@roguewave.com Tue Oct 10 21:24:00 2000 From: bjorn@roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 14:24:00 -0600 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> Message-ID: <39E37AE0.C7380FFD@roguewave.com> To answer some of your questions: - there is no win64 devstudio (and I haven't found a way of getting the current devstudio to use the new compiler) - Intel does have a native compiler for win64 (don't use it, see below). - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the Microsoft compiler. It works MUCH better. It's also binary compatible with the Intel ecl compiler, and they didn't have any problems with us switching. My main interest is in having a python version that runs on the itanium box with socket support (they included socket support in sdk2 didn't they?) I.e. no need to provide a build mechanism for my needs if you can refer me to an executable ;-) -- bjorn Trent Mick wrote: > > On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > > Are there any instructions on how to build this for Win64/itanium > > anywhere? > > > > Um... not really. I did/am doing the Win64 port but I have not really given > the information required to build it, which, I agree, kind of sucks. I have > not done so because: > > - the Python build system on Windows uses DevStudio project files > - AFAIK there is no DevStudio yet for Win64 (if there were, building Python > would be trivial, just setup a new configuration in DevStudio) > - I am currently using a cross-compiler for Win64 provided by Intel (as > part of a contract that ActiveState has to port Python to Win64 and other > OSes for the IA-64 platform). I don't know if there is a publicly > available compiler for Win64 (I haven't looked). > - My method for building for Win64 involves: > (1) exporting Win32 build makefile from the Python *.dsp files from > within DevStudio. > (2) running a hack script of my own to convert those to makefile to ones > that will build for Win64 (these makefiles are extremely specific to > my system, i.e. it is a hack) > (3) run those makefiles > > I *could* checkin this hack script of mine and provide some documentation in > Python's standard readme, if the other python-dev'ers would be ammenable to > this. [Note: my files would be isolated to one directory, say PCbuild/win64.] > As I said, I have not done this because I expected to just wait until > DevStudio for Win64 came on the scene and then the build system for it would > fit in smoothly to the current .dsp's. > > I would rather not become a separate provider of the Win64 build scripts > because I don't want to support them outside of Python's mechanisms (i.e. > through SourceForge). In other words, I'll check them into the Python core > if others think that that is okay, otherwise I am afraid the answer is > "please wait until DevStudio for Win64 comes along". > > Trent > > -- > Trent Mick > TrentM@ActiveState.com From trentm@ActiveState.com Tue Oct 10 21:20:42 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:20:42 -0700 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think Message-ID: <20001010132042.B22561@ActiveState.com> test_poll.py currently fails on Monterey (64-bit AIX) because of a difference in the system poll() function as compared to Linux. On Linux (and as required by the Signle Unix Specification: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()" a bogus file descriptor you get a POLLNVAL return value in the 'revents' field of the structure sent to poll(). This is tested like so in test_poll.py: # returns NVAL for invalid file descriptor FD = 42 try: os.close(FD) except OSError: pass p = select.poll() p.register(FD) r = p.poll() assert r[0] == (FD, select.POLLNVAL) Monterey decided to return -1 instead. [Aside: However, 'revents's type is "short" so the Python interface to poll() (using PyInt_FromLong) actually interprets that as -32768 instead.] Questions: 1. Can anybody offer an opinion if this is Python's or Monterey's problem? 2. Can anybody tell me where I can browse the POSIX spec to see if this breaks POSIX compliance as well? 3. Could someone (Vladimir?) run this test program on a normal AIX box and tell me what the output is (does the return value == POLLNVAL?)? ---------------------------------------------------------------------- #include #include #define NFDS 1 int main(void) { struct pollfd ufds[NFDS]; int pollResult; printf("hello\n"); /* poll for any event on a bogus file descriptor */ ufds[0].fd = 42; ufds[0].events = POLLIN | POLLPRI | POLLOUT; pollResult = poll(ufds, NFDS, -1); if (pollResult != 1) { printf("*** poll result was %d, I expected 1.\n", pollResult); } printf("ufds[0].revents = %hd\n", ufds[0].revents); printf("POLLNVAL = %ld\n", POLLNVAL); return 0; } ---------------------------------------------------------------------- Thanks, Trent -- Trent Mick TrentM@ActiveState.com From trentm@ActiveState.com Tue Oct 10 21:30:03 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:30:03 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com> Message-ID: <20001010133003.C22561@ActiveState.com> On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote: > - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the > Microsoft compiler. It works MUCH better. It's also binary compatible > with the Intel ecl compiler, and they didn't have any problems with us > switching. Yes, I knew that that was there. I remember either some earlier problem with it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for me well enough, I just haven't tried the one in Win64/. > My main interest is in having a python version that runs on the itanium > box with socket support (they included socket support in sdk2 didn't > they?) I.e. no need to provide a build mechanism for my needs if you can > refer me to an executable ;-) Well, Python's test_socket runs on my Win64 box so yes, socket support is there. As far as referring you to an exe, I would rather not go down that distribution road in preference to checking in my build scripts. Trent -- Trent Mick TrentM@ActiveState.com From mal@lemburg.com Tue Oct 10 21:37:30 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:37:30 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 Message-ID: <39E37E0A.90176759@lemburg.com> FYI, Here's what gcc -Wall gives on Linux: ceval.c: In function `eval_code2': ceval.c:345: warning: `v' might be used uninitialized in this function ceval.c:346: warning: `w' might be used uninitialized in this function ceval.c:347: warning: `u' might be used uninitialized in this function ceval.c:348: warning: `t' might be used uninitialized in this function errors.c: In function `PyErr_Format': errors.c:409: warning: value computed is not used errors.c:415: warning: value computed is not used -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Oct 10 21:45:00 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:45:00 +0200 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? Message-ID: <39E37FCC.9925555A@lemburg.com> It was mentioned early in the beta phase that cycle GC would be enabled only during the beta cycle and disabled in the final. Is this still true ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Tue Oct 10 21:47:06 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:47:06 -0400 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think In-Reply-To: <20001010132042.B22561@ActiveState.com> Message-ID: [Trent Mick] > test_poll.py currently fails on Monterey (64-bit AIX) because of > a difference in the system poll() function as compared to Linux. > > On Linux (and as required by the Signle Unix Specification: > http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if > you "poll()" a bogus file descriptor you get a POLLNVAL return value in > the 'revents' field of the structure sent to poll(). > ... > Monterey decided to return -1 instead. [Aside: However, 'revents's type is > "short" so the Python interface to poll() (using PyInt_FromLong) actually > interprets that as -32768 instead.] > > Questions: > 1. Can anybody offer an opinion if this is Python's or Monterey's > problem? Both. "Another day, another incompatible flavor of Unix(tm)." In the early days, Guido actually hoped he could get away without a massive hack like autoconf . > 2. Can anybody tell me where I can browse the POSIX spec to see if this > breaks POSIX compliance as well? Nowhere: ISO/ANSI stds are generally never available online. They get the bulk of their money from selling standards. http://webstore.ansi.org/ is a good place to buy. There are about 20 POSIX-related stds documents; the C API spec is US$245.00. You may get a cheaper answer on comp.unix.aix, of course. may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs - tim From tim_one@email.msn.com Tue Oct 10 21:58:54 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:58:54 -0400 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? In-Reply-To: <39E37FCC.9925555A@lemburg.com> Message-ID: [M.-A. Lemburg] > It was mentioned early in the beta phase that cycle GC would be > enabled only during the beta cycle and disabled in the final. > > Is this still true ? No, and it probably never was : the intent of enabling gc during the betas was to determine *whether* to enable it for the final release. The beta experience with gc was very good: a few subtle problems were uncovered, and Neil fixed them quickly. It should probably get a ton of performance testing that never happened, but then so should have all of 2.0 -- no particular reason to pick on gc alone for that. full-cycle-ahead-ly y'rs - tim From fdrake@beopen.com Tue Oct 10 22:13:47 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <39E37E0A.90176759@lemburg.com> References: <39E37E0A.90176759@lemburg.com> Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function These would be a real tedium to fix, and I'm not convinced the loss of clarity is worth it. From looking at the code in the DUP_TOPX code, I'm led to think that the compiler just isn't smart enough (it should figure out that oparg won't change before the second case statement, and figure it out more carefully. I'll bet *that* would remove these warnings and still right in all cases. > errors.c: In function `PyErr_Format': > errors.c:409: warning: value computed is not used > errors.c:415: warning: value computed is not used Fixed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Wed Oct 11 00:16:42 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:16:42 -0500 Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available! Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> We're experiencing a serious problem with the pythonlabs.com website. Unfortunately the site is down with no estimated time for when it will be back up. Our bestest brains are working on the problem! In the mean time, the Python 2.0c1 source tree can be downloaded from this address: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz The Windows installer is here: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe And the 2.0c1 documentation is still here (on-line browseable and downloadable): http://www.python.org/doc/2.0c1/ If the outage lasts for more than a day, we'll find another place to hold the full distribution. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Tue Oct 10 23:47:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 18:47:19 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: [MAL] > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function [Fred] > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. I'll take this one. It looks easy to fix, and to my eye doing *everything* needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own blocks) would be much clearer than the current distributed trickiness (faster, too -- the code now is branching more than computing). > From looking at the code in the DUP_TOPX code, I'm led to think that > the compiler just isn't smart enough (it should figure out that oparg > won't change before the second case statement, and figure it out more > carefully. I'll bet *that* would remove these warnings and still right > in all cases. I agree, except that it wasn't trivial for *me* to decide the compiler was being stupid. Code that's obviously correct is better than code that's not obviously wrong. >> errors.c: In function `PyErr_Format': >> errors.c:409: warning: value computed is not used >> errors.c:415: warning: value computed is not used Thanks! > Fixed. Thanks! From thomas@xs4all.net Tue Oct 10 23:49:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 00:49:37 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400 References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <20001011004937.Q12812@xs4all.nl> On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote: > M.-A. Lemburg writes: > > ceval.c: In function `eval_code2': > > ceval.c:345: warning: `v' might be used uninitialized in this function > > ceval.c:346: warning: `w' might be used uninitialized in this function > > ceval.c:347: warning: `u' might be used uninitialized in this function > > ceval.c:348: warning: `t' might be used uninitialized in this function > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. From looking at the code in the DUP_TOPX > code, I'm led to think that the compiler just isn't smart enough (it > should figure out that oparg won't change before the second case > statement, and figure it out more carefully. I'll bet *that* would > remove these warnings and still right in all cases. Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall sometime before, and I didn't get those warnings then. Probably depends on the version of gcc. As a colleague of mine would say, "insert clue" (into gcc, that is ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@python.org Wed Oct 11 00:57:38 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:57:38 -0500 Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available! In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST." <200010102316.SAA20071@cj20424-a.reston1.va.home.com> References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com> I wrote: > We're experiencing a serious problem with the pythonlabs.com website. > Unfortunately the site is down with no estimated time for when it will > be back up. Our bestest brains are working on the problem! With the help of Digital Creations' bestest brain, Jim Fulton, the site is back up in record time. We'll try not to break it again, Jim! And thanks to Digital Creations for helping us out on such a short notice. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Wed Oct 11 01:57:11 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <20001011004937.Q12812@xs4all.nl> References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> <20001011004937.Q12812@xs4all.nl> Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall > sometime before, and I didn't get those warnings then. Probably depends on > the version of gcc. As a colleague of mine would say, "insert clue" (into > gcc, that is ;) This is very reasonable. I don't think we'll give you too many demerits for this. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Wed Oct 11 05:40:41 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 00:40:41 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: We need a glibc expert! Anyone qualify? [Huaiyu Zhu] > ... > This is very likely to be a 2.0 bug. Or a 1.5.2 bug. I have to keep saying this stuff is a platform-dependent crap shoot, because it is (I too prefer that Python underflow silently by default, though). > Just to make sure, I have used freshly downloaded source code of > both 1.5.2 and 2.0b2, then > ./configure > make > ./python > > from math import * > exp(-746) > > I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2. > > The file mathmodule.c has quite some differences between the two versions, > mostly related to the ANSIfication. I'm not sure where the problem is. It's not in mathmodule.c. > I haven't tried the 2.0c1 yet, as the site is not available. Can > other Unix users confirm this behavior? I went over to Guido's and forced him to try it. He sees the same behavior: after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries, 1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises OverflowError. But there is no code in Python that accounts for the difference. Running it under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets errno to ERANGE (34) under 2.0. Since the platform exp was the only conceivable cause for this difference, it's not surprising that the debugger confirmed that the platform exp is in fact the cause. So the remaining question is why the same exp from the same library has different errno behavior depending on which version of Python it's called from. *That* one we couldn't answer, after a fruitless time digging thru the Byzantine glibc source code trying to reverse engineer it. Their exp *can* display different error behavior at runtime depending on several obscure things, but they're too obscure to relate back clearly to anything Python is doing. The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what the glibc exp author believes POSIX mandates, and is one of their exp's possible runtime behaviors, and your own little C program (which you posted earlier) suggests that's the default behavior under gcc + glibc. So presumably 1.5.2 config was such as to inhibit the default behavior. However, nobody changed this on purpose, so it smells like an unintended side effect of some other (currently unknown) config change. I don't know what to do next. I can't pursue it myself, and you've seen from the lack of replies to your posts that I'm the only who'll even listen to you . Guido suggests that one big change in 2.0 is that we're including a lot more std headers than we used to. It could well be that one of those #defines some God-forsaken preprocessor symbol one of whose five meanings (documented or not) is "use POSIX-conformant libm error reporting", but which someone #include'd in 2.0 to make (who knows?) sockets work right on some other flavor of Unix. Don't know. Unix config is a mess, and so is glibc. Best hope now is for someone intimately familiar with glibc internals to jump in and own this. staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs - tim From huaiyu_zhu@yahoo.com Wed Oct 11 09:12:37 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim Peters] > We need a glibc expert! Anyone qualify? If there is none here, maybe someone cares to ask in some gcc or gnu news groups? > The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what > the glibc exp author believes POSIX mandates, and is one of their exp's > possible runtime behaviors, and your own little C program (which you posted > earlier) suggests that's the default behavior under gcc + glibc. So > presumably 1.5.2 config was such as to inhibit the default behavior. > However, nobody changed this on purpose, so it smells like an unintended > side effect of some other (currently unknown) config change. So can we set a flag to explicitly discount ERANGE? There are only 19 lines in the source code that contain ERANGE, and 8 lines containing math_error. All the latter are in Modules/{c,}mathmodule.c. Could we just add an ifdef IEEE754 on these 8 lines? This would go a long way to aleviate this problem before we find a perfect solution, if there is one. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. I'm not interested in where this comes from - the only thing that matters is that it worked in 1.5.2 and breaks in 2.0. Whether the 1.5.2 behavior was intended or not, it's not a bug. The 2.0 behavior is a bug. If Posix conflicts with IEEE floating point arithmetic, then confirming to Posix in this regard is a bug. I would suggest the next thing to do is to introduce an IEEE754 flag and let those who do not like it to voice their opinions. Since this is the same behavior as 1.5.2 I doubt any running code would be broken by this. Huaiyu From thomas@xs4all.net Wed Oct 11 09:26:14 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:26:14 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400 References: Message-ID: <20001011102614.R12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote: > We need a glibc expert! Anyone qualify? No, at least not me ;) > So the remaining question is why the same exp from the same library has > different errno behavior depending on which version of Python it's called > from. *That* one we couldn't answer, after a fruitless time digging thru > the Byzantine glibc source code trying to reverse engineer it. Their exp > *can* display different error behavior at runtime depending on several > obscure things, but they're too obscure to relate back clearly to anything > Python is doing. Well, I've seen & heard about compilers doing slightly different things depending on ANSI or K&R style C, so perhaps the presence of ANSI C definitions triggered this. I sincerely doubt it, though, but you never know, and it's fairly easy to test. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. Actually, there was some activity to define the right combination of _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not sure what the end result was. If any #define changes the behaviour of glibc, these would definately be it ! A simple test might be to compile 1.5.2 with the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, and do some of the above tests. Computers-suck-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Oct 11 09:31:49 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:31:49 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700 References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <20001011103148.S12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote: > default: > fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg); Hm, this fprintf is stray debugging code, added because I wasn't sure that a SystemError wouldn't crash the interpreter, given that the stack is utterly fu*d up at this point and we don't know what the compiler thinks is the stack size or block size here. (The snippet doesn't show it, but it also raises a SystemError.) Is it okay if I remove/comment this fprintf() before 2.0 final ? (At least it didn't say "awoogah, stray debugging code detected, this machine will self-destruct in 10 seconds" :-) Another-day-another-demerit-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Wed Oct 11 10:52:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 05:52:59 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > So can we set a flag to explicitly discount ERANGE? There are > only 19 lines in the source code that contain ERANGE, and 8 lines > containing math_error. > All the latter are in Modules/{c,}mathmodule.c. Could we just > add an ifdef IEEE754 on these 8 lines? This would go a long way to > aleviate this problem before we find a perfect solution, if there > is one. That would stop the exception on exp() underflow, which is what you're concerned about. It would also stop exceptions on exp() overflow, and on underflow and overflow for all other math functions too. I doubt Guido will ever let Python ignore overflow by default, #ifdef'ed or not. A semantic change that jarring certainly won't happen for 2.0 (which is just a week away). > ... > I'm not interested in where this comes from - the only thing that > matters is that it worked in 1.5.2 and breaks in 2.0. The behavior of underflowing exp() is hardly the only thing that matters, although it's becoming clear it may be the only thing you care about <0.9 wink>. I would like to change that too for 2.0, but give a thought to the other consequences. If some change to the Python config screwed up exp(-1000) for you, what else is going wrong? You're not going to get an answer to that until we know exactly "where this comes from". > Whether the 1.5.2 behavior was> intended or not, it's not a bug. The > 2.0 behavior is a bug. If Posix conflicts with IEEE floating point > arithmetic, then confirming to Posix in this regard is a bug. POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno, as is POSIX on 754 issues. It was Python's decision (not POSIX's) to raise an exception when errno gets set. Python wasn't designed to support 754, and makes no claim to support any part of it, so conformance to 754 may be presented as a feature request, but trying to beat Python over the head with it won't work: there's no bug here, in the strong sense that no documented (or even intended!) behavior has changed. What happened is that one platform accident got changed to a different platform accident. You certainly get sympathy for that, but not enough to buy radical last-minute changes. > I would suggest the next thing to do is to introduce an IEEE754 > flag and let those who do not like it to voice their opinions. Nothing like that will happen without a PEP first. I would like to see *serious* 754 support myself, but that depends too on many platform experts contributing real work (if everyone ran WinTel, I could do it myself ). > Since this is the same behavior as 1.5.2 I doubt any running code would be > broken by this. Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and current code certainly relies on detecting overflows in math functions. It would also break code on platforms that were setting errno to ERANGE all along on underflow (as POSIX appears to require, and ANSI C doesn't appear to forbid; I don't know of such a platform for sure offhand, but to judge from their manpages, HPUX looks like one). In no case can you expect to see overflow ignored in 2.0. I want to know where this comes from, so we have *some* handle on what other surprises may be lurking. If no progress is made on determining the true cause over the next few days, I'll hack mathmodule.c to ignore ERANGE in the specific case the result returned is a zero (which would "fix" your exp underflow problem without stopping overflow detection). Since this will break code on any platform where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a long discussion w/ Guido first. I *believe* that much is actually sellable for 2.0, because it moves Python in a direction I know he likes regardless of whether he ever becomes a 754 True Believer. like-herding-cats-indeed-ly y'rs - tim From tim_one@email.msn.com Wed Oct 11 11:02:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 06:02:05 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011103148.S12812@xs4all.nl> Message-ID: > > default: > > fprintf(stderr, "Invalid argument > to DUP_TOPX: %d!\n", oparg); [Thomas Wouters] > Hm, this fprintf is stray debugging code, added because I wasn't > sure that a SystemError wouldn't crash the interpreter, given that the > stack is utterly fu*d up at this point and we don't know what the > compiler thinks is the stack size or block size here. (The snippet > doesn't show it, but it also raises a SystemError.) Is it okay if I > remove/comment this fprintf() before 2.0 final ? Suggest replacing it with: assert(!"Invalid argument to DUP_TOPX"); Then there's no cost in release mode, but we have a useful check in debug mode. ("assert(!string)" is a handy C debugging idiom more people should know about! It's semantically the same as assert(0) (i.e. will fail if ever reached), but unlike using a comment, using a string gets a useful msg displayed if it ever does fail). > (At least it didn't say "awoogah, stray debugging code detected, this > machine will self-destruct in 10 seconds" :-) Beats "Unto the root this day a brother is born" . > Another-day-another-demerit-ly y'rs, That's a funny thing about working on Python: collect 5 demerits and you can exchange them for 1 brownie point! If you're not leaving crap behind, you're not eating enough Python code. continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs - tim From guido@python.org Wed Oct 11 15:39:06 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:39:06 -0500 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400." References: Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com> Incidentally, math.exp(800) returns inf in 1.5, and raises OverflowError in 2.0. So at least it's consistent. --Guido van Rossum (home page: http://www.python.org/~guido/) From Moshe Zadka Wed Oct 11 13:38:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT) Subject: [Python-Dev] OS Dependant Bugs Message-ID: Many of the sourceforge bugs are platform dependant. Unfortunately, it is impossible, from the main bugs page, to see which are platform dependant, and which platform the occur on. I suggest that, until SF supports it properly, each bug report we enter will have an optional [Platform] in front, if it seems to be platform dependant. Any opinions? Anyone thinks submitting an SF request to add this field is foolish? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@python.org Wed Oct 11 15:41:47 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:41:47 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400." References: Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> > Suggest replacing it with: > > assert(!"Invalid argument to DUP_TOPX"); Actually, I would recommend Py_FatalError("Invalid argument to DUP_TOPX") It's not quite the same since it also triggers in release mode. If, as Thomas says, this should never happen and can only be caused by garbled bytecode, a fatal error is proper rather than a SystemError. --Guido van Rossum (home page: http://www.python.org/~guido/) From Moshe Zadka Wed Oct 11 13:41:27 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > Py_FatalError("Invalid argument to DUP_TOPX") > > It's not quite the same since it also triggers in release mode. If, > as Thomas says, this should never happen and can only be caused by > garbled bytecode, a fatal error is proper rather than a SystemError. Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception. Unless I misunderstand the discussion completely. jumping-to-discussions-in-the-middle-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake@beopen.com Wed Oct 11 14:42:57 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net> References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com> Tim Peters writes: > Update of /cvsroot/python/python/dist/src/Python > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg, > by making the DUP_TOPX code utterly straightforward. This also gets rid > of all normal-case internal DUP_TOPX if/branches, and allows replacing one > POP() with TOP() in each case, so is a good idea regardless. Tim, There's still one left: gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c -o ceval.o ../../Python/ceval.c ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:346: warning: `w' might be used uninitialized in this function Cruising through this code, it looks like the problem might be in the PRINT_NEWLINE case: case PRINT_NEWLINE: if (stream == NULL || stream == Py_None) { w = PySys_GetObject("stdout"); if (w == NULL) PyErr_SetString(PyExc_RuntimeError, "lost sys.stdout"); } if (w != NULL) { /* If PRINT_NEWLINE is the opcode, w might not be initialized * here (I think), since I don't see it initialize before the * switch. Since we can't initialize it to NULL with the case * (doing so would break the PRINT_NEWLINE_TO case), it would * have to be initialized before the main loop is entered. */ err = PyFile_WriteString("\n", w); if (err == 0) PyFile_SoftSpace(w, 0); } Py_XDECREF(stream); stream = NULL; break; Ok.... yep, initializing that seems to work. I'll check in the fix for this one after I've run the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Wed Oct 11 15:54:14 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:14 -0500 Subject: [Python-Dev] OS Dependant Bugs In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300." References: Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com> > Many of the sourceforge bugs are platform dependant. Unfortunately, it is > impossible, from the main bugs page, to see which are platform dependant, > and which platform the occur on. > > I suggest that, until SF supports it properly, each bug report we enter > will have an optional [Platform] in front, if it seems to be platform > dependant. > > Any opinions? Anyone thinks submitting an SF request to add this field > is foolish? I think it's sufficient (actually better) if the platform name is mentioned in the summary. Note that you can edit the summary of existing bug reports. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Oct 11 15:54:54 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:54 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300." References: Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> > Can't user Python code, fiddling around with bytecode, produce garbled > bytecode? In that case, it seems even better to raise an exception. Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing. --Guido van Rossum (home page: http://www.python.org/~guido/) From Moshe Zadka Wed Oct 11 13:56:17 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > > Can't user Python code, fiddling around with bytecode, produce garbled > > bytecode? In that case, it seems even better to raise an exception. > > Yes, they can produce garbled bytecode, and if that is detected, it's > not safe to proceed. So a fatal error is the right thing. The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From akuchlin@mems-exchange.org Wed Oct 11 14:56:50 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 09:56:50 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: >Actually, there was some activity to define the right combination of >_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not >sure what the end result was. If any #define changes the behaviour of glibc, >these would definately be it ! A simple test might be to compile 1.5.2 with That seems the likely cause. Another faint possibility might be threading, since 2.0 automatically uses threads but 1.5.2 needs to have them enabled. (Perhaps Tim remembered this and supplied --with-thread to the 1.5.2 configure script.) --amk From guido@python.org Wed Oct 11 16:03:00 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:03:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300." References: Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > bytecode? In that case, it seems even better to raise an exception. > > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > restricted execution much more difficult. Well, something to think about > for 2.1... Huh? In restricted execution you shouldn't be allowed to mess with bytecode! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Oct 11 16:25:32 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:25:32 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400." <20001011095650.A17931@kronos.cnri.reston.va.us> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Bingo! 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the 1.5.2 link line makes is raise OverflowError too. Adding it to the 2.0 link line makes it return 0.0 for exp(-1000) and inf for exp(1000). Next question: what changed in the configure script, and why? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Wed Oct 11 15:24:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:24:37 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011162436.T12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: [ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ] > Actually, there was some activity to define the right combination of > _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not > sure what the end result was. If any #define changes the behaviour of glibc, > these would definately be it ! A simple test might be to compile 1.5.2 with > the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in > 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can > reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, > and do some of the above tests. Well, that was no success. I do see the difference between 1.5.2 and 2.0, but *damned* if I can figure out where it comes from. It doesn't seem to be any of the properly placed defines, and it doesn't seem to be the changes in mathmodule itself. Not autoconf, either. What I did: old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0 new tree (current CVS): math.exp(-1000) raises OverflowError (No difference between threads enabled and disabled.) Use new config.h in old tree: math.exp(-1000) returned 0.0 Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0 Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000) raises OverflowError Copy new mathmodule.c to old tree (adding an 'include math.h' because the old Python.h isn't doing that): math.exp(-1000) returns 0.0 Copy config.h and Python.h from new tree to old one (removing the include of unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h to make it compile): math.exp(-1000) returns 0.0 So, as far as I can tell, it's not related to any code in mathmodule.c itself, nor any defines in config.h or Python.h. mymath.h isn't used either, as far as I can tell it only contains stuff for broken math stuff on obscure platforms. Sounds like time for that glibc expert right about now ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin@mems-exchange.org Wed Oct 11 15:32:23 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 10:32:23 -0400 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: >1.5.2 links with -lieee while 2.0 doesn't. >Next question: what changed in the configure script, and why? The patch from revisions 1.138 to 1.139 of configure.in is: 853c1139,1142 < AC_CHECK_LIB(ieee, __fpu_control) --- > AC_CHECK_FUNC(__fpu_control, > [], > [AC_CHECK_LIB(ieee, __fpu_control) > ]) The check-in comment is "Only link with -lieee when it's necessary". If it only checks for -lieee when the __fpu_control function is defined, perhaps the function disappeared in glibc 2.1. --amk From thomas@xs4all.net Wed Oct 11 15:32:45 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:32:45 +0200 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011163244.U12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). Ack, that's the one thing I didn't check: link libraries ;-P > Next question: what changed in the configure script, and why? Well, that's easy. Old configure.in: # Linux requires this for correct f.p. operations AC_CHECK_LIB(ieee, __fpu_control) New configure.in: # Linux requires this for correct f.p. operations AC_CHECK_FUNC(__fpu_control, [], [AC_CHECK_LIB(ieee, __fpu_control) ]) I remember the patch that did this, on SF. It was titled "don't link with -lieee if it isn't necessary" or something. Not sure what it would break, but mayhaps declaring -lieee necessary on glibc systems is the right fix ? (For the non-autoconf readers among us: the first snippet writes a test program to see if the function '__fpu_control' exists when linking with -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second snippet writes a test program to see if the function '__fpu_control' exists with the current collection of $LIBS. If it doesn't, it tries it again with -lieee, and adds -lieee to $LIBS if it finds it then.) Pesonally, I think the patch should just be reversed... The comment above the check certainly could be read as 'Linux requires -lieee for correct f.p. operations', and perhaps that's how it was meant. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Wed Oct 11 17:31:48 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <14820.38388.827883.710489@beluga.mojam.com> Tim> I'll take this one. It looks easy to fix ... Seems to me like a patch that ought to wait until after 2.0final. It's definitely not a show-stopping bug... Skip From thomas@xs4all.net Wed Oct 11 19:04:31 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 20:04:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500 References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> Message-ID: <20001011200431.V12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote: > > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > > bytecode? In that case, it seems even better to raise an exception. > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > > restricted execution much more difficult. Well, something to think about > > for 2.1... > Huh? In restricted execution you shouldn't be allowed to mess with > bytecode! Well, I can see what Moshe means. You get a code object passed in, say, an untrusted pickle or some such. You want to execute it, but you don't want it to ruin your life. Causing the entire program to quit could be considered 'ruining'. On the other hand, if you can hand-tweak bytecode streams in that degree, you can f** up a lot more. On the one foot, though, most of the calls to Py_FatalError (as far as I can see) deal with initialization failures, or structures to which tweaked bytecode would not have access. On the other foot, it's probably possible to tweak bytecode to *get* access to those structures, or at least structures that don't like being dereferenced or DECREF'd. And there's probably more to consider, but I haven't got any public appendages left, and there might be children listening ;) All in all, Guido's probably right... If something like this happens, you don't want to continue. If the argument to DUP_TOPX is something other than what compile.c generates (between 1 and 5, inclusive, that is) something strange is going on internally. Better to quit now than delete c:\command.com by 'accident'. If people can do this to code being run in restricted environments, they can probably do worse things, too! Now I just need an OK from Jeremy, as the maitre d', and I'll check it in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@python.org Wed Oct 11 22:19:28 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 16:19:28 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200." <20001011163244.U12812@xs4all.nl> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Thanks for digging deeper into this. > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct f.p. > operations', and perhaps that's how it was meant. No, the configure patch is right. Tim will check in a change that treats ERANGE with a return value of 0.0 as underflow (returning 0.0, not raising OverflowError). --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Wed Oct 11 22:02:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:02:16 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: [Tim] > I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy > to fix ... [Skip Montanaro] > Seems to me like a patch that ought to wait until after 2.0final. It's > definitely not a show-stopping bug... Would have been a more interesting argument had you posted this before the patch was checked in . But wngs are non-negotiable with me anyway. This example turned out to be a good one for showing why: the bogus wngs covered up a legitimate "uninitialized vrbl" complaint (see Fred's later discovery and following checkin). I've simply got zero tolerance for wngs or for failures in the std test suite. My view is warped by prior experience, though: the last 6 years, I worked on projects where the compilers were fiddled to treat warnings as fatal errors. So while this may have looked like a harmless batch of wngs to you, as far as I was concerned Python couldn't even be compiled anymore <0.7 wink>. extremism-in-defense-of-simple-best-practice-may-or-may-not-be- vice-but-it's-sure-effective-over-the-long-term-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Wed Oct 11 22:07:42 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: <14820.54942.114086.773609@beluga.mojam.com> Tim> [Tim] >> I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy >> to fix ... Tim> [Skip Montanaro] >> Seems to me like a patch that ought to wait until after 2.0final. >> It's definitely not a show-stopping bug... Tim> Would have been a more interesting argument had you posted this Tim> before the patch was checked in . Agreed, but I posted as soon as I saw it. Can't help it if I can't keep up with all the flurry of activity. Tim> So while this may have looked like a harmless batch of wngs to you, Tim> as far as I was concerned Python couldn't even be compiled anymore Tim> <0.7 wink>. I accept your explanation. ;-) S From jack@oratrix.nl Wed Oct 11 22:10:36 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 11 Oct 2000 23:10:36 +0200 Subject: [Python-Dev] test_StringIO failing on the Mac Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl> I have one remaining problem (at least, as far as I'm aware:-) with 2.0c1 on the Mac: test_StringIO fails. The reason is that the test_StringIO output file was generated on Unix, and hence it uses the unix form of string.letters (a-zA-Z), whereas the Mac version of string.letters has far more values. As this isn't what the test is about in the first place, shall I fix the test? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tim_one@email.msn.com Wed Oct 11 22:14:17 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:14:17 -0400 Subject: [Python-Dev] test_StringIO failing on the Mac In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl> Message-ID: [Jack Jansen] > I have one remaining problem (at least, as far as I'm aware:-) with > 2.0c1 on the Mac: test_StringIO fails. > > The reason is that the test_StringIO output file was generated on > Unix, and hence it uses the unix form of string.letters (a-zA-Z), > whereas the Mac version of string.letters has far more values. > > As this isn't what the test is about in the first place, shall I fix > the test? +1 from me on making the test portable. From jeremy@beopen.com Thu Oct 12 00:06:56 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011200431.V12812@xs4all.nl> References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> <20001011200431.V12812@xs4all.nl> Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: [Moshe:] >> > The problem with letting Python code cause fatal errors is that >> > it makes restricted execution much more difficult. Well, >> > something to think about for 2.1... [Guido:] >> Huh? In restricted execution you shouldn't be allowed to mess >> with bytecode! TW> Well, I can see what Moshe means. You get a code object passed TW> in, say, an untrusted pickle or some such. You want to execute TW> it, but you don't want it to ruin your life. Causing the entire TW> program to quit could be considered 'ruining'. On the other TW> hand, if you can hand-tweak bytecode streams in that degree, you TW> can f** up a lot more. Damn straight! If you're using restricted execution mode and accepting bytecode objects that weren't produced by a trusted Python compiler, you're nuts. I am not aware of any effort made to protect the Python VM from attack via malicious bytecode. TW> Now I just need an OK from Jeremy, as the maitre d', and I'll TW> check it in. Your table is ready. A checkin message will be accepted as gratuity. Jeremy From jeremy@beopen.com Thu Oct 12 00:12:15 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT) Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net> I checked in the patch that removed the -lieee link in some cases. I don't remember the details off the top of my head, but I can go digging in the SF patch logs if it's important. As I recall, someone reported problems on a platform (HPUX?) where link with ieee caused problems. I didn't have access to the platform in question. So I applied the patch on a Linux box and ran the regression test; it reported no errors, so I assumed the patch fixed some other platform and did mine no harm. At the moment, I would assume that the patch still helps some other platform but might not be right on Linux. On the other hand, it sounds like Tim has a patch that will cause Linux to do the right thing. It's hard to say much about what should or should not happen since neither the language reference nor the regression tests specifies much about what should happen with fp. Jeremy From thomas@xs4all.net Thu Oct 12 00:15:21 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 01:15:21 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15 In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700 References: <200010112144.OAA20776@slayer.i.sourceforge.net> Message-ID: <20001012011521.X12812@xs4all.nl> On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717 > > Modified Files: > dlmodule.c > Log Message: > > Remove one more gcc -Wall warning. To note, if gcc didn't inherit at least *some* of C's original philosophy of 'the programmer always knows what [s]he is doing', gcc would yell bloody murder at this code. The 'func' function pointer is used to point to symbols loaded from arbitrary shared objects, and the dlmodule has no way of knowing howmany arguments the function expects, or even if it isn't more than 10 (which would result in the function grabbing garbage off the stack, on most architectures, I think.) While on the ANSIfication spree, I ran screaming and hid under my bed after reading this code ;) Is anyone using the dlmodule anymore ? Is it really useful ? Is this *really* how loading and calling arbitrary shared objects should be done ? :P > { > PyObject *name; > ! long (*func)(long, long, long, long, long, > ! long, long, long, long, long); > long alist[10]; > long res; Idle-and-post-2.0-talk-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu@yahoo.com Thu Oct 12 00:33:08 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: On the issue of whether Python should ignore over/underflow on IEEE-enabled platforms: [Tim Peters] > That would stop the exception on exp() underflow, which is what you're > concerned about. It would also stop exceptions on exp() overflow, and on > underflow and overflow for all other math functions too. I doubt Guido will > ever let Python ignore overflow by default, #ifdef'ed or not. A semantic > change that jarring certainly won't happen for 2.0 (which is just a week > away). It can be argued that on IEEE enabled systems the proper thing to do for overflow is simply return Inf. Raising exception is WRONG. See below. [Guido van Rossum] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. That is not consistent at all. Suppose I'm plotting the curve f(x) where x include some singular points of f. In the first case the plot works with some portion of the curve clipped. In the second case it bombs. [Tim Peters] > Nothing like that will happen without a PEP first. I would like to see > *serious* 754 support myself, but that depends too on many platform experts > contributing real work (if everyone ran WinTel, I could do it myself > ). [Guido van Rossum] > Bingo! > > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). If using ieee is as simple as setting such a flag, there is no reason at all not to use it. Here are some more examples: Suppose you have done hours of computation on a problem. Just as you are about to get the result, you get an exception. Why? Because the residual error is too close to zero. Suppose you want to plot the curve of Gausian distribution. Oops, it fails. Because beyond a certain region the value is near zero. With these kinds of problems, vectorized numerical calculation becomes nearly impossible. How do you work in such an environment? You have to wrap every calculation in a try/except structure, and whenever there is an exception, you have to revert to elementwise operations. In practice this simply means Python would not be suitable for numerical work at all. What about the other way round? No problem. It is easy to write functions like isNaN, isInf, etc. With these one can raise exceptions in any place one want. It is even possible to raise exceptions if a matrix is singular to a certain precision, etc. The key point to observe here is that most numerical work involve more than one element. Some of them may be out of mahcine bounds but the whole thing could still be quite meaningful. Vice versa it is also quite possible that all elements are within bounds while the whole thing is meaningless. The language should never take over or subvert decisions based on numerical analysis. [Tim Peters] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. As Guido observed ERANGE is not generated with ieee, even for overflow. So it is the same behavior as 1.5.2. Besides, no correct numerical code should depend on exceptions like this unless the machine is incapable of handling Inf and NaN. Even in the cases where you do want to detect overflow, it is still wrong to use exceptions. Here's an example: x*log(x) approaches 0 as x approaches 0. If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want. But exception is the wrong tool to hangle this, because if x is an array, some of its element may be zero but other's may not. The right way to do it is something like def entropy(probability): p = max(probability, 1e-323) return p*log(p) [Tim Peters] > In no case can you expect to see overflow ignored in 2.0. You are proposing a dramatic change from the behavior of 1.5.2. This looks like to me to need a PEP and a big debate. It would break a LOT of numerical computations. [Thomas Wouters] > I remember the patch that did this, on SF. It was titled "don't link with > -lieee if it isn't necessary" or something. Not sure what it would break, > but mayhaps declaring -lieee necessary on glibc systems is the right fix ? > > (For the non-autoconf readers among us: the first snippet writes a test > program to see if the function '__fpu_control' exists when linking with > -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second > snippet writes a test program to see if the function '__fpu_control' > exists with the current collection of $LIBS. If it doesn't, it tries it > again with -lieee, > > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct > f.p. operations', and perhaps that's how it was meant. The patch as described seems to be based on flawed thinking. The numbers Inf and NaN are always necessary. The -lieee could only be unnecessary if the behavior is the same as IEEE. Obviously it isn't. So I second Thomas's suggestion. [Tim Peters] > If no progress is made on determining the true cause over the next few days, > I'll hack mathmodule.c to ignore ERANGE in the specific case the result > returned is a zero (which would "fix" your exp underflow problem without > stopping overflow detection). Since this will break code on any platform > where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a > long discussion w/ Guido first. I *believe* that much is actually sellable > for 2.0, because it moves Python in a direction I know he likes regardless > of whether he ever becomes a 754 True Believer. [Guido van Rossum] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). What is the reason to do this? It looks like intetionally subverting ieee even when it is available. I thought Tim meant that only logistical problems prevent using ieee. If you do choose this route, please please please ignore ERANGE entirely, whether return value is zero or not. The only possible way that ERANGE could be useful at all is if it could be set independently for each element of an array, and if it behave as a warning instead of an exception, ie. the calculation would continue if it is not caught. Well, then, Inf and NaN serve this purpose perfectly. It is very reasonable to set errno in glibc for this; it is completely unreasonable to raise an exception in Python, because exceptions cannot be set to individual elements and they cannot be ignored. Huaiyu -- Huaiyu Zhu hzhu@users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From dubois@users.sourceforge.net Thu Oct 12 01:04:51 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Wed, 11 Oct 2000 17:04:51 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: I don't have time to follow in detail this thread about changed behavior between versions. These observations are based on working with hundreds of code authors. I offer them as is. a. Nobody runs a serious numeric calculation without setting underflow-to-zero, in the hardware. You can't even afford the cost of software checks. Unfortunately there is no portable way to do that that I know of. b. Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going. From guido@python.org Thu Oct 12 02:45:30 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 20:45:30 -0500 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST." References: Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> > I don't have time to follow in detail this thread about changed behavior > between versions. These observations are based on working with hundreds of > code authors. I offer them as is. > > a. Nobody runs a serious numeric calculation without setting > underflow-to-zero, in the hardware. You can't even afford the cost of > software checks. Unfortunately there is no portable way to do that that I > know of. > > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > stop, not put a zero and keep going. Thanks, Paul! This behavior has always been what I wanted Python to do (even though it's not always what Python did, depending on the platform) and also what Tim's proposed patch will implement for the specific case of math.exp() (and other math functions that may underflow or overflow), on most reasonable platforms. There are still lots of places where the platform gives Python no choice of creating NaN and Inf, and because there's no platform-independent way to test for these, they are hard to avoid in some cases; but eventually, Tim will find a way to root them out. And for people like Huaiyu, who want to see Inf, there will (eventually) be a way to select this as a run-time option; and ditto for whoever might want underflow to raise an exception. --Guido van Rossum (home page: http://www.python.org/~guido/) From huaiyu_zhu@yahoo.com Thu Oct 12 03:22:54 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> Message-ID: [Paul Dubois] > > > > a. Nobody runs a serious numeric calculation without setting > > underflow-to-zero, in the hardware. You can't even afford the cost of > > software checks. Unfortunately there is no portable way to do that that I > > know of. Amen. > > > > b. Some people use Inf but most people want the code to STOP so they can > > find out where the INFS started. Otherwise, two hours later you have big > > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > > stop, not put a zero and keep going. $ /usr/bin/python Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from math import * >>> exp(777) inf >>> exp(-777) 0.0 >>> sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error This was sane behavior. Are we saying that Python 2.0 has invented something better than IEEE 754? [Guido van Rossum] > Thanks, Paul! This behavior has always been what I wanted Python to > do (even though it's not always what Python did, depending on the > platform) and also what Tim's proposed patch will implement for the > specific case of math.exp() (and other math functions that may > underflow or overflow), on most reasonable platforms. Guido, with due respect to your decisions on Python issues, I simply have to fight this one. It is one thing to accomodate for naive users, but it is another to dumb down every one else. Case 1. Someone writes a flawed numerical routine. Two hours later he finds his array filled with Inf and NaN. Case 2. Someone writes a perfect numerical routine. Two hours later he gets an exception, because the error is near zero. Solution for case 1. Use better algorithm. Use better error control. Raise exceptions when error is too large. These are proper solutions. They are easy and efficient to implement. They are needed anyway - If something's wrong, you want to raise exceptions far earlier than Inf, certainly before you get arrays filled with elements like 1e300. Solution for case 2. Almost impossible. The division between under- and over-flow is artificial. What about 1/x or similar functions? The only way to work on such a platform is to abandon vectorized computation. > There are still lots of places where the platform gives Python no > choice of creating NaN and Inf, and because there's no > platform-independent way to test for these, they are hard to avoid in > some cases; but eventually, Tim will find a way to root them out. And > for people like Huaiyu, who want to see Inf, there will (eventually) > be a way to select this as a run-time option; and ditto for whoever > might want underflow to raise an exception. I can understand that exceptions are the only available choices if IEEE is not available. But is there a compelling reason that Python should behave "better" than IEEE when it's in fact available? If the reason is to protect naive users, I can think of several responses: 1. For people doing one-off interactive work, returning Inf is in fact more informative. 2. For users iterative numerical computations, they need to be educated about error control. Otherwise they won't get corrent results anyway. 3. For really serious work, we could provide good numerical modules so that they don't need to write themselves. To make this happen fast the fewer debacles like this one the better. Case in point: Someone asked for regession modules two weeks ago. I was trying to convert my old matlab programs, which only took a few hours. But I wasted a week of (spare) time fighting for some mysterious "overflow". Turns out that a Guassian is near zero when it's far from center, and Python does not like it. In practice, Inf may be generated more often as a proper value than by mistake. This is not an issue about whether someone "prefers" Inf or exception. It is about whether there is a choice to do proper computation. Returning Inf does not prevent someone to raise exception. Raising exception automatically prevents perfect algorithms to work properly. As Kevin has volunteered to help with IEEE implementation and made a plan, is there a strong reason to drop IEEE for Linux in 2.0? If there is insufficient time to carry out his plan, wouldn't it be prudent to keep things as they were in 1.5.2? Huaiyu From tim_one@email.msn.com Thu Oct 12 03:44:20 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 22:44:20 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim From sdm7g@virginia.edu Thu Oct 12 04:23:32 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: First: I haven't followed this thread from the beginning -- only the last ten or so posts. Second: One reason I didn't follow it from the start is that I'm not doing any heavy numerical stuff in Python. I've been using Lisp for that, and use Python more for string/symbolic or GUI hacking. But, if I was going to do the sort of numerical stuff I now do in Lisp in Python, I would agree with Huaiya Zhu. I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points in the vector -- they are independent of the bad points. In my case, it's not that these are lengthy calculations. It's that they are interactive and tied to immediate graphical representations. If there are strange zero's or infinities in the result, there is (or should be) a way to backtrack and investigate. ( That's why people want interactive and graphical regression analysis and modeling tools! ) The idea that your calculation should blow up and you should check it and resubmit your job sounds just so ancient-20th-century- Fortran-JCL-and-punched-cards-technology! ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one@email.msn.com Thu Oct 12 05:18:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 00:18:19 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011234038.A2322@better.net> Message-ID: [William Park] > On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. I didn't write that. Paul Dubois did. > Hmm... I don't like this. It should stop or return complex. Paul said it should stop. You said it should stop (or return complex). So what is it that you don't like ? 754 mandates that sqrt(x) for x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently doesn't like. [actually Tim] > I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* > have silently returned a NaN (not a zero) without setting errno if it > was *self*-consistent -- anyone care to check that under -lieee?: > > import math > math.sqrt(-1) > > NaN or ValueError? 2.0 should raise ValueError regardless of > what 1.5.2 did here.). [back to William] > It returns 'OverflowError: math range error' in 1.5.2, Ah, that's hilarious ! It's tempting to believe that glibc is violating the IEEE std despite the -lieee flag in this case, but I don't believe that's true: it's almost certainly the case that glibc is actually returning a NaN, *not* setting errno at all, and this other check in Python's mathmodule.c: #define CHECK(x) if (errno != 0) ; \ else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \ else errno = ERANGE is setting errno to ERANGE purely due to an accident of the way gcc happens to compile code for comparing NaN to Inf and -Inf. > and 'ValueError: math domain error' in 2.0. Which is the correct exception, so is another reason for Python to avoid -lieee in 2.0. will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out- what-happens-by-accident-now-ly y'rs - tim From tim_one@email.msn.com Thu Oct 12 07:16:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 02:16:23 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > $ /usr/bin/python > Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux-i386 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from math import * > >>> exp(777) > inf > >>> exp(-777) > 0.0 > >>> sqrt(-1) > Traceback (innermost last): > File "", line 1, in ? > OverflowError: math range error > > This was sane behavior. Are we saying that Python 2.0 has invented > something better than IEEE 754? 754 allows users to choose the behaviors they want. Any *fixed* policy is not 754. So long as we have to fix a single policy, yes, I believe Guido (& know I) would say that raising OverflowError on exp(777), and silently returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not* OverflowError, as shown above), is indeed better than the 754 default behaviors. And 2.0 will do all three of those (& I just checked in the code to make that happen). About the sqrt example above, that's neither 754 behavior nor sane behavior: default 754 behavior on sqrt(-1) is to return a NaN and keep on going. I'm pretty sure that's what glibc linked w/ -lieee actually does, too (if it doesn't, glibc -lieee is violating 754). That 1.5.2 raised an OverflowError instead is insane, and appears purely due to an accident of how gcc compiles code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was fooled by this into setting errno to ERANGE itself). Python should raise a ValueError there instead (corresponding to libm setting errno to EDOM -- this is a domain error, not a range error) -- which it does now under CVS Python. 754-doesn't-work-unless-you've-got-all-of-it-ly y'rs - tim From thomas@xs4all.net Thu Oct 12 09:11:57 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 10:11:57 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400 References: Message-ID: <20001012101157.Y12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. > Nobody has proposed changing anything about libm domain (as opposed to > range) errors (although Huaiyu probably should if he's serious about his > flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on > 1.5.2, but it *should* have silently returned a NaN (not a zero) without > setting errno if it was *self*-consistent -- anyone care to check that > under -lieee?: > import math > math.sqrt(-1) >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do: >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error Consistency-conschmistency-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Thu Oct 12 16:58:10 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT) Subject: [Python-Dev] (no subject) Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net> Cc xml-sig@python.org Subject: test_minidom non-failure failure? X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: jeremy@beopen.com Comments: Hyperbole mail buttons accepted, v04.18. SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7 J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0 cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4 dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4 dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0 ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3 aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ== From jeremy@beopen.com Thu Oct 12 17:11:53 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net> Sorry about the previous message; a mail munger somewhere between my display and python.org choked on a very long line... I am getting an occasional, hard-to-reproduce error in test_minidom. When I run the test, it displays about a thousand lines of garbage, but the test suite does not report test_minidom as failed or skipped. The output I see during the test run is this: test_minidom garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': , 'childNodes': None, 'attributes': None, 'parentNode': None, 'data': u'Obsolete but implemented...', 'previousSibling': None}, , {'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a [... many hundreds of lines omitted] At the end of the test, I get a pretty normal result: 95 tests OK. 13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl test_imgfile test_largefile test_nis test_sunaudiodev test_timing test_winreg test_winsound So two questions: Why is test_minidom producing all this output? And why is it only happening intermittently? Why does regrtest.py think that test_minidom is working correctly when it produces all this output? Jeremy From nas@arctrix.com Thu Oct 12 10:31:34 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 02:31:34 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <20001012023134.A18254@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > I am getting an occasional, hard-to-reproduce error in test_minidom. > When I run the test, it displays about a thousand lines of garbage, > but the test suite does not report test_minidom as failed or skipped. > > The output I see during the test run is this: > > test_minidom > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': This is most likely the garbage collector. regrtest.py contains the following code: if findleaks: gc.collect() if gc.garbage: print "garbage:", repr(gc.garbage) found_garbage.extend(gc.garbage) del gc.garbage[:] findleaks is true if the -l option is specified (TESTOPS in the makefile includes it). Something is producing cyclic garbage. Neil From guido@python.org Thu Oct 12 18:39:40 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 12:39:40 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST." <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com> > On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > > I am getting an occasional, hard-to-reproduce error in test_minidom. > > When I run the test, it displays about a thousand lines of garbage, > > but the test suite does not report test_minidom as failed or skipped. > > > > The output I see during the test run is this: > > > > test_minidom > > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': [Neil] > This is most likely the garbage collector. regrtest.py contains > the following code: > > if findleaks: > gc.collect() > if gc.garbage: > print "garbage:", repr(gc.garbage) > found_garbage.extend(gc.garbage) > del gc.garbage[:] > > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. Of course something is producing cyclic garbage! The DOM tree is full of parent and child links. Does this output mean that the GC works correctly? Or does it mean that there is a reason why this garbage cannot be disposed of? In the latter case, could that be because there are __del__ methods? --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Thu Oct 12 17:55:19 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > This is most likely the garbage collector. regrtest.py contains > the following code: ... > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. This is definately the problem. Lars, Paul: This looks like a problem in the unlink() method of the DOM. Could you please check that the unlink() method is updated to handle the latest version of the other changes? Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Oct 12 17:59:33 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is test_minidom producing all this output? And why is it only > happening intermittently? It isn't. See Neil's excellent explanation. > Why does regrtest.py think that test_minidom is working correctly when > it produces all this output? The test is passing just fine, and is complete before the test for garbage is performed. The unlink() method on DOM objects is the culprit; it is updating the Node.allnodes dictionary correctly, but not the Node instances. I've already asked Paul & Lars to fix this; it should work just fine with or without GC once they've seen the report. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas@arctrix.com Thu Oct 12 11:24:48 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 03:24:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> Message-ID: <20001012032448.A18407@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote: > Of course something is producing cyclic garbage! > > The DOM tree is full of parent and child links. > > Does this output mean that the GC works correctly? Or does it > mean that there is a reason why this garbage cannot be disposed > of? In the latter case, could that be because there are > __del__ methods? The -l option tries to find any cyclic garbage produced by the tests. I don't think that that option should be enabled default. The output means that the GC is working and is finding stuff that would not be freed by reference counting alone. I can't tell if the GC would free this garbage. The -l option sets the DEBUG_SAVEALL option which causes all garbage found to end up in gc.garbage, not just garbage the can't be cleaned up. I don't have pyexpat installed here so I can't test it. If you want to find out if test_minidom is creating garbage the collector can't free you should comment out the: gc.set_debug(gc.DEBUG_SAVEALL) line in regrtest.py and run: regrtest.py -l test_minidom If that does what I think it does and you still get the "garbage: " line then the test is creating evil things. :) Neil From hinsen@dirac.cnrs-orleans.fr Thu Oct 12 18:24:18 2000 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Thu, 12 Oct 2000 19:24:18 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: (sdm7g@virginia.edu) References: Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr> > The idea that your calculation should blow up and you should > check it and resubmit your job sounds just so ancient-20th-century- > Fortran-JCL-and-punched-cards-technology! Long-running jobs are still with us, even there's neither Fortran nor JCL in them. And for these applications, stopping is better than going on with nonsense values. On the other hand, as you point out, exceptions for math errors are a bit of a pain for interactive work. So how about making this a run-time option? I'd choose exceptions by default and Infs and Nans by specifying a command-line option, but there are certainly others who would prefer it the other way round. What matters most to me is that the choice is possible somehow. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From sdm7g@virginia.edu Thu Oct 12 19:25:44 2000 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr> Message-ID: On Thu, 12 Oct 2000 hinsen@dirac.cnrs-orleans.fr wrote: > > The idea that your calculation should blow up and you should > > check it and resubmit your job sounds just so ancient-20th-century- > > Fortran-JCL-and-punched-cards-technology! > > Long-running jobs are still with us, even there's neither Fortran nor > JCL in them. And for these applications, stopping is better than going > on with nonsense values. On the other hand, as you point out, exceptions > for math errors are a bit of a pain for interactive work. > > So how about making this a run-time option? I'd choose exceptions by > default and Infs and Nans by specifying a command-line option, but > there are certainly others who would prefer it the other way round. > What matters most to me is that the choice is possible somehow. > I agree entirely! Maybe I was being a bit too glib, but I didn't mean to imply that wanting it to halt or throw an exception on errors is wrongheaded. I just wanted to make sure the counter-case to what Paul was saying also got heard: Yes-- underflows or infinities where they aren't expected are usually a sign that something is very wrong somewhere. But in the case where the vector holds independent observations or data points, then usually what it means is that there's something wrong with *that* data point -- miscallibrated or mislabeled -- but no reason not to complete the calculations for all of the other points. Scaling or doing projections for interactive graphics is another case where bad points are often better than throwing an exception. ( And it's a pain to have to remember to lambda wrap all the function calls with some sort of guard when you'ld be happy to get NaNs. ) I also mostly agree with Tim, except that I'm not sure that bad or incomplete ieee support is always better than none at all. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From thomas@xs4all.net Thu Oct 12 20:14:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 21:14:37 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700 References: <200010121711.KAA00584@slayer.i.sourceforge.net> Message-ID: <20001012211436.Z12812@xs4all.nl> On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote: [ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ] > There is one known warning at this time, caught by the -Wstrict-prototypes > option. In Modules/main.c, the declaration of getopt() without parameters > gets a complaint (rightly) that it is not a proper prototype. The lack of > a complete prototype information should be corrected when the right > portability conditions have been identified. I already looked at this before, and the problem is that the prototype for getopt is not portable (because of quirks in the ANSI C standard regarding 'compatible' pointer types.) Some systems define it as 'const char **' (or 'char const **'), some perhaps as 'char **', and some as 'char * const *'. 'const char **' and 'char const **' are the same, but 'char * const *' is something else, and so is 'char **'. 'char * const *' and 'char **' are equivalent types, meaning that conforming compilers should be able to intermix them without problems, but 'const char **' is a different type, and ANSI C either demands or strongly suggests a warning. (Why exactly it's a different type is mostly a choice of language, though I'm sure there are people who would defend the choice. What it means it that you can't mix two layers of indirection with qualifiers like 'const' or 'volatile', without paying close attention to assignment and prototypes :P) As a result, no matter what prototype we think up, we're always screwing either the one type of platform or the other. And not with a warning; the conflicting prototype would generate an error, nto a warning. The only solution I can think of is adding the proper prototype to the pyport.h header file, inside a proper #ifdef. For generated code it doesn't really matter which of the prototypes is used, but if the system headers do provide a prototype, and it doesn't match in indirect-constness, compilation will fail. (In other words, even on the platforms that are missing it, close attention should be paid to the manual pages, trying to guess what the prototype is going to look like if that particular system would ever grow a prototype in a system header. From what I read in the getopt(3) manpage on my linux box the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) Does anyone have a system where the prototype to getopt() is not defined in header files ? My Solaris 2.x testbox has that problem, but the box in question is one huge mess, and I doubt it has anything to do with Solaris in particular. I only use it to reproduce reported bugs, not report any myself ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Thu Oct 12 21:10:50 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012032448.A18407@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> The -l option tries to find any cyclic garbage produced by the NS> tests. I don't think that that option should be enabled NS> default. The output means that the GC is working and is finding NS> stuff that would not be freed by reference counting alone. NS> I can't tell if the GC would free this garbage. The -l option NS> sets the DEBUG_SAVEALL option which causes all garbage found to NS> end up in gc.garbage, not just garbage the can't be cleaned up. NS> I don't have pyexpat installed here so I can't test it. If you NS> want to find out if test_minidom is creating garbage the NS> collector can't free you should comment out the: NS> gc.set_debug(gc.DEBUG_SAVEALL) NS> line in regrtest.py and run: NS> regrtest.py -l test_minidom NS> If that does what I think it does and you still get the NS> "garbage: " line then the test is creating evil things. :) The test is not creating evil things. I commented out the DEBUG_SAVEALL line and got no error report. The question, then, is what to do about the -l option. I assume we should remove the -l option from the Makefile, so that "make test" doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in some way so that it still reports on tests that create evil things? Jeremy From nas@arctrix.com Thu Oct 12 14:20:10 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:20:10 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <20001012062010.A19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote: > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? This is a policy decision. Is it okay for the test suite to create garbage that is not collectable by reference counting? If yes, what about garbage that is not collectable by the (current) GC? Neil From guido@python.org Thu Oct 12 22:21:39 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:21:39 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400." <14822.6858.920988.167252@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com> > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. This seems to make sense, yes. Since the "leaked" objects that are found will be released by the GC code, I see no point in reporting these during the regression test. This can only confuse people (like it did Jeremy :-). > Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? Any form of evilness that can be detected without *too* much effort is worth it... I have no idea what kind of evil we're looking for here or how to detect is, so I can't answer yes or no. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Thu Oct 12 21:18:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT) Subject: [Python-Dev] New development documentation up... Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com> I don't normally post when I've updated the development copy of the documentation, but there are a couple of big additions there now. Martin von L=F6wis contributed substantial SAX2 documentation, which I've now integrated. Thanks, Martin! Chris Barker is working on new documentation for the Macintosh manual; I've only just started to look at it, but there's definately a *lot* of new material. That's not checked into CVS yet, but will be once I've had more time to go over it. Thanks, Chris! =09ftp://python.beopen.com/pub/docco/devel/index.html -Fred --=20 Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas@arctrix.com Thu Oct 12 14:28:04 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:28:04 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> Message-ID: <20001012062804.B19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote: > Any form of evilness that can be detected without *too* much effort is > worth it... I have no idea what kind of evil we're looking for here > or how to detect is, so I can't answer yes or no. That would be reference cycles with finalizers (ie. instances with __del__ methods). The current garbage collector does not free such structures but instead appends them to gc.garbage. Sorry for not being clear. In any case, regrtest should probably print a more clueful message when objects are found in gc.garbage. That would go a long way in clearing up the confusion. I'll see about a patch. Neil From guido@python.org Thu Oct 12 22:26:49 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:26:49 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST." <20001012062010.A19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com> > This is a policy decision. Is it okay for the test suite to > create garbage that is not collectable by reference counting? I don't see why that should be forbidden. After all some of the code we test has such leaks -- we haven't declared those absolute bugs. > If yes, what about garbage that is not collectable by the (current) > GC? Can you give an example of how such garbage can be created? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Thu Oct 12 21:38:29 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012062804.B19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> <20001012062804.B19026@glacier.fnational.com> Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> In any case, regrtest should probably print a more clueful NS> message when objects are found in gc.garbage. That would go a NS> long way in clearing up the confusion. I'll see about a patch. I think there is some value to issueing reports when a test creates trash that can't be cleaned up by the GC, but it doesn't make sense to report this by default. If "make test" reports an error, it should mean that something has gone wrong with the user's build and the interpreter is broken. That's not the case here. The build was fine; it's just the test that is iffy. I think we should turn of the -l option by default *and* patch it so that the output is more useful. I would suggest printing a count of the objects, perhaps organized by type/class name. Something like this: Test created 6 uncollectable objects 4 foo.Bar instances 2 foo.Baz instances Jeremy From tim_one@email.msn.com Thu Oct 12 21:33:41 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 16:33:41 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages . Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas , asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great . all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). From nas@arctrix.com Thu Oct 12 14:43:09 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:43:09 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> Message-ID: <20001012064309.C19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote: > > This is a policy decision. Is it okay for the test suite to > > create garbage that is not collectable by reference counting? > > I don't see why that should be forbidden. After all some of the code > we test has such leaks -- we haven't declared those absolute bugs. Again, "-l" should probably not be a default. I don't know who added it to TESTOPTS but it wasn't me. > Can you give an example of how such garbage can be created? Look at test_gc. Here is an example: class Foo: def __del__(self): pass foo = Foo() foo.foo = foo del foo Theoretically this structure could be collected without problem but the GC is too simple minded to realize that there is only one finalizer involved. Here's a better example: foo = Foo() bar = Foo() foo.bar = bar bar.foo = foo del foo, bar The GC cannot safely break this cycle so it punts and adds the instance objects involved to gc.garbage and forgets about it. Neil From tim_one@email.msn.com Thu Oct 12 22:38:13 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 17:38:13 -0400 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <20001012211436.Z12812@xs4all.nl> Message-ID: [Thomas Wouters, on getopt] > ... > From what I read in the getopt(3) manpage on my linux box the > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) I bet it's actually talking about Interpretation 150 to POSIX.2, here (while you can't read the std online, you can read the complaints online!): http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. html Doesn't have anything to do with the prototype, alas. > Does anyone have a system where the prototype to getopt() is not > defined in header files ? My Solaris 2.x testbox has that problem, but > the box in question is one huge mess, and I doubt it has anything to do > with Solaris in particular. ... Sure: Windows doesn't have a getopt; getopt isn't std C (not even in C99). Assorted derived stds demand that a getopt protoptype appear in stdlib.h, and others that it appear in unistd.h. I have a different suggestion: screw it. getopt keeps creating problems on GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU getopt shuffles all the "option strings" to the front, making a mess of, e.g., python myprog.py -v The Python source tree already has its own getopt implementation (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we like, and have Python use that instead on all systems. Every second we've spent tracking down problems with platform-supplied getopts has been a waste of time. they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- ly y'rs - tim From jack@oratrix.nl Thu Oct 12 23:03:57 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 13 Oct 2000 00:03:57 +0200 Subject: [Python-Dev] MacPython 2.0c1 available Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl> MacPython 2.0c1 is available, both as binary installer and in source form. You can find it through http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive please let me know whether it works, and, in the unlikely event it doesn't:-) what the problems are. Thanks, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From guido@python.org Fri Oct 13 00:07:28 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 18:07:28 -0500 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400." References: Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com> > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of, > e.g., > > python myprog.py -v > > The Python source tree already has its own getopt implementation > (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get > rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we > like, and have Python use that instead on all systems. Every second we've > spent tracking down problems with platform-supplied getopts has been a waste > of time. Excellent. After 2.0. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Thu Oct 12 23:18:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 00:18:01 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: ; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400 References: <20001012211436.Z12812@xs4all.nl> Message-ID: <20001013001801.A12812@xs4all.nl> On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote: > [Thomas Wouters, on getopt] > > ... > > From what I read in the getopt(3) manpage on my linux box the > > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) > > I bet it's actually talking about Interpretation 150 to POSIX.2, here (while > you can't read the std online, you can read the complaints online!): > http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. > html > Doesn't have anything to do with the prototype, alas. Ah, that sounds about right. Nifty link, too. I thought it had something to do with the prototype because of this comment: CONFORMING TO getopt(): POSIX.2, provided the environment variable POSIXLY_CORRECT is set. Otherwise, the elements of argv aren't really const, because we permute them. We pretend they're const in the prototype to be compatible with other systems. > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of [ a lot of things ] Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when necessary. Funny, I've seen that file a number of times, and read it, and read the getopt autoconf test as well, but somehow I never connected it with the loose prototype in main.c. I'm +1 on doing what you suggested, then. Wonder why it hasn't been done yet, though... we have no use for a system-wide getopt, except for a slightly smaller binary on systems that do have a 'good' system getopt. We can't use enhancements made to system getopt or anything, anyway. > they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- > ly y'rs - tim what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules- ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From m.favas@per.dem.csiro.au Fri Oct 13 01:47:25 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Fri, 13 Oct 2000 08:47:25 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au> Just a little unreality check - the whole world is not (yet) Linux - or even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour of 2.0 - OverflowError: math range error. Thus, on these platform, the proposed fixes _will_ change behaviour. But that's cool - I like Tim's proposed, um, steps to "rationalizing" fp behaviour, and will do what I can to help in the future. -- Email - m.favas@per.dem.csiro.au CSIRO Exploration & Mining From tim_one@email.msn.com Fri Oct 13 06:15:13 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:15:13 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au> Message-ID: [Mark Favas] > Just a little unreality check - the whole world is not (yet) Linux - or > even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on > Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour > of 2.0 - OverflowError: math range error. This is unfortunate. Guido never intended for Python to raise exceptions on underflow (and especially not *Over*flowError(!)), but he apparently didn't run on any platforms where this happened (I never have!), and AFAIK nobody ever mentioned this before. > Thus, on these platform, the proposed fixes _will_ change behaviour. See "unfortunate" above <0.5 wink>. > But that's cool - I like Tim's proposed, um, steps to "rationalizing" > fp behaviour, and will do what I can to help in the future. Want to fund a crack group of 754 experts for a year? Didn't think so. Constructive complaints will help a lot. So will beta testing. For example, I'm very keen to know whether the current CVS version of Python (2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or Tru64 Unix boxes. Running the (current CVS) std test suite will tell you: test_libm will pass or fail accordingly. If it's still busted on one of your systems, we've only got about a day to fix it (2.0 final is shipping early next week, and we have to let the codebase settle down for a couple days before building the final release). but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not- losing-much-sleep-over-it-ly y'rs - tim From tim_one@email.msn.com Fri Oct 13 06:18:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:18:52 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim hallucinated ...] > ... I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. Sorry for contradicting myself within a single sentence: I couldn't care less what happens in 2.0c1 anymore. Like I clearly said at the start, "current CVS version" is the question. From bwarsaw@beopen.com Fri Oct 13 06:33:57 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> Message-ID: <14822.40645.656159.493390@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> Again, "-l" should probably not be a default. I don't know NS> who added it to TESTOPTS but it wasn't me. I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I think (but don't really remember) that LEAK_DEBUG had different semantics than it does now. No matter. This was useful when gc was spankin' new and only semi-tested. It's probably fine to turn off -l in "make test" by default for the 2.0 release. -Barry From tim_one@email.msn.com Fri Oct 13 09:01:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 04:01:16 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim] > ... > We cannot consider this to be a bug since Python has had no *intended* > behavior whatsoever wrt 754 gimmicks. We can and do consider gripes > about these accidents to be feature requests. [Huaiyu Zhu] > Yes it varies widely in Python. But isn't that precisely because Python > does not support IEEE? Yes, but that's darned near tautological <0.5 wink>. > If Python does not actively undermine IEEE on platforms that have it, > would it still vary widely across these platforms? Yes. Your own -lieee example showed that math.sqrt(-1) computes not only a non-754 result, but a senseless result, on your platform under 1.5.2. If I show you a platform, how are you going to decide whether it "has" IEEE? 754 is a very involved std, and it's still rare to find a platform C that supports it correctly. On platform C's that do support it correctly, I know of none that do so without requiring platform-specific tricks. Python has *nothing* portable it can rely on, and its mass of utterly non-754-aware code building on haphazard C implementations adds up to the random x-platform crap we have today. ... [T] > The patch to stop setting -lieee was contributed by a Python user who > claimed it fixed bugs on *their* platform. That's "the reason". > We don't want to screw them either. [H] > Q: What bug? Which platform? Maybe there is another way that has less > impact on others? How to find out? I didn't check it in, and you can search the CVS archives as easily as I can (I'm not inclined to, since I don't think it can affect the outcome of this). Jeremy Hylton may, or may not, remember more about it (IIRC, he said he checked it in). > ... > If there is a way to fix the bug on that other platform while still keep > -lieee on Linux, would that be acceptable? No: Guido *wants* overflow to raise OverflowError by default, and *wants* sqrt(-1.0) to raise ValueError by default. Python's x-platform fp numerics today are an utter mess, and the best we can do for 2.0 is to make them as consistent as we have time to make them, despite that we know it will break some of your code (but you can still link with -lieee if you feel you must), and that Mark Favas has confirmed it will break code under both his Solaris and Tru64 Unix systems (but for a reason opposite of yours: he's been getting OverflowError on underflow since 1.5.2, and we're taking that away from him, and he'll have *no* way to go back). At this point we favor forcing consistency over maintaining platform accidents, no matter how attached people have gotten to them; else we'll be stuck with them forever. [oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/] > Interesting! I've glanced through some of Prof Kahan's writings. He is an entertaining writer, although his rhetoric is often more extreme than either of ours . > It appears that he favors raising flags that can be checked optionally, and > he is against mandatary raising exceptions. Have you read the 754 std? He's in favor of the 754 std. [quotes snipped, except for my favorite, which I've paraphrased many times over the years on c.l.py] > ... > They are called "Exceptions" because to any policy for handling them, > imposed in advance upon all programmers by the computer system, some > programmers will have good reason to take exception. > ... > From these quotes and others I understand that he wants f.p. exceptions to > be merely messanges, not errors that force programmers to take extra > actions, unless the programmer choose to. So what aspect of Java did he > think is deficient? It is the "Trap" style exception that mandate a users > action. His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5 main gripes about Java in bullet points at the top of page 3. The paper runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink>, reducing it to a bogus claim about Java that Kahan didn't make (Java has neither "Trap" nor "Flag" style fp exception signaling). > He told "A cautionary Tale of the Ariane 5", Which has nothing to do with Java -- the software in question was written in Ada, which (unlike Java) has "Trap" style. Why he put it in a paper about Java is a bit of a mystery; I write it off to rhetorical excess. > the European rocket that mulfunctioned after lift off. It turned out > that a piece of software produced an unimportant exception that is > not caught by a handler and caused debugging data to be dumped to a > critical memory location. This would have been avoided if the exception > merely raised a flag and returned a NaN, and the program continued. Actually, that was impossible to do, and he didn't suggest that. What he wrote is Had overflow merely obeyed the IEEE 754 default policy, the recalibration software would have raised a flag and delivered an invalid result both to be ignored by the motor guidance programs, and the Ariane 5 would have pursued its intended trajectory. Note that he didn't say NaN. He couldn't, because this was overflow in a conversion from Float to Integer. Despite his cheery optimism here, 754 is approximately useless in this case, since there is no generally accepted "invalid result" in integer formats (and 754 doesn't define one either -- the result of overflow in converting floats to ints is ill-defined in 754; 754 doesn't even require that it set the overflow flag). > So do we want every Python program to bomb whenever there is a floating > point value outside bound and is not trapped by try/except? By default, yes, Guido does, but for overflow, not underflow. If you read the following section of Kahan's paper, you should have noticed that he is *just* as critical of just returning Infs and NaNs (which is all Java does, and which is the accidental Python behavior you're arguing we keep in glibc) as he is of just trapping! His conclusion: "Without Traps nor Flags, Java’ s floating-point is Dangerous": Without flags, detecting rare creations of Inf and NaN before they disappear requires programmed tests and branches that, besides duplicating tests already performed by the hardware, slow down the program and impel a programmer to make decisions prematurely in many cases. Worse, a plethora of tests and branches undermines a program’s modularity, clarity and concurrency. I agree with him there wholeheartedly: without the 754-mandated flags, *and* without raising exceptions, the subset of 754 remaining sucks. >> ironically, 754 is hardest to sell to those who could benefit from >> it the most. > So far the only concern from number-crunchers voiced here is that it might > allow sqrt(-1)==0, which is not the case. Gimme a break! In the very msg Paul Dubois said that, he also said "Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened.". I'm starting to drop my assumption of good faith on your part: what you remember and how you paraphrase (whether it's Paul or Kahan) is extremely selective, beyond normal bounds of zeal-inspired distortion. > I was a fortran programmer before. I switched to using IEEE ten years > ago as soon as it was available on the machine I was using. So there > are different opinions. Certainly, and good 754 support will cater to most of them. I don't believe your opinion (or mine, for that matter) reflects anything even close to the majority view here, though. As I said in my reply to Paul, my observations (based on 15 years on the vendor side of the fp biz) matched his exactly (based on his experience with hundreds of numeric code authors): a vast majority still want divide-by-0, invalid operation, and overflow to raise an exception the vast majority of the time. > ... > Obviously we agree on the benefit of having a choice. But we > have different perspective on what choice means. Your want a choice > to force user to take explicit action, I want a choice to ignore these > events. No. I want exactly the choices 754 lays out: user-settable sticky flags and user-maskable exceptions. We're not getting that for 2.0. And we're *never* getting it if 2.0 doesn't do *something* to start disabusing people of the notion that their historical numeric platform accidents in Python will be faithfully preserved forever more. > The ideal solution might be to have a sys.fp_exception class. Each > exception would set a flag like fp_exception.overflow so that user can > check them. There could also be a variable like fp_exception.force_trap, > which when set, could make each f.p. exception to produce a Python > exception. This would confirm to IEEE 754 and give both of us a choice > we want. Kinda, except that each of the 5 754-defined traps must be individually maskable. 754 spells out what's needed. A PEP will be required to spell out the Python- and C-level APIs. I've corresponded (just -- no time now) a little with Kevin Jacobs about that offline. > Now that we are in feature freeze for 2.0, we can't get both choices. > Can we adopt the one that does not break behaviors on previous official > release, even if that's only by accident? Not as far as Guido or I are concerned, no. You can link with -lieee yourself if you must, although I can't recommend perpetuating the x-platform confusion here. We want to say that, e.g., math.exp works substantially the same way on *all* platforms under 2.0, not repeat the same decade-old "umm, don't know, and no way to guess -- try it on your platform and see what it does" yet again. I don't expect 2.0 will actually achieve that on all platforms, but it should on the primary ones. > ... > So now I know why people reported that NaN and Inf were broken on HPUX > and Windows and some others. If Python had simply ignored the flags ... Then we would have broken 754 subsets in slightly subtler ways, and still wildly varying across platforms. > ... > Could you please point a URL to "presubstitution"? In the paragraphs I > quoted the only mention of presubstitute is with NaNs and Inf, etc. Sorry, I don't save URLs, and don't recall whether this was in a paper or on David Hough's "Numeric Interest" mailing list in the early 90's. A Google search on "presubstitution Kahan" turns up 4 promising-looking hits I'll leave you to pursue. The basic idea is that the programmer gets to specify, via library calls (whatever), which particular fp value each 754 exceptional case returns. So, e.g., if it made sense for some part of the app, the programmer could say they wanted +- pi returned instead +- Inf, if and whenever overflow happened. Then set it back to +- Inf (or anything else they needed) later. This would be best if supported in HW directly, of course. > ... > You are not confirming to 754 until you allow all the exceptions to go > through with well defined values as default. I know that, but don't care. As I said, enabling overflow + invalid + div0 by default is the only scheme that can be *sold*. If you can find two NumPy users in favor of disabling them all by default, I'll be mildly astonished. 754 did itself enormous harm by insisting on that trivial point (it's trivial because, with proper support, anyone can change the defaults to anything they like with one line of code): I worked in the supercomputer biz at the time 754 was adopted, and for a decade after, and the "non stop" defaults were *universally* opposed by customers. Scared the hell out of language stds committees too, which goes a lot farther than the 754 folks would like to admit toward explaining why language committees stayed away from 754 bindings in droves. C99 is 15 years(!) after the fact. > Raising Python exceptions on some of them does not confirm to 754, as > the default IEEE 754 behavior on f.p. exception is not a Python exception, > but just a raised flag. See above. > Before that happens, what is the motive to make IEEE less usable for those > who have it (pretty much every one nowadays), even if just by accident? I think I've repeated the reasons to death already, and you've repeated to death that you'll never agree. So no more from me on that. > ... > But just to clarify some wordings you quoted in another post: I meant that > sqrt(-1)==0 is insane, whether silent or not. I agree. > Raising an exception is sane, Not according to 754's default rules, which you wanted me to take as sacred just a few paragraphs ago . > although OverflowError is not so reasonable. I'd say it's insane. > Raising a ValueError is reasonable. I expect we'll have to make InvalidOperationError a subclass of ValueError for that reason, when 754 support materializes. > But just returning NaN without a fuss is even better. You're going to find that's a very lonely position. > My favorite is returning 1j, as MatPy does. Then you should use cmath.sqrt instead of math.sqrt. Even $3 business calculators have a sqrt key these days, and you do not want to be on the other end of email when trying to explain to a businessperson why their crappy std deviation program returned a complex number <0.1 wink>. > if-it-ain't-broke-don't-fix-it-ly y'rs it-it-weren't-broke-we-wouldn't-ly y'rs - tim From fgranger@altern.org Fri Oct 13 11:08:23 2000 From: fgranger@altern.org (Francois Granger) Date: Fri, 13 Oct 2000 12:08:23 +0200 Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl> Message-ID: on 13/10/00 0:03, Jack Jansen at jack@oratrix.nl wrote: > MacPython 2.0c1 is available, both as binary installer and in source > form. You can find it through > http://www.cwi.nl/~jac/macpython.html. This one works better. http://www.cwi.nl/~jack/macpython.html --=20 Fran=E7ois Granger fgranger@altern.org From nas@arctrix.com Fri Oct 13 07:37:17 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 23:37:17 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> Message-ID: <20001012233717.A20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote: > I think (but don't really remember) that LEAK_DEBUG had > different semantics than it does now. Nope. LEAK_DEBUG prints to stderr information about all garbage the GC finds, even stuff the GC can free. The thinking was that GC would be an option and people would want to find applications that leak when only using reference counting. > No matter. This was useful when gc was spankin' new and only > semi-tested. It's probably fine to turn off -l in "make test" by > default for the 2.0 release. I've left -l enabled for now. Detecting tests that create uncollectable garbage is probably a good thing. It doesn't cost much and the message should be fairly clear now. Neil From fdrake@beopen.com Fri Oct 13 14:34:03 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012233717.A20054@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I've left -l enabled for now. Detecting tests that create > uncollectable garbage is probably a good thing. It doesn't cost > much and the message should be fairly clear now. Perhaps one thing that could be done is to reduce the volume of the output; perhaps just list the first 1K or 2K of the repr? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas@arctrix.com Fri Oct 13 08:09:48 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 00:09:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400 References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Message-ID: <20001013000948.C20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote: > Perhaps one thing that could be done is to reduce the volume of the > output; perhaps just list the first 1K or 2K of the repr? It just prints the number of object found now. Neil From fdrake@beopen.com Fri Oct 13 15:06:22 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001013000948.C20054@glacier.fnational.com> References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> <20001013000948.C20054@glacier.fnational.com> Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > It just prints the number of object found now. Ok, I must have missed the checkin that changed that. This is fine in my book as well. Thanks for staying on top of this work! I think you've really done a great job with the GC effort. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw@fnal.gov Fri Oct 13 16:18:23 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach I tried sending a message with the output of ./configure and make attached, but it was over the 40K limit. If anybody wants to see these, email me. From nas@arctrix.com Fri Oct 13 09:28:49 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 01:28:49 -0700 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013012849.C20168@glacier.fnational.com> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Unresolved: > __pthread_mutex_init [...] What is the LIBS variable set to in Modules/Makefile? It looks your missing something like "-lpthread". Neil From cgw@fnal.gov Fri Oct 13 16:35:52 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013012849.C20168@glacier.fnational.com> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013012849.C20168@glacier.fnational.com> Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov> Neil Schemenauer writes: > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > > Unresolved: > > __pthread_mutex_init > [...] > > What is the LIBS variable set to in Modules/Makefile? It looks > your missing something like "-lpthread". Hehehe. I might be kinda thick sometimes, but I think I would have caught that. Here's a little more of the "make" output: cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. From thomas@xs4all.net Fri Oct 13 17:34:36 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 18:34:36 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013183436.B12812@xs4all.nl> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Sorry, I don't have time to investigate this fully right now. Maybe > this weekend. For now this is just a heads-up. Hopefully, something > is just misconfigured on this system. > The machine in question is running OSF1 V4.0 878 alpha That's a former DEC alpha, right ? Perhaps running configure with '--with-dec-threads' will solve the problem ? I'm not sure if that will work alone, so you might need '--with-dec-threads --with-threads=no' to disable 'normal' thread-checking. You can also try this by hand; after running configure, edit Modules/Makefile.pre, and change LDLAST= into LDLAST= -threads (not -lthreads, just -threads) That seems to be the only difference --with-dec-threads uses. I looked at this before, but don't have an alpha or anything else that needs --with-dec-threads, so I couldn't detect this automatically. I do think it should be done automatically, though. Perhaps I can figure it if you can send me, for instance, config.log and the output of configure, and find the time to run a few tests later. > I can only build Python from current CVS sources on OSF/1 if I specify > --without-thread. If I don't specify this I get the following errors > at link time: > Unresolved: > __pthread_mutex_init > I tried sending a message with the output of ./configure and make > attached, but it was over the 40K limit. If anybody wants to see > these, email me. If the above doesn't fix it, I can take a look at the output of configure and config.log. No need to see the output of make just yet. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From cgw@fnal.gov Fri Oct 13 19:31:34 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013183436.B12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov> Thomas Wouters writes: > > That's a former DEC alpha, right ? Perhaps running configure with > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > alone, so you might need '--with-dec-threads --with-threads=no' to disable > 'normal' thread-checking. Thank you, that indeed solves the problem. Sorry for the noise. It would be nice if configure were smart enough to figure this out! From cgw@fnal.gov Fri Oct 13 19:38:26 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <200010131453.JAA23050@buffalo.fnal.gov> Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov> Tim Peters wrote: > I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. I just repeated this test, on the following 4 platforms: 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 2) OSF1 V4.0 878 alpha DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) 3) IRIX64 6.5 07151432 IP27 MIPSpro Compilers: Version 7.2.1 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 gcc version 2.95.2 19991024 (release) On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) raises an exception, and test_math.py completes successfully. Testing-ly (not to be confused with testily) yr's, cgw From tim_one@email.msn.com Fri Oct 13 19:56:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 14:56:43 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: [Charles G Waldman] > I just repeated this test, on the following 4 platforms: > > 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise > cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 > > 2) OSF1 V4.0 878 alpha > DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) > > 3) IRIX64 6.5 07151432 IP27 > MIPSpro Compilers: Version 7.2.1 > > 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 > gcc version 2.95.2 19991024 (release) > > On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) > raises an exception, and test_math.py completes successfully. Excellent! Note that test_math.py was augmented to verify that: 1. exp(-huge) returns 0 without exception. 2. exp(+huge) raises OverflowError. 3. sqrt(-1) raises ValueError. None of those were reliable across platforms before, and I'm afraid there's strong reason to suspect one or more still won't work right under Mandrake Linux when Python is compiled with -O (this based on the output of a C program someone posted to c.l.py yesterday). But it's a world better than it used to be. > Testing-ly (not to be confused with testily) yr's, You bet -- everyone leave testily to me on this one. I'm bitter enough about floating-point in stinking C for everyone combined <0.9 wink>. From thomas@xs4all.net Fri Oct 13 20:19:38 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 21:19:38 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> Message-ID: <20001013211938.C12812@xs4all.nl> --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > > > That's a former DEC alpha, right ? Perhaps running configure with > > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > > alone, so you might need '--with-dec-threads --with-threads=no' to disable > > 'normal' thread-checking. > Thank you, that indeed solves the problem. Sorry for the noise. No problem. When I went over the README file a few weeks back, and sent Guido an update, this particular issue was one of the biggest problems for me: the old README, which assumed threads were not default, was quite adamant about using --with-dec-threads for OSF/1 and its incarnations. Unfortunately, it doesn't say why :) And the configure script only says that it's necessary to get threadsafe libraries. > It would be nice if configure were smart enough to figure this out! Configure is as smart as we make it. configure is made by autoconf, which is moderately intelligent, and we just have to add the extra geniality to configure.in. If the only check we need is 'does this system call itself OSF1', we can easily add that. See the attached patch (configure.in version only. Let me know if you need a patched configure as well, I don't know if OSF systems come with autoconf. It's pretty large, though, and you don't need to generate configure on the same system as you run it on. Just apply the configure.in patch, type 'autoconf', and copy the resulting configure script to your OSF1 machine.) The question is, is this enough ? Will this detect all the OSF platforms that need '-threads', and will it only add it to those platforms ? It wouldn't be particularly nice of configure if it insisted on adding '-threads' on platforms that don't need it, or worse, break because of it. For instance, the patch uses 'OSF*', which might be too generic... but 'OSF1' might be too restrictive :-) A better fix would probably be to write a test program that explicitly uses threads & the -threads arguments, but that could fail for a large number of reasons, which doesn't mean -threads isn't needed :P (Configure is really amusing like that. For instance, if your compile system is broken, like when you unpacked a new linux kernel source tree in /usr/src/linux, but forgot to type 'make symlinks', configure will assume the worst (every check is negative, after all.) If you're lucky, it will complain because you miss an essential feature... If you're unlucky, it finishes cleanly, writes the config.cache file, your compile fails, you figure out the problem, and you keep compiling using the wrong autoconf 'settings'. And re-configuring doesn't fix it, because the config.cache file is just fine ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dec-thread.patch" Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.172 diff -c -r1.172 configure.in *** configure.in 2000/10/12 17:11:38 1.172 --- configure.in 2000/10/13 19:15:11 *************** *** 805,810 **** --- 805,819 ---- LIBS="$LIBS -lthread" LIBOBJS="$LIBOBJS thread.o" USE_THREAD_MODULE=""]) + + if test "$USE_THREAD_MODULE" != "#" + then + # If the above checks didn't disable threads, (at least) OSF1 + # needs this '-threads' argument during linking. + case $ac_sys_system in + OSF*) LDLAST=-threads;; + esac + fi fi # Check for GC support --jRHKVT23PllUwdXP-- From skip@mojam.com (Skip Montanaro) Fri Oct 13 20:39:42 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: <14823.25854.786347.542654@beluga.mojam.com> Tim> None of those were reliable across platforms before, and I'm afraid Tim> there's strong reason to suspect one or more still won't work right Tim> under Mandrake Linux when Python is compiled with -O (this based on Tim> the output of a C program someone posted to c.l.py yesterday). But Tim> it's a world better than it used to be. After executing cvs update -d . ./configure make clean make OPT=-O3 I get the following output from regrtest.py regarding test_math: % ./python Lib/test/regrtest.py test_math test_math 1 test OK. This is on a Mandrake 7.1 system. Here are the bits I think are relevant to identify my environment: % cat /etc/issue.net Linux Mandrake release 7.1 (helium) Kernel 2.2.16-9mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -q -a | egrep glibc glibc-devel-2.1.3-15mdk compat-glibc-5.3-2.0.7.6mdk glibc-2.1.3-15mdk If you have a C test program you'd like me to try, shoot it over. I'll be glad to run it and shoot back the results. Skip From fdrake@beopen.com Fri Oct 13 20:41:46 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: The test passes for me as well on Mandrake 7.1. Here's the environment info: % ./python -tt ../Lib/test/regrtest.py test_math test_math 1 test OK. % cat /etc/issue.net Welcome to %h Linux Mandrake release 7.1 (helium) Kernel 2.2.15-4mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -qa | egrep glibc nedit-5.1.1-1.glibc glibc-profile-2.1.3-5mdk glibc-2.1.3-5mdk compat-glibc-5.3-2.0.7.6mdk glibc-devel-2.1.3-5mdk > If you have a C test program you'd like me to try, shoot it over. I'll be > glad to run it and shoot back the results. Same here... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw@fnal.gov Fri Oct 13 20:52:44 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: > % gcc -v > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs > gcc version 2.95.3 19991030 (prerelease) AFAIK, this version of GCC was never "blessed" by the GCC maintainers and should not be being used for any production work. I think Mandrake did a bad thing by shipping this version. Not quite as bad as what RedHat did by shipping the completely not-for-general-use gcc-2.96, but nonetheless still a bad thing. When will distribution builders learn that having a higher version number is not necessarily a good thing? Why do they keep second-guessing the good advice of the GCC Steering Committee? Sigh... In any case, I don't think we should put effort into chasing down bugs that are caused by bogus C compilers. Any reports coming in from RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. From fdrake@beopen.com Fri Oct 13 20:58:53 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> <14823.26636.59174.832572@buffalo.fnal.gov> Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com> Charles G Waldman writes: > AFAIK, this version of GCC was never "blessed" by the GCC maintainers > and should not be being used for any production work. I think > Mandrake did a bad thing by shipping this version. Not quite as bad I agree. > In any case, I don't think we should put effort into chasing down bugs > that are caused by bogus C compilers. Any reports coming in from > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. I think Skip & I were showing that there isn't a bug for Mandrake 7.1. I don't know what version of GCC shipped with Mandrake 7.0, which may have been the version Tim received the report for (I recall he said "Mandrake 7", which isn't specific). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From larsga@garshol.priv.no Fri Oct 13 21:08:05 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Oct 2000 22:08:05 +0200 Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Message-ID: * Fred L. Drake, Jr. | | This looks like a problem in the unlink() method of the DOM. Could | you please check that the unlink() method is updated to handle the | latest version of the other changes? It seems that the current unlink() does not remove sibling cycles. Patch #101897 adds a line to set sibling references to None, which seems to make regrtest.py -l happy. --Lars M. From prescod@prescod.net Fri Oct 13 21:12:38 2000 From: prescod@prescod.net (Paul) Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT) Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Message-ID: Right, I just checked in the fix to that. Paul Prescod On 13 Oct 2000, Lars Marius Garshol wrote: > > * Fred L. Drake, Jr. > | > | This looks like a problem in the unlink() method of the DOM. Could > | you please check that the unlink() method is updated to handle the > | latest version of the other changes? > > It seems that the current unlink() does not remove sibling cycles. > Patch #101897 adds a line to set sibling references to None, which > seems to make regrtest.py -l happy. > > --Lars M. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From tim_one@email.msn.com Fri Oct 13 21:23:31 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 16:23:31 -0400 Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> Message-ID: The original source of my concern was this c.l.py post from David Cooke: http://www.deja.com/getdoc.xp?AN=680840594 He ran a little C program that Huaiyu Zhu had posted earlier in the thread. According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ... without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt *never* set errno, regardless of input. In which case what Python does with the platform NaN result from math.sqrt(-1.) is an accident (and probably ends up setting errno to ERANGE itself by mistake), and an overflowing exp would let the platform +Inf result pass thru silently. So, if David's report is correct, and best I understand it you were all using 7.1 too with at least some level of optimization, it's A Mystery why CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would probably fail; its new math.exp(+huge) test would almost certainly fail). I'm anal enough about this stuff that I'd try to figure out why if I had a Mandrake system, but in the cosmic scheme of things I doubt it's important enough for anyone else to burn time on. From jeremy@beopen.com Sat Oct 14 00:05:02 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT) Subject: [Python-Dev] build problems large and small on FreeBSD Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net> I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE FreeBSD). There are a number of compiler warnings, all having to do with redefinitions, plus some linker warnings and a test failure. I don't have time to investigate further, but thought I'd let people know in case someone else has time to take a look. test_math failed -- overflowing exp() didn't trigger OverflowError Python 2.0c1 (#2, Oct 13 2000, 15:50:26) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.exp(1200) Inf The warnings from the linker seem harmless enough. I don't know why it is complaining about setkey and des_setkey. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() The compiler-time warnings look like they are caused by a configure problem. If so, I don't know how to fix it :-). gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c In file included from /usr/include/unistd.h:42, from ../../Python/thread.c:28: /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined ../config.h:136: warning: this is the location of the previous definition In file included from ../../Python/thread.c:118: ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined /usr/include/pthread.h:158: warning: this is the location of the previous definition ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined /usr/include/pthread.h:157: warning: this is the location of the previous definition ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined /usr/include/pthread.h:156: warning: this is the location of the previous definition Jeremy From jeremy@beopen.com Sat Oct 14 00:11:10 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT) Subject: [Python-Dev] warnings --with-pydebug Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net> If you configure using '--with-pydebug' you get a lot of compile-time warnings. ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:672: warning: value computed is not used ../../Python/ceval.c:675: warning: value computed is not used ../../Python/ceval.c:678: warning: value computed is not used ../../Python/ceval.c:680: warning: value computed is not used ../../Python/ceval.c:681: warning: value computed is not used [etc.] I assume these are caused by the definition of Py_INCREF #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) Is there some way to change this macro so that the warnings are silenced? Jeremy From thomas@xs4all.net Sat Oct 14 00:28:19 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:28:19 +0200 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400 References: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <20001014012819.D12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote: > The warnings from the linker seem harmless enough. I don't know why > it is complaining about setkey and des_setkey. That's probably due to 'crypt()' being used, or some other library call that Python uses indirectly. If you want crypt(), you need to install a seperate DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all crypt purposes by default, because of the US Counter-Espionage Protection Plan or something :) If you don't want to install those, don't enable the crypt module. There are a couple of pure python crypt() implementations around, by the way, which always use pure DES crypt(). > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. This one is weirdish. I don't see any gets() call in Python, so I have to assume it's in some library or header file Python includes. A good candidate would be readline, which has appalled me before :) but who knows :P I'm inclined to think it isn't a library that comes with FreeBSD by default, since they are usually pretty picky about such things. (especially if it generates a linker warning each time it's used!) > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Yes, I've seen this before. Debian-unstable (I think ?) complains about tmpnam() and tempnam() as well. The manpages just say 'don't use this function, use mkstemp(3)'. It doesn't mention a reason, but it's probably because the files/directories created by these functions are predictable, which means you shouldn't use them for security-by-obscurity. The mktemp() warning doesn't come from Python, looks like. Probably another library that is included. If you really care about which it is, you'll have to comment them out one by one (I'd suggest starting with the oldest and least FreeBSDish one, i.e. readline :) but I don't think it's going to really matter. Python does use 'tempnam' and 'tmpnam', but only in the posixmodule, to provide Python versions. I'm not sure if we can just change these functions to use mkstemp (or tempfile, see below) internally, without breaking code, though I expect it'll be alright. What's more, these functions are new since 1.5.2. And also, I just noticed a bug/typo in the tempnam docstring. The one funny bit, though, is that these three functions point to mkstemp(), and the mkstemp() manpage reads this: Don't use this function, use tmpfile(3) instead. It's better defined and more portable. "When does the hurting stop ?" > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. And this falls in the 'it wasn't us' category again. > The compiler-time warnings look like they are caused by a configure > problem. If so, I don't know how to fix it :-). > gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c > In file included from /usr/include/unistd.h:42, > from ../../Python/thread.c:28: > /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined > ../config.h:136: warning: this is the location of the previous definition Hm, yes. This looks like an unfortunate clash between a Python internal #define and a FreeBSD libc internal #define. I'm not sure if this is really the case, maybe the Python one serves exactly the same purpose as the FreeBSD one, but in that case, configure shouldn't redefine it. We can either rename the #define in Python, as it's only used to determine which thread functionality is available, or adjust the configure tests to see if it is #defined and not redefine it if so. (Or rather, to be sure that it defines the right thing, configure would have to test for posix threads, check the #define (if any), and if they don't match up, scream its head off. So perhaps renaming is the smarter thing.) On the other hand, the fact that you only got a warning, and not an error, means that Python isn't defining it to a different value than FreeBSD did, so it's not really a problem. It might be a problem if Python #defines it, but FreeBSD does not, but FreeBSD does have code that checks that #define, and starts doing weird things... > In file included from ../../Python/thread.c:118: > ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined > /usr/include/pthread.h:158: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined > /usr/include/pthread.h:157: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined > /usr/include/pthread.h:156: warning: this is the location of the previous definition Not sure about these, because I don't know enough about the various types of posix thread standards, and almost-posix thread almost-standards. I'm not sure if those names are reserved in any way, but they are apparently clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code that does the defines like Python does, too. A simple '#undef' or '#ifndef' would suffice, here, I think, but I'm not sure. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sat Oct 14 00:33:59 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:33:59 +0200 Subject: [Python-Dev] warnings --with-pydebug In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400 References: <14823.38542.908547.275077@bitdiddle.concentric.net> Message-ID: <20001014013359.E12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote: > If you configure using '--with-pydebug' you get a lot of compile-time > warnings. > ../../Python/ceval.c: In function `eval_code2': > ../../Python/ceval.c:672: warning: value computed is not used > ../../Python/ceval.c:675: warning: value computed is not used > ../../Python/ceval.c:678: warning: value computed is not used > ../../Python/ceval.c:680: warning: value computed is not used > ../../Python/ceval.c:681: warning: value computed is not used > [etc.] > I assume these are caused by the definition of Py_INCREF > #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) > Is there some way to change this macro so that the warnings are > silenced? Yes, prefix it with '(void)': #define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++) However, that means that the 'return value' of Py_INCREF() must never be used anywhere. (If it does, it'll generate an error.) The return value of Py_INCREF() is not terribly useful, though. Both in debug and in normal mode, it expands to the refcount of the object *before* it was INCREF'd. I still consider this kind of warning (I've seen it before, always with macros that do several things by using the otherwise fairly useless tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements have sideeffects, and it's obvious we want to throw away the first result, so why worry about the second ? But at least it isn't screwing up floating-point operations, and nobody's perfect :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu@yahoo.com Sat Oct 14 01:25:49 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: Tim, Thank you for the explanations. We actually agree more than it appears: - Full IEEE 754 support in Python is good, which should allow the user to decide when to use raised flags and when to use Python exceptions. - If the user default can be changed with one line of code, it does not matter if Python default use exceptions, even if that's not strict compliance in words. The "factory default" might as well set for the benefit of newbies. - Without IEEE 754 support, or with just partial support, f.p. computation is a mess. Following are some contentious issues: I am not so sure that even with 754, there would still be a great variety. I see you giving one example: sqrt(-1) in 1.5.2. But wasn't that caused by extra Python checking? I say this because errno=3D=3D0 in C. Maybe I'm mi= ssing something. Or, do you mean that glibc itself is deficient, because it should have set the flag? My worry concerns the decision to unify 2.0 f.p. behavior in a specific way before full IEEE 754 support. I understand that you say this does not coun= t as a changed behavior because the previous one is accidental. But I don't see the particular fixed subset chosen as any better than any other. I agre= e that I do have a choice of using -lieee, though. It is interesting to know that someone actually relies on OverflowError to detect underflow. But why not let them continue that as well, given that all of these would be available in the future anyway? > At this point we favor forcing consistency over maintaining platform > accidents, no matter how attached people have gotten to them; else we'll > be stuck with them forever. I do not understand. Once there is full IEEE 754, everyone would have a choice, which pretty much includes all the things people are doing now. Before that happens, why consistency accross platform is deemed more important than consistency accross releases? My naive thinking is that people port more from 1.5.2 to 2.0 than from one platform to another, isn't it? :-) Following does not have much new to say, just some clarification. You are right to emphasise that Kahan does not favor any subset of IEEE 754= : > > They are called "Exceptions" because to any policy for handling them, > > imposed in advance upon all programmers by the computer system, some > > programmers will have good reason to take exception. Yes. And that's what's happening. :-) > His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his= 5 > main gripes about Java in bullet points at the top of page 3. The paper > runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink= >, > reducing it to a bogus claim about Java that Kahan didn't make (Java has > neither "Trap" nor "Flag" style fp exception signaling). Thank you for correcting me on this one. I did "glance over" all the pages= =2E I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and got Exception in thread "main" java.lang.ArithmeticException: / by zero But now I see that 1/0.0 is Infinity. So is Math.exp(777). And so on. So that teaches me to test, test, test, ... > > He told "A cautionary Tale of the Ariane 5", >=20 > Which has nothing to do with Java -- the software in question was written= in > Ada, which (unlike Java) has "Trap" style. Why he put it in a paper abou= t > Java is a bit of a mystery; I write it off to rhetorical excess. You are right it does not apply to Java. I guess he meant that as a warnin= g that changing to the other side might be equally bad. > > So do we want every Python program to bomb whenever there is a floating > > point value outside bound and is not trapped by try/except? >=20 > By default, yes, Guido does, but for overflow, not underflow. That's the harsh reality I have to live with, I suppose. <0.9wink> > If you read > the following section of Kahan's paper, you should have noticed that he i= s > *just* as critical of just returning Infs and NaNs (which is all Java doe= s, > and which is the accidental Python behavior you're arguing we keep in gli= bc) > as he is of just trapping! His conclusion: "Without Traps nor Flags, Ja= va=92 > s floating-point is Dangerous": >=20 > Without flags, detecting rare creations of Inf and NaN before they > disappear requires programmed tests and branches that, besides > duplicating tests already performed by the hardware, slow down the > program and impel a programmer to make decisions prematurely in many > cases. Worse, a plethora of tests and branches undermines a program= =92s > modularity, clarity and concurrency. >=20 > I agree with him there wholeheartedly: without the 754-mandated flags, > *and* without raising exceptions, the subset of 754 remaining sucks. That is true, but all these problems apply to "without raising flags", whether with or without "raising exceptions". Silent overflow forces programmers to do extra checking if they need to find them. Mandatory exception forces programmer to do extra checking if they don't want them to stop the program. Which is more common? It depends on programming style. In my programs, intentional NaN is far more than NaN by mistake. As to whether it is dangerous, I would say that if an overflow is really an error, good programming style requires that it be detected much earlier tha= n the actual overflow. I agree this cannot be expected of everyone, though. > >> ironically, 754 is hardest to sell to those who could benefit from > >> it the most. >=20 > > So far the only concern from number-crunchers voiced here is that it mi= ght > > allow sqrt(-1)=3D=3D0, which is not the case. >=20 > Gimme a break! In the very msg Paul Dubois said that, he also said "Some > people use Inf but most people want the code to STOP so they can find out > where the INFS started. Otherwise, two hours later you have big arrays o= f > Infs and no idea how it happened.". I'm starting to drop my assumption o= f > good faith on your part: what you remember and how you paraphrase (wheth= er > it's Paul or Kahan) is extremely selective, beyond normal bounds of > zeal-inspired distortion. Well, I was talking about whether anyone has shown a concern to oppose 754. I was not talking about whether exception is prefered to flags. See the line I was replying to? Actually, thinking about it, Paul was not talking about concerns over 754, either. So there appears zero resistence to 754 from number crunchers here. > > Obviously we agree on the benefit of having a choice. But we > > have different perspective on what choice means. Your want a choice > > to force user to take explicit action, I want a choice to ignore these > > events. >=20 > No. I want exactly the choices 754 lays out: user-settable sticky flags > and user-maskable exceptions. We're not getting that for 2.0. And we're > *never* getting it if 2.0 doesn't do *something* to start disabusing peop= le > of the notion that their historical numeric platform accidents in Python > will be faithfully preserved forever more. Let me make it clear that we agree on all essential points about full 754 support. The difference only exists in the period before that. Since both the 1.5.2 accidental behaviors and the one you want to unify to are just subsets of the full support, it does not appear to me that disabling severa= l of them is a prerequisite for the full support. > Kinda, except that each of the 5 754-defined traps must be individually > maskable. 754 spells out what's needed. A PEP will be required to spell > out the Python- and C-level APIs. I've corresponded (just -- no time now= ) a > little with Kevin Jacobs about that offline. Great! If the true IEEE 754 support could come soon, all my gripe is moot. So I'll stop disturbing you on the good work. :-) OK, I see that you want consistency above anything else before that good da= y comes. Well, consistency is good. Whether the price is too high is a subjective judgement. So I'll just use the -lieee hack for myself, then. [On presubstitution]=20 Ok, I found it. It looks good. [On whether 754 default uses flags or exceptions]=20 I agree with you: the system default matters very little as long as users can set their own defaults easily. =20 > I expect we'll have to make InvalidOperationError a subclass of ValueErro= r > for that reason, when 754 support materializes. That'll be handy. > > My favorite is returning 1j, as MatPy does. >=20 > Then you should use cmath.sqrt instead of math.sqrt.=20 Thanks. Huaiyu From skip@mojam.com (Skip Montanaro) Sat Oct 14 01:29:06 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT) Subject: [Python-Dev] Simple xml.sax example? Message-ID: <14823.43218.337621.157021@beluga.mojam.com> Is there a simple example available that demonstrates how to use elements of the new xml.sax package? I'd prefer something that doesn't require me to install anything other than what comes with the Python 2.0 distribution? Thanks, Skip From cbarker@jps.net Sat Oct 14 02:22:28 2000 From: cbarker@jps.net (Chris Barker) Date: Fri, 13 Oct 2000 18:22:28 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) References: Message-ID: <39E7B554.29A168E3@jps.net> Incomplete vs. non-at-all IEEE 754 support is a non argument. If you have full IEEE support (which it seems everyone here thinks would be good, but difficult), it is clear what you have. If not, you are not consistent with a standard, and therefor making up your own. That being the case, it's a matter of what we want the Python standard to be. I, for one think that NaN and Inf are fantastic!!! I think the best argument for them here is that it is almost impossible to do a lot of array based calculations without them, and you can't do serious number crunching in Python without array based calculations. I've come to Python from MATLAB for numerics, and I really appreciated MATLAB's way of handling all this. I don't think MATLAB has true 754 support, as I don't think you can change the behaviour, but you do get a consistent result across platforms (including non-iee machines like the Cray?---I have no idea). I have not yet heard a decent response to the question of what to do when a single value in a large array is bad, and causes an exception. This really does render Python essentially useless for Numerics for me. I suspect all those number crunchers that want an exception rather than an Inf are NOT using array-oriented languages. My goal is to dump MATLAB for Python, but this may prevent me from doing that. Does anyone know what other array-oriented languages use? I know what MATLAB does: >> exp(-777) ans = 0 >> exp(777) ans = Inf >> sqrt(-1) ans = 0 + 1.0000i Hey! I like that! Python is dynamic, why can't we just get the actual answer to sqrt(-1), without using cmath, that always returns a complex ? sorry, other subjet, not meant to be raised at the moment. >> 54/0 Warning: Divide by zero. ans = Inf Here we get a warning, but also a result that won't crash the computation. >> a = 0/0 Warning: Divide by zero. a = NaN >> b = a b = NaN >> a == b ans = 0 So comparing two NaNs yields a false, as it should, and though Python won't do it now, it could. One thing that a numerical routine should NEVER do is give an incorrect answer. No answer is often bad, but an incorrect one is much worse. NaN == NaN must return false. Does anyone know what FORTRAN 90 specifies (if anything)? What other array-oriented languages are there? I think what MATLAB does is what Tim is calling "bad *and* incomplete 754 support" Incomplete is surely true, "bad" is clearly a matter of opinion. It seems we have a variety of users of numerics in Python, that I break into three broad catagories: Casual users: mostly doing non-numeric stuff, with the occasional calculation: This group could use any non-cryptic handling of over/underflow, it just doesn't matter. Mid-level number crunchers: This is the group I put myself in. We crunch a lot of numbers, really like the array semantics (and speed) of NumPy, and are doing things like graphing functions, statistical calculations, etc. We have probably only taken one of two (at most) numerical analysis courses, and many don't know what the heck IEE 754 is. (The one Numerical Analysis course I did take, happened to be with Kahan, which is why I know what it is) For this group, the incomplete IEEE support is probably the best way to go. We're more likely to be annoyed by our whole computation stopping because of one bad data point, than we are to be pissed off that it didn't stop when it started to compute garbage. Hard Core Number crunchers: These are the folks that do things like write optimised routines for particular architectures, adn teach numerical analysis courses. These folks want either FULL IEEE, or plain old "classic" overflow and underflow errors, that they can handle themselves. Do these folks really use Python as other than a glue language? Are they really doing massive number crunching in Python itself, rather than in C (or whatever) extensions? If so, I'd be surprised is they didn't find Huaiyu's argument compelling when doing array based calculations. Tim pointed out that Python was not designed with 754 in mind, so for 2.0, what he is doing is probably our best bet, but it seems to not be the best ultimate solution, I hope using NaN and Inf will be considered for future versions, even if it is incomplete 754 compliance. Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible without custom re-compiling your own interpreter? If so, is there any chance that it will come any time soon (2.1 ?) , so we don't have to have this discussion at all? Thanks for all of your work on this, Python just keeps getting better!! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cgw@fnal.gov Sat Oct 14 03:44:42 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov> Chris Barker writes: > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? You have to import the sqrt function from somewhere. Either you import it from math or from cmath, depending on which flavor you need. Anybody sophisticated enough to know what complex numbers are, and sophisticated enough to want to get complex values as a result of a calculation, should be sophisticated enough to be able to type "cmath". From larsga@garshol.priv.no Sat Oct 14 11:19:20 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 14 Oct 2000 12:19:20 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com> References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: * Skip Montanaro | | Is there a simple example available that demonstrates how to use | elements of the new xml.sax package? Here are a couple from an internal seminar I recently gave on this. I could make the slides available as well, if there is interest. --Lars M. --- elem_count.py import sys from xml.sax import make_parser, handler class FancyCounter(handler.ContentHandler): def __init__(self): self._elems = 0 self._attrs = 0 self._elem_types = {} self._attr_types = {} def startElement(self, name, attrs): self._elems = self._elems + 1 self._attrs = self._attrs + len(attrs) self._elem_types[name] = self._elem_types.get(name, 0) + 1 for name in attrs.keys(): self._attr_types[name] = self._attr_types.get(name, 0) + 1 def endDocument(self): print "There were", self._elems, "elements." print "There were", self._attrs, "attributes." print "---ELEMENT TYPES" for pair in self._elem_types.items(): print "%20s %d" % pair print "---ATTRIBUTE TYPES" for pair in self._attr_types.items(): print "%20s %d" % pair parser = make_parser() parser.setContentHandler(FancyCounter()) parser.parse(sys.argv[1]) --- roundtrip.py """ A simple demo that reads in an XML document and spits out an equivalent, but not necessarily identical, document. """ import sys, string from xml.sax import saxutils, handler, make_parser # --- The ContentHandler class ContentGenerator(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out # ContentHandler methods def startDocument(self): self._out.write('\n') def startElement(self, name, attrs): self._out.write('<' + name) for (name, value) in attrs.items(): self._out.write(' %s="%s"' % (name, saxutils.escape(value))) self._out.write('>') def endElement(self, name): self._out.write('' % name) def characters(self, content): self._out.write(saxutils.escape(content)) def ignorableWhitespace(self, content): self._out.write(content) def processingInstruction(self, target, data): self._out.write('' % (target, data)) # --- The main program parser = make_parser() parser.setContentHandler(ContentGenerator()) parser.parse(sys.argv[1]) --- rss2html.py import sys from xml.sax import make_parser, handler # --- Templates top = \ """ %s

%s

""" bottom = \ """
Converted to HTML by sax_rss2html.py.
""" # --- The ContentHandler class RSSHandler(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out self._text = "" self._parent = None self._list_started = 0 self._title = None self._link = None self._descr = "" # ContentHandler methods def startElement(self, name, attrs): if name == "channel" or name == "image" or name == "item": self._parent = name self._text = "" def endElement(self, name): if self._parent == "channel": if name == "title": self._out.write(top % (self._text, self._text)) elif name == "description": self._out.write("

%s

\n" % self._text) elif self._parent == "item": if name == "title": self._title = self._text elif name == "link": self._link = self._text elif name == "description": self._descr = self._text elif name == "item": if not self._list_started: self._out.write("
    \n") self._list_started = 1 self._out.write('
  • %s %s\n' % (self._link, self._title, self._descr)) self._title = None self._link = None self._descr = "" if name == "rss": self._out.write(bottom) def characters(self, content): self._text = self._text + content # --- Main program parser = make_parser() parser.setContentHandler(RSSHandler()) parser.parse(sys.argv[1]) From thomas@xs4all.net Sat Oct 14 12:05:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:05:41 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> Message-ID: <20001014130541.F12812@xs4all.nl> On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote: > On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: [ DEC threads (OSF1) are not automatically detected, causing a compilation failure on such systems ] > > It would be nice if configure were smart enough to figure this out! > ... we can easily add that. See the attached patch ... Charles, if you get a chance to test this patch before monday, please do. I think it's important to try and get the thread compiling right, now that threads are on by default. This is going to create a lot of confusion with OSF-users that don't read the README all the way through! If you can't test it, perhaps we can apply it before 2.0 none the less. I personally think there are more systems calling themselves OSF1 that do need the -threads argument than there are that don't need it (if any) and the patch only adds -threads if threads are really enabled. (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be conservative.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Thomas Wouters wrote: > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > in the case stmt, to be conservative.) are there really any others? (that "1" is part of the original name, it's not a version number) From thomas@xs4all.net Sat Oct 14 12:28:20 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:28:20 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Message-ID: <20001014132820.Y12776@xs4all.nl> On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote: > Thomas Wouters wrote: > > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > > in the case stmt, to be conservative.) > are there really any others? Don't know. That's why I asked it :) > (that "1" is part of the original name, it's not a version number) Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1) in others: case $ac_sys_system in OSF1) CC=cc without_gcc=;; versus if test -z "$LDSHARED" then case $ac_sys_system/$ac_sys_release in [..] OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; [..] I guess the OSF*) action is specific enough (most likely to lead to errors on systems that call themselves, say, OSFORME) that we don't really have to worry about it right now. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Sat Oct 14 13:32:33 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT) Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Lars Marius Garshol writes: > Here are a couple from an internal seminar I recently gave on this. I > could make the slides available as well, if there is interest. Could we include this in Demos/xml/ ? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw@fnal.gov Sat Oct 14 14:08:30 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001014130541.F12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov> Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > think it's important to try and get the thread compiling right, now that > threads are on by default. OK, I just tried it and it worked for me. (I only tested it on one OSF/1 system, but I suppose that's better than nothing). Thanks for patching this, I think you are right that it will save a lot of confusion (at least for that handful of people running this OS!) From m.favas@per.dem.csiro.au Sat Oct 14 14:11:11 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Sat, 14 Oct 2000 21:11:11 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au> [Huaiyu Zhu, replying to Tim...] >It is interesting to know that someone actually relies on >OverflowError to detect underflow. But why not let them continue that >as well, given that all of these would be available in the future >anyway? I think I'm the someone referred to - but I _don't_ rely on this at all. I was reporting that, on my platforms, the behaviour of exp(-666) did _not_ change between 1.5.2 and 2.0, both of which raised an OverflowError (for underflow). I prefer Tim's change so that exp(-huge) will produce 0, and that exp(huge) produces an OverflowError, even though this changes the behaviour when moving from 1.5.2 to 2.x... [Huaiyu Zhu again] >Before that happens, why consistency accross platform is deemed more >important than consistency accross releases? My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it? :-) In spite of the smiley, I'd have to say (politely) "Rubbish!". One of the many attractions of Python to me _is_ cross-platform consistency - more so than up-version consistency. In my previous life as a computational chemist I spent a lot of effort in writing code that was portable - indeed, we developed a pre-processor language (which spat out FORTRAN) to try to more easily handle OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first came up against IEEE stuff in the early 80's, and I agree with Tim - as a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I was used to my code stopping when I divided by zero - it usually indicated a coding or algorithmic error. When (if) Python supports access to masking/unmasking 754 exceptions, that'll be good - in the meantime, from my POV, the steps taken by Tim/Guido are in the right direction. -- Mark Favas - m.favas@per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA From thomas@xs4all.net Sat Oct 14 18:12:34 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 19:12:34 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov> Message-ID: <20001014191234.G12812@xs4all.nl> On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > > think it's important to try and get the thread compiling right, now that > > threads are on by default. > OK, I just tried it and it worked for me. (I only tested it on one > OSF/1 system, but I suppose that's better than nothing). Yeah, I already tested it on the ther platforms I have. Not really necessary, since the patch is really tiny and can only really be a problem on platforms that have a 'system name' that matches 'OSF*' but don't need '-threads'. Thanx for testing that it works, though. Jeremy, are you OK on checking this autoconf change in ? Is it in time for 2.0-final ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Sat Oct 14 23:11:30 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Sat, 14 Oct 2000 18:11:30 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56 In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net> Message-ID: Greg, Do you intend these most recent changes to be included in 2.0 final on Monday? Just giving you a heads up in case you didn't realize what the release schedule is. The only changes we should be making are critical bugs fixes for mainline code (non-demo, tools, etc.). Also, there is some code in the top-level of the CVS repository that hasn't been put in the previous source tarballs; at least the C code for the Windows installer, but maybe other things as well. Can you recommend how to include this in the source distribution for the final release? We'd like to include *all* the source code for distutils. Jeremy From barry@scottb.demon.co.uk Sun Oct 15 00:28:45 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 15 Oct 2000 00:28:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000001c03636$7f5b5600$060210ac@private> > -----Original Message----- > From: Tim Peters [mailto:tim_one@email.msn.com] > Sent: 08 October 2000 20:29 > To: Barry Scott; PythonDev; Python list > Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers > > > [Barry] > > Two requests: > > > > 1. Can you ship the .PDB files for the debug images so devo's > > do not need to build the python sources to debug extensions. > > And Yes I know the .ZIP will be huge. If you want a > > compromise only include the .PDB for python20_d.dll. > > Sure! Most .pdb files are highly compressible, and the zip size hit isn't > anything to worry about. Thanks > > > 2. Place the files into libs, pyd etc dirs. I had to extract > > the groups into the right places which is a bit tedious > > and error prone. > > No. If you want a directory structure that doesn't match the actual build > directory structure, I can't read your mind, and have no reason to believe > that the specific artificial structure you have in mind is of use to anyone The structure I refer to is the one used by the Python Windows installer. > but you. Don't be so helpless : write a tiny Python script to move I comment not because I'm lazy but because it seemed that every developer would need to reorganise the files. > the files where you want them after unpacking. What I upload will be an > exact image of the build directory structure. Most feedback I've gotten is > that people want exactly that, because they *want* to compile Python I'd not thought of that. MY assumption was that I build the release windows code against the files installed by the python windows installer. And that the debug settings would logically point into the same structure. > themselves and just want to avoid jumping thru all the snaky hoops needed to > compile the 3rd-party subprojects (from _tkinter to zlib). > > alphabetically y'rs - tim Barry From MarkH@ActiveState.com Sun Oct 15 00:53:03 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Sun, 15 Oct 2000 10:53:03 +1100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry] > I'd not thought of that. My either. I must admit mild surprise at that. If people want the debug files in the same tree as the build tree, it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries? My experience with people wanting debug binaries is that they either don't want to, or can not build. When people need debug binaries, they go one of 2 routes - try and find pre-built debugs, or build them themselves. I can't see when people ever do both. For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different. Just-FWIW ly, Mark. From nick@nickbower.com Sun Oct 15 06:09:26 2000 From: nick@nickbower.com (Nick Bower) Date: Sun, 15 Oct 2000 05:09:26 GMT Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <20001015.5092600@cricket.> > Does anyone know what other array-oriented languages use? I know what > MATLAB does: I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's=20 Space Science Ceter is split down the middle between this and MatLab, =20 but python/numpy is definitely on the increase). As you can see from=20 results below, like MatLab over/under-flows in IDL are reported but do=20 not stop execution. This is the best (only) possible scenario for an=20 interactive arrays and visualization environment. IDL> print, exp(-777) 0.00000 % Program caused arithmetic error: Floating underflow IDL> print, exp(777) Inf % Program caused arithmetic error: Floating overflow IDL> print, sqrt(-1) -NaN % Program caused arithmetic error: Floating illegal operand IDL> print, 54/0 54 % Program caused arithmetic error: Integer divide by 0 From martin@loewis.home.cs.tu-berlin.de Sun Oct 15 16:57:18 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 15 Oct 2000 17:57:18 +0200 Subject: [Python-Dev] Mandrake vs glibc Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de> > So, if David's report is correct, and best I understand it you were > all using 7.1 too with at least some level of optimization, it's A > Mystery why CVS test_math.py succeeds on that system (its new > math.sqrt(-1) test would probably fail; its new math.exp(+huge) test > would almost certainly fail). I'm anal enough about this stuff that > I'd try to figure out why if I had a Mandrake system, but in the > cosmic scheme of things I doubt it's important enough for anyone > else to burn time on. Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I get Python 2.0 (#104, Oct 15 2000, 15:47:19) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> math.exp(800) inf >>> math.exp(-800) 0.0 It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That is implemented as _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_; in this version of glibc, which in turn changes the behaviour of double __exp(double x) /* wrapper exp */ { double z; z = __ieee754_exp(x); if(_LIB_VERSION == _IEEE_) return z; if(__finite(x)) { if(x>o_threshold) return __kernel_standard(x,x,6); /* exp overflow */ else if(x > Can you recommend how to include this in the source distribution for > the final release? Even though I was not asked, I still answer :-) I think having the source code for the installer is essential, just so that people won't get frightened by the potential for a Trojan Horse in front of the gates (or, rather, the windows?-) I'd put the installer (i.e. all of distutils/misc except for get_metadata.py) into Tools/wininst. (I'd actually preferred to see the wininst sources in distutils in a different directory as well). In case you need some descripting text as well, here's my proposal. In Tools/README, maybe it would be wininst Sources for Windows installer of distutils.command.bdist_wininst. For Tools/wininst/README, see the text below. One complication is that invoking bdist_wininst as a program will regenerate the module, but it expects the installer binary in ../../misc/wininst.exe; I'm not sure whether it is worth the effort to change that for the Python distribution. Regards, Martin THE WINDOWS INSTALLER ===================== The distutils support the command bdist_wininst, which will produce a windows auto-installing executable using the information in the setup function. The executable consists of a user interface program, concatenated with a zip archive of the distributed files. This directory contains the sources of the user interface program. The bdist_wininst command itself does not need the sources, instead, it has an embedded copy of the installer binary file. If the installer program is modified, bdist_wininst.py must be updated by invoking it as a program (i.e. "python bdist_wininst.py") Building the installer ---------------------- To build the installer, you need a copy of Microsoft Visual C++ version 6; the project file is wininst.dsp. You may also use the executable compressor UPX, which is available from http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is not strictly required - it just reduces the size of the installation program itself. Using the bdist_wininst command ------------------------------- To create an binary distribution of your package for Windows, simply invoke "python setup.py bdist_wininst" in your package directory. If your package does not contain C modules, you may invoke this command on any system; if it does contain C modules, bdist_wininst will need the C compiler used to build Python (typically MSVC++). It will not need MSVC++ or UPX to build the setup program. To build the ZIP file contained in the installer, bdist_wininst will first try an external zip program (zip.exe) that understands the -rq option, such as Info-ZIP (http://www.info-zip.org/pub/infozip/Zip.html). If no such program is found, it will next try the zipfile module, which is available if Python was build with zlib support. From larsga@garshol.priv.no Sun Oct 15 18:52:16 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 15 Oct 2000 19:52:16 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> References: <14823.43218.337621.157021@beluga.mojam.com> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Message-ID: * Lars Marius Garshol | | Here are a couple from an internal seminar I recently gave on this. | I could make the slides available as well, if there is interest. * Fred L. Drake, Jr. | | Could we include this in Demos/xml/ ? Sure. Do whatever you like with them. --Lars M. From hinsen@cnrs-orleans.fr Sun Oct 15 20:04:27 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Sun, 15 Oct 2000 21:04:27 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13 Oct 2000 18:22:28 -0700) References: <39E7B554.29A168E3@jps.net> Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr> > I've come to Python from MATLAB for numerics, and I really appreciated > MATLAB's way of handling all this. I don't think MATLAB has true 754 MATLAB is fine for simple interactive data processing, and its behaviour is adapted to this task. I don't think anyone would use MATLAB for developing complex algorithms, its programming language isn't strong enough for that. Python is, so complex algorithms have to be considered as well. And for that kind of application, continuing a calculation with Infs and NaNs is a debugging nightmare. > I have not yet heard a decent response to the question of what to do > when a single value in a large array is bad, and causes an exception. I'd like to have at least the option of raising an exception in that case. Note that this is not what NumPy does today. > >> sqrt(-1) > ans = > 0 + 1.0000i > > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? For the same reason that makes 2/3 return zero instead of a float division result. Like C or Fortran, Python treats integers, floats, and complex numbers as different data types. And the return type of a function should depend only on the types, but not the values, of its parameters (for consistency, not because of any implementational limitation). So sqrt(a) for a of type float can either always return a float (math, Numeric) and crash for negative arguments, or always return a complex (cmath). The "right" solution, in my opinion, would be to have a single "number" type of which integers, float, and complex numbers are simply different internal representations. But such a change cannot be introduced without breaking a lot of code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tim_one@email.msn.com Sun Oct 15 20:22:09 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 15:22:09 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry Scott] > I'd not thought of that. [Mark Hammond] > My either. I must admit mild surprise at that. Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree. > If people want the debug files in the same tree as the build tree, Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count. > it seems all they are trying to do is avoid the initial huge build. If > they intend compiling, why are they asking for the binaries? The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours. > My experience with people wanting debug binaries is that they either don't > want to, or can not build. If they can't build, it's hard to take their claim to be developing extension modules seriously . > ... > For the last year or so, I have been making Debug builds of win32all > available to registered users. This has always been made available in > the "install" structure - quite a bit different than the source/build > structure. I've never been asked for anything different. Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over-ly y'rs - tim From tim_one@email.msn.com Sun Oct 15 21:35:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 16:35:27 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr> Message-ID: [cbarker@jps.net] >> I've come to Python from MATLAB for numerics, and I really appreciated >> MATLAB's way of handling all this. I don't think MATLAB has true 754 ... [Konrad Hinsen] > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. A non-constructive (because futile) speculation: the first time I saw what 754 was intending to do, my immediate reaction was "hmm -- the exponent field is too narrow!". With a max (double) val in the ballpark of 1e300, you get an infinity as soon as you square something as small as 1e150, and once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and Inf/Inf). The dynamic range for 754 singles is much smaller still. There's no doubt about Cray arithmetic being hard to live with, but while Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's exponent field (vs. 11 for 754). As a result, overflows were generally a non-issue on Cray boxes, and *nobody* complained (in my decade there) about Cray HW raising a fatal exception if one occurred. In return, you got only 48 bits of precision (vs. 53 for 754). But, for most physical problems, how accurate are the inputs? 10 bits on a good day, 20 bits on a great day? Crays worked despite their sloppy numerics because, for most problems to which they were applied, they carried more than twice the precision *and* dynamic range than the final results needed. >> I have not yet heard a decent response to the question of what to do >> when a single value in a large array is bad, and causes an exception. I'd usually trace back and try to figure out how it got "bad" to begin with ... > I'd like to have at least the option of raising an exception in that > case. Note that this is not what NumPy does today. Does NumPy use the fpectl module? I suppose not. LLNL contribued that code, but we hear very little feedback on it. It arranges to (in platform-dependent ways) convert the 754 overflow, divide-by-0 and invalid-operation signals into Python exceptions. In core Python, this is accomplished at the extraordinary expense of doing a setjmp before, and a function call + double->int conversion after, every single fp operation. A chief problem is that SIGFPE is the only handle C gives us on fp "errors", and the C std does not allow returning from a SIGFPE handler (the result of trying to is undefined, and indeed varies wildly across platforms); so if you want to regain control, you have to longjmp out of the handler. The NumPy implementation could use the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros to brackete entire array operations, though, and so pay for the setjmp etc only once per array op. This is difficult stuff, but doable. >> >> sqrt(-1) >> ans = >> 0 + 1.0000i >> >> Hey! I like that! Python is dynamic, why can't we just get the actual >> answer to sqrt(-1), without using cmath, that always returns a complex ? > For the same reason that makes 2/3 return zero instead of a float > division result. Like C or Fortran, Python treats integers, floats, > and complex numbers as different data types. You know I'm in general agreement with you on this one, but I have to draw a distinction here: Guido thinks that 2/3 returning 0 was a design mistake, but not that math.sqrt(-1) raising an exception is a mistake. Most Python users won't know what to do with a complex number, so it's "an error" to them. I would like to view this in P3K (if not earlier) as being akin to 754 exceptions: some people are delighted to have 1e300**2 return +Inf, while others want to see OverflowError instead, and still others want to see +Inf *and* have a sticky flag set saying "an overflow occurred". We could treat f(x) (for f == sqrt and everything else) the same way wrt to a new ComplexResultFromNonComplexInputsError: define "non-stop" complex results, let the user choose whether to do nonstop or raise an exception, and a supply a sticky flag saying whether or not any complex results were generated from non-complex inputs. > ... > The "right" solution, in my opinion, would be to have a single > "number" type of which integers, float, and complex numbers are simply > different internal representations. But such a change cannot be > introduced without breaking a lot of code. The current distinction between ints and longs (unbounded ints) should also get swallowed by this. A way to get from here to there is especially irksome at the C API level, since, e.g., many C API functions pass Python ints as C longs directly. A smaller number pass Python floats as C doubles directly. it's-wonderful-that-p3k-will-solve-everything-ly y'rs - tim From MarkH@ActiveState.com Mon Oct 16 00:49:19 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 10:49:19 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. Message-ID: I just struck this, and wonder if it is intentional: * Adding 2 buffer objects together yields a string. Fair enough. * Adding a buffer and a string yields a type error! Eeek. This yields the following strange behaviour: >>> a=buffer('a') >>> a+a 'aa' >>> a+a+a Traceback (innermost last): File "", line 1, in ? TypeError: cannot add type "buffer" to string >>> That doesnt seem correct to me? Mark. From rob@hooft.net Mon Oct 16 06:39:13 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18 In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net> References: <200010091242.FAA02671@slayer.i.sourceforge.net> Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl> Just checking my E-mail coming back from holidays, I see: diff -C2 -r1.17 -r1.18 *** calendar.py 2000/08/30 14:01:28 1.17 --- calendar.py 2000/10/09 12:42:04 1.18 *************** *** 55,60 **** def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2 and no funny (non-leap century) years.""" ! return (y2+3)/4 - (y1+3)/4 def weekday(year, month, day): --- 55,62 ---- def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2.""" ! y1 -= 1 ! y2 -= 1 ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) def weekday(year, month, day): I am worried about the use of "-=" here. The code basically says: "if the arguments are mutable numeric types, I'd like to modify them in place". In c.l.py it has been stressed multiple times that "-=" is not the same as "= -". I think this is clearly a place where "= -" is preferable over "-=". Even though you might think people will always call this with python integers, you can never be sure enough. Rob -- ===== rob@hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From pf@artcom-gmbh.de Mon Oct 16 08:23:11 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST) Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext) In-Reply-To: Message-ID: Hi Ulf, Ulf Betlehem: [...] > ok, I compiled 2.0c1 and tried gettext. Now, there seems to be > a bug in the "normalize and expand" code that can prevent > gettext from finding an existing .mo file. The normalization > is done using a dictionary and therefore the languages get > reordered (as dict keys do). Later when selecting language the > function returns None if 'C' happens to come before the > required languages. I've included a patch to fix this. Your patch looks good to me. Thanks for taking the time to test and contributing the patch. I've submitted your bug report and your patch to sourceforge. See: https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470 https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 Regards, Peter P.S.: Cc to python-dev -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal@lemburg.com Mon Oct 16 08:50:22 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 09:50:22 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAB33E.35B72EA4@lemburg.com> Mark Hammond wrote: > > I just struck this, and wonder if it is intentional: > > * Adding 2 buffer objects together yields a string. Fair enough. > * Adding a buffer and a string yields a type error! Eeek. This just seems plain wrong. Adding two buffers should yield a new buffer -- in the long run, buffers should replace strings wrt to holding binary data. If not even buffers themselves implement this idea, I don't see any perspective for ever getting there... > This yields the following strange behaviour: > > >>> a=buffer('a') > >>> a+a > 'aa' > >>> a+a+a > Traceback (innermost last): > File "", line 1, in ? > TypeError: cannot add type "buffer" to string > >>> > > That doesnt seem correct to me? Neither to me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Mon Oct 16 10:14:49 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon, 16 Oct 2000 11:14:49 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> IMHO, the whole buffer interface is weird. - Only the Buffer_FromObject() function is exposed to the python level (as buffer()), the other functions are missing. This means that one could only use the buffer interface in extension modules. Was this intentional? - No way a python class can expose the buffer interface - There is a bug in the buffer interface (which prevented recently that I could use buffer objects at all, I had to implement my own) PyObject *base = PyBuffer_New(100); PyObject *buffer = PyBuffer_FromObject(base, 0, 100); Py_DECREF(base); After this code is executed, buffer points to deallocated memory (because buffer does not hold a reference to base anymore). (Guido classified this as a wish, but at least it contradicts the documentation) Thomas From MarkH@ActiveState.com Mon Oct 16 10:38:26 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 20:38:26 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> Message-ID: > IMHO, the whole buffer interface is weird. I'm not sure that weird is the correct term for your points (it is for my spelling, though :-) > - Only the Buffer_FromObject() function is exposed to the ... > - No way a python class can expose the buffer interface These are simply oversights, I would suggest. Nothing in the design prevents this. > - There is a bug in the buffer interface (which > prevented recently that I could use buffer objects > at all, I had to implement my own) This looks like quite a simple bug. bufferobject.c, line 77: /* if the base object is another buffer, then "deref" it */ if ( PyBuffer_Check(base) ) base = ((PyBufferObject *)base)->b_base; if the condition was changed to: if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base) Then I think this one would be solved? A more serious design flaw is the one Fredrik pointed out quite some time ago. If you have (eg.) an "array" object and query for its buffer, life is good. If the array then resizes itself, your pointer is now dangling. The simplest solution to this is probably to simply define the lifetimes of these pointers as very very short ;-) Mark. From mal@lemburg.com Mon Oct 16 11:14:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 12:14:46 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAD516.7EA34C20@lemburg.com> Mark Hammond wrote: > [Problems with the buffer interface] > If you have (eg.) an "array" object and query for its buffer, life is > good. If the array then resizes itself, your pointer is now dangling. The > simplest solution to this is probably to simply define the lifetimes of > these pointers as very very short ;-) ...or disable the buffer interface for mutable types altogether ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Mon Oct 16 14:01:26 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 06:01:26 -0700 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200 References: <39EAB33E.35B72EA4@lemburg.com> Message-ID: <20001016060126.X347@lyra.org> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > Mark Hammond wrote: >... > > This yields the following strange behaviour: > > > > >>> a=buffer('a') > > >>> a+a > > 'aa' > > >>> a+a+a > > Traceback (innermost last): > > File "", line 1, in ? > > TypeError: cannot add type "buffer" to string > > >>> > > > > That doesnt seem correct to me? > > Neither to me. It is caused by the non-commutative aspect of Python types. You end up with a string, and that type doesn't know how to add a buffer to itself. Ideally, it might be nice to allow a string to append any object that exports the buffer-interface. But when somebody goes and writes "abc"+my_array ... hoo boy, will we hear complaints. The alternative is to allow the buffer to resolve the type conflict and do the appending within the buffer code. Of course, the choice of returning a string (from buf+buf) rather than a buffer was arguably the wrong choice. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@python.org Mon Oct 16 15:30:44 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 09:30:44 -0500 Subject: [Python-Dev] mutable integers In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200." <14826.38017.352907.716552@temoleh.chem.uu.nl> References: <200010091242.FAA02671@slayer.i.sourceforge.net> <14826.38017.352907.716552@temoleh.chem.uu.nl> Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com> Rob W. W. Hooft: > Just checking my E-mail coming back from holidays, I see: [...] > def leapdays(y1, y2): > """Return number of leap years in range [y1, y2). > ! Assume y1 <= y2.""" > ! y1 -= 1 > ! y2 -= 1 > ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) > > I am worried about the use of "-=" here. The code basically says: "if the > arguments are mutable numeric types, I'd like to modify them in place". In > c.l.py it has been stressed multiple times that "-=" is not the same as > "= -". I think this is clearly a place where "= -" is preferable over > "-=". Even though you might think people will always call this with > python integers, you can never be sure enough. Hmm... Your fear sounds a little paranoid for this particular case, but I can't say that I totally disagree in general. This is definitely something to keep in mind when writing polymorphic functions for which a NumPy array might be an acceptable input argument. I don't think it's worth checking in a patch in this case. --Guido van Rossum (home page: http://www.python.org/~guido/) From hinsen@cnrs-orleans.fr Mon Oct 16 16:52:43 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 16 Oct 2000 17:52:43 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr> > > I'd like to have at least the option of raising an exception in that > > case. Note that this is not what NumPy does today. > > Does NumPy use the fpectl module? I suppose not. LLNL contribued that No. Perhaps it should, but it doesn't make sense unless fpectl works on a large number of platforms. I confess I have never looked at it. I want my code to be portable, so I don't even consider using packages that aren't. > > For the same reason that makes 2/3 return zero instead of a float > > division result. Like C or Fortran, Python treats integers, floats, > > and complex numbers as different data types. > > You know I'm in general agreement with you on this one, but I have to draw a > distinction here: Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Well, that would be a good occasion to learn about complex numbers! I remember having learned about generalized inverses by using APL in high school (in a very similar way: I was amazed that it could invert non-square matrices), and that turned out to be very useful knowledge later on. Perhaps that's a topic for the EDU-SIG... Anyway, I don't care what math.sqrt(-1) does, but I would definitely prefer Numeric.sqrt(-1) to return a complex result. And I think that someone who uses NumPy has probably heard about complex numbers. > I would like to view this in P3K (if not earlier) as being akin to > 754 exceptions: some people are delighted to have 1e300**2 return +Inf, > while others want to see OverflowError instead, and still others want to see > +Inf *and* have a sticky flag set saying "an overflow occurred". We could > treat f(x) (for f == sqrt and everything else) the same way wrt to a new > ComplexResultFromNonComplexInputsError: define "non-stop" complex results, > let the user choose whether to do nonstop or raise an exception, and a > supply a sticky flag saying whether or not any complex results were > generated from non-complex inputs. There is, however, one difference: in properly debugged production code, there should be no overflow situations, so it doesn't matter much how they are treated. Complex number can (do!) occur in production code, but there could also be production code relying on exceptions for sqrt(-1) (e.g. for input error checking). Therefore a program using several libraries might be impossible to run with either setting. Since this concerns only the math module, I'd prefer to keep separate module versions for the two cases, which can be used in parallel. > > The "right" solution, in my opinion, would be to have a single > > "number" type of which integers, float, and complex numbers are simply > > different internal representations. But such a change cannot be > > introduced without breaking a lot of code. > > The current distinction between ints and longs (unbounded ints) should also > get swallowed by this. A way to get from here to there is especially > irksome at the C API level, since, e.g., many C API functions pass Python > ints as C longs directly. A smaller number pass Python floats as C doubles > directly. I don't see the problem in that direction, it's rather C API functions that *return* numbers in C data types that would be difficult to adapt. But then, why should be C API not be allowed in P3K? it's-wonderful-that-anything-may-be-changed-in-p3k'ly Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From guido@python.org Mon Oct 16 19:08:07 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:08:07 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST." <20001016060126.X347@lyra.org> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> The buffer interface is one of the most misunderstood parts of Python. I believe that if it were PEPped today, it would have a hard time getting accepted in its current form. There are also two different parts that are commonly referred by this name: the "buffer API", which is a C-only API, and the "buffer object", which has both a C API and a Python API. Both were largely proposed, implemented and extended by others, and I have to admit that I'm still uneasy with defending them, especially the buffer object. Both are extremely implementation-dependent (in JPython, neither makes much sense). The Buffer API -------------- The C-only buffer API was originally intended to allow efficient binary I/O from and (in some cases) to large objects that have a relatively well-understood underlying memory representation. Examples of such objects include strings, array module arrays, memory-mapped files, NumPy arrays, and PIL objects. It was created with the desire to avoid an expensive memory-copy operation when reading or writing large arrays. For example, if you have an array object containing several millions of double precision floating point numbers, and you want to dump it to a file, you might prefer to do the I/O directly from the array's memory buffer rather than first copying it to a string. (You lose portability of the data, but that's often not a problem the user cares about in these cases.) An alternative solution for this particular problem was consdered: object types in need of this kind of efficient I/O could define their own I/O methods, thereby allowing them to hide their internal representation. This was implemented in some cases (e.g. the array module has read() and write() methods) but rejected, because a simple-minded implementation of this approach would not work with "file-like" objects (e.g. StringIO files). It was deemed important that file-like objects would not place restrictions on the kind of objects that could interact with them (compared to real file objects). A possible solution would have been to require that each object implementing its own read and write methods should support both efficient I/O to/from "real" file objects and fall-back I/O to/from "file-like" objects. The fall-back I/O would have to convert the object's data to a string object which would then be passed to the write() method of the file-like object. This approach was rejected because it would make it impossible to implement an alternative file object that would be as efficient as the real file object, since large object I/O would be using the inefficient fallback interface. To address these issues, we decided to define an interface that would let I/O operations ask the objects where their data bytes are in memory, so that the I/O can go directly to/from the memory allocated by the object. This is the classic buffer API. It has a read-only and a writable variant -- the writable variant is for mutable objects that will allow I/O directly into them. Because we expected that some objects might have an internal representation distributed over a (small) number of separately allocated pieces of memory, we also added the getsegcount() API. All objects that I know support the buffer API return a segment count of 1, and most places that use the buffer API give up if the segment count is larger; so this may be considered as an unnecessary generalization (and source of complexity). The buffer API has found significant use in a way that wasn't originally intended: as a sort of informal common base class for string-like objects in situations where a char[] or char* type must be passed (in a read-only fashion) to C code. This is in fact the most common use of the buffer API now, and appears to be the reason why the segment count must typically be 1. In connection with this, the buffer API has grown a distinction between character and binary buffers (on the read-only end only). This may have been a mistake; it was intended to help with Unicode but it ended up not being used. The Buffer Object ----------------- The buffer object has a much less clear reason for its existence. When Greg Stein first proposed it, he wrote: The intent of this type is to expose a string-like interface from an object that supports the buffer interface (without making a copy). In addition, it is intended to support slices of the target object. My eventual goal here is to tweak the file object to support memory mapping and the buffer interface. The buffer object can then return slices of the file without making a new copy. Next step: change marshal.c, ceval.c, and compile.c to support a buffer for the co_code attribute. Net result is that copies of code streams don't need to be copied onto the heap, but can be left in an mmap'd file or a frozen file. I'm hoping there will be some perf gains (time and memory). Even without some of the co_code work, enabling mmap'd files and buffers onto them should be very useful. I can probably rattle off a good number of other uses for the buffer type. I don't think that any of these benefits have been realized yet, and altogether I think that the buffer object causes a lot of confusion. The buffer *API* doesn't guarantee enough about the lifetime of the pointers for the buffer *object* to be able to safely preserve those pointers, even if the buffer object holds on to the base object. (The C-level buffer API informally guarantees that the data remains valid only until you do anything to the base object; this is usually fine as long as you don't release the global interpreter lock.) The buffer object's approach to implementing the various sequence operations is strange: sometimes it behaves like a string, sometimes it doesn't. E.g. a slice returns a new string object unless it happens to address the whole buffer, in which case it returns a reference to the existing buffer object. It would seem more logical that a subslice would return a new buffer object. Concatenation and repetition of buffer objects are likewise implemented inconsistently; it would have been more consistent with the intended purpose if these weren't supported at all (i.e. if none of the buffer object operations would allocate new memory except for buffer object headers). I would have concluded that the buffer object is entirely useless, if it weren't for some very light use that is being made of it by the Unicode machinery. I can't quite tell whether that was done just because it was convenient, or whether that shows there is a real need. What Now? --------- I'm not convinced that we need the buffer object at all. For example, the mmap module defines a sequence object so doesn't seem to need the buffer object to help it support slices. Regarding the buffer API, it's clearly useful, although I'm not convinced that it needs the multiple segment count option or the char vs. binary buffer distinction, given that we're not using this for Unicode objects as we originally planned. I also feel that it would be helpful if there was an explicit way to lock and unlock the data, so that a file object can release the global interpreter lock while it is doing the I/O. But that's not a high priority (and there are no *actual* problems caused by the lack of such an API -- just *theoretical*). For Python 3000, I think I'd like to rethink this whole mess. Perhaps byte buffers and character strings should be different beasts, and maybe character strings could have Unicode and 8-bit subclasses (and maybe other subclasses that explicitly know about their encoding). And maybe we'd have a real file base class. And so on. What to do in the short run? I'm still for severely simplifing the buffer object (ripping out the unused operations) and deprecating it. --Guido van Rossum (home page: http://www.python.org/~guido/) From cbarker@jps.net Mon Oct 16 18:38:11 2000 From: cbarker@jps.net (Chris Barker) Date: Mon, 16 Oct 2000 10:38:11 -0700 Subject: [Python-Dev] Re: numpy, overflow, inf, ieee, and rich comparison References: Message-ID: <39EB3D03.A00C78B6@jps.net> > >> I have not yet heard a decent response to the question of what to do > >> when a single value in a large array is bad, and causes an exception. > > I'd usually trace back and try to figure out how it got "bad" to begin with And from Konrad Hinsen >I'd like to have at least the option of raising an exception in that >case. Note that this is not what NumPy does today. Exactly. This was Huaiyu's point. The problem is that for your code to be usable for folks other than yourself, you'd have to have a lot of checks in there, and essentially revert to elementwise code, which would kill you. With the addition of the occasional "isnan" and something like Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of A are NaNs) you could set up your code to raise an exception in the middle of computation. If, on the other hand the Code definiately raises an exception, than you are stuck with a lot of elementwise coding. > over/under-flows in IDL are reported but do > not stop execution. This is the best (only) possible scenario for an > interactive arrays and visualization environment. Exactly!!! ("the best (only) possible scenario" part) > IDL> print, 54/0 > 54 > % Program caused arithmetic error: Integer divide by 0 This, however, is wierd!! 54/0 == 54 ??? I'd much rather see a NaN or Inf here! > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. People do some pretty complex algorith develpment with MATLAB. I'm also no so sure about "continuing a calculation with Infs and NaNs is a debugging nightmare" I'm don't think it's any more of a nighmare than having your calculation on an entire array stop because of one Inf. It's just a different trade off. Sprinkle a few "isnan"'s in there and and you can get the behaviour you want, while not forcing it on all calculations. Of course, the best option is to have it switchable, but that may prove to be very difficult. Are people doing the kind of numeric programming with "complex algorithms" using Python that Konrad refers to? More importantly, how many people? > Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Guido's philosophy is clearly that Python defaults should be geared to "Most Python users". I agree, and as I wrote in an earlier post, the only users for whom the "exception raising only" option is best are the users Konrad refers to as writing "complex algorithms". I would argue that those users are few, and the group most able to deal with a less-that-optimum system. Maybe we can have true 754 compliance in Py3k, and we can all be happy!! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From effbot@telia.com Mon Oct 16 18:47:55 2000 From: effbot@telia.com (Fredrik Lundh) Date: Mon, 16 Oct 2000 19:47:55 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid> guido wrote: > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. agreed. (does this mean that we're in post-2.0 mode? ;-) From mal@lemburg.com Mon Oct 16 18:42:15 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 19:42:15 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <39EB3DF7.459A1BC1@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > > Mark Hammond wrote: > >... > > > This yields the following strange behaviour: > > > > > > >>> a=buffer('a') > > > >>> a+a > > > 'aa' > > > >>> a+a+a > > > Traceback (innermost last): > > > File "", line 1, in ? > > > TypeError: cannot add type "buffer" to string > > > >>> > > > > > > That doesnt seem correct to me? > > > > Neither to me. > > It is caused by the non-commutative aspect of Python types. You end up with > a string, and that type doesn't know how to add a buffer to itself. The problem is that buffer() objects coerce to strings in the first place... they should return new buffer objects instead of strings -- then we wouldn't have the above problems. > ... > Of course, the choice of returning a string (from buf+buf) rather than a > buffer was arguably the wrong choice. Right :-/ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Mon Oct 16 19:51:51 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:51:51 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200." <00f601c03799$39f2c7b0$3c6340d5@hagrid> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com> > guido wrote: > > What to do in the short run? I'm still for severely simplifing the > > buffer object (ripping out the unused operations) and deprecating it. > > agreed. > > (does this mean that we're in post-2.0 mode? ;-) Yes :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Mon Oct 16 19:03:15 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 20:03:15 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <39EB42E3.B76F37EB@lemburg.com> Guido van Rossum wrote: > ... > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. I used the buffer object since I thought that buffer() objects were to replace strings as container for binary data. The buffer object wraps a memory buffer into a Python object for the purpose of decoding it into Unicode. 8-bit string objects would have worked just as well... > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. It would be nice to have an object for "copy by reference" rather than "malloc + copy". This would be useful for strings (e.g. to access substrings of a large string), Unicode and binary data. The buffer object almost does this... it would only have to stick to always returning buffer objects in coercion, slicing etc. I also think that the name "buffer" is misleading, since it really means "reference" in the context published by the Python interface (the C API also has a way of defining new malloc areas and referencing them through the buffer interface, but that is not published in Python). The other missing data type in Python is one for binary data. Currently, string objects are in common use for this kind of data. The problems with this are obvious: in some contexts strings are expected to contain text data in other binary data. When the two meet there's great confusion. I'd suggest either making arrays the Python standard type for holding binary data, or creating a completely new type (this should then be called something like "buffer"). > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. True. > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). How about adding a generic low-level lock type for these kind of tasks. The interpreter could be made aware of these types to allow a much more fine-grained lock mechanism, e.g. to check for acquired locks of certain objects only. > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. Great... but 3000 is a long way ahead :-( > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. Since it isn't all that known anyway, how about streamlining the buffer object implementations of the various protocols and removing the distinction between "s" and "t" ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jcollins@endtech.com Mon Oct 16 21:22:22 2000 From: jcollins@endtech.com (Jeff Collins) Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: All this just when I was getting accustomed to the thought of using buffer objects in the Palm Python port... I need buffer objects for many the same reasons as Greg Stein originally proposed, as you quoted below. The on the Palm, the datamanager heap (used for permanent database storage and limited by the physical memory size) already stores the compiled python module. Directly referencing the data of objects like bytecodes and strings would greatly reduce the dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM or greater) requirements. Buffer objects seem like a natural choice. A record in a Palm database is just chunk of contiguous memory. Representing this chunk as a buffer object would allow the direct referencing it and any of it's slices. So, the co_code of code objects could be unmarshalled with a reference to permanent storage. Further, with the appropriate modifications, string objects (char *ob_sval?) could access this memory as well, though this additional optimization is probably only appropriate for small platforms. I think that buffer object is fairly important. They provide a mechanism for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), something that no other python object does, AFIAK. Perhaps clarifying the interface (such as the slice operator returning a buffer, as suggested below) and providing more hooks from Python for creating buffers (via newmodule, say) would be helpful. On Mon, 16 Oct 2000, Guido van Rossum wrote: > The buffer interface is one of the most misunderstood parts of > Python. I believe that if it were PEPped today, it would have a hard > time getting accepted in its current form. > > There are also two different parts that are commonly referred by this > name: the "buffer API", which is a C-only API, and the "buffer > object", which has both a C API and a Python API. > > Both were largely proposed, implemented and extended by others, and I > have to admit that I'm still uneasy with defending them, especially > the buffer object. Both are extremely implementation-dependent (in > JPython, neither makes much sense). > > The Buffer API > -------------- > > The C-only buffer API was originally intended to allow efficient > binary I/O from and (in some cases) to large objects that have a > relatively well-understood underlying memory representation. Examples > of such objects include strings, array module arrays, memory-mapped > files, NumPy arrays, and PIL objects. > > It was created with the desire to avoid an expensive memory-copy > operation when reading or writing large arrays. For example, if you > have an array object containing several millions of double precision > floating point numbers, and you want to dump it to a file, you might > prefer to do the I/O directly from the array's memory buffer rather > than first copying it to a string. (You lose portability of the data, > but that's often not a problem the user cares about in these cases.) > > An alternative solution for this particular problem was consdered: > object types in need of this kind of efficient I/O could define their > own I/O methods, thereby allowing them to hide their internal > representation. This was implemented in some cases (e.g. the array > module has read() and write() methods) but rejected, because a > simple-minded implementation of this approach would not work with > "file-like" objects (e.g. StringIO files). It was deemed important > that file-like objects would not place restrictions on the kind of > objects that could interact with them (compared to real file objects). > > A possible solution would have been to require that each object > implementing its own read and write methods should support both > efficient I/O to/from "real" file objects and fall-back I/O to/from > "file-like" objects. The fall-back I/O would have to convert the > object's data to a string object which would then be passed to the > write() method of the file-like object. This approach was rejected > because it would make it impossible to implement an alternative file > object that would be as efficient as the real file object, since large > object I/O would be using the inefficient fallback interface. > > To address these issues, we decided to define an interface that would > let I/O operations ask the objects where their data bytes are in > memory, so that the I/O can go directly to/from the memory allocated > by the object. This is the classic buffer API. It has a read-only > and a writable variant -- the writable variant is for mutable objects > that will allow I/O directly into them. Because we expected that some > objects might have an internal representation distributed over a > (small) number of separately allocated pieces of memory, we also added > the getsegcount() API. All objects that I know support the buffer API > return a segment count of 1, and most places that use the buffer API > give up if the segment count is larger; so this may be considered as > an unnecessary generalization (and source of complexity). > > The buffer API has found significant use in a way that wasn't > originally intended: as a sort of informal common base class for > string-like objects in situations where a char[] or char* type must be > passed (in a read-only fashion) to C code. This is in fact the most > common use of the buffer API now, and appears to be the reason why the > segment count must typically be 1. > > In connection with this, the buffer API has grown a distinction > between character and binary buffers (on the read-only end only). > This may have been a mistake; it was intended to help with Unicode but > it ended up not being used. > > The Buffer Object > ----------------- > > The buffer object has a much less clear reason for its existence. > When Greg Stein first proposed it, he wrote: > > The intent of this type is to expose a string-like interface from > an object that supports the buffer interface (without making a > copy). In addition, it is intended to support slices of the target > object. > > My eventual goal here is to tweak the file object to support > memory mapping and the buffer interface. The buffer object can > then return slices of the file without making a new copy. Next > step: change marshal.c, ceval.c, and compile.c to support a buffer > for the co_code attribute. Net result is that copies of code > streams don't need to be copied onto the heap, but can be left in > an mmap'd file or a frozen file. I'm hoping there will be some > perf gains (time and memory). > > Even without some of the co_code work, enabling mmap'd files and > buffers onto them should be very useful. I can probably rattle off > a good number of other uses for the buffer type. > > I don't think that any of these benefits have been realized yet, and > altogether I think that the buffer object causes a lot of confusion. > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. (The > C-level buffer API informally guarantees that the data remains valid > only until you do anything to the base object; this is usually fine as > long as you don't release the global interpreter lock.) > > The buffer object's approach to implementing the various sequence > operations is strange: sometimes it behaves like a string, sometimes > it doesn't. E.g. a slice returns a new string object unless it > happens to address the whole buffer, in which case it returns a > reference to the existing buffer object. It would seem more logical > that a subslice would return a new buffer object. Concatenation and > repetition of buffer objects are likewise implemented inconsistently; > it would have been more consistent with the intended purpose if these > weren't supported at all (i.e. if none of the buffer object operations > would allocate new memory except for buffer object headers). > > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. > > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. > > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. > > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). > > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. > > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > -- Jeffery D. Collins Sr. Software Developer Endeavors Technology, Inc. From akuchlin@mems-exchange.org Mon Oct 16 20:35:13 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 16 Oct 2000 15:35:13 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500 References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us> On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote: >> (does this mean that we're in post-2.0 mode? ;-) >Yes :-) Then this is a good time to ask what strategy will be followed post-2.0. Do you want a moratorium on massive checkins for a time while 2.0 shakes out, re-opening the tree for larger changes in a few months? Or will you try to live with a CVS branch for 2.0 and re-open the tree immediately? --amk From fdrake@beopen.com Mon Oct 16 20:37:30 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT) Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com> Andrew M. Kuchling writes: > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? I think a maintenance branch for 2.0.1 (or whatever) should be created as part of the release process in case we need a quick release for critical bug fixes. The tree should be re-opened after the release via a message to python-dev after the release is published. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Mon Oct 16 21:46:22 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 15:46:22 -0500 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400." <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com> > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? If we need to issue a patch release, we'll use a branch. That seems the only reasonable approach. The tree will be open for checkins as soon as 2.0 is released (tonight is looking good!), but I hope the people exercise some restraint and discuss their plans for significant checkins on the python-dev list first. A lot of things should probably be discussed in the form of PEPs too! --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Mon Oct 16 20:47:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 16 Oct 2000 15:47:05 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out ... It's not a great time to ask, as we're still balls-to-the-wall *building* the release and doing last-second checkins (things like NEWS, not code). So there's an absolute ban on any checkins until further notice (on Python-Dev), excepting for those explicitly approved by Jeremy. After that, I agree with Fred that we should make a 2.0.1 branch simultaneous with the release. From jeremy@beopen.com Mon Oct 16 23:11:49 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT) Subject: [Python-Dev] Python 2.1 Release Schedule (tentative) Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net> FYI: In anticpation of the Python 2.0 final release this evening, we just created a new PEP describing the release schedule for Python 2.1. Jeremy PEP: 226 Title: Python 2.1 Release Schedule Version: $Revision: 1.1 $ Author: Jeremy Hylton Status: Incomplete Type: Informational Created: 16-Oct-2000 Python-Version: 2.1 Post-History: Abstract This document describes the post Python 2.0 development and release schedule. According to this schedule, Python 2.1 will be released in mid-March of 2001. The schedule primarily concerns itself with PEP-size items. Small bug fixes and changes will occur up until the first beta release. Tentative Release Schedule 16-Oct-2000: Python 2.0 final release These dates represent goals, not commitments. 16-Dec-2000: 2.1 PEPs ready for review 01-Feb-2001: First 2.1 beta release 16-Mar-2001: 2.1 final release Guidelines for making changes for Python 2.1 The guidelines and schedule will be revised based on discussion in the python-dev@python.org mailing list. The PEP system was instituted late in the Python 2.0 development cycle and many changes did not follow the process described in PEP 1. The development process for 2.1, however, will follow the PEP process as documented. The first eight weeks following 2.0 final will be the design and review phase. By the end of this period, any PEP that is proposed for 2.1 should be ready for review. This means that the PEP is written and discussion has occurred on the python-dev@python.org and python-list@python.org mailing lists. The next six weeks will be spent reviewing the PEPs and implementing and testing the accepted PEPs. When this period stops, we will end consideration of any incomplete PEPs. Near the end of this period, there will be a feature freeze where any small features not worthy of a PEP will not be accepted. Before the final release, we will have six weeks of beta testing and a release candidate or two. Bug fix releases before 2.1 We may have to issue Python 2.0.1 for critical bug fixes. If we need to issue a bug fix release, we will use a CVS branch. General guidelines for submitting patches and making changes Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SourceForge (SF) Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, must include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you should write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database (if you have access to the bug database). It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it must be fixed within 24 hours or it will be backed out. All contributed C code must be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code must follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From greg@cosc.canterbury.ac.nz Tue Oct 17 00:09:55 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz> Guido: > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. This seems like a fatal flaw to me, which should have prevented the buffer object in its present form from ever having been implemented. I suggest that this problem MUST be fixed, or the buffer object removed entirely. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From gstein@lyra.org Tue Oct 17 02:57:09 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 18:57:09 -0700 Subject: [Python-Dev] The buffer interface In-Reply-To: ; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700 References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <20001016185709.J25097@lyra.org> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: >... > I think that buffer object is fairly important. They provide a mechanism > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > something that no other python object does, AFIAK. Perhaps clarifying the > interface (such as the slice operator returning a buffer, as suggested > below) and providing more hooks from Python for creating buffers (via > newmodule, say) would be helpful. There have been quite a few C extensions (and embedding Python!) where the buffer objects have been used in this fashion. For example, if you have a string argument that you wish to pass into Python, then you can avoid a copy by wrapping a Buffer Object around it and passing that. Many of the issues with the buffer object can be solved with simple changes. For example, the "mutable object" thing is easily dealt with by having the object not record the pointer, but just fetch it every time that it wants to do an operation. [ and if we extend the buffer API, we could potentially optimize the behavior to avoid the ptr refetch on each operation ] I don't recall the motivation for returning strings. I believe it was based on an attempt to make the buffer look as much like a string as possible (and slices and concats return strings). That was a poor choice :-) ... so, again, some basic changes to return slices and concats as buffer objects would make sense. Extending the buffer() builtin to create writeable buffer objects has been a reasonably common request. What seems to happen instead is that people developing C extensions (which desire buffer objects as their params) just add a new function to the extension to create buffer objects. Re: the buffer API: At the time the "s"/"t" codes were introduced (before 1.5.2 was released), we had a very different concept of how Unicode objects would be implemented. At that time, Unicode objects had no 8-bit representation (just 16-bit chars), so the difference was important. I'm not clued in enough on the ramifications of torching the difference in the API, but it would be a nice simplification. Buffers vs arrays: this is a harder question. Which is the "recommended binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. Arrays maintain their own memory. I believe the two models are needed, so I'd initially offer that both buffers and arrays need to be maintained. However, given that... what is the purpose of the array if a buffer can *also* maintain its own memory? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@python.org Tue Oct 17 04:35:02 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com> I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Tue Oct 17 05:53:25 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT) Subject: [Python-Dev] CVS repository open for business Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com> The Python CVS repository is now open for further development. If critical patches are needed to the 2.0 release, they should be developed against the branch tagged "release20-maint", and should be posted at SourceForge and discussed here on python-dev before checking them into the branch. Thanks to all the Python developers for your hard work and contributions! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Tue Oct 17 09:16:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 17 Oct 2000 10:16:56 +0200 Subject: [Python-Dev] The buffer interface References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <20001016185709.J25097@lyra.org> Message-ID: <39EC0AF8.5FA79E97@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: > >... > > I think that buffer object is fairly important. They provide a mechanism > > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > > something that no other python object does, AFIAK. Perhaps clarifying the > > interface (such as the slice operator returning a buffer, as suggested > > below) and providing more hooks from Python for creating buffers (via > > newmodule, say) would be helpful. > > There have been quite a few C extensions (and embedding Python!) where the > buffer objects have been used in this fashion. For example, if you have a > string argument that you wish to pass into Python, then you can avoid a copy > by wrapping a Buffer Object around it and passing that. Perhaps we ought to flesh out the current uses of buffer objects and then decide how to proceed ?! IMHO, the problem with buffer objects (apart from the sometimes strange protocol behaviour) is that there too many "features" built into it. Simplification and possibly diversification is needed: instead of trying to achieve every possible C hack with buffer objects we should try to come up with a reasonably small set of types which allow only very basic tasks, e.g. 1. wrapping C memory areas with the possibility of accessing the raw bytes in a read-only way (this should be buffer()), 2. providing a non-copying object reference type (I'd call this reference()) and 3. maintaining a writeable C memory buffer (arrays provide this feature). The buffer object currently tries to do all three. > Many of the issues with the buffer object can be solved with simple changes. > For example, the "mutable object" thing is easily dealt with by having the > object not record the pointer, but just fetch it every time that it wants to > do an operation. > [ and if we extend the buffer API, we could potentially optimize the > behavior to avoid the ptr refetch on each operation ] Please don't extend the buffer API: the whole design is flawed since it undermines data encapsulation in very dangerous ways. If at all, we should consider a new API at abstract API level which doesn't return raw C pointers, but real Python objects (e.g. type 2 reference objects). > I don't recall the motivation for returning strings. I believe it was based > on an attempt to make the buffer look as much like a string as possible (and > slices and concats return strings). That was a poor choice :-) ... so, > again, some basic changes to return slices and concats as buffer objects > would make sense. +1. > Extending the buffer() builtin to create writeable buffer objects has been a > reasonably common request. What seems to happen instead is that people > developing C extensions (which desire buffer objects as their params) just > add a new function to the extension to create buffer objects. Please don't. Instead either suggest to use arrays or come up with some new type with the sole purpose of providing read-write access to a chunk of bytes. > Re: the buffer API: At the time the "s"/"t" codes were introduced (before > 1.5.2 was released), we had a very different concept of how Unicode objects > would be implemented. At that time, Unicode objects had no 8-bit > representation (just 16-bit chars), so the difference was important. I'm not > clued in enough on the ramifications of torching the difference in the API, > but it would be a nice simplification. Well, think of it this way: Unicode was the first object to actually try to make a difference between "s" and "t" -- and failed badly. In the end, we reverted the decision to make any difference and now special case Unicode objects in the getargs.c parser (so that "s" and "t" work virtually the same for Unicode). +1 on the idea of removing the difference altogether in 2.1. If anyone needs to a special representation of an object, the object should provide a clearly defined C API for this instead. E.g. Unicode has lots of APIs to encode Unicode into quite a few new repesentations. > Buffers vs arrays: this is a harder question. Which is the "recommended > binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. > Arrays maintain their own memory. I believe the two models are needed, so > I'd initially offer that both buffers and arrays need to be maintained. > However, given that... what is the purpose of the array if a buffer can > *also* maintain its own memory? Right and that's the problem: buffers shouldn't be able to own memory. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From barry@scottb.demon.co.uk Tue Oct 17 09:40:52 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Tue, 17 Oct 2000 09:40:52 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <001201c03815$f54c4960$060210ac@private> The FreeBSD ports collection had to be updated to support importing C++ extensions with Python 1.5.2. (You get things like cout not defined when importing). Are the nessesary compile/link changes in 2.0? BArry From gstein@lyra.org Tue Oct 17 11:48:27 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 17 Oct 2000 03:48:27 -0700 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: ; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200 References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <20001017034827.F26804@lyra.org> [ moving from xml-sig to python-dev ] Reality check time... On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote: > [maintaining a pythonforge.org would take time and ressources] > > Yes. But I understand a commercial company (BeOpen) has taken over python > development. I think it is the kind of free services they could give > back to the python community. If VA Linux is already offering the service, then how does the community benefit from BeOpen offering the same thing? More importantly: how is BeOpen going to benefit from it? How do they get a business return on that investment? That *will* come into play, you know. Somebody has to pay for those sysadmins and hardware and connectivity. > > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-) > > > > I'd personally hope that python.org becomes accessible in that > > way. You could probably have all of the current content there, and > > then also have python.org/projects/pyxml; python.org/users/someone; > > xml.python.org (and whatever other gimmicks they offer). The last I heard, the intent was to move python.org from CNRI to a machine at VA Linux. The content would then become available for the community to work on; possibly through SourceForge facilities. > > One advantage of taking things off SF is that responsiveness of that > > system was really bad. That seems to have improved recently; > > My concern is not about responsiveness as much as distribution (as in > Internet is a distributed system). SourceForge is a great service. Good. > Now are we to host every single open source project on SourceForge ? If we > do so, the day SourceForge closes or changes its policy, or whatever, > every single open source project will be halted or maybe discontinued. There is no way that SF is ever going to close and take all of those projects with it. VA Linux would be see their business instantly vaporized. As ESR is fond to point out: VA Linux has built their business on trust from the community. *ANY* failure to meet that trust will kill their biz. > The people at SourceForge know their job: they provide a good service and > the tools (code+doc) to implement that same service at other places. > > Why wouldn't a community as big an active as python's put up ressources in > common to offer such a useful service, but dedicated to python > development ? There use to be a python.starship.net, maintained by > volunteers, that is now hosted by BeOpen. Why not take the next step ? python.starship.net has historically been a disaster area. Poorly maintained or (even worse) maintained by a whole bunch of people. Have you ever seen what happens when you give 20 people root access? Then there was the time that a drive crashed. The machine was *gone* for months. Oh, and the network connectivity loss. A month offline, maybe? The community is way to busy to run a service. Sorry. That is why I like SF so much. They are ready and willing to run a service and to fund that operation. And to all appearances, they are running it very well (and continually upgrading it!). > > if anybody is to host a similar server, they need to be aware that it > > is probably hard to compete with SF in terms of provided services. For > > example, I trust that SF has a reasonable backup strategy - they They do. It is somewhere on their site. They have a complete backup strategy. In fact, a while back, they lost a drive and restored most of it from backup. I forget if there was any actual material lost. > > simply can't risk a desaster. Anybody hosting a server for just a few > > projects would not get the same sort of trust from me. > > That's why I think we shouldn't look for someone able to host a server for > a few projects but for some company(ies) able to put up the ressources for > "python projects" and volunteers that help them. Idealistic, but it won't happen. starship.net is my case in point. > That would also make it easier for people to look for python ressources: > code in development would be at something.python.org and 3rd party > software at www.vex.net/parnassus. But I would agree that's a weak > argument as long as www.python.org continues to be well-maintained with > no broken links and stays the central hub for python information. When python.org moves, then it will be maintained much better. I don't recall the status of that, but I presume that Guido is still pushing to see it happen. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@python.org Tue Oct 17 04:35:02 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Oct 17 15:06:00 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 09:06:00 -0500 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100." <001201c03815$f54c4960$060210ac@private> References: <001201c03815$f54c4960$060210ac@private> Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> > The FreeBSD ports collection had to be updated to support > importing C++ extensions with Python 1.5.2. (You get things > like cout not defined when importing). > > Are the nessesary compile/link changes in 2.0? Tell you what: I have no idea. :-( I believe there were some changes to the Makefile and/or config file to support C++, but I don't know if this works on FreeBSD. I'm not a big C++ user myself, so I rarely try this... Can you try it? If it doesn't work out of the box, let's sit down together and figure out a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Tue Oct 17 14:59:46 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> [Moved to python-dev, since the shift has begun.] Nicolas Chauvat writes: > I'm sure several people from PythonLabs are on this list. What is their > opinion ? I rather like letting the SourceForge crew take care of running the service. Running a website that needs constant updates is no trivial matter, and SourceForge is *much* more complex than that! I have a great deal of respect for the hard work that I know goes into running SourceForge, and would rather see that effort bolstered by volunteers & contributions (docs, code, whatever) by people who are able, than to see the efforts splintered. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Nicolas.Chauvat@logilab.fr Tue Oct 17 15:07:36 2000 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> Message-ID: > I have a great deal of respect for the hard work that I know goes > into running SourceForge, and would rather see that effort bolstered > by volunteers & contributions (docs, code, whatever) by people who are > able, than to see the efforts splintered. Hum, maybe I did not explain myself correctly and I don't want a misunderstanding: I never meant "let's create a SourceForge-like tool, SourceForge is bad", but only "why not host a python specific service using the SourceForge code and tools", as www.bioinformatics.org does for projects related to bio-ingeneering. --=20 Nicolas Chauvat http://www.logilab.com - "Mais o=F9 est donc Ornicar ?" - LOGILAB, Paris (F= rance) From guido@python.org Tue Oct 17 16:26:31 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 10:26:31 -0500 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200." References: Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> > Hum, maybe I did not explain myself correctly and I don't want a > misunderstanding: I never meant "let's create a SourceForge-like tool, > SourceForge is bad", but only "why not host a python specific service > using the SourceForge code and tools", as www.bioinformatics.org does for > projects related to bio-ingeneering. Why not indeed? Why spend time running a service that SourceForge is already providing, and very well at that? This has come up occasionally at BeOpen but the only argument for it that was ever brought up (by the marketing folks, of course :-) was the hope that it would help sell banner ads -- not that there would be an advantage for the community. What would be the advantage for the community or running our own? What's wrong with using SourceForge? I say, if it ain't broke don't fix it. (And then again, there may be a very good reason to run our own, and maybe I just don't see it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Tue Oct 17 16:11:11 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 17 Oct 2000 17:11:11 +0200 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500 References: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> Message-ID: <20001017171111.K12812@xs4all.nl> On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote: > > Hum, maybe I did not explain myself correctly and I don't want a > > misunderstanding: I never meant "let's create a SourceForge-like tool, > > SourceForge is bad", but only "why not host a python specific service > > using the SourceForge code and tools", as www.bioinformatics.org does for > > projects related to bio-ingeneering. > What would be the advantage for the community or running our own? > What's wrong with using SourceForge? I say, if it ain't broke don't > fix it. (And then again, there may be a very good reason to run our > own, and maybe I just don't see it. :-) There is no advantage that I know of. I know a lot about keeping machines and websites up and running (that's what I do for a living(*), after all) and I can tell you you need a big (or very dedicated) sysadmin staff to be able to offer anything as reliable as SourceForge. So the website & CVS tree itself could be run on a low-end machine. Say a PII-300 with 128 MB RAM. You need at least two, preferably three machines, regardless of performance, to be able to offer 'reliable' services. Preferably load-balanced by something like a smart switch (we use Alteon Layer-4 ethernet switches for that task, and you can do cool things with them. They're also pretty expensive.) And you need a way to back it up. A tape library or DAT streamer of some kind. Preferably a separate machine to do the actual backups. Live or fast-cycled backups can also be a lifesaver, which either requires another machine or two with speedy disks, or storing your data on something dedicated like a NetApp Filer. (Very cool machine, a dedicated NFS and CIFS (SMB) fileserver with excellent live backups, 'snapshots', as many as you want/need. Only costs you diskspace. Oh, and this quality comes at a price, too, of course.) And then there's the reliable network access, reliable system room (with reliable and preferably redundant power), and the 24/7 warning system that wakes up stand-by sysadmins to fix problems. And for the specialized hardware and software, you need a few people who know how to handle them. You need several people anyway, to cover all bases even in the face of illness, vacations and the famous bus accidents. We have a crew of 12 now, with a few new additions, and even then we run into trouble with vacations. I dare say we offer more reliable services than SourceForge does, but we also cost more :-) In short, the only advantage to not using SourceForge is that you can do things SourceForge can't or won't. Run software SourceForge won't, for instance. However, I would strongly suggest making such software 'non-essential', keeping most of the stuff on SourceForge, spend lots less money on the technical setup, and suffer a bit when the service is down. *) Where living is defined as 'making enough money to stay breathing and work on Python', and 'work on Python' has higher importance, of course :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin@mems-exchange.org Tue Oct 17 17:47:34 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 12:47:34 -0400 Subject: [Python-Dev] Publicity for 2.0 release? Message-ID: Is BeOpen doing any publicity for the release of 2.0? For example, issuing a press release and sending it to lots of different publications, such as DDJ, Web Development, Windows programming magazines, whatever that XML magazine is called, etc.? (Hmm... www.beopen.com hasn't been updated to mention the new release -- nor even 2.0c1.) --amk From pf@artcom-gmbh.de Tue Oct 17 18:21:19 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST) Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm" Message-ID: Andrew Kuchling: > Is BeOpen doing any publicity for the release of 2.0? For example, > issuing a press release and sending it to lots of different > publications, such as DDJ, Web Development, Windows programming magazines, > whatever that XML magazine is called, etc.? > > (Hmm... www.beopen.com hasn't been updated to mention the new release > -- nor even 2.0c1.) Really bad marketing! ;-) But not as bad as it could have been: Other places hopping into my mind were: http://slashdot.org/ (already done, see below) http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) http://www.newsforge.com/ (didn't see Python mentioned there yet) and not to forget http://www.python.org/ (already done) quoting from slashdot: """Python 2.0 Released Posted by timothy on 5:34 Tuesday 17 October 2000 from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept. atallah writes: "It would appear that the long awaited Python 2.0 was finally released today. The front page of the Web site has the announcement." According to that announcement, Python 2.0 will receive minor-version updates around every 6 months, even as work begins on the shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list includes "full XML support and several forms of new syntax," as well as the BeOpen label. ( Read More... | 164 comments ) """ Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From akuchlin@mems-exchange.org Tue Oct 17 18:33:22 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 13:33:22 -0400 Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200 References: Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us> On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote: > http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) By Jeremy, actually. I'm not sure why it lists my name instead -- Freshmeat bug? --amk From hinsen@cnrs-orleans.fr Tue Oct 17 21:27:10 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:10 +0200 Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16 Oct 2000 10:38:11 -0700) References: <39EB3D03.A00C78B6@jps.net> Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr> > Are people doing the kind of numeric programming with "complex > algorithms" using Python that Konrad refers to? More importantly, how > many people? At least one: me. > > Guido thinks that 2/3 returning 0 was a design mistake, > > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > > users won't know what to do with a complex number, so it's "an error" to > > them. > > Guido's philosophy is clearly that Python defaults should be geared to > "Most Python users". I agree, and as I wrote in an earlier post, the It's difficult to say what "most Python users" want; it's not a static community. I'd say the basic principle is "no bad surprises". 2/3 == 0 is a bad surprise for anyone who knows elementary math but is not familiar with certain programming languages, especially since the program goes on silently with a "wrong" intermediate result. > Maybe we can have true 754 compliance in Py3k, and we can all be happy!! Py3k forever! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Nicolas.Chauvat@logilab.fr Wed Oct 18 09:35:02 2000 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de> Message-ID: On Tue, 17 Oct 2000, Martin v. Loewis wrote: [about my suggestion concerning a SourceForge dedicated to python] That was only a suggestion, not a demand as someone stated. I would love to set up a pythonforge myself if I had the resources, unfortunately I don't... maybe in a few months? Time will tell. For now I'll just go back to hacking and keep quiet. Cheers, :) --=20 Nicolas Chauvat http://www.logilab.com - "Mais o=F9 est donc Ornicar ?" - LOGILAB, Paris (F= rance) From barry@scottb.demon.co.uk Wed Oct 18 10:57:04 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 18 Oct 2000 10:57:04 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> Message-ID: <001401c038e9$c4cabbd0$060210ac@private> O.k. will do, hopefully this weekend. BArry > -----Original Message----- > From: guido@cj20424-a.reston1.va.home.com > [mailto:guido@cj20424-a.reston1.va.home.com]On Behalf Of Guido van > Rossum > Sent: 17 October 2000 15:06 > To: Barry Scott > Cc: jeremy@beopen.com; python-dev@python.org > Subject: Re: [Python-Dev] build problems large and small on FreeBSD > > > > The FreeBSD ports collection had to be updated to support > > importing C++ extensions with Python 1.5.2. (You get things > > like cout not defined when importing). > > > > Are the nessesary compile/link changes in 2.0? > > Tell you what: I have no idea. :-( > > I believe there were some changes to the Makefile and/or config file > to support C++, but I don't know if this works on FreeBSD. I'm not a > big C++ user myself, so I rarely try this... > > Can you try it? If it doesn't work out of the box, let's sit down > together and figure out a fix. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > From mal@lemburg.com Wed Oct 18 17:03:16 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 18 Oct 2000 18:03:16 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? Message-ID: <39EDC9C4.7D61454@lemburg.com> Before starting to work on postponed patches and checking them in: is the current CVS tree ready for new checkins (tags applied, etc.) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Wed Oct 18 17:29:45 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <39EDC9C4.7D61454@lemburg.com> References: <39EDC9C4.7D61454@lemburg.com> Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Before starting to work on postponed patches and checking them > in: is the current CVS tree ready for new checkins (tags applied, > etc.) ? Yes; I posted a note re-opening the tree yesterday (or late Monday night; I can't remember that far back). We've just been too tired to do a lot since the release. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Wed Oct 18 17:52:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 12:52:52 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > We've just been too tired to do a lot since the release. ;) LOL! You're the very soul of diplomacy, Fred -- but I guess, overall, it really is prudent not to mention all our recent suicide attempts . my-wrists-are-killing-me-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Wed Oct 18 18:19:25 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: <14829.56221.303087.523464@beluga.mojam.com> Tim> my-wrists-are-killing-me-ly y'rs - tim You need my typing watcher: http://www.musi-cal.com/~skip/python/watch.py Only problem is I never figured out how to make it watch keystrokes directly. It detects mouse movement. Since I do most of my typing in Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the mouse a little... I've tried, so far unsuccessfully, to make this a SourceForge project. I've even asked for help from SF, but their response wasn't helpful, and the round-trip time for a response is too long to make pursuing that path worthwhile. The watch project is at http://sourceforge.net/projects/watch/ All I have is a CVSROOT/modules file. Nothing I've tried has successfully imported the one project file into cvs. If anyone has any suggestions for kickstarting this thing, it would be much appreciated. Thx, Skip From thomas@xs4all.net Wed Oct 18 19:43:19 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 18 Oct 2000 20:43:19 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> Message-ID: <20001018204319.L12812@xs4all.nl> On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote: > Tim> my-wrists-are-killing-me-ly y'rs - tim > You need my typing watcher: Given his remark about suicide attempts, I'm not sure if Tim really meant 'RSI' when he wrote that :-) > http://www.musi-cal.com/~skip/python/watch.py > Only problem is I never figured out how to make it watch keystrokes > directly. It detects mouse movement. Since I do most of my typing in > Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the > mouse a little... Funny, a colleague of mine has a similar tool. Also written in Python, I think, though it may have been created in his Perl Period. On a linux box, you can determine keystrokes by using /proc/interrupts. At least, if your keyboard has an interrupt all for itself. (Pretty likely, really :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Wed Oct 18 20:11:20 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <20001018204319.L12812@xs4all.nl> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> Message-ID: <14829.62936.109759.567547@beluga.mojam.com> Thomas> On a linux box, you can determine keystrokes by using Thomas> /proc/interrupts. At least, if your keyboard has an interrupt Thomas> all for itself. (Pretty likely, really :) Thanks, Neil S. sent me a patch for that already. I'll try to work it into the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or other Unix flavors? I suspect I'll just have to bite the bullet and work in platform-dependent code for this. Skip From esr@thyrsus.com Wed Oct 18 20:36:01 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 18 Oct 2000 15:36:01 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <20001018153601.A18127@thyrsus.com> Skip Montanaro : > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Might this monitoring function be a candidate for the Python library when it's done? -- Eric S. Raymond A man with a gun is a citizen. A man without a gun is a subject. From cgw@fnal.gov Wed Oct 18 20:53:09 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov> Skip Montanaro writes: > > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Can't tell you about Windows or Mac, but for Unix I'd read the file driver/timers.c in the XScreensaver distribution (www.jwz.org). This code is pretty sophisticated and runs on all the major Unix flavors. From skip@mojam.com (Skip Montanaro) Wed Oct 18 21:22:45 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> <14829.65445.421622.258893@buffalo.fnal.gov> Message-ID: <14830.1685.932659.181060@beluga.mojam.com> Charles> ... but for Unix I'd read the file driver/timers.c in the Charles> XScreensaver distribution (www.jwz.org). This code is pretty Charles> sophisticated and runs on all the major Unix flavors. Thanks, Charles. I will check it out. Those of you who are former (or current) od users will appreciate Jamie Zawinski's home page even if you're not interested in this topic. I revisit his site periodically. I'm never disappointed... Skip From est@hyperreal.org Wed Oct 18 21:30:46 2000 From: est@hyperreal.org (est@hyperreal.org) Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro at "Oct 18, 2000 03:22:45 pm" Message-ID: <20001018203047.27215.qmail@hyperreal.org> Skip Montanaro discourseth: > > Those of you who are former (or current) od users will appreciate Jamie > Zawinski's home page even if you're not interested in this topic. I revisit > his site periodically. I'm never disappointed... Looks more like emacs hexl-mode to me. Hmm..I guess you got this thread off topic. :) E From martin@loewis.home.cs.tu-berlin.de Wed Oct 18 22:09:36 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 18 Oct 2000 23:09:36 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> What is the reason for not publishing Python 2.0 on SF for download? SF certainly wouldn't be the primary source, but I think at least the source distribution should be available there, with the release notes telling where to get binary distributions (BeOpen, ActiveState, who else?) Regards, Martin From tim_one@email.msn.com Wed Oct 18 22:34:38 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 17:34:38 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: [Martin v. Loewis] > What is the reason for not publishing Python 2.0 on SF for download? From BeOpen.com's POV, so long as they were paying major bills, they would rather have download traffic tickle their ad banners than SF's ad banners. From our (PythonLabs) POV, another publishing site is more work, and one URL is about as good as any other. Besides, rising to the top of SF's "most active" list has not been an explicit life goal for any of us . > SF certainly wouldn't be the primary source, but I think at least the > source distribution should be available there, with the release notes > telling where to get binary distributions (BeOpen, ActiveState, who > else?) I didn't see any advantage claimed for publishing on SF. Without an advantage, the work/benefit ratio is infinite. From gstein@lyra.org Wed Oct 18 23:44:13 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 18 Oct 2000 15:44:13 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400 References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: <20001018154413.A31010@lyra.org> On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote: > [Martin v. Loewis] > > What is the reason for not publishing Python 2.0 on SF for download? > > >From BeOpen.com's POV, so long as they were paying major bills, they would > rather have download traffic tickle their ad banners than SF's ad banners. > > >From our (PythonLabs) POV, another publishing site is more work, and one URL > is about as good as any other. Besides, rising to the top of SF's "most > active" list has not been an explicit life goal for any of us . And here is where the larger community can help. Presuming that non-admins can publish files, then we could take on the burden of publishing the files via SF. > > SF certainly wouldn't be the primary source, but I think at least the > > source distribution should be available there, with the release notes > > telling where to get binary distributions (BeOpen, ActiveState, who > > else?) > > I didn't see any advantage claimed for publishing on SF. Without an > advantage, the work/benefit ratio is infinite. Work == 0 for you guys, presuming that non-admins can publish. [ off to take a look... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Thu Oct 19 17:20:37 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 12:20:37 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us> Before we all become focused on new features for Python 2.1, it would be nice to do a bit more work on raising awareness of the new features in 2.0. There's little point in developing software if you don't actually tell anyone about it, after all. I'd like to suggest that people try to write some brief articles, just a few pages long, each covering a particular feature in some detail. Looking through the list of new stuff, the most significant features are: * Unicode support. (Perl's UTF-8 support still seems incomplete, with developers referring to it as "unusable", so we should definitely try and point out that we have working Unicode support right now.) * Distutils: an introduction to writing setup scripts for simple Python modules, packages, and C extensions. * The new XML tools. * The new gettext support. * Maybe the linuxaudiodev module, too. Any other suggestions? If the story of how a particular feature was implemented is interesting, then that would also make a fine topic for a more developer-oriented publication such as DDJ. SRE or Unicode may be the best candidates for this sort of thing, as their implementation presented various tricky technical problems along the way. Any volunteers? --amk From gvwilson@nevex.com Thu Oct 19 17:53:31 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > Before we all become focused on new features for Python 2.1, it would be > nice to do a bit more work on raising awareness of the new features in 2.0. "Doctor Dobb's Journal" would be very interested in articles --- 3000 words (plus or minus), plus some code examples and diagrams. > * Unicode support. (Perl's UTF-8 support still seems incomplete, with > developers referring to it as "unusable", so we should definitely try and > point out that we have working Unicode support right now.) Definitely --- the practical details of implementing Unicode, and a Unicode-aware regular expression engine, would be very interesting to our readers. However, please steer clear of saying, "And anyway, Perl is broken." (I just got a review copy of Hunt and Thomas's book on Ruby. There are three places in the first two chapters where they say, "And Ruby has more users in Japan than Python." I'll finish the book anyway.) > * Distutils: an introduction to writing setup scripts for simple > Python modules, packages, and C extensions. Possibly interesting; would be more so if Distutils could be applied/was being applied to installation problems in other languages. > * The new XML tools. Definitely. > * The new gettext support. > * Maybe the linuxaudiodev module, too. These are both probably too specialized... > Any other suggestions? The garbage collector: Java and Ruby both score points by having full garbage collection, so its availability in Python 2.0 (along with a discussion of the things that might break or change as a result) would be very interesting. Thanks, Greg (a contributing editor with DDJ) From nas@arctrix.com Thu Oct 19 11:09:52 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 19 Oct 2000 03:09:52 -0700 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019030952.A32671@glacier.fnational.com> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: > The garbage collector: Java and Ruby both score points by having full garbage > collection, so its availability in Python 2.0 (along with a discussion of the > things that might break or change as a result) would be very interesting. This is on my todo list. I think there are some interesting implementation issues. Also, the article would be useful documentation for python-dev type people. Neil From akuchlin@mems-exchange.org Thu Oct 19 18:32:08 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:32:08 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >"Doctor Dobb's Journal" would be very interested in articles --- 3000 words >(plus or minus), plus some code examples and diagrams. I was thinking more about on-line places such as oreillynet.com/python/, but DDJ would be better still. >The garbage collector: Java and Ruby both score points by having full garbage >collection, so its availability in Python 2.0 (along with a discussion of the >things that might break or change as a result) would be very interesting. Arising out of lunch-time discussion, a comparison of how different FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection would be interesting, though perhaps unsuitable for DDJ, since the topic is a rather unfocused one. --amk From martin@loewis.home.cs.tu-berlin.de Thu Oct 19 18:31:58 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 19 Oct 2000 19:31:58 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> [Tim Peters] > From BeOpen.com's POV, so long as they were paying major bills, they > would rather have download traffic tickle their ad banners than SF's > ad banners. Even though this should have been clear to me all the time, stating it explicitly triggers alarms for me. I just checked, and it appears that Python 2.0 is not available for download via ftp. In particular, it is not available via ftp from ftp.python.org! If it was there, mirrors all over the world would pick it up and bring it in a location near me (ftp.fu-berlin.de would be nearest) (*). So while making it available on SF may indeed give no advantage, making it available on python.org would provide users with alternative download locations, so that I don't feel the bandwidth limitation that Web download from pythonlabs.com produces. That would be a clear advantage to me, at least. Of course, having ftp mirrors would mean that many downloads do not tickle anybody's ad banners - which would probably be in the interest of other users as well, just not in the interest of BeOpen. So I'm curious how this conflict of interest is resolved... Regards, Martin (*) ftp://ftp.python.org/python/src/README does not even mention Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Note that some mirrors only collect the this directory (src), and the doc and contrib siblings, while the ftp master site, , has much more. "Much more" may be true, just nothing recent... I probably should ask ftpmaster.python.org to put Python-2.0.tar.gz in that directory. From akuchlin@mems-exchange.org Thu Oct 19 18:42:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:42:19 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >(*) ftp://ftp.python.org/python/src/README does not even mention >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Unless one of the BeOpen Pythoneers is already going to do this, I'll go ahead and drop the relevant files into places. Guys? While we're at it, how about making the filenames for the source code consistent? -rw-r--r-- 1 guido psa 2533053 Apr 13 1999 py152.tgz -rw-r--r-- 1 1103 psa 2259957 Oct 31 1998 pyth151.tgz -rw-r--r-- 1 guido psa 1907724 May 31 1995 python1.2.tar.gz -rw-r--r-- 1 guido psa 2037062 Oct 12 1995 python1.3.tar.gz -rw-r--r-- 1 guido psa 2252481 Oct 25 1996 python1.4.tar.gz -rw-r--r-- 1 guido psa 2904353 Jan 3 1998 python1.5.tar.gz I like pythonX.X.tar.gz best, and will change the filenames (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. Though isn't the standard GNU naming convention more like python-1.5.tar.gz? --amk From esr@thyrsus.com Thu Oct 19 19:05:48 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 19 Oct 2000 14:05:48 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019140548.A21315@thyrsus.com> Andrew Kuchling : > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? It is, and I wish we'd move to it as did the Perl guys. It makes life substantially easier to have really uniform naming conventions, especially for programs like the Metalabs file clerk. -- Eric S. Raymond Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' From mwh21@cam.ac.uk Thu Oct 19 19:01:29 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 19 Oct 2000 19:01:29 +0100 Subject: [Python-Dev] 2.0 articles In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400" References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Before we all become focused on new features for Python 2.1, it would > be nice to do a bit more work on raising awareness of the new features > in 2.0. There's little point in developing software if you don't > actually tell anyone about it, after all. > > I'd like to suggest that people try to write some brief articles, just > a few pages long, each covering a particular feature in some detail. [snip] > Any volunteers? It's not as exciting as Unicode or XML, but I've thrashed out a few hundred words on the new "setdefault" dictionary method. It's up here: http://starship.python.net/crew/mwh/hacks/setdefault.html Tell me what you think! There's the beginning of a longer example in a comment at the bottom, but I felt it was getting a bit long-winded to be of interest. Cheers, M. -- If i don't understand lisp, it would be wise to not bray about how lisp is stupid or otherwise criticize, because my stupidity would be archived and open for all in the know to see. -- Xah, comp.lang.lisp From gstein@lyra.org Thu Oct 19 19:52:53 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:52:53 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019115253.W31108@lyra.org> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >... > Of course, having ftp mirrors would mean that many downloads do not > tickle anybody's ad banners - which would probably be in the interest > of other users as well, just not in the interest of BeOpen. So I'm > curious how this conflict of interest is resolved... Stating that a "conflict of interest" even EXISTS is a rather sorry statement on things. -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Oct 19 19:54:36 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:54:36 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019115436.X31108@lyra.org> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: > On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: > >(*) ftp://ftp.python.org/python/src/README does not even mention > >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says > > Unless one of the BeOpen Pythoneers is already going to do this, I'll > go ahead and drop the relevant files into places. Guys? Please... just do it. >... > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? I'm with Eric -- go for the GNU standard. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Thu Oct 19 20:11:42 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 15:11:42 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote: >On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> Unless one of the BeOpen Pythoneers is already going to do this, I'll >> go ahead and drop the relevant files into places. Guys? >Please... just do it. I charged ahead and did it anyway; the Pythoneers can spank me for it later. (Worse, maybe they'll do something *bad* to me...) There were already doc/1.6/ and doc/2.0/ directories, and binaries (Windows, RPMs) were in /pub/python/2.0/, along with the source. So I only touched /pub/python/src/. All the releases and betas are now consistently named python-X.Y.Z.tar.gz. I've left symlinks in place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final releases, but didn't bother making links for releases older than 1.5.1 or for beta versions, so any FTP URLs pointing directly to those files will be broken. --amk From jeremy@beopen.com Fri Oct 20 17:28:19 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >> >(*) ftp://ftp.python.org/python/src/README does not even mention >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says >> >> Unless one of the BeOpen Pythoneers is already going to do this, >> I'll go ahead and drop the relevant files into places. Guys? GS> Please... just do it. In the interest of making the distribution as widely available as possible, I've placed files on SourceForge and at http://www.python.org/2.0/ >> ... I like pythonX.X.tar.gz best, and will change the filenames >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless >> vetoed. Though isn't the standard GNU naming convention more >> like python-1.5.tar.gz? GS> I'm with Eric -- go for the GNU standard. I used the file name conventions that we used throughout the 2.0 release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU standard or not (didn't realize it was a standard; don't know where to find said standard; or is it just a custom?) Jeremy From jeremy@beopen.com Fri Oct 20 17:31:47 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us> References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >> "Doctor Dobb's Journal" would be very interested in articles --- >> 3000 words (plus or minus), plus some code examples and diagrams. AMK> I was thinking more about on-line places such as AMK> oreillynet.com/python/, but DDJ would be better still. And, of course, there's the Python conference: http://python9.org/ >> The garbage collector: Java and Ruby both score points by having >> full garbage collection, so its availability in Python 2.0 (along >> with a discussion of the things that might break or change as a >> result) would be very interesting. AMK> Arising out of lunch-time discussion, a comparison of how AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with AMK> garbage collection would be interesting, though perhaps AMK> unsuitable for DDJ, since the topic is a rather unfocused one. A comparison of different FFIs with respect to garbage collection might be interesting; hard to say without seeing what the conclusions are. Jeremy From akuchlin@mems-exchange.org Fri Oct 20 17:26:56 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:26:56 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote: >release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU >standard or not (didn't realize it was a standard; don't know where to >find said standard; or is it just a custom?) See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24 Though I think here the standard is just codifying an existing custom that's proved convenient. www.fsf.org seems unresponsive at the moment, hence the strange link; is *every* Web site in the world breaking today for some reason? --amk From akuchlin@mems-exchange.org Fri Oct 20 17:28:10 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:28:10 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net> Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote: >And, of course, there's the Python conference: http://python9.org/ That's preaching to the converted, though. --amk From fdrake@acm.org Fri Oct 20 17:51:44 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ There's a separate python-rpms "Package"; the RPM files should go there (I think). -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From thomas@xs4all.net Fri Oct 20 21:21:18 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 20 Oct 2000 22:21:18 +0200 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: ; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100 References: Message-ID: <20001020222118.M12812@xs4all.nl> On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote: > "Jean-Claude Levieux" writes: > > I just tried to compile Python 2.0. > > on BSDI BSD/OS 4.0.1 [ Sorry, missed the original message. Used the Archive to find it, tho ] > Random guess, but you are using a ANSI C compiler, aren't you? Python > 2.0 now demands that. BSDI uses gcc, so that's not the problem. Neither are these three warnings: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype /usr/include/wchar.h:17: warning: function declaration isn't a prototype (or any other warnings regarding 'function decl isn't a prototype) They are a result of Python using '-Wstrict-prototypes' by default, if the compiler is gcc. It just means BSDI declares a few functions without specifying argument lists (prototypes) and has nothing to do with Python (other than that Python always defines CFLAGS to contain -Wstrict-prototypes.) There isn't an easy way to get this 'fixed', unfortunately. If you want to quench the warnings, you'll have to edit =2E/Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile, and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly, because it's overwritten by the 'makesetup' script, which parses the Setup file.) As for the other error, that's really an error :( =2E./libpython2.0.a(fileobject.o): In function =1Fportable_fseek': /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined reference to `TELL64' The problem is that BSDI has an 'off_t' type that is larger than the 'long' type, and Python's configure makes the flawed assumption that this means BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug is even present with BSDI 4.1, and probably more platforms. You can fix this by editing './config.h' after running './configure', and commenting out the HAVE_LARGEFILE_SUPPORT line; changing this: #define HAVE_LARGEFILE_SUPPORT 1 into something like this: /* #define HAVE_LARGEFILE_SUPPORT 1 */ (You can just remove the line as well.) The downside of both these 'hacks' (excuse me, 'hotfixes'), is that you'll have to reedit the files again after running configure again (or something that runs configure, like 'config.status'.) I see a total of three bugs here: Python adds -Wstrict-prototypes even though it can generate a lot of warnings that aren't related to Python; there is no way to override the CFLAGS variable (you can pass it to configure, and it uses it at first, but then just overwrites it); and mis-detecting large file support. I can't decide which of the last two is the biggest bug :-) I would write a patch for the lot of 'm, but I'm in the middle of getting ready to head to London for the Apache conference (any other Pythonistas going ? :) and Have I Got News For You is about to start on BBC1. If you don't do it, Jean-Claude, I'll submit bugreports on these when I'm back, next Thursday. (Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1. You can leave them on for 4.1, but 4.0.1 has very broken threads, and it will cause lots of problems in the signal module if you leave them on. You can disable them by using '--with-threads=3Dno' -- this is also listed in t= he README, by the way. And note that BSDI 4.1 only has the large file support problem, none of the others, and I strongly suggest upgrading for other reasons as well.) Python-dev: CC'd because this is material for a bugfix-release. There are likely to be other platforms hit by the large filesupport misdetection. Don't think this is enough to warrant a bugfix release (it's not *that* brownbaggy) but it should definately go in if there is one ;P If I or someone else didn't fix it by the time a bugfix release is considered, please hit me. I also appologize for not properly testing Python 2.0 on BSDI 4.0.1 or 4.1... We still have those machines, but we are using less and less of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux :) BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all- -those-good-sides-too-ly y'rs, --=20 Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me sp= read! From trentm@ActiveState.com Fri Oct 20 21:54:59 2000 From: trentm@ActiveState.com (Trent Mick) Date: Fri, 20 Oct 2000 13:54:59 -0700 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200 References: <20001020222118.M12812@xs4all.nl> Message-ID: <20001020135459.C1562@ActiveState.com> On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:=0D > As for the other error, that's really an error :(=0D > =0D > ../libpython2.0.a(fileobject.o): In function =1Fportable_fseek':=0D > /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined=0D > reference to `TELL64'=0D > =0D > The problem is that BSDI has an 'off_t' type that is larger than the 'lon= g'=0D > type, and Python's configure makes the flawed assumption that this means= =0D > BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This = bug=0D > is even present with BSDI 4.1, and probably more platforms. You can fix t= his=0D > by editing './config.h' after running './configure', and commenting out t= he=0D > HAVE_LARGEFILE_SUPPORT line; changing this:=0D > =0D > #define HAVE_LARGEFILE_SUPPORT 1=0D > =0D > into something like this:=0D > =0D > /* #define HAVE_LARGEFILE_SUPPORT 1 */=0D > =0D > (You can just remove the line as well.) The downside of both these 'hacks= '=0D > (excuse me, 'hotfixes'), is that you'll have to reedit the files again af= ter=0D > running configure again (or something that runs configure, like=0D > 'config.status'.)=0D =0D This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I s= ee=0D a pattern)=0D http://sourceforge.net/bugs/?func=3Ddetailbug&bug_id=3D112289&group_id=3D54= 70=0D =0D It was fixed by adding a hack in fileobject.c to *define* TELL64.=0D http://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D101558= &group_id=3D5470=0D =0D For the quickfix, the same hack could be used for BSDI.=0D =0D As you suggest Thomas, the proper fix is to patch configure.in such that it= =0D does not report that these system support largefiles.=0D =0D I don't have the time to do this right away, nor do I have one of these box= es=0D on which to test it. I can try to make a patch though. We don't you file a= =0D bug and assign it to me.=0D =0D Trent=0D =0D =0D -- =0D Trent Mick=0D TrentM@ActiveState.com=0D From martin@loewis.home.cs.tu-berlin.de Fri Oct 20 21:54:02 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 20 Oct 2000 22:54:02 +0200 Subject: [Python-Dev] This Project Has Released Files Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de> > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ Thanks! also to anybody else contributing to the release process, in particular to amk for his ongoing maintainance of various pieces on python.org, and his efforts in getting the word out. Regards, Martin From cgw@fnal.gov Fri Oct 13 16:11:03 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach Below find the output of cc -V as well as the output of ./configure and make (sorry for the flood, I assume too much detail is better than not enough) creating cache ./config.cache checking MACHDEP... osf1V4 checking for --without-gcc... checking for --with-cxx=... no checking for gcc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for --with-suffix... checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... cc -E checking for AIX... no checking for minix/config.h... no checking whether cc accepts -OPT:Olimit=0... no checking whether cc accepts -Olimit 1500... yes checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... no checking for poll.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for db_185.h... no checking for db.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for pty.h... yes checking for libutil.h... no checking for ndbm.h... yes checking for db1/ndbm.h... no checking for gdbm/ndbm.h... no checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of char... 1 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking size of fpos_t... 8 checking for long long support... yes checking size of long long... 8 checking for uintptr_t support... no checking size of off_t... 8 checking whether to enable large file support... no checking size of time_t... 4 checking for pthread_t... yes checking size of pthread_t... 8 checking for --with-next-framework... no checking for --with-dyld... no checking SO... .so checking LDSHARED... ld -shared -expect_unresolved "*" checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... no checking for shl_load in -ldld... no checking for --with-pydebug... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for --with-libs... no checking for --with-dec-threads... no checking for --with-threads... yes checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... yes checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking for --with-cycle-gc... yes checking for --with-libdb... yes checking for dbopen... no checking for --with-wctype-functions... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for dlopen... yes checking DYNLOADFILE... dynload_shlib.o checking for alarm... yes checking for chown... yes checking for clock... yes checking for confstr... yes checking for ctermid... yes checking for ctermid_r... no checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... yes checking for fpathconf... yes checking for ftime... yes checking for ftruncate... yes checking for getgroups... yes checking for getlogin... yes checking for getpeername... yes checking for getpid... yes checking for getpwent... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for mremap... no checking for nice... yes checking for pathconf... yes checking for pause... yes checking for plock... yes checking for poll... yes checking for pthread_init... no checking for putenv... yes checking for readlink... yes checking for select... yes checking for setegid... yes checking for seteuid... yes checking for setgid... yes checking for setlocale... yes checking for setregid... yes checking for setreuid... yes checking for setsid... yes checking for setpgid... yes checking for setuid... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... yes checking for strftime... yes checking for strptime... yes checking for symlink... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for tempnam... yes checking for timegm... no checking for times... yes checking for tmpfile... yes checking for tmpnam... yes checking for tmpnam_r... no checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for _getpty... no checking for openpty... yes checking for forkpty... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... yes checking for ftell64... no checking for ftello... no checking for statvfs... yes checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... yes checking for setpgrp... yes checking for gettimeofday... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for member tm_zone in aggregate type struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for inline... __inline checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... yes checking gethostbyname_r with 6 args... yes checking for __fpu_control... no checking for __fpu_control in -lieee... no checking for --with-fpectl... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for genuine getopt... yes checking what malloc(0) returns... null checking for wchar.h... yes checking for usable wchar_t... no checking whether byte ordering is bigendian... no checking whether right shift extends the sign bit... yes checking for socklen_t... no updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Grammar/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.config creating config.h (cd Modules; make -f Makefile.pre Makefile) + cp ./Setup.in Setup rm -rf ../libpython2.0.a /bin/sh ./makesetup Setup.config Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Grammar `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo yes >hassignal; break; fi; done cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ./Grammar Compiling (meta-) parse tree into NFA grammar Making DFA for 'single_input' ... Making DFA for 'file_input' ... Making DFA for 'eval_input' ... Making DFA for 'funcdef' ... Making DFA for 'parameters' ... Making DFA for 'varargslist' ... Making DFA for 'fpdef' ... Making DFA for 'fplist' ... Making DFA for 'stmt' ... Making DFA for 'simple_stmt' ... Making DFA for 'small_stmt' ... Making DFA for 'expr_stmt' ... Making DFA for 'augassign' ... Making DFA for 'print_stmt' ... Making DFA for 'del_stmt' ... Making DFA for 'pass_stmt' ... Making DFA for 'flow_stmt' ... Making DFA for 'break_stmt' ... Making DFA for 'continue_stmt' ... Making DFA for 'return_stmt' ... Making DFA for 'raise_stmt' ... Making DFA for 'import_stmt' ... Making DFA for 'import_as_name' ... Making DFA for 'dotted_as_name' ... Making DFA for 'dotted_name' ... Making DFA for 'global_stmt' ... Making DFA for 'exec_stmt' ... Making DFA for 'assert_stmt' ... Making DFA for 'compound_stmt' ... Making DFA for 'if_stmt' ... Making DFA for 'while_stmt' ... Making DFA for 'for_stmt' ... Making DFA for 'try_stmt' ... Making DFA for 'except_clause' ... Making DFA for 'suite' ... Making DFA for 'test' ... Making DFA for 'and_test' ... Making DFA for 'not_test' ... Making DFA for 'comparison' ... Making DFA for 'comp_op' ... Making DFA for 'expr' ... Making DFA for 'xor_expr' ... Making DFA for 'and_expr' ... Making DFA for 'shift_expr' ... Making DFA for 'arith_expr' ... Making DFA for 'term' ... Making DFA for 'factor' ... Making DFA for 'power' ... Making DFA for 'atom' ... Making DFA for 'listmaker' ... Making DFA for 'lambdef' ... Making DFA for 'trailer' ... Making DFA for 'subscriptlist' ... Making DFA for 'subscript' ... Making DFA for 'sliceop' ... Making DFA for 'exprlist' ... Making DFA for 'testlist' ... Making DFA for 'dictmaker' ... Making DFA for 'classdef' ... Making DFA for 'arglist' ... Making DFA for 'argument' ... Making DFA for 'list_iter' ... Making DFA for 'list_for' ... Making DFA for 'list_if' ... Adding FIRST sets ... Writing graminit.c ... Writing graminit.h ... cp graminit.h ./../Include/graminit.h cp graminit.c ./../Python/graminit.c cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"' ./getplatform.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"' -DPREFIX='"/usr/local"' -DEXEC_PREFIX='"/usr/local"' -DVERSION='"2.0"' -DVPATH='""' ./getpath.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c if test ! -f libpython2.0.a; then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true; else true; fi for i in Parser Grammar Objects Python Modules; do (cd $i; make VERSION="2.0" add2lib); done ar cr ../libpython2.0.a acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o myreadline.o if test ! -f ../Modules/hassignal; then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o; else echo leaving intrcheck.o out; fi leaving intrcheck.o out touch add2lib ar cr ../libpython2.0.a abstract.o bufferobject.o classobject.o cobject.o complexobject.o fileobject.o floatobject.o frameobject.o funcobject.o intobject.o listobject.o longobject.o dictobject.o methodobject.o moduleobject.o object.o rangeobject.o sliceobject.o stringobject.o tupleobject.o typeobject.o unicodeobject.o unicodectype.o touch add2lib ar cr ../libpython2.0.a bltinmodule.o exceptions.o ceval.o compile.o codecs.o errors.o frozen.o frozenmain.o getargs.o getcompiler.o getcopyright.o getmtime.o getplatform.o getversion.o graminit.o import.o importdl.o marshal.o modsupport.o mystrtoul.o pyfpe.o pystate.o pythonrun.o structmember.o sysmodule.o traceback.o dynload_shlib.o thread.o if test ! -f ../Modules/hassignal; then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o; else echo leaving sigcheck.o out; fi leaving sigcheck.o out touch add2lib if test -f hassignal; then echo removing sigcheck.o intrcheck.o; ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null; else echo leaving sigcheck.o intrcheck.o in; fi removing sigcheck.o intrcheck.o *** Exit 2 (ignored) ar cr ../libpython2.0.a threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o touch add2lib echo 0 >buildno cd Modules; make OPT="-O -Olimit 1500" python.o cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c expr `cat buildno` + 1 >buildno1 mv -f buildno1 buildno cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` ./Modules/getbuildinfo.c ar cr libpython2.0.a getbuildinfo.o ranlib libpython2.0.a true cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) /usr/lib/cmplrs/cc/ld: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $ $RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $ $RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $ $RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $ $RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $ $RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $ $RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $ $RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $ $RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $ $RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $ $RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $ $RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $ $RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $ $RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $ $RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $ $RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $ $RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $ $RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $ $RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $ $RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $ $RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $ $RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $ $RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $ $RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $ $RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $ $RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $ $RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $ $RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $ $RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $ $RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $ $RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $ $RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $ $RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $ $RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $ $RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $ $RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $ $RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $ $RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $ $RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $ $RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $ $RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $ $RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $ $RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $ $RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $ $RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $ $RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $ $RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $ $RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $ $RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $ $RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $ $RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $ $RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $ $RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $ habitat_id = realtime_12:1991 $RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $ $RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $ $RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $ $RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $ $RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $ $RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $ /usr/lib/cmplrs/cc/ftoc: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ /usr/lib/cmplrs/cc/cord: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ ldtbread.c: 1.1 1/7/82 /usr/lib/cmplrs/cc/crt0.o: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ cc (cc) Digital UNIX Compiler Driver 3.11 From mal@lemburg.com Mon Oct 23 14:35:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 23 Oct 2000 15:35:40 +0200 Subject: [Python-Dev] Starship down ? Message-ID: <39F43EAC.1A518A27@lemburg.com> Sorry for using this list, but the crew list sits on starship as well... The starship.python.net server seems to be down. Could someone with sysadmin access please fix this ?! Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot@telia.com Mon Oct 23 18:44:49 2000 From: effbot@telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 19:44:49 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid> looks like Tcl's parent company has ceased to be: http://biz.yahoo.com/bw/001020/ca_interwo.html "The Ajuba team will be assimilated into Interwoven's existing technical staff much as the Neonyoyo team was immediately after its acquisition in June. The Ajuba product line will be discontinued." From guido@python.org Mon Oct 23 21:12:49 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 15:12:49 -0500 Subject: [Python-Dev] Starship down ? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200." <39F43EAC.1A518A27@lemburg.com> References: <39F43EAC.1A518A27@lemburg.com> Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! Yeah, this is very unfortunate. It's the same problem that's keeping pytholabs.com down. The BeOpen systems staff is working on it, but I don't know what the problem is or when it will be fixed. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr@thyrsus.com Mon Oct 23 20:40:16 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 15:40:16 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> Message-ID: <20001023154016.A2722@thyrsus.com> Fredrik Lundh : > looks like Tcl's parent company has ceased to be: This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support? It seems to me that the Tcl world has been in increasing disarray for the last two years. Its growth doesn't seem to have matched Perl's or Python's; no strong community site analogous to python.org or CPAN has emerged; and John Osterhout's attempt to commercialize the language have led to a series of false starts and erratic moves. And Osterhout cheerfully acknowledges that on a technical level that Tcl has been pushed past the natural limits of applicability for its design approach. Tcl's long-term prognosis looks, to me, increasingly poor. Which suggests to me that some move toqwards making Python less dependent on Tk would be a good thing. I understand that we can't simply drop Tkinter. But I think it might be worth another look at alternatives (notably wxPython) to consider bringing one into the core distribution during 2.x, so that later on we can plan to move Tk to "unsupported -- legacy". -- Eric S. Raymond You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948) From guido@python.org Mon Oct 23 22:08:13 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 16:08:13 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400." <20001023154016.A2722@thyrsus.com> References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> [ESR] > This raises anew a question I've been meaning to bring up for the last > week: is it finally time to move away from Python's dependence on > Tcl/Tk for GUI support? > > It seems to me that the Tcl world has been in increasing disarray for > the last two years. Its growth doesn't seem to have matched Perl's or > Python's; no strong community site analogous to python.org or CPAN has > emerged; and John Osterhout's attempt to commercialize the language > have led to a series of false starts and erratic moves. And Osterhout > cheerfully acknowledges that on a technical level that Tcl has been > pushed past the natural limits of applicability for its design > approach. > > Tcl's long-term prognosis looks, to me, increasingly poor. Which > suggests to me that some move toqwards making Python less dependent > on Tk would be a good thing. > > I understand that we can't simply drop Tkinter. But I think it > might be worth another look at alternatives (notably wxPython) to > consider bringing one into the core distribution during 2.x, so that > later on we can plan to move Tk to "unsupported -- legacy". Yes, it may be time to have this discussion again. Of course, Tcl/Tk still has a much larger following than wxWindows, and it is more stable too. (For example, it's easy to cause crashes -- not just exceptions -- by leaving out an initialization call in wxPython.) Plus, Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc. The Scintilla text widget comes close (and surpasses Tkinter in some respects, while coming short in others), but I know of no widget in a popular widget set that offers anything close to the Canvas widget. There are other choices too, all of which have Python support already: gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Mon Oct 23 21:21:18 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:21:18 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us> Fredrik Lundh wrote: > looks like Tcl's parent company has ceased to be: I checked out comp.lang.tcl after hearing about this. Ousterhout posted to say that an official statement will be coming out today or tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see what he says the core team is going to do... On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote: >This raises anew a question I've been meaning to bring up for the last >week: is it finally time to move away from Python's dependence on >Tcl/Tk for GUI support? It seems to me that supporting MacOS is the big problem for cross-platform GUIs. There are several different systems such as Qt that aim for portability across Windows and Unix, but add in the MacOS and the options really decrease. How good is wxWindows support for MacOS? Or will MacOS X fix the problem? I know MacOS X uses a BSD-based underlying kernel, but don't know if it will support X Windows out of the box. If people can only use MacOS-specific GUI APIs, then software such as Tk would still need to be ported specially to MacOS X. --amk From akuchlin@mems-exchange.org Mon Oct 23 21:30:11 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:30:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: >The Scintilla text widget comes close (and surpasses Tkinter in some >respects, while coming short in others), but I know of no widget in a >popular widget set that offers anything close to the Canvas widget. I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a fork of the Tk widget that was then substantially enhanced to be a general-purpose display engine, with antialiasing, alpha compositing, more attention to performance, and other fancy features. I don't know if the corresponding text widget (which is Pango, www.pango.org, I think) is equally featureful. --amk From gvwilson@nevex.com Mon Oct 23 21:33:48 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT) Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com> Message-ID: > Fredrik Lundh : > > looks like Tcl's parent company has ceased to be: > Eric Raymond: > This raises anew a question I've been meaning to bring up for the last week: > is it finally time to move away from Python's dependence on Tcl/Tk for GUI > support? Yes please. > It seems to me that the Tcl world has been in increasing disarray for the > last two years. Its growth doesn't seem to have matched Perl's or Python's; > no strong community site analogous to python.org or CPAN has emerged; I have been told by two different publishers that they can't even give Tcl books away any longer. It's also interesting that the new Ruby book from Hunt and Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or Perl (I saw three mentions in the first ten minutes of the fact that Ruby is more widely used in Japan than Python). Also interesting that the Ruby GUI toolkit they describe is Tk-based... > I understand that we can't simply drop Tkinter. But I think it might be > worth another look at alternatives (notably wxPython) to consider bringing > one into the core distribution during 2.x, so that later on we can plan to > move Tk to "unsupported -- legacy". I thought about using wxPython in the most recent run of my Python course, but decided to stick to Tkinter because: - There isn't a wxWindows/wxPython book (matters a lot when organizations are trying to decide what to adopt for long-term use). - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. - There aren't as many tools on top of wxPython as there are on top of Tkinter. In particular, I think that a vector drawing package on top of wxPython that did what Sketch does, but on Windows as well as Linux, would make a great subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Thanks, Greg From effbot@telia.com Mon Oct 23 22:02:58 2000 From: effbot@telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:02:58 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... from an open-source perspective, Tcl might be more alive than ever: http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-) From esr@thyrsus.com Mon Oct 23 22:15:03 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:15:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023171503.B2889@thyrsus.com> Guido van Rossum : > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). I'm glad you brought up GTK+. Of all the alternatives you mentioned, it seems to me the most likely to attract long-term cross-platform support by lots of developers (GNOME, Nautilus and Sun Microsystems seem like a tough trio to beat on this score). Thus, GTK+ may be be the safest alternative in terms of being least likely to strand us N years down the road. The GTK+ API seems like a nice clean design, and there is already a Python binding. Any comment from anybody on how stable it is? Are the text and canvas widgets anywhere near competitive with Tk's? There are hints of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port? -- Eric S. Raymond .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) From trentm@ActiveState.com Mon Oct 23 22:06:41 2000 From: trentm@ActiveState.com (Trent Mick) Date: Mon, 23 Oct 2000 14:06:41 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023140641.A3899@ActiveState.com> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: > There are other choices too, all of which have Python support already: ... > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). XUL. Though slappin' a GUI together in XUL is not all the same as for the other toolkits. Layout with XML, functionality with JavaScript and Python (and/or Perl of C++). Trent -- Trent Mick TrentM@ActiveState.com From effbot@telia.com Mon Oct 23 22:33:02 2000 From: effbot@telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:33:02 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... they just updated their site: http://www.ajubasolutions.com/company/whatsnew.html "Tcl is not a core technology at Interwoven, and Interwoven will not invest in the development of Tcl. However, Ajuba has transferred responsibility for Tcl core development to the newly formed Tcl Core Team /.../ We expect the Tcl Core Team to evolve Tcl at a much faster rate than any single organization could achieve by itself. "Over the next few weeks Ajuba will release in open- source form many of the Tcl packages that we deve- loped for our products. Stay tuned for more info... From akuchlin@mems-exchange.org Mon Oct 23 22:26:18 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 17:26:18 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: ; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400 References: <20001023154016.A2722@thyrsus.com> Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us> Some details begin to emerge at http://www.ajubasolutions.com/company/whatsnew.html It looks like some of their proprietary code will be released as open source, possibly including the TclPro development environment. The new company will not be funding Tcl/Tk development, and instead it's up to the 14 members of the recently-formed Tcl core team. I don't know if any of those people are being paid to work on Tcl, but probably at least some of them are. I expect this will cause a good deal disruption, perhaps even a fatal amount, particularly if core developers such as Jeffrey Hobbs no longer work on Tcl full-time. --amk From esr@thyrsus.com Mon Oct 23 22:58:20 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:58:20 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400 References: <20001023154016.A2722@thyrsus.com> <20001023172618.A23898@kronos.cnri.reston.va.us> Message-ID: <20001023175820.A3117@thyrsus.com> Andrew Kuchling : > Some details begin to emerge at > http://www.ajubasolutions.com/company/whatsnew.html > > It looks like some of their proprietary code will be released as open > source, possibly including the TclPro development environment. The > new company will not be funding Tcl/Tk development, and instead it's > up to the 14 members of the recently-formed Tcl core team. I don't > know if any of those people are being paid to work on Tcl, but > probably at least some of them are. I expect this will cause a good > deal disruption, perhaps even a fatal amount, particularly if core > developers such as Jeffrey Hobbs no longer work on Tcl full-time. Not necessarily... Good for Tcl: they *have* a core team now Bad for Tcl: at 14 it's too big, unless there's some inner core of no more than three or four architects. Good for Tcl: Much of the proprietary code will go open. Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are on the new core team. Not clear whether their time available will increase or decrease. Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users. With good leadership, they could manage the transition to something resembling the Apache Software Foundation's organization. If so, Tcl might actually improve. -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From robin@alldunn.com Tue Oct 24 00:03:44 2000 From: robin@alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:03:44 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES> I'm not on python-dev so please be sure to copy me on replies. "Greg Wilson" wrote: > > I thought about using wxPython in the most recent run of my Python course, but > decided to stick to Tkinter because: > > - There isn't a wxWindows/wxPython book (matters a lot when organizations are > trying to decide what to adopt for long-term use). > This is something I am hoping to change in the near future. I have a lot of ideas, have been putting an outline together, and have a phone conference with a potential publisher tomorrow. > - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. > > - There aren't as many tools on top of wxPython as there are on top of Tkinter. > In particular, I think that a vector drawing package on top of wxPython that > did what Sketch does, but on Windows as well as Linux, would make a great > subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Hint received and understood... "Andrew Kuchling" akuchlin@mems-exchange.org wrote: > > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. There are several different systems such as Qt > that aim for portability across Windows and Unix, but add in the MacOS > and the options really decrease. How good is wxWindows support for > MacOS? My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. It's in use in at least a few commercial applications around the world. The next step I guess is getting it wrapped up in wxPython, which should just be a matter of porting some of the low level startup and helper code, and putting some ifdef's in the SWIG interface files for things that may be different in the Mac version of wxWindows. Unfortunately, given the current state of the amount of my spare time and relative Mac-illiterate-ness, it's either going to require someone else to work on it and be wxPython-Mac's champion, or somebody needs to fund my ramp-up and development time so I can cut back on other things. The good news is that I have been loaned a Mac and CodeWarior and such to play with, I just haven't found the time to play much lately. "Guido van Rossum" guido@python.org wrote: > Plus, Tk has two very high quality widgets: the Canvas and Text > widgets are unsurpassed in functionality and robustness by other > widget sets. You can draw more lines or characters per second in most > toolkits, but few toolkits offer the convenience of marks and tags, > not having to deal with refresh events, being able to group objects, > move them around, change attributes, etc., etc., etc. > > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), Just in case anybody didn't know already, wxWindows/wxPython has a wrapper around Scintilla available called wxStyledTextCtrl. > but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. wxWindows has a canvas widget in development right now. I've been trying to nudge the developers working on it towards features found in the tk canvas and the GNOME canvas widget. I have high hopes for it but I'm not sure how long it will be before it gets to the same level as the others. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From esr@thyrsus.com Tue Oct 24 00:29:54 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 19:29:54 -0400 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700 References: <036501c03d45$81aefae0$3225d2d1@ARES> Message-ID: <20001023192954.A3313@thyrsus.com> Robin Dunn : > Unfortunately, given the current > state of the amount of my spare time and relative Mac-illiterate-ness, it's > either going to require someone else to work on it and be wxPython-Mac's > champion, or somebody needs to fund my ramp-up and development time so I can > cut back on other things. This is exactly what CoSource and SourceXchange are for. Post your Mac port as a project there and see who ponies up money. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From MarkH@ActiveState.com Tue Oct 24 00:19:33 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 10:19:33 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001023140641.A3899@ActiveState.com> Message-ID: Trimmed all CCs [Guido] > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). [Trent "David Ascher" Mick responds] > XUL. Though slappin' a GUI together in XUL is not all the same as for > the other toolkits. Layout with XML, functionality with > JavaScript and Python (and/or Perl of C++). As a fairly irrelevant (at this point in time) observation: Something about the Mozilla XUL engine seems "right". It is large and complex, but their XML based layout engine, and powerful "code-less" widget creation has a lot of potential IMO. It is very very new and rough. It is very tightly bound with Mozilla itself and javascript, although efforts are underway to separate it from both. It is huge, and constantly changing. It has been designed for tomorrow, and struggles along today. But it may well turn out to be and expressive and compelling model for the future. So, if we can just continue to disagree for the next 2 or 3 years, it may well become something worth considering ;-) Mark. From robin@alldunn.com Tue Oct 24 00:56:59 2000 From: robin@alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:56:59 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com> Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES> > > This is exactly what CoSource and SourceXchange are for. Post your Mac port > as a project there and see who ponies up money. Now why didn't I think of that??? Thanks for the idea! -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From DavidA@ActiveState.com Tue Oct 24 05:00:51 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. > > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). The mozilla toolkits has more names than I care to remember. =) The most generic name is XPFE, although there are some parts of it with nicer names like XUL (pronounced Zool) and XBL. It also heavily uses XML, DTDs, CSS, etc. Mozilla is definitely a long-term investment in our part. For example, currently it's not possible to have Python code inline in the XUL (XML) code, and JavaScript is the only option there. We'll be working w/ the Netscape and Mozilla crowds to fix that, but it's not there yet. That said, Mozilla does have a fairly strong vision for the future, allows some of the benefits of the web technologies to transfer to the GUI world (designers, not coders, can do the UI work). In terms of the closest equivalent to the Canvas widget, apart from XUL itself, which is very hierarchical, there is the promise of SVG support, which will give you a lot more than the Canvas. That, too, is not quite ready for prime time yet. Hope this is helpful, --david From cgw@fnal.gov Tue Oct 24 05:32:04 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov> David Ascher writes: > > That said, Mozilla does have a fairly strong vision for the future, allows > some of the benefits of the web technologies to transfer to the GUI world > (designers, not coders, can do the UI work). Sounds great for the future, but I want to inject a few of my unsolicated, opinionated observations - today, in 2000, the Mozilla stuff is *far* from usable. If you want to produce nice, professional looking GUI apps which fit nicely with the desktop (rather that having their own completely different look-and-feel) it's hard to beat Gtk+ or Tkinter. Tkinter is still quite viable, especially if cross-plaform support is important. Some of the examples in Grayson's book are quite beautiful. It will be a long time until XPFE/XUL/whatchamacallit gets to this level of viability. Also consider that Sun (and HP?) now ship Gnome by default, rather than CDE (or so I hear, anyway). I predict that Gnome compatibility will become more and more of a desirable feature. Evidence of the above is the "Galeon" project. It's widely perceived that Mozilla has a nice rendering engine (Gecko) wrapped up in a dreadful GUI (XPFE). So the Galeon project places the Gecko engine inside a Gtk+/Gnome GUI, which provides a much more pleasant user experience. There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/ And, finally, IMO, the work being done on PyGtk is of high quality. I'm using it currently in production code. From DavidA@ActiveState.com Tue Oct 24 06:12:14 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: > There's also a (preliminary) port of Gtk+ to Win32: > http://www.gimp.org/~tml/gimp/win32/ FWIW, the last time I checked, this was useless. I'd be glad to be wrong, but I'm not holding my breath. Not surprisingly, the GTK crowd, which is rooted in Linux tradition (!), has little interest in Win32 ports, and even less experience in that world. Until that happens, a lot of platform-agnostic projects and vendors will have a hard time w/ GTK. I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included). --david From tim_one@email.msn.com Tue Oct 24 06:20:07 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:20:07 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: [ESR] > ... > and John Osterhout's attempt to commercialize the language have led to > a series of false starts and erratic moves. We don't want to criticize anyone for that: PythonLabs' attempts *not* to commercialize Python may yet make Tcl's path look as straight and true as a laser beam . obliquely y'rs - tim From tim_one@email.msn.com Tue Oct 24 06:31:07 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:31:07 -0400 Subject: [Python-Dev] Starship down ? In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> Message-ID: [MAL] > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! [GvR] > Yeah, this is very unfortunate. It's the same problem that's keeping > pytholabs.com down. The BeOpen systems staff is working on it, but I > don't know what the problem is or when it will be fixed. FYI, pythonlabs.com is up again, but Starship is still down. We only said it's the same problem because we didn't know what either problem was. And, we still don't! long-distance-ly y'rs - tim From cgw@fnal.gov Tue Oct 24 06:34:23 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov> David Ascher writes: >cgw> There's also a (preliminary) port of Gtk+ to Win32: >cgw> http://www.gimp.org/~tml/gimp/win32/ > > FWIW, the last time I checked, this was useless. That's what I meant by "preliminary" ;-) > I don't mean to diss GTK, just pointing out that cross-platform solutions > are important to a whole lot of communities (Python included). Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face. Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win, seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and they will just hate it. (Yes, this is based on observations of actual paying customers). I have a little bit of experience with cross-platform development - having used a lot of these tools - at my last job, after evaluating just about everything, we bought into (against my advice!) a doomed commercial product called Visix Galaxy (for which I immediately created a set of Python bindings). The problem with all of these things, of course, is that the more cross-platform they are, the more "lowest-common-denominator" they are forced to become. Tkinter, with widgets like Canvas, was really pretty amazing - for its day - feature-rich *and x-platform. But even this broke down if you started using fancy features like drawing with dashed lines - works on X, not on Windows (last time I checked, anyway) - the more you start pushing the limits of the toolkit, the more the portability breaks down. Tkinter-is-dead-long-live-Tkinter'ly yrs, -C From MarkH@ActiveState.com Tue Oct 24 06:48:34 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 16:48:34 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov> Message-ID: > Right. Cross-platform is very important, but so is native > look-and-feel, and this is where (IMO) XPFE falls flat on its face. Actually, my experience with XPFE from a look-and-feel POV has been pretty positive. It is true they have re-implemented most widgets rather than use native ones, and also true that you can make these widgets look nothing like native LAF - but generally, my experience with Mozilla and the "classic" skin is that it is close enough that it is very hard to tell. It looks more like "subtle enhancements", in the same way IE provides "subtle enhancements" > seems like it could be a real winner. If the x-platform GUI doesn't > use native dialog boxes and filechoosers, users REALLY notice this and Agreed. However, XPFE works fine here IMO. Again, I do not want to propose XPFE as viable today, and I agree it may never be viable. Most other critisisms posted are valid, but I don't think that LAF is one such problem with XPFE. Mark. From paul@prescod.net Tue Oct 24 07:29:42 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:29:42 -0700 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> Message-ID: <39F52C56.214B28A1@prescod.net> Fredrik Lundh wrote: > >... > > http://sourceforge.net/projects/tcl > http://sourceforge.net/projects/tktoolkit > > and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo > will rock ;-) Perhaps this could be an opportunity to split Tcl and Tk more cleanly. People like Fredrick and his Perl/Ruby/... equivalents could get more deeply involved in setting direction. It would be interesting to contrast the number of Tcl versus Tk users right now. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul@prescod.net Tue Oct 24 07:40:49 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:40:49 -0700 Subject: [Python-Dev] Gradual migration Message-ID: <39F52EF1.A201C6D9@prescod.net> Python 3K. It is the repository for our hopes and dreams. We tend to invoke it in three different situations: 1. in delaying discussions of gee-whiz features (e.g. static type checking) 2. in delaying hairy implementation re-factoring that we don't want to undertake right now. 3. in delaying painful backwards-compatibility breakage I think it is somewhat debatable whether we really need to or should do these three things all at once but that's a separate discussion for another day. (the other experiment may inform our decision) I want to focus on "3" -- breakage. Rather than delaying painful backwards-compatibility breakage I thing we should make it less painful. We should decide where we are going long before we ask our users to move there. I think we should start including alternatives to syntaxes and features that we know are broken. Once people move to the alternatives we can "reassign" or remove the original syntax with much less pain. In other words, rather than telling people "here's a new version, your code is broken, sorry." We should tell them: "we're going to break code. Here's an alternative syntax that you can use that will be interpreted the same in the old and new versions -- please move to this new syntax as quickly as possible." I'll outline some examples of the strategy. You may or may not like details of the particular proposals but you might still agree with the strategy. Also, I don't claim that all of the proposals are fully fleshed-out...again, it's the strategy I'm most interested in. I don't even agree with every feature change I describe below -- they are just some I've heard of for Python 3000. In other words ** this is not a design document for Python 3000! ** Separating byte arrays from strings: 1. immediately introduce two new functions: binopen("foo").read() -> byte array stropen("foo","UTF-8".read() -> u"...." 2. warn about string literals that have embedded non-Unicode characters 3. deprecate extension modules that return "old fashioned" string arrays 4. after a period where all strings have been restricted to Unicode-compatibility, merge the Unicode and string types. 5. deprecate the special Unicode u"" syntax as an imperialist anachronism Reclaiming the division operator from truncating integer division: 1. immediately introduce new functions: div() that does division as we wish it was. 2. add a warning mode to Python (long overdue) 3. with the warning mode on, old-fashioned division triggers a deprecation warning. 4. after three years as a warning situation we expect all in-use Python scripts to have been upgraded to use the new operations and to explicitly truncate integer division when that is what is wanted. 5. at that point we can re-assign the division operator to be a floating point division if we wish. Case insensitivity: 1. Warn whenever a module or class has two __dict__ entries that differ only by case 2. Eventually, disallow that form of name-clash altogether 3. After a period, allow case variations to be equivalent. Unifying types and classes (more vague): 1. Add something like extension class to make type subclassing easier. 2. Informally deprecate modules that do not incorporate it. 3. Replace or fix details of the language and implementation that behave differently for types and classes. (e.g. the type() operator) -- Paul Prescod - Not encumbered by ActiveState consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From pf@artcom-gmbh.de Tue Oct 24 08:47:03 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST) Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm" Message-ID: Hi, Paul Prescod wrote on python-dev@python.org: [...] > Reclaiming the division operator from truncating integer division: [...] Bruce Sherwood and David Scherer suggested a IMHO very clever solution to this particular problem in March/April this year. This thread was first posted to idle-dev and afterwards X-posted to python-dev: http://www.python.org/pipermail/idle-dev/2000-April/000138.html http://www.python.org/pipermail/idle-dev/2000-April/000140.html http://www.python.org/pipermail/python-dev/2000-April/010029.html Unfortunately I'm no native english speaker and have not enough time to make a Python-2.1 PEP from it. May be somebody else wants to go for it? I still believe, this was a very clever Python enhancement, which should be officially proposed. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal@lemburg.com Tue Oct 24 09:45:03 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 10:45:03 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <39F54C0F.25798309@lemburg.com> Paul Prescod wrote: > > Python 3K. It is the repository for our hopes and dreams. We tend to > invoke it in three different situations: > > 1. in delaying discussions of gee-whiz features (e.g. static type > checking) > > 2. in delaying hairy implementation re-factoring that we don't > want to undertake right now. > > 3. in delaying painful backwards-compatibility breakage > > I think it is somewhat debatable whether we really need to or should do > these three things all at once but that's a separate discussion for > another day. (the other experiment may inform our decision) I think will simply be a consequence of doing a complete rewrite of the interpreter for Py3K. AFAIR, the only truely feasable solution would be doing the rewrite in a widely portable subset of C++ and then managing classes at that level. Moving to a common and very low-level strategy for classes will allows us to put even the most basic types (strings and numbers) into an inheritence tree. Differences like the ones between Unicode and 8-bit strings would then flesh out as two different subclasses of a generic string type which again is based on a generic sequence type. The same could be done for dictionaries: special ones for just string keys, case insensitive lookups, etc. could all be subclasses of a generic mapping class. Dito for numbers (and division strategies). By following this principle there won't be all that much breakage, since the old functionality will still be around, only the defaults will have changed. Add to this pluggable compilers and ceval loops, plus a nice way of configuring the lot on a per-module basis and you're set. (Ok, it's a fluffy clouds image, but you get the picture ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Tue Oct 24 16:57:43 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 10:57:43 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200." <39F54C0F.25798309@lemburg.com> References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com> > Paul Prescod wrote: > > > > Python 3K. It is the repository for our hopes and dreams. We tend to > > invoke it in three different situations: > > > > 1. in delaying discussions of gee-whiz features (e.g. static type > > checking) > > > > 2. in delaying hairy implementation re-factoring that we don't > > want to undertake right now. > > > > 3. in delaying painful backwards-compatibility breakage > > > > I think it is somewhat debatable whether we really need to or should do > > these three things all at once but that's a separate discussion for > > another day. (the other experiment may inform our decision) Marc-Andre Lemburg replied: > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. > > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. > > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. > > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. > > Dito for numbers (and division strategies). > > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. > > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Good job in channeling me, Marc-Andre! I'm sure that's not exactly how it's going to be, but on the face of it, this sure sounds like a reasonable possible route. Do you want to be the author for PEP-3000? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Oct 24 17:13:37 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 11:13:37 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST." <39F52EF1.A201C6D9@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com> > I want to focus on "3" -- breakage. Rather than delaying painful > backwards-compatibility breakage I thing we should make it less painful. > We should decide where we are going long before we ask our users to move > there. I think we should start including alternatives to syntaxes and > features that we know are broken. Once people move to the alternatives > we can "reassign" or remove the original syntax with much less pain. Absolutely. Whenever possible, we should try to plan for migration in Python 2.x. > In other words, rather than telling people "here's a new version, your > code is broken, sorry." We should tell them: "we're going to break code. > Here's an alternative syntax that you can use that will be interpreted > the same in the old and new versions -- please move to this new syntax > as quickly as possible." It would also help if we could produce automatic translation tools that will convert the old syntax into the new. This desire may restrict our choices however: the translation tools don't have runtime information to go by. It's easy enough to change obsolete syntax into new syntax, but it's hard to decide whether a particular "/" operator should be changed into an integer divide ("//") or left alone. > I'll outline some examples of the strategy. You may or may not like > details of the particular proposals but you might still agree with the > strategy. Also, I don't claim that all of the proposals are fully > fleshed-out...again, it's the strategy I'm most interested in. I don't > even agree with every feature change I describe below -- they are just > some I've heard of for Python 3000. In other words ** this is not a > design document for Python 3000! ** I think the proper approach is to start a separate migration process for each of these proposed changes. Each should be paced separately (the pace may depend on how hard to swallow the change is for users as well as how hard it is to implement the new functionality) and for each, a separate PEP in the 3000 series should be started. I can even see that several PEPs will be needed in some cases (e.g. one to describe the new syntax, one to to flesh out the implementation, and one to decide on the migration steps). I won't comment on Paul's examples, that's for the various PEP processes. --Guido van Rossum (home page: http://www.python.org/~guido/) From cgw@fnal.gov Tue Oct 24 16:21:45 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.14407.954185.466011@buffalo.fnal.gov> Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov> Mark Hammond writes: > > > Agreed. However, XPFE works fine here IMO. > > > cgw> "Here" means on MS-Win, right? Maybe that's why our perceptions are > cgw> so different. > > Correct. Although I have run it under Linux a few times, I wouldnt really > know LAF issues if I tripped over them there ;-) > > Mark. It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not agree!) Gnome is gathering momentum, especially now that Sun has joined the Gnome Foundation. With outfits like Eazel, Helix Code, etc, turning out high-quality products, things are moving fast in the Gnome/Gtk+ world and it seems clear to me that this will be the major desktop platform for Unix machines in the upcoming decade. Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up. OK, enough off-topic rambling (for now), -C From akuchlin@mems-exchange.org Tue Oct 24 16:43:26 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 11:43:26 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote: >It's certainly true that the lack of a consistent look and feel for >Linux apps has been somewhat of a problem historically. However, with >the emergence of Gnome, it seems that there is finally some >convergence. (Althought people in the KDE/Qt camp will certainly not Careful... while people may try to port GTk+ to Windows, porting GNOME is a different kettle of wax, because GNOME needs GTk+ but also entails gnome-libs and gnome-vfs and Bonobo and esound and lots of other things, which provide services such as object embedding that wouldn't be required -- or would be very different -- on Windows. I don't know if anyone is trying to tease apart GNOME into a Windows-suitable subset; it seems like it would be a difficult task. Qt is at least a toolkit that aims at cross-platform portability, though there again, the KDE environment built on top of it is not going to be portable to anything that isn't Unix. Both the Qt and GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only real possibilities. This is why, every time this debate comes up, we end up sticking with Tk; it may suck, but all the other systems don't support everything... Maybe the best approach is to follow /F's lead with Tkinter3000, and reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that *is* what Tkinter3000 is, right?) What's the problem we're trying to solve here? * Is it that the problem that the Tkinter module is a bad API for GUI programming? * Or is it that the Tk implementation is slow or bulky? * Or do we just dislike having to require Tcl as well as Tk? Can someone articulate why Tk should be replaced? --amk From gvwilson@nevex.com Tue Oct 24 16:52:00 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > What's the problem we're trying to solve here? > > * Is it that the problem that the Tkinter module is a bad API for > GUI programming? > > * Or is it that the Tk implementation is slow or bulky? > > * Or do we just dislike having to require Tcl as well as Tk? > > Can someone articulate why Tk should be replaced? I can articulate why I'm unhappy with the current set-up: 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los Alamos before my first Python course cost me several hours, and I had to do it again two months' later. I've run into similar problems with multiple Tcl installations on Windows machines (personal use). 2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python). Performance doesn't really matter --- I've never had students complain about speed, although I've never asked them to build something large enough that refresh would be an issue. I don't have experience teaching wxPython, so I can't comment on the relative teachability of its API vs. Tk's. Hope this helps, Greg From paul@prescod.net Tue Oct 24 17:12:12 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:12:12 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <39F5B4DC.C226D8F6@prescod.net> "M.-A. Lemburg" wrote: > >... > > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. I disagree for a variety of reasons: * implementation language and Python inheritance semantics are almost completely distinct. After all, we have Python implementations in a variety of languages with minor incompatibilities. Python could have a proper type/class merging even if it were written in assembly language. So let's leave implementation language aside. * there is a hell of a lot we can do to make the type/class split less visible without a major rewrite. For instance, lists could have a __getitem__ method so that they "act like" instances. Instances could return their methods in a dir() so that they "act like" built-in objects. So there is no reason to wait for a complete rewrite to start on this path. * It may even be the case that we can get from here to complete merged type/class semantics WITHOUT a rewrite. If a mad genious had not written stackless Python I would have sworn up and down that stackless Python would require a Python rewrite. It didn't. If another slightly less mad genious had not integrated ints and longs I would never have believed it possible without another rewrite. Someone needs to do an analysis of what it takes to merge types and classes and *demonstrate* that it requires a rewrite rather than *asserting* that it requires a rewrite. In other words, let's stop sprinkling the "major rewrite" pixie dust on hard problems and instead decide where we want to go and how we want to get there! > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. I don't know what you mean by a "low-level strategy" for classes. It's not like we can somehow use C++ vtables without giving up Python's dynamicity. Python's class handling is about as low-level as it can get in my humble opinion. > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. Of course that's where we want to go but it doesn't avoid the backwards compatibility problems. We can do this today using proxying. > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. We can easily do this today. > Dito for numbers (and division strategies). There's no way I'm going to let you get away with that little sleight of hand. How is inheritance holy water going to allow us to change the semantics of: 5/2 without breaking code?? The same goes for a.b = 5 versus a.B = 5 C++ does not help. Inheritance does not help. Pluggable compilers do not help. We *will* break code. We just need to decide whether to do it in a thoughtful way that gives people a chance to migrate or put off decisions until the last possible moment and then spring it on them with no between-version upgrade path. > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. When you change defaults you break code. Keeping the old functionality around is barely helpful. Nobody has EVER proposed a change to Python where something that was previously possible is now made impossible. So whatever our strategy, the PROBLEM is changing defaults. The solution is telling people what defaults are changing in what timeline and discouraging them from depending on the old defaults. > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Sounds mythical. I'm trying to take it out of the realm of fluffy clouds and bring it into the world that people can plan their businesses and coding strategies around. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul@prescod.net Tue Oct 24 17:30:17 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:30:17 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> Message-ID: <39F5B919.4B80A526@prescod.net> Guido van Rossum wrote: > > ... > > I think the proper approach is to start a separate migration process > for each of these proposed changes. I agree. As a more concrete extension to my last email, I propose the following doctrine: """ No major documented feature should be removed or have changed semantics in Python 3000 or any other new version of Python until users have had a year (preferably MORE!) of upgrade time. Upgrade time entails the following parts: 1. the released Python version has a new recommended way to accomplish the task in a manner that will remain available in the "breakage version" e.g. a div() function that people can use for a few years while the semantics of "/" are in transition. 2. the mechanism/syntax that will be removed is formally deprecated. The documentation would say, e.g. "You should not use '/' for now. It is changing semantics in the future." 3. the released Python version sports a runtime warning to tell users that the mechanism/syntax is going away. "CompatibilityError: Future versions of Python will have different semantics for the '/' operator. Please use div() instead." The actual "right" amount of upgrade time depends on the extent of the breakage and its ease of detection. """ I can PEP this if people agree. I think that the user community would appreciate our effort to promise not to break code suddenly and capriciously. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry@wooz.org Tue Oct 24 17:26:13 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? References: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.47141.817450.488896@anthem.concentric.net> >>>>> "GW" == Greg Wilson writes: GW> 2. (Lack of) native look and feel. This is a complete GW> show-stopper for many of the outfits I've dealt with (and not GW> just with Python). On the other hand, it's incredibly easy to whip together a GUI in Tk for simple applications. Yes, Tk gets painful as applications grow, but I'd hate to abandon such a simple, well-known toolkit for a complicated, hard-to-learn but powerful native look-and-feel one. You don't /always/ care about strict native LAF. Or to restate: I'd hate to have to make that choice. If we can't satisfy both requirements (mandatory-native-LAF and rapid prototyping friendliness), we may need to continue to support multiple toolkits. the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs, -Barry From guido@python.org Tue Oct 24 18:39:38 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:39:38 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400." References: Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los > Alamos before my first Python course cost me several hours, and I had > to do it again two months' later. I've run into similar problems with > multiple Tcl installations on Windows machines (personal use). For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and install our own Tcl/Tk binaries, in a place that doesn't affect or require existing Tcl/Tk installations. Maybe we can do the same for Unix binary distributions? I believe Jeremy has already had to create a separate RPM for _tkinter because there are too many different versions of Tcl/Tk out there -- it shouldn't be hard to install our own altogether. > 2. (Lack of) native look and feel. This is a complete show-stopper for > many of the outfits I've dealt with (and not just with Python). Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much. Or are you saying that IDLE isn't designed as a typical Microsoft app? That's quite a separate issue from the widget look-and-feel! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@wooz.org Tue Oct 24 17:40:50 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <14837.48018.547379.464959@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> * implementation language and Python inheritance semantics PP> are almost completely distinct. After all, we have Python PP> implementations in a variety of languages with minor PP> incompatibilities. Python could have a proper type/class PP> merging even if it were written in assembly language. So PP> let's leave implementation language aside. Jython experience backs this up. It would be incredibly convenient if we could just map Java classes to Python classes, so that for example, we'd have in Java a PyException class that is exceptions.Exception with minimal or no Java wrappings. And Finn nearly did this. The problem that we ran into with Java is that it allows only single inheritance. So you couldn't create a Python exception that multiply inherited from two or more other Python exceptions. Doesn't happen often, but it does happen, so is that an acceptable tradeoff? C++ might be better in this particular respect, but there will be other issues, because as soon as you start transparently showing the implementation's classes into Python, you inherit their semantics and restrictions as well. Just saying that it's tricky. -Barry From guido@python.org Tue Oct 24 18:54:39 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:54:39 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST." <39F5B919.4B80A526@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> <39F5B919.4B80A526@prescod.net> Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com> > As a more concrete extension to my last email, I propose the following > doctrine: > > """ > No major documented feature should be removed or have changed semantics > in Python 3000 or any other new version of Python until users have had a > year (preferably MORE!) of upgrade time. Upgrade time entails the > following parts: > > 1. the released Python version has a new recommended way to > accomplish the task in a manner that will remain available in the > "breakage version" e.g. a div() function that people can use for a few > years while the semantics of "/" are in transition. > > 2. the mechanism/syntax that will be removed is formally deprecated. > The documentation would say, e.g. "You should not use '/' for now. It is > changing semantics in the future." > > 3. the released Python version sports a runtime warning to tell > users that the mechanism/syntax is going away. "CompatibilityError: > Future versions of Python will have different semantics for the '/' > operator. Please use div() instead." > > The actual "right" amount of upgrade time depends on the extent of the > breakage and its ease of detection. > """ > > I can PEP this if people agree. I think that the user community would > appreciate our effort to promise not to break code suddenly and > capriciously. Go for it. I have little bandwidth to think about this deeply, but what you're proposing here sounds like a good approach. Certainly it will make it easier if I can point to this PEP when I get the next FUD email about "should I bother to learn Python 2.0 when Py3K is going to be all different?"... --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot@telia.com Tue Oct 24 18:07:12 2000 From: effbot@telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 19:07:12 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid> paul wrote: > Perhaps this could be an opportunity to split Tcl and Tk more cleanly. > People like Fredrick and his Perl/Ruby/... equivalents could get more > deeply involved in setting direction. I'm waiting for the Tcl/Tk developers to grow up -- they still fear that any attempt to make it easier to use Tk from other languages would be to "give up the crown jewels" :-( From effbot@telia.com Tue Oct 24 17:59:23 2000 From: effbot@telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 18:59:23 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid> andrew wrote: > Maybe the best approach is to follow /F's lead with Tkinter3000, and > reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that > *is* what Tkinter3000 is, right?) nope -- at least not initially. the first two steps are a new Tk glue layer, and an extension API that allows you to write new widgets in pure Python. also see: http://w1.132.telia.com/~u13208596/tkinter/index.htm ::: I have plans for how to take the Tkinter API *and* the new extension API beyond Tk, but let's save that for another day... ::: > Can someone articulate why Tk should be replaced? beats me ;-) From cgw@fnal.gov Tue Oct 24 17:54:35 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov> Andrew Kuchling writes: > > Careful... while people may try to port GTk+ to Windows, porting GNOME > is a different kettle of wax, because GNOME needs GTk+ but also > entails gnome-libs But I was never seriously advocating Gtk+ on Windows. This was just a footnote. I shouldn't have even mentioned the Windows Gtk+ port because it just muddied the water. The major point I was trying to make is that toolkits like Tkinter and WxWindows, which try to delegate to the native widget sets whenever possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which reimpliment all the widgets from scratch, are doomed to fail. (IMO, of course). What I believe we need is a suitable abstraction which uses MFC on MS-Win platforms and Gtk+ on Unix. And which also doesn't, due to the abstraction, take away too many features. I don't know that much about MFC, but for a simple example - Gtk+ offers an option for its canvas widget to do all drawing in antialised mode (by the way, this is slow but produces very nice looking results). It would be a shame if the abstraction layer didn't allow for things like this to be used. > This is why, every time this debate comes up, we > end up sticking with Tk; it may suck, but all the other systems don't > support everything... Right. FWIW, in my day-to-day work, if it has to run on MS-Win I use Tkinter, and if MS-Win is not an issue I use PyGtk. Fermilab will be showing some network monitoring software at the Supercomputing 2000 conference next month, and it's mostly all stuff I whipped up a few days using Tkinter. From gmcm@hypernet.com Tue Oct 24 18:14:42 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 13:14:42 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F58B42.26855.490B8F73@localhost> Paul Prescod wrote: ... > .... It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. But that's exactly what COM does. not-to-be-taken-as-an-endorsement-ly y'rs - Gordon From akuchlin@mems-exchange.org Tue Oct 24 18:15:14 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 13:15:14 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid> Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote: >I'm waiting for the Tcl/Tk developers to grow up -- they still >fear that any attempt to make it easier to use Tk from other >languages would be to "give up the crown jewels" :-( In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. --amk From gvwilson@nevex.com Tue Oct 24 18:58:59 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson: > > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. > Guido van Rossum: > For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and > install our own Tcl/Tk binaries OK. > > Greg Wilson: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > Guido van Rossum: > Really? Are you sure that's not just general resistence against new things? Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development. Thanks, Greg From guido@python.org Tue Oct 24 20:04:55 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 14:04:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400." References: Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> > Well, my students' resistance to novelty is low enough that they're > willing to take a Python course :-). This comes up every time I > teach; no idea whether it has any impact on the usability of > completed applications, but I believe it makes people less likely to > choose Tkinter when starting development. Can you elaborate on the line of argument that you typically hear? What do you say to dispel it? --Guido van Rossum (home page: http://www.python.org/~guido/) From nas@arctrix.com Tue Oct 24 12:56:11 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 04:56:11 -0700 Subject: [Python-Dev] A small step to removing the type/class split Message-ID: <20001024045611.B9993@glacier.fnational.com> I've run into a problem with ExtensionClass which I believe can only be fixed by modifying Python. I will try to explain. I have an ExtensionClass which defines __cmp__. Depending on the objects being compared, the __cmp__ method may never be called. This is due to code in object.c that looks like this: if (PyInstance_Check(v) || PyInstance_Check(w)) { try to use use __cmp__ method } else { try number coerce and fall back on type name comparison } Extension classes can never pass the PyInstance_Check predicate. I've searched for all occurances of PyInstance_Check in the 2.0 source. In many places that PyInstance_Check occurs a more general "is this an instance-like type" check would seem to be more suitable. Here is my proposal: * Define a new type flag Py_TPFLAGS_INSTANCE. * Create a new predicate Py_IsInstance which checks for this flag. * Set this flag on PyInstance_Type. * Replace most occurances of PyInstance_Check with Py_IsInstance. Extension types (like ExtensionClass) can then define the type flag Py_TPLAGS_INSTANCE and be treated as an instance type by the Python interpreter. This should make it quite a bit easier to make extension types behave like "real" classes. Comments? Neil From mal@lemburg.com Tue Oct 24 20:37:30 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:37:30 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F5E4FA.9FD6D35@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > >... > > > > I think will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. AFAIR, the only truely feasable > > solution would be doing the rewrite in a widely portable > > subset of C++ and then managing classes at that level. > > I disagree for a variety of reasons: > > * implementation language and Python inheritance semantics are almost > completely distinct. After all, we have Python implementations in a > variety of languages with minor incompatibilities. Python could have a > proper type/class merging even if it were written in assembly language. > So let's leave implementation language aside. Hey, think of it as opportunity: we can reuse much of C++'s optimizations and the integration of Python and C++ applications will get *much* easier. A rewrite shouldn't scare anyone away -- much of the existing code can be reused since only the Python C APIs of the various types will have to be rewritten, not the logic behind the types. Besides, Py3K will be a project which runs in parallel to the 2.x development (at least that's what I've read on some BeOpen webpage), so there's really not much to worry about wrt to breakage, etc. People will be able to test-drive Py3K while using the 2.x series. > * there is a hell of a lot we can do to make the type/class split less > visible without a major rewrite. For instance, lists could have a > __getitem__ method so that they "act like" instances. Instances could > return their methods in a dir() so that they "act like" built-in > objects. So there is no reason to wait for a complete rewrite to start > on this path. Right. I didn't want to say that things cannot be done prior to the rewrite, only that a rewrite will give us much more options that we currently have. > * It may even be the case that we can get from here to complete merged > type/class semantics WITHOUT a rewrite. If a mad genious had not written > stackless Python I would have sworn up and down that stackless Python > would require a Python rewrite. It didn't. If another slightly less mad > genious had not integrated ints and longs I would never have believed it > possible without another rewrite. Someone needs to do an analysis of > what it takes to merge types and classes and *demonstrate* that it > requires a rewrite rather than *asserting* that it requires a rewrite. > > In other words, let's stop sprinkling the "major rewrite" pixie dust on > hard problems and instead decide where we want to go and how we want to > get there! See above. > > Moving to a common and very low-level strategy for classes > > will allows us to put even the most basic types (strings and > > numbers) into an inheritence tree. > > I don't know what you mean by a "low-level strategy" for classes. It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. Python's class handling is about as low-level as it can get > in my humble opinion. With "low-level" I meant trying to build Python classes and instances on top of a very thin layer on top of C++ classes, e.g. all slots could be implemented using true C++ methods with additional logic to override them using dynamically bound Python method objects. > > Differences like the > > ones between Unicode and 8-bit strings would then flesh > > out as two different subclasses of a generic string type which > > again is based on a generic sequence type. > > Of course that's where we want to go but it doesn't avoid the backwards > compatibility problems. Huh ? I was talking about clear design... not ways to avoid b/w compatibility. Merging Unicode and strings will hurt one way or another. This is simply a consequence of using strings as binary containers where Unicode is meant for text only use. > We can do this today using proxying. Could you explain this ? > > The same could be done for dictionaries: special ones for > > just string keys, case insensitive lookups, etc. could all > > be subclasses of a generic mapping class. > > We can easily do this today. No we can't: Python's use of pointer compares to find out which type it is dealing with prevent this. > > Dito for numbers (and division strategies). > > There's no way I'm going to let you get away with that little sleight of > hand. How is inheritance holy water going to allow us to change the > semantics of: > > 5/2 > > without breaking code?? > > The same goes for > > a.b = 5 > > versus > > a.B = 5 > > C++ does not help. Inheritance does not help. Pluggable compilers do not > help. We *will* break code. We just need to decide whether to do it in a > thoughtful way that gives people a chance to migrate or put off > decisions until the last possible moment and then spring it on them with > no between-version upgrade path. Just tell Python to use the correct class for what the code was written for (and this could be done by plugging in a 2.0 compiler). The instances of those classes would still work together with other semantics by virtue of exposing the same interface, yet the internals would work differently, e.g. a module using case insensitive lookup would be compiled using case insensitive dictionaries as namespaces. > > By following this principle there won't be all that much > > breakage, since the old functionality will still be around, > > only the defaults will have changed. > > When you change defaults you break code. Keeping the old functionality > around is barely helpful. Nobody has EVER proposed a change to Python > where something that was previously possible is now made impossible. So > whatever our strategy, the PROBLEM is changing defaults. The solution is > telling people what defaults are changing in what timeline and > discouraging them from depending on the old defaults. All true. I was just referring to the possibility of keeping the old semantics around in case some module relies on them. In this ideal world, a simple "define pythonlevel=2.0" would suffice to make the old module work with Py3k. > > Add to this pluggable compilers and ceval loops, plus a nice > > way of configuring the lot on a per-module basis and you're > > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) > > Sounds mythical. I'm trying to take it out of the realm of fluffy clouds > and bring it into the world that people can plan their businesses and > coding strategies around. Hmm, wasn't Py3k meant as sandbox for new experiments ? The 2.x series is for doing business with, IMHO at least. At the current dev speed we'll have plenty of time to get Py3k rock solid. Then we can add all the backward compatibility layers we want to it. If the design is a good, adding these layers won't pose much of a problem. Why spoil all the fun when we haven't even started thinking about all the possibilities we could use to make Py3k a success ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Oct 24 20:54:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:54:39 +0200 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F5E8FF.5F18C71E@lemburg.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Sounds fine, except that the "isinstance()" behaviour would have to be defined somewhere / somehow... a mapping of slots to __special_methods__ would be a good start. BTW, mxProxy does some of this mapping already... you may want to have a look. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm@hypernet.com Tue Oct 24 21:01:25 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 16:01:25 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F5B255.22108.49A43169@localhost> Greg Wilson: > > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > > many of the outfits I've dealt with (and not just with Python). > > > Guido van Rossum: > > Really? Are you sure that's not just general resistence against new things? > > Well, my students' resistance to novelty is low enough that they're willing to > take a Python course :-). This comes up every time I teach; no idea whether it > has any impact on the usability of completed applications, but I believe it > makes people less likely to choose Tkinter when starting development. As I see it, Tk, like SQL, has the property that it's dead easy to get something crappy running, but it takes a real expert (like /F) to make it good. With wxPython, though, it's easy (if somewhat tedious) to get something good - at least as far as normal "forms" style GUIs. I'm not taking sides - I dabble in both and will never be an expert at either. But for clients using Windows, I use wxPython because it's indistinguishable from native Win32. (BTW, MFC is lagging further and further behind native Win32 - I believe MS considers it "legacy".) - Gordon From barry@wooz.org Tue Oct 24 21:06:23 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT) Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <14837.60351.887533.801888@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> I've run into a problem with ExtensionClass which I believe NS> can only be fixed by modifying Python. I will try to explain. NS> I have an ExtensionClass which defines __cmp__. Depending on NS> the objects being compared, the __cmp__ method may never be NS> called. This is due to code in object.c that looks like this: | if (PyInstance_Check(v) || PyInstance_Check(w)) { | try to use use __cmp__ method | } | else { | try number coerce and fall back on type name comparison | } I hit a similar wall when I tried (a long time ago) to take a boolean class I'd written in Python and make it a built-in type. The problem was that in Python I could compare a Boolean instance against any other object for truth equivalence, but because of this hack, I couldn't do the same with the built-in type. | * Define a new type flag Py_TPFLAGS_INSTANCE. | * Create a new predicate Py_IsInstance which checks for this | flag. | * Set this flag on PyInstance_Type. | * Replace most occurances of PyInstance_Check with | Py_IsInstance. NS> Extension types (like ExtensionClass) can then define the type NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by NS> the Python interpreter. This should make it quite a bit NS> easier to make extension types behave like "real" classes. I'm not sure how well this addresses what I ran into. Would PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set? Does that actually make sense? How does this interact with the rich comparisons idea? Seems like this is a hack that doesn't quite get at the heart of the matter, worthwhile as it may be given the current implementation. -Barry From barry@wooz.org Tue Oct 24 21:11:54 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] getting at the current frame Message-ID: <14837.60682.437334.797392@anthem.concentric.net> I've been playing around with ideas for internationalizing Mailman, which naturally leads to string interpolation. To see why, think about making the following code translatable: def trade(yours, mine): print 'if you give me %s, i will give you %s' % (yours, mine) Because the order of the interpolated values may change in the translated string, you really have to do something like: def trade(yours, mine): print 'if you give me %(yours)s, i will give you %(mine)s' % { 'yours': yours, 'mine' : mine, } which actually will look something like this in real code: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % { 'yours': yours, 'mine' : mine, } The string wrapped in _() is what gets translated here. Okay, we all know that's a pain, right? Lots of people have proposed solutions. I've looked briefly at !?ng's Itpl.py, but I think it probably does too much by adding evaluation. I can define _() to make the problem somewhat more convenient: def _(s): try: raise Exception except Exception: frame = sys.exc_info()[2].tb_frame.f_back d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d Now I can write the code like this: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') All well and good and doable in Python today, except getting the current frame with the exception raising trick is slooow. A simple proposed addition to the sys module can improve the performance by about 8x: def _(s): frame = sys.getcaller(1) d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d The implementation of sys.getcaller() is given in the below patch. Comments? I think this particular addition is too small for a PEP, although ?!ng still owns PEP 215 (which needs filling in). -Barry -------------------- snip snip -------------------- Index: sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.78 diff -u -r2.78 sysmodule.c --- sysmodule.c 2000/09/01 23:29:28 2.78 +++ sysmodule.c 2000/10/24 17:50:30 @@ -15,6 +15,8 @@ */ #include "Python.h" +#include "compile.h" +#include "frameobject.h" #include "osdefs.h" @@ -284,6 +286,38 @@ } #endif +static char getcaller_doc[] = +"getcaller([depth]) -> frameobject\n\ +\n\ +By default, return the frame object at the top of the call stack. If an\n\ +integer depth is given, return the frame object that many calls below the\n\ +top of the stack. If that is deeper than the call stack, a ValueError is\n\ +raised."; + + +static PyObject * +sys_getcaller(PyObject *self, PyObject *args) +{ + PyFrameObject *f = PyThreadState_Get()->frame; + int depth = -1; + + if (!PyArg_ParseTuple(args, "|i:getcaller", &depth)) + return NULL; + + while (depth > 0 && f != NULL) { + f = f->f_back; + --depth; + } + if (f == NULL) { + PyErr_SetString(PyExc_ValueError, + "call stack is not deep enough"); + return NULL; + } + Py_INCREF(f); + return (PyObject*)f; +} + + #ifdef Py_TRACE_REFS /* Defined in objects.c because it uses static globals if that file */ extern PyObject *_Py_GetObjects(PyObject *, PyObject *); @@ -313,6 +347,7 @@ {"getrefcount", sys_getrefcount, 1, getrefcount_doc}, {"getrecursionlimit", sys_getrecursionlimit, 1, getrecursionlimit_doc}, + {"getcaller", sys_getcaller, 1, getcaller_doc}, #ifdef USE_MALLOPT {"mdebug", sys_mdebug, 1}, #endif From nas@arctrix.com Tue Oct 24 14:45:35 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 06:45:35 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400 References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net> Message-ID: <20001024064535.A10253@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote: [on Py_TPLAGS_INSTANCE] > I'm not sure how well this addresses what I ran into [with a > boolean extension type]. Would PyBooleanObject then have to > have it's Py_TPFLAGS_INSTANCE flag set? Does that actually > make sense? I think it would address your problem but I don't know if the name of the flag makes sense. Code around PyInstance_Check() usually looks like this: if (PyInstance_Check(obj)) { PyObject *foo = PyObject_GetAttrString(obj, "__foo__"); ... } else { ... } There is not a lot of code that assumes (obj->ob_type == PyInstance_Type) after a PyInstance_Check(). That's encouraging. > How does this interact with the rich comparisons idea? I don't know. I think I am trying to a address a deeper problem here. > Seems like this is a hack that doesn't quite get at the heart > of the matter, worthwhile as it may be given the current > implementation. Yes, I have that feeling as well. More deep thinking is probably required. :) Neil From mal@lemburg.com Tue Oct 24 21:45:28 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 22:45:28 +0200 Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <39F5F4E8.1188E1E0@lemburg.com> "Barry A. Warsaw" wrote: > [...] > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. I have a similar function in mxTools. I would use a different name though... something like "sys.getframe()". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Tue Oct 24 22:50:32 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 16:50:32 -0500 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST." <20001024045611.B9993@glacier.fnational.com> References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com> > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Good analysis of a problem -- but I disagree on the solution. Rather than formalizing the exceptions made for instances, we should work on eradicating the differences between classes and types. I believe that the plans for rich comparisons would or could also take care of this. I hope I'll have more time soon to explore this. --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@wooz.org Tue Oct 24 21:49:04 2000 From: barry@wooz.org (barry@wooz.org) Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <39F5F4E8.1188E1E0@lemburg.com> Message-ID: <14837.62912.897422.392307@anthem.concentric.net> >>>>> "M" == M writes: M> I have a similar function in mxTools. I would use a different M> name though... something like "sys.getframe()". Works for me. Thanks, -Barry From guido@python.org Tue Oct 24 23:16:00 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 17:16:00 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400." <14837.63819.667508.794728@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com> > GvR> Agreed. I think it's good to have the functionality > GvR> available, but it's also good to make it *real* clear not to > GvR> mess with it unless you really know what you're doing. Maybe > GvR> it should be in a separate module or at least have a leading > GvR> _underscore. > > I think you're fairly safe from mischief since the only writable > attributes of a frame object are f_trace, f_exc_type, f_exc_value, and > f_exc_traceback. The same caveats about f_globals and f_locals apply > as with the dicts returned by locals() and globals(). It's not so much that it's easy to do damage with. I have a philosophical problem with making this a feature that people can use whenever they feel like. It's a messy feature and its use should limited as an implementation aid for language features like variable substitution. The other, perhaps more major, problem with this it is that you can't easily wrap functions that use it in other functions. Normally, if there's a function foo(arg) that does something, I can write a function wrapfoo(arg) that does something else, then calls foo(arg), and then does another thing. But if foo() uses getframe(), that's not so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame. A way around this would be to implement foo as a call to (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()). Then _wrapfoo(arg, frame) could be defined as a wrapper around _foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()). This is another reason to be very selective in the use of getframe(). --Guido van Rossum (home page: http://www.python.org/~guido/) From nas@arctrix.com Tue Oct 24 15:37:12 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 07:37:12 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500 References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <20001024073712.A10539@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote: > Rather than formalizing the exceptions made for instances, we > should work on eradicating the differences between classes and > types. Yes, I see this now. Those PyInstance_Check() calls should really go away. Instead, the type should be responsible for providing different behavior. > I believe that the plans for rich comparisons would or could > also take care of this. I've just briefly looked at the proposal. It consists of two parts. One is splitting __cmp__ into __gt__, __lt__, etc. That is a separate issue to the one we are dicussing. The other part is directly related. In order for types to define their own comparison behavior, it proposes that types have an optional pointer to a rich comparison function in the type structure. I think this is the right idea but it doesn't go far enough. Every operation should be implementable by the type. Code like: if (PyString_Check(obj)) { something } else if (PyInstance_Check(obj)) { something else } ... should disappear unless it is need for performance reasons. I think we are close to achieving this goal. I'll try to come up with a proposal. Neil From barry@wooz.org Tue Oct 24 22:34:54 2000 From: barry@wooz.org (barry@wooz.org) Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> Message-ID: <14838.126.77589.541148@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> The other, perhaps more major, problem with this it is that GvR> you can't easily wrap functions that use it in other GvR> functions. Normally, if there's a function foo(arg) that GvR> does something, I can write a function wrapfoo(arg) that does GvR> something else, then calls foo(arg), and then does another GvR> thing. But if foo() uses getframe(), that's not so easy: the GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame. GvR> A way around this would be to implement foo as a call to GvR> (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, GvR> sys.getframe()). Then _wrapfoo(arg, frame) could be defined GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as GvR> _wrapfoo(arg, sys.getframe()). Darn good point. So where could we put it? It's a useful introspection device. If it goes in a separate module, should that perhaps be called `reflection'? Or maybe `runtime'? Or maybe "sys._getframe()" is good enough. -Barry From guido@python.org Wed Oct 25 00:13:43 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 18:13:43 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400." <14838.126.77589.541148@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com> > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. sys._getframe() is good enough. --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA@ActiveState.com Wed Oct 25 00:08:28 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: > Back in my former life, when I was still worrying about Windows, the > company I worked for bought into a commerical x-platform GUI toolkit > called Galaxy (I mentioned this earlier). Galaxy re-implemented all > the native widgets, kind of like XPFE does. One issue with this was > that MS seemed to change something about the widgets in every release > - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came > out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, > Win98 came out. Now I hear there's something called Windows ME. Have > they changed the look-and-feel again? Seems to me like all the > widget-reimplementors are doomed to playing eternal catch-up. Back in a former life of _mine_, I was one of two people who understood the architecture of Neuron Data's Open Interface Toolkit. It used the same strategy. Not sure what that has to do with Python, though it was a very fun project. It was also fun to turn on the Mac 'theme' on a Decwindows box (we're talking 1989 or so =). The funniest story about that job involves Cray and black and white monitors, but that's a story for another time, another place. --da From greg@cosc.canterbury.ac.nz Wed Oct 25 00:18:59 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT) Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Andrew Kuchling : > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. It appears that we can't rely on anyone else to provide and support a GUI properly across all three platforms. If we want one, it looks like we'll have to do it ourselves. How about reviving and building upon stdwin? I quite liked stdwin, despite its limitations, because it was small and simple, and it worked on both Mac and Unix. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From est@hyperreal.org Tue Oct 24 22:58:43 2000 From: est@hyperreal.org (est@hyperreal.org) Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT) Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org" at "Oct 24, 2000 05:34:54 pm" Message-ID: <20001024215843.7507.qmail@hyperreal.org> barry@wooz.org discourseth: > > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. Hmm..I'd think `reification' instead of `reflection'. My understanding was that reification involves taking an implicit language entity and making it an expressed value (e.g., getframe() or call_with_current_continuation()) while reflection goes in the opposite direction (e.g., eval()). pedantically, e From greg@cosc.canterbury.ac.nz Wed Oct 25 02:14:52 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT) Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <20001024073712.A10539@glacier.fnational.com> Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Neil Schemenauer : > Those PyInstance_Check() calls should really go away. Instead, the > type should be responsible for providing different behavior. Yes, that's the crux of the problem, I think. Another place where this is a nuisance is where it assumes that if x has any tp_as_sequence slots and y has any tp_as_number slots, then x*y is a sequence replication operation. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From esr@thyrsus.com Wed Oct 25 05:56:27 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 21:56:27 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid> Message-ID: <20001024215627.B1147@thyrsus.com> Fredrik Lundh : > > Can someone articulate why Tk should be replaced? > > beats me ;-) My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become effectively unmaintained in the foreseeable future. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr@thyrsus.com Wed Oct 25 06:29:17 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 22:29:17 -0700 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300 References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Message-ID: <20001024222917.I1147@thyrsus.com> Greg Ewing : > It appears that we can't rely on anyone else to provide and > support a GUI properly across all three platforms. If we > want one, it looks like we'll have to do it ourselves. I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance. -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From barry@wooz.org Wed Oct 25 04:11:54 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> Message-ID: <14838.20346.451094.231019@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. Cool, I'll upload the patch to SF. -Barry From barry@wooz.org Wed Oct 25 04:44:10 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> <14838.20346.451094.231019@anthem.concentric.net> Message-ID: <14838.22282.676715.200546@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. BAW> Cool, I'll upload the patch to SF. Patch #102106 http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 (includes doc patch) -Barry From tim_one@email.msn.com Wed Oct 25 08:10:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 03:10:36 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F54C0F.25798309@lemburg.com> Message-ID: [MAL] > ... > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. Not just to be my usual self , but I do see a from-scratch rewrite as being less likely as the years go by. There's nothing I know of in Guido's plans that can't be done incrementally instead -- and if he doesn't either, selling a total- rewrite project to an employer is probably impossible. The most successful projects I've seen and been on *did* rewrite all the code routinely, but one subsystem at a time. This happens when you're tempted to add a hack, realize it wouldn't be needed if an entire area were reworked, and mgmt is bright enough to realize that hacks compound in fatal ways over time. The "ain't broke, don't fix" philosophy is a good guide here, provided you've got a very low threshold for insisting "it's broke" <0.4 wink>. if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means- *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs - tim From Moshe Zadka Wed Oct 25 08:49:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 24 Oct 2000, Guido van Rossum wrote: > Maybe we can do the same for Unix binary distributions? I don't know what you mean by "UNIX" binary distributions: each UNIX has its own sets of horrors in the distribution arena. Personally, I don't care what we do about RPMs, since I'm not a Red Hat user. However, this should probably be more Red Hat's job then ours. Debian, on the other hand, would probably do this much better then Python-Dev can, without gratutitous Tcl/Tk installations. For other unices, most people install from sources anyway, which mostly means I should get off my butt and start working on the Sumo interpreter. > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. I don't know how to break this to you, but you're not the average computer user . -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal@lemburg.com Wed Oct 25 09:10:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Oct 2000 10:10:46 +0200 Subject: [Python-Dev] Gradual migration References: Message-ID: <39F69586.E017DA7E@lemburg.com> Tim Peters wrote: > > [MAL] > > ... > > I think this will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. > > Not just to be my usual self , but I do see a from-scratch rewrite as > being less likely as the years go by. There's nothing I know of in Guido's > plans that can't be done incrementally instead -- and if he doesn't either, > selling a total- rewrite project to an employer is probably impossible. > > The most successful projects I've seen and been on *did* rewrite all the > code routinely, but one subsystem at a time. This happens when you're > tempted to add a hack, realize it wouldn't be needed if an entire area were > reworked, and mgmt is bright enough to realize that hacks compound in fatal > ways over time. The "ain't broke, don't fix" philosophy is a good guide > here, provided you've got a very low threshold for insisting "it's broke" > <0.4 wink>. As I mentioned in the posting, the idea was from the "fluffy clouds" area. The rewrite would only involve the core type system and perhaps the core interpreter layout (parser, compiler, etc. all wrapped in classes) -- most of the existing code would be reusable. The idea behind this is somewhat like what you do when starting out a project based on a few simple functions and then reorganizing the code into a class-based approach. There's no need to rewrite all the type internals, just the type interfaces. Python has long reached a level of complexity that is counter- productive when it comes to adding new extension types. Just think of all the problems people have with coercion, the integration of user defined and internal types, the missing links between types and classes, etc. etc. BTW, why all the talk about "employers" ? Much of Python's code base was written without any employer knowing about it ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim@interet.com Wed Oct 25 11:40:56 2000 From: jim@interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:40:56 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <39F6B8B8.E3242929@interet.com> Andrew Kuchling wrote: > Can someone articulate why Tk should be replaced? I don't know whether Tk should replaced, but I can explain why I don't use it for our commercial Python application. It is just too big and complicated. Windows comes with a built-in GUI, and I hesitate to install another scripting language (Tcl) and its libraries, and then install a big system which has frequently been out of phase with Python releases just to access the Windows GUI. What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks. JimA From jim@interet.com Wed Oct 25 11:47:05 2000 From: jim@interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:47:05 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F6BA29.3CAB4C0E@interet.com> Guido van Rossum wrote: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. In the past I have resolutely demanded native Windows look and feel in my apps. In fact, I have been tiresome on the topic. Now I am changing my mind. Lots of prominent Windows apps now depart from Microsoft LAF, and I have the impression that users are getting used to it. I still think the usual File menu items and file open/save dialogs should be standard, but I am less concerned about other controls. For a look at how to really do controls, check out software for kids. Just my 1.e-2$. JimA From guido@python.org Wed Oct 25 13:11:35 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:11:35 -0500 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST." <20001024222917.I1147@thyrsus.com> References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> <20001024222917.I1147@thyrsus.com> Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com> > Greg Ewing : > > It appears that we can't rely on anyone else to provide and > > support a GUI properly across all three platforms. If we > > want one, it looks like we'll have to do it ourselves. Eric Raymond: > I fear this is much too big a job to be practical -- not just in the > additional code but the downstream maintainance. Well said. The "roll your own" approach has been attempted before, but simply isn't worth the time and effort. After all, Python is a glue language! (And stdwin would really look pathetic in this time.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Oct 25 13:25:29 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:25:29 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400." <39F6B8B8.E3242929@interet.com> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> > Andrew Kuchling wrote: > > > Can someone articulate why Tk should be replaced? Jim Ahlstrom replied: > I don't know whether Tk should replaced, but I > can explain why I don't use it for our commercial > Python application. > > It is just too big and complicated. Windows comes > with a built-in GUI, and I hesitate to install > another scripting language (Tcl) and its libraries, > and then install a big system which has frequently been > out of phase with Python releases just to access the > Windows GUI. To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers. > What if a user calls with a problem? Why should I > have to debug their Tcl library path problems? No > thanks. The Tcl library paths are all taken care of by the new installer strategy. Really, give it a try. It Just Works! (SM) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Oct 25 13:27:28 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:27:28 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400." <39F6BA29.3CAB4C0E@interet.com> References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com> > In the past I have resolutely demanded native Windows look > and feel in my apps. In fact, I have been tiresome on the topic. > > Now I am changing my mind. Lots of prominent Windows apps now > depart from Microsoft LAF, and I have the impression that users > are getting used to it. I still think the usual File menu > items and file open/save dialogs should be standard, but I > am less concerned about other controls. For a look > at how to really do controls, check out software for > kids. Just my 1.e-2$. Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player? --Guido van Rossum (home page: http://www.python.org/~guido/) From jim@digicool.com Wed Oct 25 13:21:41 2000 From: jim@digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:21:41 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <39F6D055.584C4FEA@digicool.com> Guido van Rossum wrote: > (snip) > Rather than formalizing the exceptions made for instances, we should > work on eradicating the differences between classes and types. Yee ha! I couldn't agree more. :) > I believe that the plans for rich comparisons would or could also take > care of this. I assume that rich comparison's have new slots with signatures that don't assume objects of the same type. > I hope I'll have more time soon to explore this. Me too. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jim@digicool.com Wed Oct 25 13:25:53 2000 From: jim@digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:25:53 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F6D151.70F47CFF@digicool.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: (snip) I think you got some good answers later in the thread. I'll point out that a work around is to make your ExtensionClass a numeric type. Numeric types have different comparison semantics that allow you to get around this limitation. I did this a few months back for acquisition wrappers. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From gvwilson@nevex.com Wed Oct 25 13:38:12 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> Message-ID: > Guido van Rossum: > Can you elaborate on the line of argument that you typically hear > [objections to Tkinter]? What do you say to dispel it? From some feedback forms from old runs of my Python course (with spelling corrections :-) 1. "My users don't care what programs are written in. They just care if they're easy to use. They won't care if Python programs have the same look and feel on different computers, because they won't ever think of [name of program] as a Python program. To them, it will be a Windows program that looks funny." 2. "You said three times in the intro lecture this morning that the most important thing in a GUI was consistency. Then you told us to write GUIs that look different from everything else on the desktop." 3. "I'm confused: I didn't realize that Python was a library on top of TCL." I spent a minute drawing blob diagrams to answer #3; I think most students understood, but the person who asked the question was clearly still confused. I didn't try to dispel #1 or #2, because I agree with them: my experience is that consistent look and feel are crucial for making non-programmers less afraid of pressing the wrong button or making the program "do weird things". Other people with more experience creating end-user applications may have different views. Thanks, Greg From guido@python.org Wed Oct 25 14:53:48 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 08:53:48 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400." References: Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> > From some feedback forms from old runs of my Python course (with spelling > corrections :-) > > 1. "My users don't care what programs are written in. They just care > if they're easy to use. They won't care if Python programs have > the same look and feel on different computers, because they won't > ever think of [name of program] as a Python program. To them, it > will be a Windows program that looks funny." > > 2. "You said three times in the intro lecture this morning that the > most important thing in a GUI was consistency. Then you told us to > write GUIs that look different from everything else on the desktop." > > 3. "I'm confused: I didn't realize that Python was a library on top of > TCL." > > I spent a minute drawing blob diagrams to answer #3; I think most students > understood, but the person who asked the question was clearly still confused. > > I didn't try to dispel #1 or #2, because I agree with them: my > experience is that consistent look and feel are crucial for making > non-programmers less afraid of pressing the wrong button or making > the program "do weird things". Other people with more experience > creating end-user applications may have different views. This is helpful. Can you elaborate on what elements of the Windows look-and-feel are missing in Tkinter? As far as I know, the menu bars, file selection dialogs, scroll bars, dialog boxes and so on have a thoroughly native look-and-feel, since Tk implements these as wrappers around the native widgets. IDLE doesn't look very different from Notepad! So what's missing? A toolbar with icons? That would be easy to add using existing Tk controls (Pmw has it too). The multiple document interface? It sucks -- and even Word 2000 has gone away from that! What kind of GUIs did you teach them exactly? If you started with basic Tkinter widgets, sure, it looks different than anything else. But that depends on the widget layout in the program, not on the widget library used! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@scottb.demon.co.uk Wed Oct 25 14:55:40 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 25 Oct 2000 14:55:40 +0100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <002301c03e8b$42cbc280$060210ac@private> I choose to use wxPython over TK because: 1. wxPython has a reasonable event model 2. wxPython allows me build one object hierarchy 3. TK requires I manage two object hierarchies, TK's and my classes 4. Hooking events to TK seems clumsy from Python As others have said better docs on wxPython would be nice and its to easy to crash the world from wxPython. Barry From claird@starbase.neosoft.com Wed Oct 25 15:58:53 2000 From: claird@starbase.neosoft.com (Cameron Laird) Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters Message-ID: <200010251458.JAA77237@starbase.neosoft.com> I can rarely afford to dip into Python-Dev. My head is exploding too much of the time as it is. Maybe I can help with the recent Tkinter discussions, though. 1. Tcl's going to be around for a long time. Here's the insider scoop on what the Ajuba Solutions announcement means: insiders don't know. That is, *nobody* is sure how Tcl will develop. It'll survive, though, for quite a while. Do NOT worry that it'll suddenly dry up and blow away. I'm working on a more detailed explanation of Tcl processes. It'll probably take a few weeks, though. In the meantime, just ignore the mess, and understand that the Tcl Core Team includes bright people who'll land on their feet somehow. 2. I agree that MacOS is the thorny problem for the standard Pysolution. I'd be happy to discuss the possibilities (Tkinter? wxWindows? Qt?!? GTK+?!!?!? ...) with a smaller group, and, of course, Fredrik, Robin, Guido, ... all are quite knowledgeable about these matters. There are a few things you should know about the Tcl side. The bad is that Tk is barely maintained for MacOS. It's really rather miserable. On the other hand, Jim Ingham is now an Apple employee, and things could change in a hurry, at any time. The good is that Tk starts far ahead of any competitor. It has already solved most of the hard problems. All it needs is a little maintenance. 3. Is there a way to have Tk without contamination by Tcl? More than ever. This is what makes me most cheerful about Tkinter's prospects. The Tcl Core Team has largely given up its hangups about co-operating with foreigners (or its hangups that barbarians have hangups about co- operating with Tcl). This is a *very* good time for someone like Fredrik to establish a working relationship, and get CVS access. I really think Tk can be maintained by a different group than Tcl. Perl, Ruby, ... folks are also receptive to the idea (I've talked with them). For pointers to some of what's happening in this area, see Also, you should know that my favorite enhancement to Tk is a remodularization called TkGS. This should improve performance under Win*, make it more portable to BeOS, improve access by Python, and so on. 4. Greg's right that some publishers are dumping Tcl. Not all, though. If it matters, we can go into details. 5. Pango is indeed cool, but it's different from [text]. The world is probably moving to Pango and similar implementations. The world will be missing much of what [text] offers. 6. ANYONE with an urge to get out a Python-related idea should pursue it. *DDJ*'s a great outlet. It's far from the only one. If people have ideas about articles, but are held back by lack of time/ fluency/contacts/..., *please* get in touch with me. I'll find a way at least to give articles a fair chance at being published. Cameron Laird +1 281 996 8546 FAX http://starbase.neosoft.com/~claird/misc.writing/publications.html From cgw@fnal.gov Wed Oct 25 16:31:38 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com> References: <200010251458.JAA77237@starbase.neosoft.com> Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov> Cameron Laird writes: > I can rarely afford to dip into Python-Dev. My head is exploding > too much of the time as it is. > > Maybe I can help with the recent Tkinter discussions, though. > 2. I agree that MacOS is the thorny problem for > the standard Pysolution. What is the impact of the fact that MacOS X will run X? Doesn't this open the door to a lot of new possibilities, at least if we don't need to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just way too big to even think about dropping (or deprecating) support for it? From tim_one@email.msn.com Wed Oct 25 17:23:30 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 12:23:30 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: [Guido, on finding Tcl/Tk under Windows] > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. That's different -- > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > installer was optionally run. The version issues are also resolved > this way: you are guaranteed to get exactly the Tcl/Tk version that > was tested by the developers. Unless you're Fredrik, alas . Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course). >> What if a user calls with a problem? Why should I >> have to debug their Tcl library path problems? No >> thanks. > The Tcl library paths are all taken care of by the new installer > strategy. > > Really, give it a try. It Just Works! (SM) I'll second that! "Mystery startup errors" from the Python+Tcl+Tk+Windows combo were at least weekly questions on c.l.py for 1.5.2, often daily. I've seen none for 1.6 or 2.0. and-all-it-took-was-avoiding-ms's-recommended-practices-ly y'rs - tim From guido@python.org Wed Oct 25 18:46:55 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 12:46:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400." References: Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com> > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. [Tim] > Unless you're Fredrik, alas . Apparently Tcl still honors library > envars first if they exist, and if some other installation or use of Tcl/Tk > set those, you can still end up w/ a mix. *Much* better than before, though, > and I don't recall ay instance of this happening in real life so far apart > from /F (who had no problem figuring it out, of course). Hm... In FixTk, TCL_LIBRARY is set explicitly. Perhaps it should set TK_LIBRARY explicitly too? --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm@ActiveState.com Wed Oct 25 18:11:42 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed, 25 Oct 2000 10:11:42 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400 References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <20001025101142.B8625@ActiveState.com> On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote: > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. > > Unless you're Fredrik, alas . ...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it. Trent -- Trent Mick TrentM@ActiveState.com From pf@artcom-gmbh.de Wed Oct 25 18:02:45 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST) Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am" Message-ID: Hi, Charles G Waldman: > > 2. I agree that MacOS is the thorny problem for > > the standard Pysolution. > > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? It will take years, before MacOS X will find its way onto the desk of the average Apple Mac user. The Mac s mostly used in the graphics and printing industry (our cutsomers) where people normally don't even think about a OS upgrade, if they don't have to. They usually run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other so called creative software on the version of the OS they had on the machine when they bought it. THese machines are usually used through a period of at least four years. So MacOS X might simplify things for software vendors from 2004 on and later. Regards, Peter From guido@python.org Wed Oct 25 19:21:58 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:21:58 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST." <20001025101142.B8625@ActiveState.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> > ...Or anybody installing ActivePython for that matter. We give instructions > that the latest version of Tcl/Tk has to be installed separately, but Tk is > *not* bundled with it. And that's a shame. Any chance that will be fixed any time soon? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@alum.mit.edu Wed Oct 25 14:36:46 2000 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> ...Or anybody installing ActivePython for that matter. We give >> instructions that the latest version of Tcl/Tk has to be >> installed separately, but Tk is *not* bundled with it. GvR> And that's a shame. Any chance that will be fixed any time GvR> soon? I think a version of Tkinter packaged with a distutils setup script is the best answer for Unix platforms. As a Linux user, I do *not* want to install a second copy of Tcl/Tk. If we have a distutil-Tkinter, e.g. ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz then a user can download it and run "python setup.py install" to build a Tkinter against their installed version of Tk. This will be straightforward on many Linux systems, because they ship with Tk installed. Jeremy From jeremy@alum.mit.edu Wed Oct 25 14:41:30 2000 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT) Subject: [Python-Dev] build problems under Solaris Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net> There are two bug reports about build problems under Solaris (117508 and 117606). I don't have access to a Solaris machine, so I can't do anything to help these users. Since ActivePython is shipped for Solaris, I assume that you (or someone else at AS) does have access to a Solaris machine. Can you take a look at these problems? Or assign them to someone else who can? Jeremy From guido@python.org Wed Oct 25 19:50:07 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:50:07 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400." <14838.57838.841831.632628@bitdiddle.concentric.net> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> > I think a version of Tkinter packaged with a distutils setup script is > the best answer for Unix platforms. As a Linux user, I do *not* want > to install a second copy of Tcl/Tk. Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was, so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself, one for Python+Tkinter, one for Perl/Tk (that's a separate code base anyway so you already have this today -- if you install Perl/Tk, that is), and one for Ruby. Given modern disk sizes I don't think it's a problem. We do the same for Windows, for good reasons: so we can be independent of whatever Tcl/Tk version is already installed. > If we have a distutil-Tkinter, e.g. > ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz > then a user can download it and run "python setup.py install" to build > a Tkinter against their installed version of Tk. This will be > straightforward on many Linux systems, because they ship with Tk > installed. Of course that's easier. But less robust. (And why is there an "8.0" in the filename if it works with other Tcl/Tk versions???) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Wed Oct 25 19:11:34 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:11:34 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> Message-ID: <39F72256.C7F93BFB@prescod.net> "M.-A. Lemburg" wrote: > > ... > > > * implementation language and Python inheritance semantics are almost > > completely distinct. After all, we have Python implementations in a > > variety of languages with minor incompatibilities. Python could have a > > proper type/class merging even if it were written in assembly language. > > So let's leave implementation language aside. > > Hey, think of it as opportunity: we can reuse much of C++'s > optimizations and the integration of Python and C++ applications > will get *much* easier. We could make integrating C++ and Python easier through CXX or Py_Cpp. Perhaps we should ship one of those with Python 2.1. Anyhow, integrating C++ and Python is not really so hard, in my experience. > A rewrite shouldn't scare anyone away -- much of the existing > code can be reused since only the Python C APIs of the various > types will have to be rewritten, not the logic behind the types. I wasn't really addressing the issue of backwards compatibility of extensions -- I was talking about Python programs. Nevertheless, I can't resist: Porting your app to the Python APIs is often the majority of the work in a particular extension. A lot of Python extensions consist only of API glue! > Besides, Py3K will be a project which runs in parallel to the > 2.x development (at least that's what I've read on some BeOpen > webpage), so there's really not much to worry about wrt to > breakage, etc. People will be able to test-drive Py3K while > using the 2.x series. I don't see how that helps. If you can't write programs that work both on the old interpreter and the new one then you need to have a "switch over" day. The whole point of my doctrine is that Python 3K should run all code that the version of Python immediately before it did. The most it can do in terms of breakage is to warn about error messages. In that case it doesn't matter much whether Python 3K is available at the same time as 2.X or emerges from Guido's head fully formed. > > * there is a hell of a lot we can do to make the type/class split less > > visible without a major rewrite. For instance, lists could have a > > __getitem__ method so that they "act like" instances. Instances could > > return their methods in a dir() so that they "act like" built-in > > objects. So there is no reason to wait for a complete rewrite to start > > on this path. > > Right. I didn't want to say that things cannot be done prior > to the rewrite, only that a rewrite will give us much more > options that we currently have. Okay, so do you agree with the rule expressed here: http://www.python.org/pipermail/python-dev/2000-October/016785.html > > I don't know what you mean by a "low-level strategy" for classes. It's > > not like we can somehow use C++ vtables without giving up Python's > > dynamicity. Python's class handling is about as low-level as it can get > > in my humble opinion. > > With "low-level" I meant trying to build Python classes and > instances on top of a very thin layer on top of C++ classes, > e.g. all slots could be implemented using true C++ methods with > additional logic to override them using dynamically bound > Python method objects. I don't think that there is really interesting magic in a C++ compiler. A vtable is an array of pointers to functions. We've already implemented the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and smart pointers are a little more interesting from a code maintenance and simplicity point of view. But even then I think that we could get to a C++ implementation through incremental rewrites. > > > Differences like the > > > ones between Unicode and 8-bit strings would then flesh > > > out as two different subclasses of a generic string type which > > > again is based on a generic sequence type. > > > > Of course that's where we want to go but it doesn't avoid the backwards > > compatibility problems. > > Huh ? I was talking about clear design... not ways to avoid > b/w compatibility. But the whole point of my original article was backwards compatibility!!! I didn't address an implementation strategy for Py3K at all. > Merging Unicode and strings will hurt one > way or another. This is simply a consequence of using strings > as binary containers where Unicode is meant for text only use. The question I wanted to address is how we can *minimize the pain*. > ... > > C++ does not help. Inheritance does not help. Pluggable compilers do not > > help. We *will* break code. We just need to decide whether to do it in a > > thoughtful way that gives people a chance to migrate or put off > > decisions until the last possible moment and then spring it on them with > > no between-version upgrade path. > > Just tell Python to use the correct class for what the > code was written for (and this could be done by plugging in > a 2.0 compiler). The instances of those classes would still work > together with other semantics by virtue of exposing the same > interface, yet the internals would work differently, e.g. > a module using case insensitive lookup would be compiled using > case insensitive dictionaries as namespaces. A mode switch solutiion is fraught with dangers. First there is the issue of the correct default for the mode switch. http://www.python.org/pipermail/python-dev/2000-April/010029.html Second, there are dangers cutting and pasting between modules. Anyhow, even if we allow a mode switch we need to be able to help people to upgrade their modules in a reasonable time. That's what the message I cited advocates. >... > Why spoil all the fun when we haven't even started thinking > about all the possibilities we could use to make Py3k a > success ? Asking for a map of where we are going and how we will get here is "spoiling all of the fun?" I'm not sure what you are reacting to -- I didn't advise one implementation strategy or another -- I just said that we should employ a strategy that minimizes sudden and surprising code breakage. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From fdrake@acm.org Wed Oct 25 19:06:50 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From paul@prescod.net Wed Oct 25 19:18:16 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:18:16 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <39F723E8.2AC6787@prescod.net> Charles G Waldman wrote: > > ... > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? Would Mac users go for: "first install X. Then you can run Python." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido@python.org Wed Oct 25 20:14:57 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 14:14:57 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400." <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com> > > Why not? Because if every app using Tcl/Tk did that there would be > > hundreds of copies of Tcl/Tk on your disk? I don't think that > > argument flies; only a few other major languages use Tcl/Tk this was, > > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? Of course not, but large and important ones may. Some already do, e.g. Alice, Zope, Ultraseek. I have no problem with this. (The saving grace is that none of these needs to recursively include Tcl. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From gvwilson@nevex.com Wed Oct 25 19:17:24 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT) Subject: [Python-Dev] Gradual migration In-Reply-To: <39F72256.C7F93BFB@prescod.net> Message-ID: > Paul Prescod: > Anyhow, integrating C++ and Python is not really so hard, in my experience. ...unless you are using heavily-templated code, e.g. every damn class you've been asked to wrap up seems to be derived from something in the STL... Greg From cgw@fnal.gov Wed Oct 25 19:18:56 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <39F723E8.2AC6787@prescod.net> References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov> Paul Prescod writes: > > Would Mac users go for: "first install X. Then you can run Python." > I should probably just shut up, because I really don't know enough about Mac OS X, but what I was wondering is whether OS X will actually *use* the X Window System. Of course we don't want to tell users that they have to go install X on their own. From tim_one@email.msn.com Wed Oct 25 19:18:55 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 14:18:55 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: [Guido] > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, [Fred Drake] > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? So long as Python doesn't guarantee binary compatibility across releases, that's the only thing that works. Play PySol lately ? From paul@prescod.net Wed Oct 25 19:27:33 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:27:33 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov> Message-ID: <39F72615.40B38862@prescod.net> Charles G Waldman wrote: > >... > > I should probably just shut up, because I really don't know enough > about Mac OS X, but what I was wondering is whether OS X will actually > *use* the X Window System. Of course we don't want to tell users that > they have to go install X on their own. And become just another Unix? Then how would they get people to pay the Macintosh usability premium? Seriously, maybe someday as a "Linux compatibility mode" but I don't think it is officially proposed. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul@prescod.net Wed Oct 25 19:30:34 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:30:34 -0700 Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) References: Message-ID: <39F726CA.9D472E50@prescod.net> Peter Funk wrote: > > .. > > Bruce Sherwood and David Scherer suggested a IMHO very clever solution to > this particular problem in March/April this year. This thread was first > posted to idle-dev and afterwards X-posted to python-dev: > > http://www.python.org/pipermail/idle-dev/2000-April/000138.html > http://www.python.org/pipermail/idle-dev/2000-April/000140.html > http://www.python.org/pipermail/python-dev/2000-April/010029.html Tim's last message on it doesn't sound overwhelmingly positiive to me! Also, don't forget that Python is also a command line so "version pragmas" cause additional complexity there. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From DavidA@ActiveState.com Wed Oct 25 19:59:35 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time) Subject: [Python-Dev] build problems under Solaris In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net> Message-ID: On Wed, 25 Oct 2000, Jeremy Hylton wrote: > There are two bug reports about build problems under Solaris (117508 > and 117606). I don't have access to a Solaris machine, so I can't do > anything to help these users. Since ActivePython is shipped for > Solaris, I assume that you (or someone else at AS) does have access to > a Solaris machine. Can you take a look at these problems? Or assign > them to someone else who can? Sure, we'll take a look. --david From akuchlin@mems-exchange.org Wed Oct 25 22:51:40 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 17:51:40 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: I'd like to begin writing an article about 2.0's Unicode support. Before beginning, has anyone else already begun this task? If yes, please let me know... (Incidentally, did a 2.0 press release ever go out? Is someone going to write one?) --amk From MarkH@ActiveState.com Wed Oct 25 23:18:27 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 09:18:27 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: [Trent] > > ...Or anybody installing ActivePython for that matter. We > > give instructions that the latest version of Tcl/Tk has to > > be installed separately, but Tk is *not* bundled with it. [Guido] > And that's a shame. Any chance that will be fixed any time soon? Not presuming to speak for anyone, least of all the ActivePython product manager :-) I don't think it will be "fixed", as it is not considered "broken". It was an explicit choice to leave out Tcl/Tk. And my recollection is that the "feedback" address sees more requests for wxPython than Tcl/Tk. We make it pretty clear Tcl/Tk is not included - I assume that everyone who cares about that simply uses BeOpen releases or source tarballs. [When I say "wont be fixed", I mean it is unlikely to appear in the core ActivePython release. It almost certainly will be supported as an add-on, whatever that turns out to mean exactly ;-] Mark. From guido@python.org Thu Oct 26 01:15:31 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 19:15:31 -0500 Subject: [Python-Dev] 2.0 articles In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400." References: Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) No; and not me... --Guido van Rossum (home page: http://www.python.org/~guido/) From MarkH@ActiveState.com Thu Oct 26 00:29:52 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 10:29:52 +1100 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: [From a mail in idle-dev - dropped idle-dev and all CCs] [idle-dev poster] > > >>> import sys > > >>> f = open('some-output-file', 'w') > > >>> sys.stdout = f > > >>> # do some stuff > > >>> sys.stdout = sys.__stdout__ > > > > Because on entry, sys.stdout is already redirected > > (not reflected in sys.__stdout__) [Guido] > Where did you get this idiom? You should never use sys.__stdout__ > this way! The proper idiom is > > save_stdout = sys.stdout > try: > sys.stdout = f > # do some stuff > finally: > sys.stdout = save_stdout > > If you know of any places that are promoting direct use of __stdout__, > please let them know this is wrong. If you are contemplating to use > this in code examples you intend to distribute, please don't! I admit that I first became aware of sys.__stdout__ after seeing this exact same idiom in other peoples code. I always assumed that this is _exactly_ what sys.__stdout__ was to be used for! The following examples exist: * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. * Tools/il8n/pygettext.py - ditto * Tools/idle/PyParse.py - disabled, debugging output function - presumably to get around sys.stdout redirection - but this sounds suspect as an idiom to me too! So what _is_ it intended for? Mark. From greg@cosc.canterbury.ac.nz Thu Oct 26 01:16:02 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz> > If you started with basic Tkinter widgets, sure, it looks different > than anything else. But that depends on the widget layout in the > program, not on the widget library used! This is one of my main gripes about the Tk API. The default behaviours of all its layout managers suck. In order to get a layout that looks pleasant and/or conforms to some style guide, you have to set a whole slew of options every time you place a widget. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From barry@wooz.org Thu Oct 26 01:17:38 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.30754.217582.20441@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> * Tools/il8n/pygettext.py That's embarassing. ;) Here's a patch, but I'm not going to check it in because I think a /much/ better idiom to adopt is to use extended print instead. I need to make some updates to pygettext.py soon, so I'll probably just 2.0-ify it at the same time. -Barry -------------------- snip snip -------------------- Index: pygettext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v retrieving revision 1.9 diff -u -r1.9 pygettext.py --- pygettext.py 2000/05/02 19:28:30 1.9 +++ pygettext.py 2000/10/26 00:16:22 @@ -283,6 +283,7 @@ options = self.__options timestamp = time.ctime(time.time()) # common header + stdout = sys.stdout try: sys.stdout = fp # The time stamp in the header doesn't have the same format @@ -314,7 +315,7 @@ print 'msgid', normalize(k) print 'msgstr ""\n' finally: - sys.stdout = sys.__stdout__ + sys.stdout = stdout def main(): From gmcm@hypernet.com Thu Oct 26 01:39:14 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 25 Oct 2000 20:39:14 -0400 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <39F744F2.17759.4FC8E6D4@localhost> > [Guido] > > > Where did you get this idiom? You should never use sys.__stdout__ > > this way! The proper idiom is > > > > save_stdout = sys.stdout > > try: > > sys.stdout = f > > # do some stuff > > finally: > > sys.stdout = save_stdout [Mark] > So what _is_ it intended for? A fail-safe. The recommended idiom might also be called "plays well with others"; a barbarian notion that fortunately has not infected most import hacks or program exits... works-for-me-so-buzz-off-ly y'rs - Gordon From akuchlin@mems-exchange.org Thu Oct 26 03:40:03 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 22:40:03 -0400 Subject: [Python-Dev] 2.0 press release In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500 References: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us> On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote: >> (Incidentally, did a 2.0 press release ever go out? Is someone going >> to write one?) >No; and not me... Little-known fact: Guido actually does nothing but sit in his pyjamas (with feet!) all day, drinking cocoa, eating Hostess Twinkies and watching Tiny Toons, while his long-suffering co-workers implement and debug the fantastically complex algorithms that go into Python. Here's some rough text: Can someone with a clue about writing a good press release give this a look? --amk Reston, VA, Oct 25 2000: The Python development team today announced the release of version 2.0 of the Python programming language. Version 2.0 adds a number of significant new features: * Unicode support, in the form of a new Unicode data type, library additions for conversion to/from various encodings, and support for displaying Unicode strings in Tk widgets. * New language features: garbage collection of cycles, list comprehensions, augmented assignment, string methods. * Distutils, a new system for making Python modules and extensions easily available to a wider audience with very little overhead for build/release/install mechanics. * Improved XML support, including support for the Simple API for XML (SAX2), a miniature Document Object Model (DOM), and the Expat parser. * Many library improvements, including HTTP/1.1 support, an enhanced curses module, the ability to read and write ZIP-format files, support for the Windows registry, and many more minor improvements. * Ports to new platforms: 64-bit Windows on the Itanium processor, Windows CE, and Darwin/MacOS X. Python is an interpreted, object-oriented, high-level programming language. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for rapid application development, as well as for use as a scripting or glue language to connect existing components together. Python's simple, easy to learn syntax emphasizes readability and therefore reduces the cost of program maintenance, and it supports modules and packages, encouraging program modularity and code reuse. Many extension modules for Python have been written to interface with other libraries and applications. Some of the available modules include: * Support for many relational databases (Oracle, Sybase, MySQL) * GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME) * Internet protocols (LDAP, WebDAV, XML-RPC, SOAP) * Mathematics (Numeric Python) Python is used for many different purposes, particularly cross-platform rapid development, Web development, and scripting of scientific applications. Some of the applications using Python include: * Zope, the leading Open Source web application server * The Mailman mailing list manager * The Reportlab PDF document generation toolset * XXX suggestions? XXX too darn many lists here? The Python interpreter and the extensive standard library are available free of charge and are distributed under an open-source license. Ports have been made to all major platforms, such as Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.) New versions are developed collaboratively by a core group of over 20 developers. About BeOpen: About Python: More information about Python can be obtained from the official Python website, http://www.python.org. (XXX Do you include About sections for the companies that provide quotes?) Press contacts: XXX whose address? From guido@python.org Thu Oct 26 05:02:11 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 23:02:11 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100." References: Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com> > So what _is_ it intended for? Example: IDLE redirects sys.stderr so that it gets displayed in the Python Shell window with a different text color. But occasionally I need to debug IDLE and the bug is in the text drawing. Then it's nice if I can write to __stderr__, which goes to the console. Or suppose I'm in a regular interactive session and I've managed to screw myself by assigning a bogus file object to sys.stdout (it happens :-). If I know that, I can type sys.stdout = sys.__stdout__ at the >>> prompt and save myself -- so I don't have to restart the session and perhaps lose valuable data. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Thu Oct 26 04:55:13 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Mark Hammond writes: > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. > * Tools/il8n/pygettext.py - ditto I've just fixed these two; too bad checkin messages aren't getting sent. ;( > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > to get around sys.stdout redirection - but this sounds suspect as an idiom > to me too! I've left this one for someone with a good idea about what to do about it. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake@acm.org Thu Oct 26 05:31:33 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <20001025222406.A8389@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> [Moved over from a discussion in the bugs list; this relates to bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470 Please be sure to CC: Jon on all replies.] Jon Ribbens writes: > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without > changes is unexpected enough to warrant mentioning in a paragraph of its > own, completely explicitly. The '.in' suffix is usually used for files which > autoconf is going to use to create a new file from - you cannot usually > simply copy the file yourself. An experienced admin installing Python is > more likely to believe the README is wrong than what it tells them to do > is correct. Why does the Setup.in file exist in the first place? Surely it > should be named 'Setup.dist' (and an identical file 'Setup' exist right from > the start). Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. Since this doesn't help if the source and build directories differ, configure.in can be modified to create Setup if (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. I have the changes to configure.in, configure, Setup*, and Modules/Makefile.pre.in ready, but I still need to update the instructions in the README & possibly elsewhere. Does this sound agreeable? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From effbot@telia.com Thu Oct 26 08:15:45 2000 From: effbot@telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 09:15:45 +0200 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid> mark wrote: > > If you know of any places that are promoting direct use of __stdout__, > > please let them know this is wrong. If you are contemplating to use > > this in code examples you intend to distribute, please don't! > > I admit that I first became aware of sys.__stdout__ after seeing this exact > same idiom in other peoples code. I always assumed that this is _exactly_ > what sys.__stdout__ was to be used for! > > The following examples exist: and several examples in the eff-bot guide. guess I'll have to fix it in the second edition... From ping@lfw.org Thu Oct 26 09:09:44 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: On Tue, 24 Oct 2000, Barry A. Warsaw wrote: > > Okay, we all know that's a pain, right? Lots of people have proposed > solutions. I've looked briefly at !?ng's Itpl.py, but I think it > probably does too much by adding evaluation. Do you think a variant of Itpl that only looked up variable names would solve your problem? > I can define _() to make the problem somewhat more convenient: > > def _(s): > try: > raise Exception > except Exception: > frame = sys.exc_info()[2].tb_frame.f_back > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d How about this routine to get the current frame: inspect.currentframe(). Could i humbly re-request approval for inspect.py in the standard library? http://lfw.org/python/inspect.py It's been up there for a long time, there's lots of good stuff in it, and previous feedback on this list has all been fairly positive -- there just hasn't been an explicit approval for inclusion. This is probably because we were busy trying to get 2.0 released (even though inspect.py was proposed here before ascii.py, and ascii.py did get accepted). I think the functionality it provides is important to supporting the language definition. It abstracts away the special secret attributes and protects us from future changes in the internals. If there are changes that need to be made before it can be accepted, i'd be happy to make them. -- ?!ng From effbot@telia.com Thu Oct 26 09:36:14 2000 From: effbot@telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 10:36:14 +0200 Subject: [Python-Dev] getting at the current frame References: Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py > > It's been up there for a long time hey, you still haven't fixed the *2 bug... > I think the functionality it provides is important to supporting the > language definition. It abstracts away the special secret attributes > and protects us from future changes in the internals. agreed. > inspect.py was proposed here before ascii.py, and ascii.py did get > accepted as part of the curses package, yes. From ping@lfw.org Thu Oct 26 09:53:56 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid> Message-ID: On Thu, 26 Oct 2000, Fredrik Lundh wrote: > > It's been up there for a long time > > hey, you still haven't fixed the *2 bug... Sorry -- looks like an older version than the one i have on my local disk, which did get fixed. The one on the website is now up to date. http://lfw.org/python/inspect.py -- ?!ng From jon+sourceforge@unequivocal.co.uk Thu Oct 26 10:39:01 2000 From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 10:39:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <20001026103901.A11873@snowy.squish.net> "Fred L. Drake, Jr." wrote: > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > Does this sound agreeable? Sounds cool. I would mention in the first part of the install instructions about the Setup file, that you edit it to change the available modules (this concept is not obvious if you don't know how Python works!), that you can edit it now but if you have not installed Python before it is best to try building without editing it first and that there are more instructions further down the README. You might like to mention 'readline' here too to head-off newsgroup questions about why up-arrow doesn't work ;-). Cheers Jon From guido@python.org Thu Oct 26 12:38:34 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:38:34 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400." <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> > > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > > to get around sys.stdout redirection - but this sounds suspect as an idiom > > to me too! > > I've left this one for someone with a good idea about what to do > about it. Don't touch it! This one is needed because at this point sys.stdout and sys.stderr are redirected to a window where you don't want the parser debug output to show up. (I mentioned this example in my previous post.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 26 12:45:49 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:45:49 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400." <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com> [Fred] > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > I have the changes to configure.in, configure, Setup*, and > Modules/Makefile.pre.in ready, but I still need to update the > instructions in the README & possibly elsewhere. > Does this sound agreeable? Sure, except I'm not comfortable with having two files with identical contents under CVS control. How about not checking in Setup, but creating it in configure if it doesn't exist? This is necessary also for the following reason: when you build in a different tree than the source tree, you should get a fresh copy of Setup in the build tree -- another copy of Setup in the source tree is useless. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Oct 26 12:48:20 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:48:20 -0500 Subject: [Python-Dev] getting at the current frame In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST." References: Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py To avoid that we forget about this again, and to make sure it gets proper treatment, could you submit it through the patch manager? No need to turn it into a context diff, just upload the entire file. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Thu Oct 26 11:21:05 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:21:05 +0200 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300 References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Message-ID: <20001026122105.N12812@xs4all.nl> On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote: > Neil Schemenauer : > > Those PyInstance_Check() calls should really go away. Instead, the > > type should be responsible for providing different behavior. > Yes, that's the crux of the problem, I think. > Another place where this is a nuisance is where it > assumes that if x has any tp_as_sequence slots and y > has any tp_as_number slots, then x*y is a sequence > replication operation. This is screwed in more than one way. The logic of which 'type' operation has precedence isn't even internally consistent. The case of 'x*y' and 'x+y' check the tp_as_number and tp_as_sequence slots in a *different order*, so 'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way 'round, I forget. I'm also struggling to catch up on my mail since Apachecon had little to no connectivity, so I don't feel like checking :) Brainwashed-into-Apache-2.0-forever-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Oct 26 11:51:30 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:51:30 +0200 Subject: [Python-Dev] ViewCVS on Sourceforge Message-ID: <20001026125130.O12812@xs4all.nl> I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon Travis and Gregory Trubetskoy where there as well, but my memory is a bit hazy) and since he's probably in some airplane over the atlantic right now, I'll run away and steal his idea ;) We were kind of reflecting how nice it would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and it doesn't need write access to the repository itself. So how about we run ViewCVS on python.sourceforge.net ourselves ? We could do it now, in fact, with the complete CVS snapshot that gets made every once in a while (that *does* still get made & backupped, right ?) though it would obviously be a lot more useful if ViewCVS just had direct access to the repository. I'm not sure how accessible that repository is, however. Cursory searches on shell.sourceforge.net doesn't show anything, except that the python-cvs.tgz that's in /home/projects/python is apparently the one used for the move to sourceforge :-) Can we get access to the repository directly, even if it's only semi-realtime ? (I wouldn't mind doing a couple of rsync's in cron to keep it up to date) If anything, running ViewCVS will show SourceForge how much nicer it is... ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jon+sourceforge@unequivocal.co.uk Thu Oct 26 12:01:27 2000 From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 12:01:27 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> Message-ID: <20001026120127.B11873@snowy.squish.net> Guido van Rossum wrote: > Sure, except I'm not comfortable with having two files with identical > contents under CVS control. How about not checking in Setup, but > creating it in configure if it doesn't exist? I think that would be fine so long as the README file makes it clear that you edit the Setup file after './configure' but before 'make'. Cheers Jon From mal@lemburg.com Thu Oct 26 12:23:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 13:23:19 +0200 Subject: [Python-Dev] 2.0 articles References: Message-ID: <39F81427.FF4223C2@lemburg.com> Andrew Kuchling wrote: > > I'd like to begin writing an article about 2.0's Unicode support. > Before beginning, has anyone else already begun this task? If yes, > please let me know... I've already started something in that direction. The plan is to write down the story of adding Unicode support to Python, the pifalls, solutions, hacks, etc. I'll probably submit it to DDJ. A article about *using* Unicode support would of course be a nice complement to get a feeling of how it's like working with the implementation :-) > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@acm.org Thu Oct 26 13:21:08 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> <200010261138.GAA04678@cj20424-a.reston1.va.home.com> Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com> I wrote: > I've left this one for someone with a good idea about what to do > about it. Guido van Rossum replied: > Don't touch it! This one is needed because at this point sys.stdout > and sys.stderr are redirected to a window where you don't want the > parser debug output to show up. See, I knew someone would come up with a better idea! ;) -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Thu Oct 26 13:31:36 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <14840.9256.408848.728486@beluga.mojam.com> Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. I don't like the idea that a file I am supposed to edit (Setup) would be in the CVS repository where it could conceivably get messed with by a "cvs up" command. The current makefile target that emits a warning if Setup.in (.dist) is newer than Setup should be sufficient to alert users when Setup needs to be looked at. -- Skip Montanaro (skip@mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From skip@mojam.com (Skip Montanaro) Thu Oct 26 13:34:09 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.9409.491061.671168@beluga.mojam.com> Ping> Could i humbly re-request approval for inspect.py in the standard Ping> library? Ping> http://lfw.org/python/inspect.py +1. I've written functions over the years to do some small bits of what inspect.py does. I'd much rather have those things in a standard place with more eyeballs checking them for correctness. Skip From akuchlin@mems-exchange.org Thu Oct 26 13:56:26 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 26 Oct 2000 08:56:26 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200 References: <39F81427.FF4223C2@lemburg.com> Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us> On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote: >A article about *using* Unicode support would of course >be a nice complement to get a feeling of how it's like working And that's what I want to write, so it works out nicely; great! Finn, your comment has been noted; I'll take note of any differences with Jython's Unicode support. A draft will be announced on python-dev, whenever it actually gets done. --amk From mal@lemburg.com Thu Oct 26 14:07:35 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 15:07:35 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> Message-ID: <39F82C97.12D04C85@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > > * implementation language and Python inheritance semantics are almost > > > completely distinct. After all, we have Python implementations in a > > > variety of languages with minor incompatibilities. Python could have a > > > proper type/class merging even if it were written in assembly language. > > > So let's leave implementation language aside. > > > > Hey, think of it as opportunity: we can reuse much of C++'s > > optimizations and the integration of Python and C++ applications > > will get *much* easier. > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > C++ and Python is not really so hard, in my experience. Ok, you can use SWIG to get most of the work done, but the interface between the C++ object world and the Python object world is one big mess -- all implementations I've seen use shadow objects or proxies to interface from one to the other... with lots of temporary objects used for the linkup. Having Python itself written in C++ we could do *much* better. But that's only a nice side-effect. The real argument here is that we can push the type logic one layer further down. Ideal would be a level of integration such as the one implemented in JPython or Jython. > > A rewrite shouldn't scare anyone away -- much of the existing > > code can be reused since only the Python C APIs of the various > > types will have to be rewritten, not the logic behind the types. > > I wasn't really addressing the issue of backwards compatibility of > extensions -- I was talking about Python programs. Nevertheless, I can't > resist: > > Porting your app to the Python APIs is often the majority of the work in > a particular extension. A lot of Python extensions consist only of API > glue! True, but we're lucky, since we could provide a compatibility layer on top of the new API. BTW, I think I now know what your main concern is: the Python level compatibility. I was talking of what goes on under the hood and still think that Py3K should be used as a chance to simplify the Python backend. As simplification often means generalization, we'll open up new doors for future developments along the way. > > > I don't know what you mean by a "low-level strategy" for classes. It's > > > not like we can somehow use C++ vtables without giving up Python's > > > dynamicity. Python's class handling is about as low-level as it can get > > > in my humble opinion. > > > > With "low-level" I meant trying to build Python classes and > > instances on top of a very thin layer on top of C++ classes, > > e.g. all slots could be implemented using true C++ methods with > > additional logic to override them using dynamically bound > > Python method objects. > > I don't think that there is really interesting magic in a C++ compiler. > A vtable is an array of pointers to functions. We've already implemented > the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and > smart pointers are a little more interesting from a code maintenance and > simplicity point of view. But even then I think that we could get to a > C++ implementation through incremental rewrites. Naa, the whole type slot interface is one big mess (sorry, Guido :-). some slots are packaged, some are not, some are NULL, some are not, there are oodles of sometimes weird dependencies between the slots which are not really documented, etc. etc. The slot design has serious drawbacks and should be replaced by something more reliable, preferably C++ methods. That way, we'll get some more "type" safety into Python and its extensions. Note that porting old extensions won't be all that hard: a class reusing the existing slot functions as methods should suffice in many cases. > > Why spoil all the fun when we haven't even started thinking > > about all the possibilities we could use to make Py3k a > > success ? > > Asking for a map of where we are going and how we will get here is > "spoiling all of the fun?" I'm not sure what you are reacting to -- I > didn't advise one implementation strategy or another -- I just said that > we should employ a strategy that minimizes sudden and surprising code > breakage. Ok, we've been talking about different things here: with "spoiling the fun" I meant putting ropes on possible changes to the C backend. You are talking about the frontend and I agree with you that there should be a clear upgrade path from the 2.x series to Py3K w/r to the Python side of things. So I guess it's time for some PEPs now... the upgrade path PEP and the fluffy clouds PEP. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Thu Oct 26 15:42:40 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 09:42:40 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100." <20001026120127.B11873@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com> > I think that would be fine so long as the README file makes it clear that > you edit the Setup file after './configure' but before 'make'. One thing -- it's perfectly fine to edit Setup after running Make for the first time. You just have to run Make again. The Makefiles are designed for this. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Thu Oct 26 14:56:40 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 06:56:40 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> Message-ID: <39F83818.38EA64AE@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Having Python itself written in C++ we could do *much* better. Agree. > ... > > The slot design has serious drawbacks and should be replaced by > something more reliable, preferably C++ methods. That way, we'll > get some more "type" safety into Python and its extensions. I agree that the slot stuff is broken but my solution would be to junk it and use the same mechanism for looking up "type methods" and "instance methods". I can think of two ways to make that perform reasonably: one is method caching and the other is by building interface objects where methods are invoked by index -- basically vtables. But if the same mechanism is going to accelerate Python and C types alike then it can't really use C++ vtables because how do you generate a vtable at runtime for a new Python class? (you could also think of it as a COM interface object) > So I guess it's time for some PEPs now... the upgrade path > PEP and the fluffy clouds PEP. Good timing. I just finished the first draft of the upgrade path PEP. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry@wooz.org Thu Oct 26 14:24:49 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <14840.9409.491061.671168@beluga.mojam.com> Message-ID: <14840.12449.241947.715016@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> Could i humbly re-request approval for inspect.py in the Ping> standard library? Ping> http://lfw.org/python/inspect.py SM> +1. I've written functions over the years to do some small SM> bits of what inspect.py does. I'd much rather have those SM> things in a standard place with more eyeballs checking them SM> for correctness. I've downloaded it, and will take a look. From jim@interet.com Thu Oct 26 15:03:43 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:03:43 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <39F839BF.DD1B86BF@interet.com> Guido van Rossum wrote: > To me this all sounds like FUD. True, but FUD is real and I have no apologies. > Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. We don't use the Python Windows installer. Our app has to use its own installer, and I would then have to run two installers, one of which I don't understand. Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors. JimA From jim@interet.com Thu Oct 26 15:06:02 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:06:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> Message-ID: <39F83A4A.26E543A3@interet.com> Guido van Rossum wrote: > Even Microsoft is violating its own (boring) style guide, when they > think it appeals to a specific audience. Have you seen their Media > Player? Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design. JimA From gward@mems-exchange.org Thu Oct 26 15:18:50 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 10:18:50 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us> On 26 October 2000, James C. Ahlstrom said: > Guido van Rossum wrote: > > > Even Microsoft is violating its own (boring) style guide, when they > > think it appeals to a specific audience. Have you seen their Media > > Player? > > Yes, very slick. My daughter has an app where you click on > doors to access parts of the program. Nice design. This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end. Go look for "User Interface Hall of Shame" at your friendly neighbourhood search engine for many enjoyable rants against bad GUI design, including the "emulate the real world" school of thought. Anyways, this is not a usability mailing list... back to our regularly scheduled python-dev... Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From paul@prescod.net Thu Oct 26 15:28:12 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:28:12 -0700 Subject: [Python-Dev] Gradual migration PEP Message-ID: <39F83F7C.2241158F@prescod.net> PEP: XXX Title: Guidelines for introducing backwards incompatibilities Version: $Revision: 1.0 $ Author: Paul Prescod Status: Draft Type: Standards Track Python-Version: All Created: 25-Oct-2000 Abstract In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behaviour of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. Implementation Details Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. Scope These guidelines apply to future versions of Python that introduce backward-incompatible behaviour. Backward incompatible behaviour is a major deviation in Python interpretation from an earlier behaviour described in the standard Python documentation. Removal of a feature also constitutes a change of behaviour. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! Steps For Introducting Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. Local Variables: mode: indented-text indent-tabs-mode: nil End: From paul@prescod.net Thu Oct 26 15:35:48 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:35:48 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F84144.105D1754@prescod.net> Mark Hammond wrote: > >... > > I don't think it will be "fixed", as it is not considered "broken". It was > an explicit choice to leave out Tcl/Tk. And my recollection is that the > "feedback" address sees more requests for wxPython than Tcl/Tk. That's all true. We also make it very easy to find the right version of Tcl/Tk and will probably go even farther in this direction in the future. Built-in Tcl/Tk support is not out of the question but there are various user confusion issues: "Why are there two GUI frameworks in this development environment? Why are there two development environments in this development environment? Doesn't ActiveState have yet another GUI framework and development environment under development?" "Why do I need Tcl at all? What is its relationship with Python? There are clear benefits to including Tcl/Tk but there are also costs and its possible we'll weigh them differently in the future. BTW: ActivePython does include Tkinter. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From gmcm@hypernet.com Thu Oct 26 15:49:20 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 10:49:20 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <39F80C30.5448.52D32F94@localhost> [Paul] > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. ... or a number of others (but SWIG falls very short when it comes to things like C++ references)... [Marc-Andre] > Ok, you can use SWIG to get most of the work done, but the interface > between the C++ object world and the Python object world is one > big mess -- all implementations I've seen use shadow objects > or proxies to interface from one to the other... with lots of > temporary objects used for the linkup. While I agree it's messy, those are not the objectionable qualities. Any refcounted C++ system is going to have proxies (smart pointers / refcounting stack-safe "reference" objects to the real heap-based objects). And while I think we'd be better off with a C++ implementation, I would warn that C++'s notion of inheritence is in conflict with Python's. It won't be "as above, so below" (unless we screw interpreting and go straight to native code). Assuming that the class / type dichotomy actually gets healed, that is. > ... The real argument here is > that we can push the type logic one layer further down. Ideal would > be a level of integration such as the one implemented in JPython > or Jython. Nope. If you heal the class / type split, there's really only one underlying type object. Unless you go the other way, and write "native" code (as JPython does). All of the existing C++ interfaces / helpers deal only with type objects (at least, those that I've examined, which is most of them). In fact, only ExtensionClass attempts to deal with the class / type split, and while it's a masterpiece, I think it's a great example of everything to avoid in Py3K. - Gordon From barry@wooz.org Thu Oct 26 15:58:23 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> <39F83818.38EA64AE@prescod.net> Message-ID: <14840.18063.152674.534458@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I agree that the slot stuff is broken but my solution would be PP> to junk it and use the same mechanism for looking up "type PP> methods" and "instance methods". I can think of two ways to PP> make that perform reasonably: one is method caching and the PP> other is by building interface objects where methods are PP> invoked by index -- basically vtables. But if the same PP> mechanism is going to accelerate Python and C types alike then PP> it can't really use C++ vtables because how do you generate a PP> vtable at runtime for a new Python class? (you could also PP> think of it as a COM interface object) Objective-C! :) From effbot@telia.com Thu Oct 26 16:14:28 2000 From: effbot@telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 17:14:28 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid> jim wrote: > Sorry to be such an old fuddy-duddy, but you will > get the same reaction from most commercial software > vendors. Make that nearly ALL vendors. what reaction? are you saying that your own installer can install the Python DLL but not the Tk DLL? From gmcm@hypernet.com Thu Oct 26 16:05:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 11:05:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us> References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 Message-ID: <39F80FDE.6102.52E19102@localhost> James C. Ahlstrom said: > > Yes, very slick. My daughter has an app where you click on > > doors to access parts of the program. Nice design. [Greg Ward] > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I once interviewed with a game designer (sports games - popular ones, too). He spent half an hour slamming MS's UI (his games run on Windows). Then he pulled up his latest (opening to a sports stadium) and said "Now here's a real UI". So I said "Show me how it works". The bozo ended up clicking on random things on the screen until something finally happened. no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs - Gordon From barry@wooz.org Thu Oct 26 16:36:37 2000 From: barry@wooz.org (barry@wooz.org) Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.20357.734136.911927@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: >> Okay, we all know that's a pain, right? Lots of people have >> proposed solutions. I've looked briefly at !?ng's Itpl.py, but >> I think it probably does too much by adding evaluation. KY> Do you think a variant of Itpl that only looked up variable KY> names would solve your problem? I think it would calm my objections, yes. I'll observe that I think there may be a middle ground between my approach and Itpl. I've found a couple of situations where I want a minimal form of evaluation, e.g. I want attributes to be expanded (and methods called), but not a general evaluation facility. So for example, I'd like to be able to say: print _("The name of the mailing list is %(mlist.listname())s") What worries me about a general evaluation framework is that we then have to be really really careful about security and origin of the strings we're using here. Maybe we'd need to adopt something like Perl's taint strings. KY> How about this routine to get the current frame: KY> inspect.currentframe(). It uses the same intentional-exception trick to get at the current frame. It's about 8x faster to do it in C. I'll note that your version raises and catches a string exception, while mine uses an exception instance. I don't see much difference in speed between the two. KY> If there are changes that need to be made before it can be KY> accepted, i'd be happy to make them. Sent under a separate private response... -Barry From gward@mems-exchange.org Thu Oct 26 17:03:09 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 12:03:09 -0400 Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400 References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us> On 24 October 2000, Barry A. Warsaw said: > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. Not sure if I would call that function 'getcaller()' or 'getframe()'; could go either way. In my implementation of this (I guess everyone has one!), I also have a couple of convenience functions: def get_caller_env (level=1): """get_caller_env(level : int = 1) -> (globals : dict, locals : dict) Return the environment of a caller: its dictionaries of global and local variables. 'level' has same meaning as for 'caller()'. """ def get_frame_info (frame): """get_frame_info(frame) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from an execution frame. """ def get_caller_info (level=1): """get_caller_info(level : int = 1) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from some caller's execution frame. 'level' is the same as for 'caller()', i.e. if level is 1 (the default), gets this information about the caller of the function that is calling 'get_caller_info()'. """ These are mainly used by my unit-testing framework (which you'll no doubt remember, Barry) to report where test failures originate. Very handy! Looks like Ping's inspect.py has something like my 'get_frame_info()', only it's called 'getframe()'. Obviously this is the wrong name if Barry's new function gets added as 'sys.getframe()'. How 'bout this: sys.getframe(n) - return stack frame for depth 'n' inspect.getframeinfo(frame) - return (filename, line number, function name, lines-of-code) Although I haven't grokked Ping's module enough to know if that rename really fits his scheme. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From jon+sourceforge@unequivocal.co.uk Thu Oct 26 17:57:01 2000 From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 17:57:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com> Message-ID: <20001026175701.A4983@snowy.squish.net> Guido van Rossum wrote: > One thing -- it's perfectly fine to edit Setup after running Make for > the first time. You just have to run Make again. The Makefiles are > designed for this. Mention this too ;-) From fdrake@acm.org Thu Oct 26 18:24:54 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT) Subject: [Python-Dev] Setup changes are checked in Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com> I've checked in the changes to the handling of the Modules/Setup file as we've discussed here. - Setup.in is now Setup.dist - Setup is created by configure - README and other instructions, comments, and documentation has been updated to reflect these changes -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake@acm.org Thu Oct 26 18:30:22 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT) Subject: [Python-Dev] development version of docs online Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Do people want to be notified when the development copy of the documentation is update? There was a comment from someone that they didn't know where the online copy was. I can send the update notice to python-dev instead of just to myself if everyone wants it, or I can send it to some other (appropriate) list. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From trentm@ActiveState.com Thu Oct 26 18:42:30 2000 From: trentm@ActiveState.com (Trent Mick) Date: Thu, 26 Oct 2000 10:42:30 -0700 Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400 References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: <20001026104230.B23283@ActiveState.com> On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote: > > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they Yes, please. Trent -- Trent Mick TrentM@ActiveState.com From jim@interet.com Thu Oct 26 20:34:03 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:34:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid> Message-ID: <39F8872B.92D69403@interet.com> Fredrik Lundh wrote: > > jim wrote: > > Sorry to be such an old fuddy-duddy, but you will > > get the same reaction from most commercial software > > vendors. Make that nearly ALL vendors. > > what reaction? > > are you saying that your own installer can install the > Python DLL but not the Tk DLL? Not exactly. I am saying I don't want to use the standard Python Windows installer. And I am saying I don't want to install Tk because it is big, complicated, and requires Tcl and its libraries. My installer does install the Python DLL python15.dll, so I guess I could study how to install Tk and duplicate the functionality of the Windows installer, and install Tk too. But why would I want to? JimA From jim@interet.com Thu Oct 26 20:38:40 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:38:40 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us> Message-ID: <39F88840.3F619707@interet.com> Greg Ward wrote: > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I agree up to a point, and my own app doesn't use doors. But kids like this kind of design, have no trouble understanding it, and people wouldn't write this if they didn't think it would sell. I just meant that people have a larger tolerance for non-Microsoft GUI design ideas than I thought up to now. JimA From skip@mojam.com (Skip Montanaro) Thu Oct 26 21:10:33 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? Message-ID: <14840.36793.19348.903534@beluga.mojam.com> Just came across this error while running configure: checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The problem was that /tmp was full - sort of. The system says there's no space: % cat /etc/termcap > /tmp/termcap bash: /tmp/termcap: No space left on device but df disagrees: % df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 153667 88796 56935 61% / Short term workaround is to run configure with TMPDIR set somewhere else. Perhaps this is something to put in a gcc-specific or Unix-specific section of the README file. I didn't see anything, and the message emitted by configure gave no hint at the cause of the problem. I realized what it was because I've been scratching my head about this problem for a couple weeks. If this is deemed useful I'll modify README and check it in. If not, no big deal. (I have no idea why the system thinks /tmp is full... sigh ...) Skip From cgw@fnal.gov Thu Oct 26 21:14:53 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com> References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov> Skip Montanaro writes: > > Just came across this error while running configure: > > checking for gcc... gcc > checking whether the C compiler (gcc ) works... no > configure: error: installation or configuration problem: C compiler cannot create executables. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. Personally, I don't think this is useful. I don't think the Python README is the place to list everything that can go wrong during ./configure. The generic advice is "If something goes wrong during ./configure, read through config.log to see what went wrong" I'm curious what is in your config.log when this error occurs! From nas@arctrix.com Thu Oct 26 14:29:49 2000 From: nas@arctrix.com (Neil Schemenauer) Date: Thu, 26 Oct 2000 06:29:49 -0700 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001026062949.A14618@glacier.fnational.com> > The problem was that /tmp was full - sort of. You might try "df -i". You could be out inodes but still have blocks. Neil From guido@python.org Thu Oct 26 22:29:33 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 16:29:33 -0500 Subject: [Python-Dev] Gradual migration PEP In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST." <39F83F7C.2241158F@prescod.net> References: <39F83F7C.2241158F@prescod.net> Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com> Paul, Your deprecation PEP looks good. A few comments: - I think that the one-year period may depend on the feature. Some may require an even longer time. Others less. - I think there will be cases where run-time checks are the only way to detect use of the old feature (e.g. I'm still struggling with how to change the division semantics). But this shouldn't stop it from becoming a PEP. Please arrange for a PEP number with Barry, the PEPmaster. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas@xs4all.net Thu Oct 26 23:58:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 00:58:41 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700 References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <20001027005841.R12812@xs4all.nl> On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote: > > The problem was that /tmp was full - sort of. > You might try "df -i". You could be out inodes but still have > blocks. Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks, or some other filesystem resource. Not often the case for something like /tmp, but definately possible on some filesystems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Fri Oct 27 00:02:24 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 01:02:24 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001027010224.S12812@xs4all.nl> On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote: > Short term workaround is to run configure with TMPDIR set somewhere else. > Perhaps this is something to put in a gcc-specific or Unix-specific section > of the README file. I didn't see anything, and the message emitted by > configure gave no hint at the cause of the problem. I realized what it was > because I've been scratching my head about this problem for a couple weeks. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. If you start adding things like that, also consider all the other possibilities of configure being wrong. I hinted at one of them a couple of weeks back, I think. (Somehow, 'last saturday', when I headed for London for the Apachecon, feels like about two months ago :P) It's perfectly possible for configure to be able to run gcc, gcc to be able to create working binaries, but every check for a function or datatype failing because the more 'involved' include files are missing. This is easy to do on Linux, (removing /usr/src/linux, for instance) but not impossible on other systems either. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From greg@cosc.canterbury.ac.nz Fri Oct 27 01:21:26 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001027005841.R12812@xs4all.nl> Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz> Thomas Wouters : > Or failing that, it could be out of 'indirect' or 'doubly-indirect' > blocks, I think they're allocated from the same pool as data blocks. What *can* happen is that you can run out of "large" blocks. The BSD-style filesystem stores files bigger than 8k in blocks made up of 8 contiguous 1k blocks. If the filesystem is nearly full, or contains a large number of small files, you can find that it's impossible to create any more files > 8k, even though there appears to be plenty of free space, because the space is too fragmented. I don't think that's what's happening here, though, since I've only ever seen it happen when the filesystem was about 99% full. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From tim_one@email.msn.com Fri Oct 27 02:13:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 26 Oct 2000 21:13:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F8872B.92D69403@interet.com> Message-ID: [Guido] > are you saying that your own installer can install the > Python DLL but not the Tk DLL? [James Ahlstrom] > Not exactly. I am saying I don't want to use the standard > Python Windows installer. And I am saying I don't want to install > Tk because it is big, complicated, and requires Tcl and its libraries. > > My installer does install the Python DLL python15.dll, so > I guess I could study how to install Tk and duplicate the > functionality of the Windows installer, and install Tk too. > But why would I want to? That's up to you and your customers. What Guido has been telling you is that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is trivial: it merely copies some Tcl/Tk files into the Python installation tree. It no longer runs the Scriptics installer, mucks with the path, changes any envars, copies any files to outside of the Python tree, or even sets anything up in the registry for Tcl/Tk. You may not *want* to install Tcl/Tk, but, if you would like to, there's no longer any basis for fearing it's difficult, obscure, delicate or error-prone. don't-know-about-those-wrt-other-gui-pkgs-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Fri Oct 27 04:54:51 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov> References: <14840.36793.19348.903534@beluga.mojam.com> <14840.37053.829696.379140@buffalo.fnal.gov> Message-ID: <14840.64651.444849.757658@beluga.mojam.com> Charles> The generic advice is "If something goes wrong during Charles> ./configure, read through config.log to see what went wrong" Agreed. Charles> I'm curious what is in your config.log when this error occurs! That's why I was thinking ("hmmm... perhaps a README bit"). It wasn't giving me obvious "no space" messages. I've concluded that it's probably best to forget it anyway. If it's a problem with configure or gcc messages, it's best addressed there. Skip From skip@mojam.com (Skip Montanaro) Fri Oct 27 04:57:00 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com> References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <14840.64780.673428.672300@beluga.mojam.com> Neil> You might try "df -i". You could be out inodes but still have Neil> blocks. Thanks, that indeed seems to be the problem: % df -i /tmp Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 39k 39k 7 100% / I don't believe in all my years of fiddling with Unix systems I've ever run out of inodes with a third of the disk space left. Now to identify the culprit. Skip From mal@lemburg.com Fri Oct 27 11:15:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 27 Oct 2000 12:15:53 +0200 Subject: [Python-Dev] Starship is still down... Message-ID: <39F955D9.279864FD@lemburg.com> It's been over a week since I posted my last gripe about our community server starship being unreachable. Nothing has happened so far... is there any chance on getting the server up and running again ? I am a bit concerned about the lack of support here: starship should be considered a very important part in the Python universe (after all, many Python extension packages and goodies are available from that site). With the frequent downtimes we recently had, I think people will get a wrong picture about the Python community support. Here's a traceroute from Germany to starship: traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets 1 193.158.137.129 (193.158.137.129) 24 ms 23 ms 23 ms 2 193.158.137.130 (193.158.137.130) 24 ms 35 ms 25 ms 3 D-gw13.D.net.DTAG.DE (212.185.10.22) 67 ms 24 ms 35 ms 4 K-gw13.K.net.DTAG.DE (194.25.124.137) 26 ms 25 ms 25 ms 5 F-gw13.F.net.DTAG.DE (194.25.121.101) 32 ms 33 ms 33 ms 6 TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98) 113 ms 127 ms 131 ms 7 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113) 115 ms 117 ms 134 ms 8 mae-east-switch0.maee.above.net (208.184.210.9) 134 ms 114 ms 123 ms 9 core1-mae-east-oc3-1.iad.above.net (209.133.31.225) 122 ms 116 ms 115 ms 10 sjc2-iad-oc48.sjc2.above.net (216.200.127.26) 184 ms 186 ms 185 ms 11 core5-core3-oc48.sjc2.above.net (208.185.156.66) 183 ms 184 ms 186 ms 12 sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37) 299 ms 183 ms !H 188 ms !H 13 * * * 14 * * * ... It looks as if ABOVE.NET is having some serious routing problems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Fri Oct 27 11:43:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 27 Oct 2000 06:43:22 -0400 Subject: [Python-Dev] Starship is still down... In-Reply-To: <39F955D9.279864FD@lemburg.com> Message-ID: [MAL] > It's been over a week since I posted my last gripe about > our community server starship being unreachable. Afraid Manus Head still gets the Most Outraged award for this one. > Nothing has happened so far... is there any chance on getting the server > up and running again ? Works for me, but only very recently. OTOH, my posts to python.org mailing lists started black-holing, so it's not like Python-Dev will actually see this post . Here's a trace from my box (in Virginia); it may take a while for recent routing changes to propagate: 1 tnt32.tco2.da.uu.net [206.115.222.61] 2 GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2] 3 156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50] 4 517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198] 5 294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26] 6 POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25] 7 137.39.52.102 8 beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139] 9 sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42] 10 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139] 11 pacbellpsfoc3.ca.us.prserv.net [165.87.161.5] 12 core3-g2-0.snfc21.pbi.net [209.232.130.78] 13 rback26-fe2-0.snfc21.pbi.net [216.102.187.153] 14 adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65] 15 starship.python.net [63.202.160.91] > I am a bit concerned about the lack of support here: starship > should be considered a very important part in the Python > universe (after all, many Python extension packages and goodies > are available from that site). With the frequent downtimes > we recently had, I think people will get a wrong picture about > the Python community support. They're getting an accurate view of current Starship support. So it goes. Plans for better support *are* in progress, but for reasons that won't become clear until later, you haven't heard anything about them yet. for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs - tim From jim@interet.com Fri Oct 27 13:23:11 2000 From: jim@interet.com (James C. Ahlstrom) Date: Fri, 27 Oct 2000 08:23:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F973AF.80D3BDBE@interet.com> Tim Peters wrote: > That's up to you and your customers. What Guido has been telling you is > that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is > trivial: it merely copies some Tcl/Tk files into the Python installation > tree. It no longer runs the Scriptics installer, mucks with the path, Oh, OK. That is much better. JimA From skip@mojam.com (Skip Montanaro) Fri Oct 27 17:15:55 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT) Subject: [Python-Dev] Starship is still down... In-Reply-To: References: <39F955D9.279864FD@lemburg.com> Message-ID: <14841.43579.261191.986406@beluga.mojam.com> Tim> Here's a trace from my box (in Virginia); ... Tim's trace doesn't show times. Looks to me like Pacbell is having trouble (note the huge leap in response time): ... 13 beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50) 30.387 ms 27.426 ms 28.392 ms 14 beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139) 27.614 ms 27.349 ms 27.250 ms 15 sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42) 71.581 ms 72.535 ms 72.429 ms 16 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139) 71.635 ms 71.420 ms 71.483 ms 17 pacbellpsfoc3.ca.us.prserv.net (165.87.161.5) 71.070 ms 71.606 ms 71.301 ms 18 core4-g2-0.snfc21.pbi.net (209.232.130.77) 70.986 ms 71.129 ms 73.628 ms 19 rback26-fe2-0.snfc21.pbi.net (216.102.187.153) 72.696 ms 77.658 ms 83.046 ms 20 adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65) 3841.343 ms 3705.648 ms 3911.584 ms 21 adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91) 3683.340 ms 3867.550 ms 3653.732 ms Skip From petrilli@amber.org Fri Oct 27 21:15:18 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Fri, 27 Oct 2000 16:15:18 -0400 Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: ; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200 References: <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <20001027161518.B3942@trump.amber.org> Peter Funk [pf@artcom-gmbh.de] wrote: > > It will take years, before MacOS X will find its way onto the desk > of the average Apple Mac user. The Mac s mostly used in the graphics > and printing industry (our cutsomers) where people normally don't > even think about a OS upgrade, if they don't have to. They usually > run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other > so called creative software on the version of the OS they had on > the machine when they bought it. THese machines are usually used > through a period of at least four years. I think this is a bit incorrect. Almost every Mac user that I interact with (including all the users hre at Digital Creations) have OS X running and using it at various levels. Mostly it's waiting for people like Adobe to release Carbon applications. Graphics designers will be the first to move to OS X, not thel ast, as they will ge the most fromt he increased stability and performance. It all depends on your market. The best goal for Mac OS would be to aim at full Carbon compliance, and not write to Cocoa, or to the original MacOS toolkit. This would let you run on all releases after 8.0 I believe (maybe even 7.6). Chris -- | Christopher Petrilli | petrilli@amber.org From guido@python.org Sat Oct 28 02:42:42 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 27 Oct 2000 20:42:42 -0500 Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com> To all Python users and developers: Less than half a year ago, I moved with my team to BeOpen.com, in the hope of finding a new permanent home for Python development. At BeOpen, we've done several good things for Python, such as moving the Python and Jython development process to SourceForge, and the successful release of Python 2.0. Unfortunately, BeOpen.com's original plans for PythonLabs didn't work out as hoped, and we weren't able to reach mutual agreement on workable alternative plans -- despite trying for months. I am proud to have found a new home for my entire team: starting today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself are working for Digital Creations. We will be spending part of our time on core Python development (including Jython and Mailman) and part of our time on Python infrastructure improvements that also benefit Zope. Python will remain Open Source; Digital Creations has no desire to monetize or brand the Python language or specific Python distributions. All future work we do on Python as Digital Creations employees will be owned by a non-profit organization yet to be created. We think of this new organization as the Python Software Foundation. In the meantime (while the PSF is under construction) I will own such copyrights personally. We're excited to be working for Digital Creations: they are one of the oldest companies active in the Python community, one of the companies most committed to Python, and they have a great product! Plus, we know they have deep financial backing. We trust that Digital Creations will provide a stable home for Python for many years. Digital Creations has also offered to take over hosting of the python.org and starship sites. On behalf of the Python community, we're grateful for this support of the two prime community sites for Python, and we expect to be implementing the transitions shortly. These are exciting times for the PythonLabs team -- and also for Python and its community. Mainstream successes for Python are showing up everywhere, and we're proud to be a part of such a smart and friendly community. A great year lies ahead! --Guido van Rossum (home page: http://www.python.org/~guido/) From jim@digicool.com Sat Oct 28 03:45:02 2000 From: jim@digicool.com (Jim Fulton) Date: Fri, 27 Oct 2000 22:45:02 -0400 Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations References: Message-ID: <39FA3DAE.ADB2C8B1@digicool.com> Guido van Rossum wrote: > (snip) > I am proud to have found a new home for my entire team: starting > today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself > are working for Digital Creations. We will be spending part of our > time on core Python development (including Jython and Mailman) and > part of our time on Python infrastructure improvements that also > benefit Zope. Needless to say (but I'll say it anyway), Digital Creations is proud and thrilled that the this team has joined us. These are indeed exciting times! Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org From martin@loewis.home.cs.tu-berlin.de Sat Oct 28 11:14:00 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:14:00 +0200 Subject: [Python-Dev] getting at the current frame Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> > which actually will look something like this in real code: > > def trade(yours, mine): > print _('if you give me %(yours)s, i will give you %(mine)s') % { > 'yours': yours, > 'mine' : mine, > } > > The string wrapped in _() is what gets translated here. > > Okay, we all know that's a pain, right? What's wrong with def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % vars() Look Ma, no magic! Regards, Martin From effbot@telia.com Sat Oct 28 11:43:05 2000 From: effbot@telia.com (Fredrik Lundh) Date: Sat, 28 Oct 2000 12:43:05 +0200 Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com> Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid> fred wrote: > At any rate, there has been activity in the source tree; you just > might want to do a CVS update to see what's changed. There have been > a number of bug fixes, a fair number of documentation updates, and > many of the modules in the standard library have been passed through > Tim Peter's reindent.py script (look in Tools/scripts/). now that this has been done, emacs users might want to add something like the following to their local configuration (based on code by jwz, so it should work...) ::: (defun python-mode-untabify () (save-excursion (goto-char (point-min)) (while (re-search-forward "[ \t]+$" nil t) (delete-region (match-beginning 0) (match-end 0))) (goto-char (point-min)) (if (search-forward "\t" nil t) (untabify (1- (point)) (point-max)))) nil) (add-hook 'python-mode-hook '(lambda () (make-local-variable 'write-contents-hooks) (add-hook 'write-contents-hooks 'python-mode-untabify))) From martin@loewis.home.cs.tu-berlin.de Sat Oct 28 11:51:20 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:51:20 +0200 Subject: [Python-Dev] build problems under Solaris Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de> > I don't have access to a Solaris machine, so I can't do anything to > help these users. The patch in 117606 looks right to me: gcc on Solaris (and on any other platform) needs -shared to build shared library; configure currently passes -G. I haven't actually tried the patch, since it is a pain to extract it from the SF bug report page. What happens is that gcc passes -G to the linker, which correctly produces a shared library. However, gcc also links crt1/crti into the library, which causes the reference to main. 117508 looks like a user error to me. On its own, configure would not try to link -ldb, unless it detects the presence of db.h. My guess is that there is a libdb in /usr/local, so a gcc configure finds it, whereas the native compiler doesn't. Later, the linker even finds a -ldb library, but somehow this doesn't have dbopen. So it could be that the BSDDB installation on that system is screwed. Regards, Martin From barry@scottb.demon.co.uk Sat Oct 28 12:14:45 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:14:45 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <000601c040d0$474ce1d0$060210ac@private> > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. Integrating C++ and Python well is hard in a general library. CXX tries to make objects that look and feel like Python objects. But to do that we have to figure out the details of how python uses objects. You have no docs on the subject so we read the source code. Barry CXX maintainer From barry@scottb.demon.co.uk Sat Oct 28 12:23:50 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:23:50 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F80C30.5448.52D32F94@localhost> Message-ID: <000701c040d1$8beecf00$060210ac@private> [Gordon wrote] > All of the existing C++ interfaces / helpers deal only with type > objects (at least, those that I've examined, which is most of > them). In fact, only ExtensionClass attempts to deal with the > class / type split, and while it's a masterpiece, I think it's a > great example of everything to avoid in Py3K. Py_Cpp support C++ classes you can derived from in Python. Once I get my head around the proxy interface I'll try and add that to CXX. CXX today allows you to create C++ class that you can use from Python, but not derive from. Barry CXX maintainer From Moshe Zadka Sun Oct 29 07:59:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST) Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote: > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they > didn't know where the online copy was. I can send the update notice > to python-dev instead of just to myself if everyone wants it, or I can > send it to some other (appropriate) list. I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that means I'm getting it twice. My foot is used to being shot at though) -- Moshe Zadka -- 95855124 http://advogato.org/person/moshez From barry@wooz.org Mon Oct 30 16:14:53 2000 From: barry@wooz.org (barry@wooz.org) Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST) Subject: [Python-Dev] Re: getting at the current frame References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> Message-ID: <14845.40573.917058.905009@anthem.concentric.net> >>>>> "MvL" == Martin v Loewis writes: MvL> What's wrong with MvL> def trade(yours, mine): print _('if you give me MvL> %(yours)s, i will give you %(mine)s') % vars() MvL> Look Ma, no magic! Except that I also want globals() to be included and vars() doesn't include that. I really want: d = globals().copy() d.update(locals()) but I've also noticed that you sometimes want attribute following so you can do things like _('the name of the list is %(mlist.listname)') -Barry From barry@wooz.org Mon Oct 30 17:35:25 2000 From: barry@wooz.org (Barry A. Warsaw) Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213 References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <14845.45405.867829.722598@anthem.concentric.net> Well, it looks like checkin messages are flowing again. Yay! From mal@lemburg.com Mon Oct 30 17:54:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 30 Oct 2000 18:54:50 +0100 Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <39FDB5EA.B60EA39A@lemburg.com> Jeremy Hylton wrote: > > Update of /cvsroot/python/python/dist/src/Python > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python > > Modified Files: > ceval.c > ... > N.B. The CALL_FUNCTION implementation is getting really hairy; should > review it to see if it can be simplified. How about a complete redesign of the whole call mechanism ?! I have an old patch somewhere which reorganizes the Python calling mechanism into something more sane than what we have in ceval.c now. Should I try to find it for someone to use as basis for the reorg (don't have time for this myself) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy@alum.mit.edu Mon Oct 30 14:59:00 2000 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST) Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com> References: <200010301715.JAA32564@slayer.i.sourceforge.net> <39FDB5EA.B60EA39A@lemburg.com> Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net> >>>>> "MAL" == M -A Lemburg writes: MAL> Jeremy Hylton wrote: >> >> Update of /cvsroot/python/python/dist/src/Python In directory >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python >> >> Modified Files: ceval.c ... N.B. The CALL_FUNCTION >> implementation is getting really hairy; should review it to see >> if it can be simplified. MAL> How about a complete redesign of the whole call mechanism ?! MAL> I have an old patch somewhere which reorganizes the Python MAL> calling mechanism into something more sane than what we have in MAL> ceval.c now. MAL> Should I try to find it for someone to use as basis for the MAL> reorg (don't have time for this myself) ? I'd be interested in looking at it. Jeremy From tim_one@email.msn.com Mon Oct 30 19:36:55 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:36:55 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? Message-ID: C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall test_extcall test test_extcall failed -- Writing: '3', expected: '' 1 test failed: test_extcall C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v test_extcall test_extcall test_extcall () {} (1,) {} (1, 2) {} (1, 2, 3) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3) {'b': 5, 'a': 4} (1, 2, 3, 4, 5) {'b': 7, 'a': 6} (1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8} TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 1 () {} 1 (2,) {} 1 (2, 3) {} 1 (2, 3, 4, 5) {} 0 (1, 2) {} 1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} keyword parameter 'x' redefined in call to g() keyword parameter 'b' redefined in function call keywords must be strings h() got an unexpected keyword argument 'e' * argument must be a sequence ** argument must be a dictionary 3 512 1 3 3 unbound method must be called with instance as first argument unbound method must be called with instance as first argument 1 test OK. From fdrake@acm.org Mon Oct 30 20:38:09 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com> Tim Peters writes: > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall > > test_extcall > test test_extcall failed -- Writing: '3', expected: '' > 1 test failed: test_extcall I get the same thing on Linux. The output appears identical to what Tim got. -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From jeremy@alum.mit.edu Mon Oct 30 16:48:08 2000 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net> This output matches the output file I just checked in under Lib/test/output/test_extcall. Looks like I failed to check in this change. Jeremy From tim_one@email.msn.com Mon Oct 30 19:54:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:54:14 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: [Jeremy] > This output matches the output file I just checked in under > Lib/test/output/test_extcall. Looks like I failed to check in this > change. Thank you -- works on Windows now. It should work on Linux too, if Linux knows what's good for it . From fdrake@acm.org Mon Oct 30 20:56:13 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com> Tim Peters writes: > Thank you -- works on Windows now. It should work on Linux too, if Linux > knows what's good for it . It does. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From guido at python.org Sun Oct 1 07:31:43 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 01 Oct 2000 00:31:43 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> I'm considering to issue a release candidate before the final 2.0 release. I'd like to poll opinions about this (we haven't had a PythonLabs group meeting about this yet). The importance of a release candidate (RC) is twofold: we announce it widely so it (hopefully) gets a lot of testing -- necessary since a lot of things have changed again since beta2; and we impose a checkin stop once the RC is out, with exceptions only allowed by the release manager to fix showstopper bugs found in the RC. This will hopefully avoid a disaster like we had with the buggy last-minute changes in beta2 (for which I take full responsibility). If the idea of a RC sounds okay, I'd like to propose to release it on October 5. The final release would still be on October 10, or perhaps 1-2 days later. Much less than a week between the RC and the final release is not good because it doesn't give testers enough time to try out the RC; much more than a week is bad because the developers get antsy when they can't check in their changes! This means that any current bug reports and patches that aren't in the RC, WON'T BE FIXED in the final release! Think about it. This is a good thing, so we won't be able to screw up the final release at the last moment. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Sun Oct 1 14:06:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 1 Oct 2000 14:06:48 +0200 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500 References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <20001001140648.A12812@xs4all.nl> On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote: > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for some lunch/breakfast ;) I would be in favor if the str() output were only used to display something to a user, but that's not the case. And too many people are under the impression that the 'print' handler is the same as the 'str' handler to make that distinction now, I'm afraid. My main gripe with this change is that it makes str() for container objects unreliable... Strings are a special case, but class-instances are not -- so something like UserString will be displayed without quotes. I don't like the idea of sometimes doing 'str' and sometimes doing 'repr'. I understand what it's trying to solve, but I don't think that's a worse inconsistency than the one this change introduces. It's also easy to explain: 'str(list or dict) is the same as repr(list or dict)'. The new phrase would be something like 'str(list or dict) calls str() on the objects it contains, except for string and unicode objects.'. And even that breaks when you mix in instances that wrap a container. A list containing a UserList containing a set of (unicode-)strings would display the strings without quotes. And you can't see that the second container is a UserList. I also don't think this change should be made between the final beta and 2.0. Jeremy, don't let him ruin your feature freeze! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jim at digicool.com Sun Oct 1 16:32:27 2000 From: jim at digicool.com (Jim Fulton) Date: Sun, 01 Oct 2000 10:32:27 -0400 Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR) Message-ID: <39D74AFB.322E5187@digicool.com> If a select-based (or, presumably, poll-based) server wants to use signals for anything other than shutdown (e.g. closing and reopening log files, rereading configs, etc.), then, on some platforms, a select call can fail with an "interrupted system call" (EINTR) error that should be ignored. The asyncore main loop should check for this error in it's select call and the select module should make this error easier to check for. In Python 1.5.2, the medusa select call can be changed from r,w,e = select.select (r,w,e, timeout) to: while 1: try: r,w,e = select.select (r,w,e, timeout) except select.error, v: if v[0] != EINTR: raise else: break I presume that this works in Python 1.6/2.0, but I haven't tried it yet? This depends on the structure of select.error values and requires that we get EINTR from somewhere. (What should the value be on NT?) I wonder if there should be an InterruptedSystemCall exception somewhere that select raises in this case? At a minimum, code like the above should be added to asyncore. Thoughts? Jim -- Jim Fulton mailto:jim at digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From rushing at nightmare.com Sun Oct 1 21:07:59 2000 From: rushing at nightmare.com (Sam Rushing) Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT) Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR) In-Reply-To: <39D74AFB.322E5187@digicool.com> References: <39D74AFB.322E5187@digicool.com> Message-ID: <14807.35727.423642.721873@seattle.nightmare.com> Jim Fulton writes: > The asyncore main loop should check for this error in it's select > call and the select module should make this error easier to check > for. It might go better into the event_loop function, which I think of as a more user-serviceable part. [for example, the default loop vs. the one in medusa/event_loop.py that supports schedulable events] > I presume that this works in Python 1.6/2.0, but I > haven't tried it yet? > > This depends on the structure of select.error values > and requires that we get EINTR from somewhere. (What > should the value be on NT?) If it's a big problem, I guess we could use a different default event_loop() function for win32 vs. unix. > At a minimum, code like the above should be added to asyncore. > > Thoughts? This has been asked for several times, I agree it'd be nice to have at least a note in the docs.. -Sam From loewis at informatik.hu-berlin.de Sun Oct 1 21:13:41 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> > I'd like to poll opinions about this (we haven't had a PythonLabs > group meeting about this yet). YES! I was hoping somebody would propose such a thing; I was quite concerned that check-in procedures are still that liberate. To report how similar projects operate: In gcc, a CVS release branch is created at some point in time (usually months before the release). When the code is declared frozen, all changes to the release branch have to go through the release manager. After the release, "important" changes to the mainline branch are manually propagated to the release branch for subminor releases. Regards, Martin From dkwolfe at pacbell.net Sun Oct 1 23:23:03 2000 From: dkwolfe at pacbell.net (Dan Wolfe) Date: Sun, 01 Oct 2000 14:23:03 -0700 Subject: [Python-Dev] FW: regarding the Python Developer posting... Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net> >> [commented out code that was causing seg fault in test_sre.py] >you could try adding a Mac OS clause to the recursion limit stuff >in Modules/_sre.c: > >#if !defined(USE_STACKCHECK) >#if defined(...whatever's needed to detect Max OS X...) [....] > >replace "...whatever...", and try larger values than 5000 (or smaller, >if necessary. 10000 is clearly too large for your platform). > >(alternatively, you can increase the stack size. maybe it's very small >by default?) the stack size is quite small by default - 512K. After some testing I was able to figure out that it fails around 440 recursions... probably a bit too small in comparison to the other *nixes.... but then I'll defer to the experts in sre. I was reading the August developer archives on the getrlimit and since that seem to be available, it's probably the right way to implement the stack check on Mac OS X. Sure I can increase the default stack size - just a simple limit -h before running it in the shell... I let it run until about 7K recursions... even then it was only about 11MB and bumping the stack up by 30K or so per recursion... and I still had nearly 100MB free... and places to go. :-) I'm going to write a bug report against Mac OS X and we'll see what happens. In the meantime, you can hard code it to 440 and it will pass the test... I've placed a patch on sourceforge that give the initial support for detecting Mac OS X as part of the make file but I still have to figure out how/where you defined MS_WIN64.... - Dan From barry at scottb.demon.co.uk Mon Oct 2 00:19:21 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 1 Oct 2000 23:19:21 +0100 Subject: [Python-Dev] Patch to avoid conflict with older versions of Python. In-Reply-To: Message-ID: <000b01c02bf5$a5edf070$060210ac@private> I still think that Python needs to fix the problem with the API between the core and the extensions. That way all the version checking would work for Windows and Unix. But since that approach has been rejected I'd take any change to python that reduces support calls. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Mark Hammond > Sent: 29 September 2000 02:36 > To: python-dev at python.org > Subject: [Python-Dev] Patch to avoid conflict with older versions of > Python. > > > Hi all, > I'd like some feedback on a patch assigned to me. It is designed to > prevent Python extensions built for an earlier version of Python from > crashing the new version. > > I haven't actually tested the patch, but I am sure it works as advertised > (who is db31 anyway?). > > My question relates more to the "style" - the patch locates the new .pyd's > address in memory, and parses through the MS PE/COFF format, locating the > import table. If then scans the import table looking for Pythonxx.dll, and > compares any found entries with the current version. > > Quite clever - a definite plus is that is should work for all old and > future versions (of Python - dunno about Windows ;-) - but do we want this > sort of code in Python? Is this sort of hack, however clever, going to > some back and bite us? > > Second related question: if people like it, is this feature something we > can squeeze in for 2.0? > > If there are no objections to any of this, I am happy to test it and check > it in - but am not confident of doing so without some feedback. > > Thanks, > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From mal at lemburg.com Mon Oct 2 09:36:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:36:49 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <39D83B11.C1DE9EE8@lemburg.com> Martin von Loewis wrote: > > > I'd like to poll opinions about this (we haven't had a PythonLabs > > group meeting about this yet). > > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. > > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. +1 I think this is very good approach to the problem which we should consider to apply to Python too. BTW, could the nightly snapshots of the CVS tree that Jeremy installed be made official ? This would be a great way to attract more beta-tester since not everyone is willing to first set CVS on their machine just to download the current Python development version. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Oct 2 09:39:09 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:39:09 +0200 Subject: [Python-Dev] What is --with-next-framework Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> I've been trying to understand how --with-next-framework is supposed to work, and on what systems it is supposed to work - with little success. From what I understand, it will create a python2.0.dylib, and it will pass that to the linker when linking extension modules. Fine. What confuses me is the snippet in Modules/getpath.c, where it somehow assumes that the Python library will live in an unversioned lib directory relative to the location of the Python framework. How is that supposed to work? Is anybody here willing to claim that this code is not entirely broken? Regards, Martin From mal at lemburg.com Mon Oct 2 09:51:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:51:37 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <39D83E89.62F57D79@lemburg.com> Guido van Rossum wrote: > > When we changed floats to behave different on repr() than on str(), we > briefly discussed changes to the container objects as well, but > nothing came of it. > > Currently, str() of a tuple, list or dictionary is the same as repr() > of those objects. This is not very consistent. For example, when we > have a float like 1.1 which can't be represented exactly, str() yields > "1.1" but repr() yields "1.1000000000000001". But if we place the > same number in a list, it doesn't matter which function we use: we > always get "[1.1000000000000001]". > > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. > > Is it too late to check this in? Another negative consequence would > be that for user-defined or 3rd party extension objects that have > different repr() and str(), like NumPy arrays, it might break some > code -- but I think this is not very likely. -1 I don't think that such a change is really worth breaking code which relies on the current output of repr(list) or str(list). As the test script from Fredrik for the Unicode database showed there are some very subtle implications to changes in str() and repr() -- e.g. in the mentioned case the hash value would change. Also, if I understand the patch correctly, str(list) would be almost the same as '[' + ', '.join(map(str, entries)) + ']' and '[' + ', '.join(map(repr, entries)) + ']' for repr(). While this may seem more transparent, I think it will cause problems in practice: e.g. for large data buffers, str(list) would now return the contents of the buffers rather than just an abstract note about a buffer containing the memory mapped data of file xyz.txt. As consequence, you'd suddenly get a few MBs of output instead of a 100 char string... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Oct 2 09:48:37 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:48:37 +0200 Subject: [Python-Dev] Usage of --with- configure options Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> I noticed that Python's configure.in does not follow the autoconf style for using --enable- options. The autoconf documentation says # Some packages require, or can optionally use, other software packages # which are already installed. The user can give `configure' command # line options to specify which such external software to use. The # options have one of these forms: # # --with-PACKAGE[=ARG] # --without-PACKAGE ... # If a software package has optional compile-time features, the user # can give `configure' command line options to specify whether to compile # them. The options have one of these forms: # # --enable-FEATURE[=ARG] # --disable-FEATURE So --with- options should be used for integrating 3rd party libraries, --enable- options for features that that can be independently turned on or off. I'd conclude that the following options are provided incorrectly in Python 2.0: --with-pydebug (should be --enable-pydebug), --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something that should change? Regards, Martin From guido at python.org Mon Oct 2 13:30:45 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:30:45 -0500 Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200." <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com> > I noticed that Python's configure.in does not follow the autoconf > style for using --enable- options. The autoconf documentation says > > # Some packages require, or can optionally use, other software packages > # which are already installed. The user can give `configure' command > # line options to specify which such external software to use. The > # options have one of these forms: > # > # --with-PACKAGE[=ARG] > # --without-PACKAGE > ... > # If a software package has optional compile-time features, the user > # can give `configure' command line options to specify whether to compile > # them. The options have one of these forms: > # > # --enable-FEATURE[=ARG] > # --disable-FEATURE > > So --with- options should be used for integrating 3rd party libraries, > --enable- options for features that that can be independently turned > on or off. > > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? I noticed that too. (Arguably also for --with-thread?) I think it's a forgiveable sin against the autoconf style guide, and not worth the work of fixing it. Either way the autoconf --with- or --enable- syntax is stupid because it doesn't check for spelling errors in the options. The rationale for that is that some folks like to pass in unsupported options to a whole tree of configure scripts. I think that stinks, but what can I do. This would make the fix even more work, because we would have to trap --with*-pydebug and --with*-cycle-gc to give an error message, else developers used to the old syntax would never notice the change. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 13:35:40 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:35:40 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200." <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com> > I've been trying to understand how --with-next-framework is supposed > to work, and on what systems it is supposed to work - with little > success. > > From what I understand, it will create a python2.0.dylib, and it will > pass that to the linker when linking extension modules. Fine. > > What confuses me is the snippet in Modules/getpath.c, where it somehow > assumes that the Python library will live in an unversioned lib > directory relative to the location of the Python framework. How is > that supposed to work? Is anybody here willing to claim that this code > is not entirely broken? It's most likely broken. Which suggests that nobody has tried it in a *looooooong* time. I have no idea what the --with-next-framework option does, and I have no idea what a NeXT framework is. Why are we still trying to support NeXT? Isn't it completely obsolete? I propose to rip out --with-next-framework and be done with it. If you feel --with-next-framework is worth having, feel free to propose platform-specific fixes to getpathp.c. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Oct 2 15:22:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT) Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? Yes, if only to make it more consistent with existing practice. A harder one to change would be --enable-threads, because we've used that for so long already. Perhaps --enable-threads should be added, and use that in the README instead of --with-threads. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fredrik at pythonware.com Mon Oct 2 15:41:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 15:41:21 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF> guido wrote: > If the idea of a RC sounds okay Sure does. > I'd like to propose to release it on October 5. Hmm. My plan was to to work on the remaining SRE issues on Saturday, leaving Sunday-Tuesday for final "burn-in"... From petrilli at amber.org Mon Oct 2 16:14:23 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 10:14:23 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> Message-ID: <20001002101423.A18958@trump.amber.org> Guido van Rossum [guido at python.org] wrote: > > I've been trying to understand how --with-next-framework is supposed > > to work, and on what systems it is supposed to work - with little > > success. > > > > From what I understand, it will create a python2.0.dylib, and it will > > pass that to the linker when linking extension modules. Fine. > > > > What confuses me is the snippet in Modules/getpath.c, where it somehow > > assumes that the Python library will live in an unversioned lib > > directory relative to the location of the Python framework. How is > > that supposed to work? Is anybody here willing to claim that this code > > is not entirely broken? > > It's most likely broken. Which suggests that nobody has tried it in a > *looooooong* time. I have no idea what the --with-next-framework > option does, and I have no idea what a NeXT framework is. A NeXT Framework is a way of building software on NeXTstep/OpenStep machines, and as far as I can tell, it continues largely unmodified on MacOS X (which is more OpenStep than MacOS at many layers). We just got our development copies of MacOS X here at Digital Creations, so we can take a look, but... as I recall, Jeffrey Shell wasn't able to get Python running without using these options. > Why are we still trying to support NeXT? Isn't it completely > obsolete? I know of a few dozen large organizations still on OpenStep, and with MacOS X I'd say it's far frrom obsolete, if anything it's more likely than ever to be a"strong platform". > I propose to rip out --with-next-framework and be done with it. If > you feel --with-next-framework is worth having, feel free to propose > platform-specific fixes to getpathp.c. I think it should be auto-detected, there's just no reason not to. The uname of a MacOS X box is quite different than a Mac OX 9 box (which has no uname :-). Hopefully we can get a chance to look at this at work this week. Chris -- | Christopher Petrilli | petrilli at amber.org From thomas at xs4all.net Mon Oct 2 19:23:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 2 Oct 2000 19:23:19 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700 References: <200010021553.IAA01251@slayer.i.sourceforge.net> Message-ID: <20001002192319.C12812@xs4all.nl> On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200 > Modified Files: > readline.c > Log Message: > Supporting rl_library_version is more trouble than it's worth -- > readline doesn't have it before readline 2.2 and there's no > compile-time way to find out which readline version is in use. But we can detect whether readline has rl_library_version during runtime, and #ifdef it ;) I think the readline version info is useful enough to warrant the extra #define and #ifdef... I can whip it up tonight, if the autoconf check is desired ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Mon Oct 2 20:54:31 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 13:54:31 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400." <20001002101423.A18958@trump.amber.org> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com> [Argument for the continued viability of OpenStep noted.] > I think it should be auto-detected, there's just no reason not to. > The uname of a MacOS X box is quite different than a Mac OX 9 box > (which has no uname :-). Hopefully we can get a chance to look at > this at work this week. Hm... That might not get there in time for the 2.0 Release Candidate, and after that it's an absolute code freeze (with exceptions only for showstopper bugfixes) until 2.0 is released. I guess MacOS X itself is still in beta, so we can afford to require the creation of additional patches to fully support it after 2.0 is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From petrilli at trump.amber.org Mon Oct 2 19:56:03 2000 From: petrilli at trump.amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 13:56:03 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com> Message-ID: <20001002135603.C18958@trump.amber.org> Guido van Rossum [guido at python.org] wrote: > [Argument for the continued viability of OpenStep noted.] > > > I think it should be auto-detected, there's just no reason not to. > > The uname of a MacOS X box is quite different than a Mac OX 9 box > > (which has no uname :-). Hopefully we can get a chance to look at > > this at work this week. > > Hm... That might not get there in time for the 2.0 Release Candidate, > and after that it's an absolute code freeze (with exceptions only for > showstopper bugfixes) until 2.0 is released. > > I guess MacOS X itself is still in beta, so we can afford to require > the creation of additional patches to fully support it after 2.0 is > released. MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's a 2.1 planned sometime around there, which I believe there is, then it'd be fine to roll it into that level in my opinion. Chris -- | Christopher Petrilli | petrilli at amber.org From guido at python.org Mon Oct 2 21:15:37 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:15:37 -0500 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200." <20001001140648.A12812@xs4all.nl> References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com> I guess Thomas has settled the fate of my str() patch -- UserString won't be dealt with properly. I hereby withdraw the patch. (I'm not sure what Marc-Andre means by buffer objects whose str() is long but whose repr() is short, but it's probably a similar issue.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 21:19:24 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:19:24 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200." <200010011913.VAA01107@pandora.informatik.hu-berlin.de> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com> > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. Good. We will have a release candidate then. > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. I am reluctant to use CVS branches (my experience with the branch for 1.6 suggests again that this is not at all smooth). About the timing for the release candidate (RC): I think we need a week +/- two days between the RC and the final release; this is needed to make sure that the RC is actually tried out by enough people and that the bug reports (if any) have been processed. I believe we can refrain from checkin in for a week but not much longer. Fredrik Lundh mentions that he can't get his final batch of SRE patches in before Saturday. So the only realistic timing is to do the RC on Monday (Oct 9) and the final release a week later (Oct 16). Everybody okay with this? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Oct 2 20:35:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 20:35:27 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com> Message-ID: <39D8D56F.F279B9E5@lemburg.com> Guido van Rossum wrote: > > I guess Thomas has settled the fate of my str() patch -- UserString > won't be dealt with properly. I hereby withdraw the patch. > > (I'm not sure what Marc-Andre means by buffer objects whose str() is > long but whose repr() is short, but it's probably a similar issue.) > Example for the record: >>> b = buffer('long string') >>> b >>> l = [b] >>> l [] >>> [str(b)] ['long string'] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nas at arctrix.com Mon Oct 2 13:48:59 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 04:48:59 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> Message-ID: <20001002044859.A9639@glacier.fnational.com> On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote: > So the only realistic timing is to do the RC on Monday (Oct 9) > and the final release a week later (Oct 16). > > Everybody okay with this? What is going to be the fate of the GC? There are currently two reported bugs which I have been unable to reproduce. If its going to be disabled for 2.0 then it should be disabled in the beta release. Neil From effbot at telia.com Mon Oct 2 21:11:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 21:11:58 +0200 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument References: <200010021341.GAA26413@bush.i.sourceforge.net> Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > Details: Split gives TypeError when called as a method of compiled > regular expression object with maxsplit as keyword argument. > This error is only in sre, pre is OK. > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > >>> import re > >>> patt = re.compile(' ') > >>> list = patt.split("a b c",50) # OK > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > >>> list = patt.split("a b c",maxsplit=50) # ERROR > Traceback (most recent call last): > File "", line 1, in ? > TypeError: this function takes no keyword arguments > > >>> import pre > >>> patt = pre.compile(' ') > >>> list = patt.split("a b c",maxsplit=50) # OK is this really a bug? should users expect to be able to use keyword arguments anywhere? From guido at python.org Mon Oct 2 22:09:32 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:09:32 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200." <20001002192319.C12812@xs4all.nl> References: <200010021553.IAA01251@slayer.i.sourceforge.net> <20001002192319.C12812@xs4all.nl> Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com> > But we can detect whether readline has rl_library_version during runtime, > and #ifdef it ;) I think the readline version info is useful enough to > warrant the extra #define and #ifdef... I can whip it up tonight, if the > autoconf check is desired ;P Actually, I'm not sure what difference the readline version makes -- why would you need it? Also, I'm not sure that the configure check is enough -- it's possible that readline lives in a non-standard place where configure can't find it but ppointed to by the Setup file. I think it's just not worth it. Please don't. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 22:18:57 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:18:57 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200." <003e01c02ca4$a7e2ef20$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com> > http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > > > Details: Split gives TypeError when called as a method of compiled > > regular expression object with maxsplit as keyword argument. > > This error is only in sre, pre is OK. > > > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > > >>> import re > > >>> patt = re.compile(' ') > > >>> list = patt.split("a b c",50) # OK > > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > > >>> list = patt.split("a b c",maxsplit=50) # ERROR > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: this function takes no keyword arguments > > > > >>> import pre > > >>> patt = pre.compile(' ') > > >>> list = patt.split("a b c",maxsplit=50) # OK > > is this really a bug? should users expect to be able to use > keyword arguments anywhere? Unclear, but the names were documented, and it worked before (when pattern objects were Python instances) -- so who knows how much code there's lying around that assumes this. Well, we know it's more than zero, because the bug report came from soemone who ran into this. :-) Can we at PythonLabs help by adding keyword arguments to all of the _sre.c functions? I presume it's a pretty straightforward change. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Mon Oct 2 21:35:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 21:35:45 +0200 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid> > Can we at PythonLabs help by adding keyword arguments to all of the > _sre.c functions? I presume it's a pretty straightforward change. if anyone can post (or point me to) an example showing how to use the keyword API, I can take if from there. From guido at python.org Mon Oct 2 23:06:00 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 16:06:00 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200." <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com> > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. Grep the Modules directory for PyArg_ParseTupleAndKeywords. It's used in the mmap, parser, pyexpat and sha modules. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Oct 2 22:04:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. This is documented in the Extending & Embedding manual. The parser module (Modules/parsermodule.c) uses this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH at ActiveState.com Tue Oct 3 00:37:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 3 Oct 2000 09:37:13 +1100 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF> Message-ID: > guido wrote: > > If the idea of a RC sounds okay > > Sure does. > > > I'd like to propose to release it on October 5. > > Hmm. My plan was to to work on the remaining SRE issues on > Saturday, leaving Sunday-Tuesday for final "burn-in"... Also FYI, I intend applying the previous-version-crash patch tomorrow (or late today), so those extra few days for /F would also prevent this patch going out _too_ green... Mark. From fdrake at beopen.com Tue Oct 3 02:23:13 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT) Subject: [Python-Dev] Development HTML docs online Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com> I've set things up so I can easily "publish" the Python documentation online without actually building a release. It's not entirely automatic, but I can push it online easily, so you'll be able to see what I'm doing. It can include more than just what's in CVS, but I try not to have too much waiting to checkin at once. Check it out: ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Tue Oct 3 04:36:03 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 21:36:03 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST." <20001002044859.A9639@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com> > What is going to be the fate of the GC? There are currently two > reported bugs which I have been unable to reproduce. If its > going to be disabled for 2.0 then it should be disabled in the > beta release. Good point. I see only the one that's assigned to you (reported by Rob Hooft): http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341 What's the other? Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe that's a clue? Does he also use threads? Is he willing to send his entire program over? (If you don't have time, we may have time at PythonLabs!) Anyway, I'm not yet ready to disable GC by default -- that's sensible but also defeats the purpose... --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at python.net Tue Oct 3 06:08:45 2000 From: gward at python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: <20001003000845.A1812@beelzebub> Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. Greg -- Greg Ward gward at python.net http://starship.python.net/~gward/ And now for something completely different. From fredrik at pythonware.com Tue Oct 3 10:52:37 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 10:52:37 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <200010030832.BAA05615@slayer.i.sourceforge.net> Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF> > Change first line to #!/usr/bin/env python (really just to test check-in). hmm. cgi.py is a CGI script. according to the Python FAQ, CGI scripts should use an explicit path, not /usr/bin/env: "Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter." (since this comes up over and over again, maybe someone should add a comment to the file?) From ping at lfw.org Tue Oct 3 12:15:13 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: On Tue, 3 Oct 2000, Fredrik Lundh wrote: > > Change first line to #!/usr/bin/env python (really just to test check-in). > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > scripts should use an explicit path, not /usr/bin/env: > > "Note -- *don't* do this for CGI scripts. The $PATH variable > for CGI scripts is often very minimal, so you need to use the > actual absolute pathname of the interpreter." The $PATH variable for CGI scripts may be minimal, but minimal as it is, Python should still be on it. Using /usr/bin/python works for half the people and /usr/local/bin/python works for the other half... /usr/bin/env is supposed to work for everyone. If this has already been argued soundly to death, i'm happy to back out the change and add a comment. It was a meaningless change for me anyway. Oh well. Anyway, i'm glad CVS commit *finally* works for me. Sorry for the extra hassle. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From nas at arctrix.com Tue Oct 3 08:41:18 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 23:41:18 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001002234118.A11108@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > What's the other? Some people from Origin Systems have reported a crash. They are using Python in a large application (probably related to the Ultima Online game). I will put the bug report in the database today. They are using a custom version of cPickle that may be causing the problem. It is an instance object which is causing the trouble. My malloc() == NULL patch for classobject.c did not fix things. They still haven't reported back regarding the cPickle fix. > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. > Maybe that's a clue? I don't think _tkinter does anything special (unlike cPickle and new). > Does he also use threads? His interpreter has threads enabled it seems. Maybe I should get him to test without threads, assuming he doesn't require them. > Is he willing to send his entire program over? From bwarsaw at beopen.com Tue Oct 3 15:49:23 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: <14809.58339.707476.273418@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> The $PATH variable for CGI scripts may be minimal, but minimal KY> as it is, Python should still be on it. Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes $PATH from the environment before calling python with a compiled in absolute path. Which leads me to ask: how often are you calling cgi.py directly anyway? That'll just run the text() function which isn't terribly useful other than to debug your cgi setup. Usually you're calling some other module that imports cgi, and in that case this line won't have any effect. And besides, it's not very safe to call a script directly so I'd recommend a wrapper program anyway. I'd say this one is rather harmless. -Barry From guido at python.org Tue Oct 3 16:58:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 09:58:00 -0500 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST." References: Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com> > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > > scripts should use an explicit path, not /usr/bin/env: > > > > "Note -- *don't* do this for CGI scripts. The $PATH variable > > for CGI scripts is often very minimal, so you need to use the > > actual absolute pathname of the interpreter." > > The $PATH variable for CGI scripts may be minimal, but minimal > as it is, Python should still be on it. Using /usr/bin/python > works for half the people and /usr/local/bin/python works for > the other half... /usr/bin/env is supposed to work for everyone. No. On a typical Unix system (Linux perhaps excluded), /usr/local/bin is not on the default $PATH. > If this has already been argued soundly to death, i'm happy to > back out the change and add a comment. It was a meaningless > change for me anyway. I backed it out for you. It really has been argued to death. Glad CVS works for you! --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Tue Oct 3 17:37:21 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT) Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <20001002234118.A11108@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001002234118.A11108@glacier.fnational.com> Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: [GvR writes:] >> Anyway, I'm not yet ready to disable GC by default -- that's >> sensible but also defeats the purpose... NS> Okay. I think I've found a possible problem. When I set NS> threshold0 to 1 in the C code, weird things start happening. NS> I'm looking into it. I agree that it isn't too useful to ship the garbage collector, but have it turned off. On the other hand, we're going to get a lot of unhappy users if GC bugs cause inexplicable crashes in large programs. It would be hard to sell Python for important applications, e.g. long-running server processes, if there was a small possibility that the program could crash through no fault of its own. Jeremy From bwarsaw at beopen.com Tue Oct 3 17:39:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in Message-ID: <14809.64935.157146.681813@anthem.concentric.net> I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with the zlib rpm installed, all I need to enable this module is the following line: zlib zlibmodule.c -lz but Setup.in has this suggestion, which I think is too hard for people to figure out what to do: zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz The standard build options will already include the right -I and -L flags for this to Just Work. I suggest we make the common case (Linux?) simple, and let others figure out what the right -I and -L flags are. I submit that even if they /do/ have to handcraft -I and -L, the defaults in Setup.in are pretty meaningless. A worthy change? For 2.0 final? -Barry From guido at python.org Tue Oct 3 19:31:47 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 12:31:47 -0500 Subject: [Python-Dev] Canvas.Canvas.bbox() return value Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com> Hi Fredrik, Re this bug report: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 I can take care of the Canvas issues, but I need your advice on bbox(). He's right that the bbox() method the Canvas class in the Canvas module is different from all other bbox() methods: it returns a tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple (x,y1,x2,y2). Do you think it's worth not breaking existing code here??? --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Tue Oct 3 18:34:51 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c Message-ID: <14810.2731.466997.243906@anthem.concentric.net> I've found a small memory leak in unicodeobject.c, in the way _PyUnicode_Fini() shuts down. Take a loop such as: -------------------- snip snip -------------------- #include "Python.h" int main(int argc, char** argv) { int i; while (1) { Py_Initialize(); Py_Finalize(); } return 0; } -------------------- snip snip -------------------- and you'll find that unicode_empty leaks. This is because, while _PyUnicode_Fini() decrefs unicode_empty, it never actually gets freed. Instead it gets placed on the already freed unicode_freelist! See _PyUnicode_Free() for why. I've come up with the following nasty hack to force unicode_empty to really be freed in _PyUnicode_Fini(). Maybe there's a better way to do this. Note that moving the decref of unicode_empty to above the freeing of unicode_freelist didn't plug the memory leak for me (but I'm quite tired so maybe I missed something! ;} ). Below is the proposed patch. -Barry -------------------- snip snip -------------------- Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -u -r2.64 unicodeobject.c --- unicodeobject.c 2000/09/26 05:46:01 2.64 +++ unicodeobject.c 2000/10/03 16:31:32 @@ -5234,7 +5234,11 @@ PyObject_DEL(v); } unicode_freelist = NULL; - unicode_freelist_size = 0; + /* XXX This is a hack to force the freeing of unicode_empty's memory. + * Otherwise, it'll get placed on the already freed free list. + */ + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; Py_XDECREF(unicode_empty); unicode_empty = NULL; + unicode_freelist_size = 0; } From effbot at telia.com Tue Oct 3 19:08:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 19:08:05 +0200 Subject: [Python-Dev] Canvas.Canvas.bbox() return value References: <200010031731.MAA08827@cj20424-a.reston1.va.home.com> Message-ID: <001801c02d5c$801d0300$766940d5@hagrid> > Hi Fredrik, > > Re this bug report: > > http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 > > I can take care of the Canvas issues, but I need your advice on > bbox(). He's right that the bbox() method the Canvas class in the > Canvas module is different from all other bbox() methods: it returns a > tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple > (x,y1,x2,y2). > > Do you think it's worth not breaking existing code here??? no idea -- I don't think I've ever used that module (!). (I'd deprecate the entire module if I were in charge -- there are better ways to put objects on the canvas) but in case someone's using it, it's probably best to leave things as they are... From thomas at xs4all.net Tue Oct 3 19:07:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 3 Oct 2000 19:07:11 +0200 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400 References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <20001003190711.D12812@xs4all.nl> On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote: > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > A worthy change? For 2.0 final? What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by default, for all modules, if those directories already exist ? Because zlib is not the only module that has this problem. On BSDI and Solaris, the same problem exists for curses, readline and gdbm, at least. If you are installing in a completely separate tree, for whatever reason, either those include/lib directories won't exist, they won't contain anything useful, or they will contain the actual libraries you want to link with, anyway ;-P And if you are installing in a 'standard' tree, like /usr, /usr/local, /usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be there, too. If you don't fall under any of these cases, you'll have to do what you have to do now, figure it out by hand. I don't think changing the zlib line alone is going to matter much; it stops working 'out of the box' for the slightly-less common case of non-linux platforms (and not even all linux platforms ! There is no reason why a distribution would install zlib in /usr.) I would prefer adding a comment that clarifies the -I/-L lines, over removing them altogether, if we aren't including $prefix/include and $exec_prefix/lib by default. I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Oct 3 19:13:39 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5 In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net> References: <200010031651.JAA06853@slayer.i.sourceforge.net> Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net> Thomas, Thanks for taking care of this. One nit on the checkin procedure, pleae reference the SF bug number when you're fixing a bug. Also, report the revision number of the changed file when you close the bug. Thanks, Jeremy From fdrake at beopen.com Tue Oct 3 19:08:06 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > A worthy change? For 2.0 final? This is good; even better would be the configure magic to make it work automatically, similar to what we have for bsddb. Given the short time frame, your approach is good. There may be other modules that need similar adjustments in Setup.in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Oct 3 19:13:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 19:13:40 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <39DA13C4.B1855D9A@lemburg.com> "Barry A. Warsaw" wrote: > > I've found a small memory leak in unicodeobject.c, in the way > _PyUnicode_Fini() shuts down. Take a loop such as: > > -------------------- snip snip -------------------- > #include "Python.h" > > int main(int argc, char** argv) > { > int i; > > while (1) { > Py_Initialize(); > Py_Finalize(); > } > return 0; > } > -------------------- snip snip -------------------- > > and you'll find that unicode_empty leaks. This is because, while > _PyUnicode_Fini() decrefs unicode_empty, it never actually gets > freed. Instead it gets placed on the already freed unicode_freelist! > See _PyUnicode_Free() for why. > > I've come up with the following nasty hack to force unicode_empty to > really be freed in _PyUnicode_Fini(). Maybe there's a better way to > do this. Note that moving the decref of unicode_empty to above the > freeing of unicode_freelist didn't plug the memory leak for me (but > I'm quite tired so maybe I missed something! ;} ). It would be easier to simply move the Py_DECREF() in front of the cleanup code for the free list. That way, unicode_empty would be placed on the free list, but then immedialtely cleaned up by the following code. Should I check in such a patch ? > Below is the proposed patch. > -Barry > > -------------------- snip snip -------------------- > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 3 20:28:08 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:28:08 -0500 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400." <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com> > I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with > the zlib rpm installed, all I need to enable this module is the > following line: > > zlib zlibmodule.c -lz > > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > > A worthy change? For 2.0 final? Check it in right now. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Tue Oct 3 19:54:44 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 19:54:44 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5 References: <200010031651.JAA06853@slayer.i.sourceforge.net> <14810.5059.445654.876073@bitdiddle.concentric.net> Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid> > Thanks for taking care of this. One nit on the checkin procedure, > pleae reference the SF bug number when you're fixing a bug. Also, > report the revision number of the changed file when you close the bug. do you really need both? the former is easy, the latter is more of a PITA, at least with the CVS setup I'm using here... From guido at python.org Tue Oct 3 20:58:20 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:58:20 -0500 Subject: [Python-Dev] Small memory leak in unicodeobject.c In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400." <14810.2731.466997.243906@anthem.concentric.net> References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com> > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } Doesn't it make more sense to decref unicode_empty sooner? The loop over the free list won't touch it: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -c -r2.64 unicodeobject.c *** unicodeobject.c 2000/09/26 05:46:01 2.64 --- unicodeobject.c 2000/10/03 17:55:34 *************** *** 5225,5230 **** --- 5225,5232 ---- { PyUnicodeObject *u = unicode_freelist; + Py_XDECREF(unicode_empty); + unicode_empty = NULL; while (u != NULL) { PyUnicodeObject *v = u; u = *(PyUnicodeObject **)u; *************** *** 5235,5240 **** } unicode_freelist = NULL; unicode_freelist_size = 0; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; } --- 5237,5240 ---- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Oct 3 20:02:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 20:02:39 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com> Message-ID: <39DA1F3F.9EFA41EB@lemburg.com> Guido van Rossum wrote: > > > Index: unicodeobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > > retrieving revision 2.64 > > diff -u -r2.64 unicodeobject.c > > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > > +++ unicodeobject.c 2000/10/03 16:31:32 > > @@ -5234,7 +5234,11 @@ > > PyObject_DEL(v); > > } > > unicode_freelist = NULL; > > - unicode_freelist_size = 0; > > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > > + * Otherwise, it'll get placed on the already freed free list. > > + */ > > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > > Py_XDECREF(unicode_empty); > > unicode_empty = NULL; > > + unicode_freelist_size = 0; > > } > > Doesn't it make more sense to decref unicode_empty sooner? Right. That's the change I proposed to Barry in my last mail. Please check this in. Thanks, Marc-Andre > The loop > over the free list won't touch it: > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -c -r2.64 unicodeobject.c > *** unicodeobject.c 2000/09/26 05:46:01 2.64 > --- unicodeobject.c 2000/10/03 17:55:34 > *************** > *** 5225,5230 **** > --- 5225,5232 ---- > { > PyUnicodeObject *u = unicode_freelist; > > + Py_XDECREF(unicode_empty); > + unicode_empty = NULL; > while (u != NULL) { > PyUnicodeObject *v = u; > u = *(PyUnicodeObject **)u; > *************** > *** 5235,5240 **** > } > unicode_freelist = NULL; > unicode_freelist_size = 0; > - Py_XDECREF(unicode_empty); > - unicode_empty = NULL; > } > --- 5237,5240 ---- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at beopen.com Tue Oct 3 22:35:10 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17150.777092.128211@anthem.concentric.net> >>>>> "M" == M writes: M> It would be easier to simply move the Py_DECREF() in front of M> the cleanup code for the free list. That way, unicode_empty M> would be placed on the free list, but then immedialtely cleaned M> up by the following code. I know that's the obvious fix -- and it was the first thing I tried, but it doesn't work! (I thought I mentioned that in my original message). Verifying after a cvs up still shows unicode_empty leaking (I loop through the Py_Initialize/Py_Finalize loop 10 times): -------------------- snip snip -------------------- 240 bytes 10 chunks allocated at unicodeobject.c, 227 malloc() _PyUnicode_New() unicodeobject.c, 227 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() 30 bytes 10 chunks allocated at unicodeobject.c, 230 malloc() _PyUnicode_New() unicodeobject.c, 230 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() -------------------- snip snip -------------------- So let me step through the code and figure out what's wrong... -Barry From loewis at informatik.hu-berlin.de Tue Oct 3 22:39:06 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de> > It would be hard to sell Python for important applications, > e.g. long-running server processes, if there was a small possibility > that the program could crash through no fault of its own. There is always a small possibility that the program could crash through no faults of its own - i.e. I don't believe that Python is bug free without gc. I'd agree that bugs in the gc are more serious than other bugs. If it turns out that there are serious bugs in 2.0 (whether in the gc or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they get fixed. Regards, Martin From bwarsaw at beopen.com Tue Oct 3 22:42:25 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17585.567814.278594@anthem.concentric.net> Oh the problem is obvious. You have to initialize the local variable `u' /after/ unicode_empty is freed otherwise it doesn't point to the proper start of the free list. I'll check that change in. -Barry From MarkH at ActiveState.com Wed Oct 4 00:58:14 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 09:58:14 +1100 Subject: [Python-Dev] pep42 procedure? Message-ID: Please excuse my ignorance... I am in the process of applying the patch to prevent 1.5/1.6 extensions crashing 2.0 under Windows. Based on the feedback here (ie, "this should be a short term patch"), the various other patches that try to do the same thing, and the belief by some that we should be more like Unix anyway, I believe we should try and capture this entire issue in a more formal manner. The 2 logical places would be as a bug, and in pep42. However, after applying this patch, it doesnt really qualify as a bug! Putting it in pep42 is slightly suspect, as it is not a thought-out feature request yet - however, I believe capturing it there, with links to the relevant patches and discussions would be valuable. So, assuming this sounds reasonable - a bug, or pep42? If pep42, what is the procedure for changing it? I couldnt find it (or any pep) in the CVS repository, and the source-force pages would show me the peps, but not their source. I do remember seeing this mentioned some time ago, but can't locate that mail either... Thanks, Mark. From trentm at ActiveState.com Wed Oct 4 01:08:09 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:08:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows Message-ID: <20001003160809.A18387@ActiveState.com> Fred's checkin: http://www.python.org/pipermail/python-checkins/2000-September/008355.html breaks test_popen2.py on windows. This is because test_popen2.py attempts to refer to popen2's internal '_active' variable, which is now explicitly deleted on Windows platforms. test_popen2.py should be updated for the new popen2 semantics. sorry-no-patch-ly yours, Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Wed Oct 4 01:10:09 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:10:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700 References: <20001003160809.A18387@ActiveState.com> Message-ID: <20001003161009.B18387@ActiveState.com> On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote: > > Fred's checkin: > http://www.python.org/pipermail/python-checkins/2000-September/008355.html > breaks test_popen2.py on windows. > > This is because test_popen2.py attempts to refer to popen2's internal > '_active' variable, which is now explicitly deleted on Windows platforms. > > test_popen2.py should be updated for the new popen2 semantics. > Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my email but before my email made it to python-dev!) Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Wed Oct 4 02:54:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT) Subject: [Python-Dev] pep42 procedure? In-Reply-To: References: Message-ID: <14810.32735.229954.547385@beluga.mojam.com> Mark> So, assuming this sounds reasonable - a bug, or pep42? I think neither. This topic seems to have generated a lot of discussion. I think it deserves a bit more elaboration than what you'd find reasonable for pep42. Also, it would be kinda nice to add it to the Python FAQ with a reference to a specific pep for all the gory details of the problem and solution(s). Skip From MarkH at ActiveState.com Wed Oct 4 05:58:25 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 14:58:25 +1100 Subject: [Python-Dev] pep42 procedure? In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: > I think neither. This topic seems to have generated a lot of > discussion. I > think it deserves a bit more elaboration than what you'd find > reasonable for > pep42. Also, it would be kinda nice to add it to the Python FAQ with a > reference to a specific pep for all the gory details of the problem and > solution(s). That would be a great idea, if only we had a PEP author. To be honest, I really dont care too much about this issue, and have been doing my level best to avoid it. But Tim knows that, and delights in assigning related patches to me ;-) I certainly don't care enough to own a pep on it. The way things stand, I have a checkin ready to go, and am unwilling to commit to any sort of pep in the short or medium term. The best I could do is to add links to the 3 or 4 other patches submitted for the same thing, and pep42 seemed ideal. So given this, what should I do - just check it in, and leave it to the collective memory? ;-) Mark. From tim_one at email.msn.com Wed Oct 4 06:58:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 4 Oct 2000 00:58:46 -0400 Subject: [Python-Dev] CIV Message-ID: No, that's not 104, it's a Call for Indentation Volunteers! An item that mistakenly got dropped on the floor before 2.0b1 was to ensure that the standard Python libraries follow the recommended "4-space indents, no hard tabs" guideline. Since 100s of files (especially older ones in oddball directories) are affected, I moved that it into PEP42 rather than risk destabilizing the release after 2.0b1. So it will happen instead soon after 2.0final is released. I looked at existing tools for doing this, and found they all left way too much manual fiddling to bear, too prone to screw up on comment lines (e.g., try running your favorite tool over pindent.py: does the output bear any resemblance to the input?! The Emacs pymode does OK there because pindent comments match its conventions for "indenting comment lines", but nothing else even gets close; OTOH, if 1: # some insane people like # writing comments # like this too and nobody knows what to do about that). Attached is a new tool that tries much harder to get perverse comments right (everything else is easy). Try it and gripe at will. Since I wrote it while on vacation, it's public domain <0.5 wink>. regularly y'rs - tim #! /usr/bin/env python # Released to the public domain, by Tim Peters, 03 October 2000. """reindent [-d][-r][-v] path ... -d Dry run. Analyze, but don't make any changes to, files. -r Recurse. Search for all .py files in subdirectories too. -v Verbose. Print informative msgs; else no output. Change Python (.py) files to use 4-space indents and no hard tab characters. Also trim excess whitespace from ends of lines, and empty lines at the ends of files. Ensure the last line ends with a newline. Pass one or more file and/or directory paths. When a directory path, all .py files within the directory will be examined, and, if the -r option is given, likewise recursively for subdirectories. Overwrites files in place, renaming the originals with a .bak extension. If reindent finds nothing to change, the file is left alone. If reindent does change a file, the changed file is a fixed-point for reindent (i.e., running reindent on the resulting .py file won't change it again). The hard part of reindenting is figuring out what to do with comment lines. So long as the input files get a clean bill of health from tabnanny.py, reindent should do a good job. """ import tokenize import os import sys verbose = 0 recurse = 0 dryrun = 0 def errprint(*args): sep = "" for arg in args: sys.stderr.write(sep + str(arg)) sep = " " sys.stderr.write("\n") def main(): import getopt global verbose, recurse, dryrun try: opts, args = getopt.getopt(sys.argv[1:], "drv") except getopt.error, msg: errprint(msg) return for o, a in opts: if o == '-d': dryrun += 1 elif o == '-r': recurse += 1 elif o == '-v': verbose += 1 if not args: errprint("Usage:", __doc__) return for arg in args: check(arg) def check(file): if os.path.isdir(file) and not os.path.islink(file): if verbose: print "listing directory", file names = os.listdir(file) for name in names: fullname = os.path.join(file, name) if ((recurse and os.path.isdir(fullname) and not os.path.islink(fullname)) or name.lower().endswith(".py")): check(fullname) return if verbose: print "checking", file, "...", try: f = open(file) except IOError, msg: errprint("%s: I/O Error: %s" % (file, str(msg))) return r = Reindenter(f) f.close() if r.run(): if verbose: print "changed." if dryrun: print "But this is a dry run, so leaving it alone." if not dryrun: bak = file + ".bak" if os.path.exists(bak): os.remove(bak) os.rename(file, bak) if verbose: print "renamed", file, "to", bak f = open(file, "w") r.write(f) f.close() if verbose: print "wrote new", file else: if verbose: print "unchanged." class Reindenter: def __init__(self, f): self.find_stmt = 1 # next token begins a fresh stmt? self.level = 0 # current indent level # Raw file lines. self.raw = f.readlines() # File lines, rstripped & tab-expanded. Dummy at start is so # that we can use tokenize's 1-based line numbering easily. # Note that a line is all-blank iff it's "\n". self.lines = [line.rstrip().expandtabs() + "\n" for line in self.raw] self.lines.insert(0, None) self.index = 1 # index into self.lines of next line # List of (lineno, indentlevel) pairs, one for each stmt and # comment line. indentlevel is -1 for comment lines, as a # signal that tokenize doesn't know what to do about them; # indeed, they're our headache! self.stats = [] def run(self): tokenize.tokenize(self.getline, self.tokeneater) # Remove trailing empty lines. lines = self.lines while lines and lines[-1] == "\n": lines.pop() # Sentinel. stats = self.stats stats.append((len(lines), 0)) # Map count of leading spaces to # we want. have2want = {} # Program after transformation. after = self.after = [] for i in range(len(stats)-1): thisstmt, thislevel = stats[i] nextstmt = stats[i+1][0] have = getlspace(lines[thisstmt]) want = thislevel * 4 if want < 0: # A comment line. if have: # An indented comment line. If we saw the same # indentation before, reuse what it most recently # mapped to. want = have2want.get(have, -1) if want < 0: # Then it probably belongs to the next real stmt. for j in xrange(i+1, len(stats)-1): jline, jlevel = stats[j] if jlevel >= 0: if have == getlspace(lines[jline]): want = jlevel * 4 break if want < 0: # Maybe it's a hanging # comment like this one, # in which case we should shift it like its base # line got shifted. for j in xrange(i-1, -1, -1): jline, jlevel = stats[j] if jlevel >= 0: want = have + getlspace(after[jline-1]) - \ getlspace(lines[jline]) break if want < 0: # Still no luck -- leave it alone. want = have else: want = 0 assert want >= 0 have2want[have] = want diff = want - have if diff == 0 or have == 0: after.extend(lines[thisstmt:nextstmt]) else: for line in lines[thisstmt:nextstmt]: if diff > 0: if line == "\n": after.append(line) else: after.append(" " * diff + line) else: remove = min(getlspace(line), -diff) after.append(line[remove:]) return self.raw != self.after def write(self, f): f.writelines(self.after) # Line-getter for tokenize. def getline(self): if self.index >= len(self.lines): line = "" else: line = self.lines[self.index] self.index += 1 return line # Line-eater for tokenize. def tokeneater(self, type, token, (sline, scol), end, line, INDENT=tokenize.INDENT, DEDENT=tokenize.DEDENT, NEWLINE=tokenize.NEWLINE, COMMENT=tokenize.COMMENT, NL=tokenize.NL): if type == NEWLINE: # A program statement, or ENDMARKER, will eventually follow, # after some (possibly empty) run of tokens of the form # (NL | COMMENT)* (INDENT | DEDENT+)? self.find_stmt = 1 elif type == INDENT: self.find_stmt = 1 self.level += 1 elif type == DEDENT: self.find_stmt = 1 self.level -= 1 elif type == COMMENT: if self.find_stmt: self.stats.append((sline, -1)) # but we're still looking for a new stmt, so leave # find_stmt alone elif type == NL: pass elif self.find_stmt: # This is the first "real token" following a NEWLINE, so it # must be the first token of the next program statement, or an # ENDMARKER. self.find_stmt = 0 if line: # not endmarker self.stats.append((sline, self.level)) # Count number of leading blanks. def getlspace(line): i, n = 0, len(line) while i < n and line[i] == " ": i += 1 return i if __name__ == '__main__': main() From bwarsaw at beopen.com Wed Oct 4 08:06:14 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT) Subject: [Python-Dev] pep42 procedure? References: Message-ID: <14810.51414.59852.855231@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> I couldnt find it (or any pep) in the CVS repository, and the MH> source-force pages would show me the peps, but not their MH> source. The PEPs are located in the nondist directory, under nondist/peps! -Barry From bwarsaw at beopen.com Wed Oct 4 08:07:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com Message-ID: <14810.51466.486982.938180@anthem.concentric.net> An embedded message was scrubbed... From: aahz at panix.com Subject: htmllib.HTMLescape() Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT) Size: 1672 URL: From thomas at xs4all.net Wed Oct 4 08:16:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 08:16:58 +0200 Subject: [Python-Dev] pep42 procedure? In-Reply-To: ; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100 References: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: <20001004081658.E12812@xs4all.nl> On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote: [ Mark wants to apply a patch that prevents crashes on windows when loading extentions linked with old Python DLLs, but doesn't know where to document it: PEP 42 or the bug report(s) ] [ Skip proposes a separate PEP ] [ Mark doesn't have time to write a PEP ] > So given this, what should I do - just check it in, and leave it to the > collective memory? ;-) PEP 42 is the meaning of life PEP, meaning that it's everything that needs to be done before python-dev can rest in pieces. I don't think that a solved issue is in its place there, even if it had such a section. A PEP on its own would probably be the best spot, because even if it's a 'temporary' solution now, we or someone else might need the info later. And a PEP doesn't have to be that hard to write ;) And besides, you don't have to be the person to write the PEP, someone else can. And if noone suitable volunteers, perhaps a checkin-message giving 'full' documentation, the necessary sourcecode comments and a reference to both in the bugreport message will suffice... But I'm willing to PEPify whatever docs or comments you write on this issue, Mark. I will need some guidance on what exactly is the issue, but I'm sure I'll get that from one of you Windows lovers ! :-) And no, I don't think Python should be more like UNIX. Windows, yes, but it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides, that would only alienate the Windows users with Uni(x)fobia. Unix-unix-unix-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Wed Oct 4 13:02:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT) Subject: [Python-Dev] Installing python in /usr/bin Message-ID: The cgi.py discussion brought my attention to this comment from Guido: > No, no, no! The /usr/bin/env form *fails* on most platforms (except > Linux) because Python is not installed in any of the default "bin" > directories -- /usr/local/bin is the standard install place and that's > not in the default path. So the natural question to ask is -- why not install Python in /usr/bin like everyone else? Perhaps a while ago Python wasn't popular enough to belong in /usr/bin and decided to modestly stay out of the way in /usr/local/bin instead? But by now, i think it's quite qualified to take its seat in /usr/bin along with all the other standard Unix binaries like /usr/bin/vi, /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default binary directory. Your thoughts? -- ?!ng From thomas at xs4all.net Wed Oct 4 13:35:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 13:35:28 +0200 Subject: [Python-Dev] Installing python in /usr/bin In-Reply-To: ; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700 References: Message-ID: <20001004133528.G12812@xs4all.nl> On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote: > So the natural question to ask is -- why not install Python in /usr/bin > like everyone else? > Perhaps a while ago Python wasn't popular enough to belong in /usr/bin > and decided to modestly stay out of the way in /usr/local/bin instead? The only reason is the hysterical one: it's always been that way. Traditionally, /usr/local/bin was the place for user-installed binaries. This sets them apart from the the vendor-supplied binaries (commonly in /bin and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and /usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.) > But by now, i think it's quite qualified to take its seat in /usr/bin > along with all the other standard Unix binaries like /usr/bin/vi, > /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default > binary directory. Perl only resides in /usr/bin if the vendor (or distribution-maker, in the case of the Free OSes) put it there. The default for Perl is /usr/local as well. In fact, almost all source packages default to /usr/local; I have yet to see a package that uses autoconf and does not have /usr/local as the default prefix, for instance. I think the best solution is just for every OS to put /usr/local/bin in their path, and not pretend they delivered the Definitive Collection of Useful Programs. Installing Python in /usr can do more damage than good -- think of all the people that are used to have it installed in /usr/local, don't specify a prefix because they 'know' it's /usr/local by default, and end up filling up their minimal /usr partition with Python ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward at python.net Tue Oct 3 06:08:45 2000 From: gward at python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. Greg -- Greg Ward gward at python.net http://starship.python.net/~gward/ And now for something completely different. From bwarsaw at beopen.com Wed Oct 4 15:44:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT) Subject: [Python-Dev] Installing python in /usr/bin References: <20001004133528.G12812@xs4all.nl> Message-ID: <14811.13384.137080.196973@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> The only reason is the hysterical one: it's always been that TW> way. Traditionally, /usr/local/bin was the place for TW> user-installed binaries. Yes exactly. And in fact on my RH6.1 system, I have Python in both /usr/bin and /usr/local/bin. RedHat sticks its rpms in /usr/bin, and right now, 1.5.2 resides there. My dev copy gets installed from source into /usr/local/bin, and that's the current CVS snapshot. This is as it should be and all is right in the world. The rule is -- and ought to be -- that the default install location in a build-from-source distro is /usr/local. rpms or other package installs can install where ever is appropriate for that platform (e.g. if someone were to build a Solaris pkg distro, it probably ought to install to /opt by default). if-it-ain't-broke...-ly y'rs, -Barry From nas at arctrix.com Wed Oct 4 11:46:36 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 02:46:36 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700 References: <200010041622.JAA17363@slayer.i.sourceforge.net> Message-ID: <20001004024636.A13475@glacier.fnational.com> On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules > > Modified Files: > cPickle.c > Log Message: > - Fix a GC bug caused by PyDict_New() failing. > > > Index: cPickle.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v > retrieving revision 2.52 > retrieving revision 2.53 > diff -C2 -r2.52 -r2.53 > *** cPickle.c 2000/09/07 14:35:37 2.52 > --- cPickle.c 2000/10/04 16:22:26 2.53 > *************** > *** 2876,2880 **** > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! Py_DECREF(inst); > goto err; > } > --- 2876,2881 ---- > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! inst = (PyInstanceObject *) PyObject_AS_GC(inst); > ! PyObject_DEL(inst); > goto err; > } I aways seem to think harder when reviewing a commit message than a diff. :( I just realized that this commit subtly modifies cPickle's behavior. Before the change instances __del__ methods would be called if allocating __dict__ failed. After the change they are not. I think the new behavior is better but the question is will it break existing code? I think probably not. BTW, pickle seems to follow the new behavior. Neil From esr at snark.thyrsus.com Wed Oct 4 19:17:39 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 13:17:39 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010041717.NAA03509@snark.thyrsus.com> In the course of maintaining fetchmail, I've developed effective techniques for integrating RPM and lsm generation into the release machinery of a package. I'm willing to do this for Python; it will involve adding a makefile production and a couple of scripts to the distribution. The benefit would be that we could generate correct RPMs automatically and ship them with each release. I think RPM is a sufficiently important distribution format to justify this effort. Comments? -- Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 From effbot at telia.com Wed Oct 4 19:25:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 19:25:37 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid> eric wrote: > In the course of maintaining fetchmail, I've developed effective > techniques for integrating RPM and lsm generation into the release machinery > of a package. I'm willing to do this for Python; it will involve > adding a makefile production and a couple of scripts to the > distribution. > > The benefit would be that we could generate correct RPMs automatically > and ship them with each release. I think RPM is a sufficiently > important distribution format to justify this effort. Comments? isn't this a distutils thing? see: ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html (lazy programmers just press the "deploy" button, of course ;-) From akuchlin at mems-exchange.org Wed Oct 4 20:02:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 4 Oct 2000 14:02:19 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: >isn't this a distutils thing? see: >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html >(lazy programmers just press the "deploy" button, of course ;-) It's not immediately obvious that the Distutils 1.0, which after all mostly aims to support installing Python modules, can be applied to installing Python itself, what with all the libraries and scripts and such that Python needs. It certainly is something to aim for, and I intend to work on this some more after 2.0, but the attempt might run into missing Distutil features. Whether it's worth adding rules for RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or -0, just 0 -- a Nirvana-like state of utter unconcern.) --amk From gward at mems-exchange.org Wed Oct 4 20:13:01 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:13:01 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us> On 04 October 2000, Fredrik Lundh said: > isn't this a distutils thing? see: > > ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html But the Distutils brag line is: The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. If that first sentence were instead The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python. then you'd have a point. What a difference one little word can make... Greg From gward at mems-exchange.org Wed Oct 4 20:16:20 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:16:20 -0400 Subject: [Python-Dev] Adding a section to PEP 0042 Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us> I need to add an entry to PEP 0042 about the lack of cross-compilation support, because that's a bug report that was assigned to me, and needs to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems to me that I should just add a section on "Build/Installation" to the PEP -- anyone disagree? This might also be a good place to gather other gripes about Python's build/installation machinery... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From effbot at telia.com Wed Oct 4 20:53:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 20:53:48 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us> Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid> greg wrote: > If that first sentence were instead > > The Python Distribution Utilities, or Distutils for short, are a > collection of modules that aid in the development, distribution, and > installation of Python. > > then you'd have a point. > > What a difference one little word can make... so why not fix it? cannot be too hard to remove one little word, can it? ;-) From loewis at informatik.hu-berlin.de Wed Oct 4 22:31:23 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> > Someone just pointed out on c.l.py that we need an HTMLescape() > function that takes a string and converts special characters to > entities. I'm not on python-dev, so could you please forward this > and find out whether I need to run a PEP? Doesn't xml.sax.saxutils.escape do what you want (together with htmlentitydefs)? I was going to say that this is quite a small change to warrant a PEP - but there are two obvious approaches (working from scratch, or working on top of xml.sax.saxutils.escape - perhaps modifying and relocating that function), so *some* design probably needs to be recorded in a PEP. Regards, Martin From trentm at ActiveState.com Wed Oct 4 23:17:37 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 4 Oct 2000 14:17:37 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails Message-ID: <20001004141737.A16659@ActiveState.com> I did not follow the discussion a while back regarding the implementation and use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results in this test: test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) in test_sre.py failing on Win64. This is because PyOS_CheckStack seem to *never* fail on Win64. Three possibilites: (1) I don't understand the PyOS_CheckStack code or I am misintepreting the problem. (2) The semantics of _alloca() has changed for Win64 such that a stack overflow exception is no longer thrown if space cannot be allocated. NOTE: I changed the number of pointers allocated in PyOS_CheckStack from 2048 to over 1 *Tera*byte and it *still* did not fail. (3) I am stoopid. In any case, I would like to *not* define USE_STACKCHECK on Win64 for the time being (and for 2.0, unless a Win64 angel comes to me in the next couple of days). Does anybody have a problem with me checking this in? *** Include\pythonrun.h~ Wed Oct 04 14:18:00 2000 --- Include\pythonrun.h Wed Oct 04 13:17:17 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif Thanks, Trent -- Trent Mick TrentM at ActiveState.com From effbot at telia.com Wed Oct 4 23:34:50 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 23:34:50 +0200 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails References: <20001004141737.A16659@ActiveState.com> Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid> trent wrote: > I did not follow the discussion a while back regarding the implementation and > use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) > instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results > in this test: > test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) > in test_sre.py failing on Win64. note that the test assumes that 50000 iterations would be enough to hit the stack limit. maybe Win64 has a *huge* stack? what does this little program do: import sre sre.match(r'(x)*', 50000*'x').span() if it prints (0, 50000), all is well, and the *test* should be disabled (or modified) on Win64... From jeremy at beopen.com Wed Oct 4 23:35:26 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com> References: <200010041717.NAA03509@snark.thyrsus.com> Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> In the course of maintaining fetchmail, I've developed ESR> effective techniques for integrating RPM and lsm generation ESR> into the release machinery of a package. I'm willing to do ESR> this for Python; it will involve adding a makefile production ESR> and a couple of scripts to the distribution. ESR> The benefit would be that we could generate correct RPMs ESR> automatically and ship them with each release. I think RPM is ESR> a sufficiently important distribution format to justify this ESR> effort. Comments? We are now distributing RPMs for RH 6 with Python and have plans to support other distributions we have access to, namely those available on the SF compile farm. This page has the RPMs: http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html Can you compare this approach to using a hand-crafted .spec file for the RPMs? It took a little while to figure out how to generate the .spec, but now that it has been created it does not seem hard to maintain. I imagine, without knowing any details of what you propose, that this is primarily beneficial for people who do not know how to build RPMs. Jeremy From effbot at telia.com Wed Oct 4 23:43:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 23:43:41 +0200 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails References: <20001004141737.A16659@ActiveState.com> Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid> trent wrote: > This is because PyOS_CheckStack seem to *never* fail on Win64. Three > possibilites: > (1) I don't understand the PyOS_CheckStack code or I am misintepreting the > problem. > (2) The semantics of _alloca() has changed for Win64 such that a stack > overflow exception is no longer thrown if space cannot be allocated. > NOTE: I changed the number of pointers allocated in PyOS_CheckStack > from 2048 to over 1 *Tera*byte and it *still* did not fail. me again: didn't read the note carefully enough, so I didn't quite figure out what you said... ::: what happens if you run this program (on my win95 box, it counts up to 8, and stops). #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ::: if it goes on and on and on, check the assembler output from this program. (maybe the win64 compiler is smarter than I -- if it realizes that I don't actually use the return value from _alloca, it may of course remove the entire thing...) From esr at thyrsus.com Wed Oct 4 23:56:38 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 17:56:38 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> Message-ID: <20001004175638.A4423@thyrsus.com> Jeremy Hylton : > We are now distributing RPMs for RH 6 with Python and have plans to > support other distributions we have access to, namely those available > on the SF compile farm. > > This page has the RPMs: > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > Can you compare this approach to using a hand-crafted .spec file for > the RPMs? It took a little while to figure out how to generate the > .spec, but now that it has been created it does not seem hard to > maintain. > > I imagine, without knowing any details of what you propose, that this > is primarily beneficial for people who do not know how to build RPMs. Actually, the point of my approach is *not* to hand-craft the spec file. What I normally do is write a specfile generator script in shell, which takes the release version as an argument. Most of the point of the generator script is so the file list part of the specfile never has to be handhacked. So, for example, a specfile generator script for Python would know that for each library file foo.py in the Python X.Y release tree, it needs to generate a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is added to the library it will automatically ripple through to the RPM. Then I embed something like this in the Makefile: # Make RPMs. You need to be root to make this work RPMROOT=/usr/src/redhat RPM = rpm RPMFLAGS = -ba rpm: dist cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES; $(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir) cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir) Hey presto! Instant RPMs. I use this approach for several of my projects. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From nas at arctrix.com Wed Oct 4 18:12:04 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 09:12:04 -0700 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> Message-ID: <20001004091204.A787@glacier.fnational.com> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > Jeremy Hylton : > > Can you compare this approach to using a hand-crafted .spec file for > > the RPMs? It took a little while to figure out how to generate the > > .spec, but now that it has been created it does not seem hard to > > maintain. > Actually, the point of my approach is *not* to hand-craft the spec file. Okay, but we already have the spec file. Why is your approach better? Is your script that generates the the spec easier to maintain then the spec file itself? Is it just as flexible? If so then Red Hat screwed up designing RPM. I can see the utility of such as script but I don't see how it helps in this situation. Neil From esr at thyrsus.com Thu Oct 5 04:23:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 22:23:18 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com> Message-ID: <20001004222318.E4742@thyrsus.com> Neil Schemenauer : > On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > > Jeremy Hylton : > > > Can you compare this approach to using a hand-crafted .spec file for > > > the RPMs? It took a little while to figure out how to generate the > > > .spec, but now that it has been created it does not seem hard to > > > maintain. > > Actually, the point of my approach is *not* to hand-craft the spec file. > > Okay, but we already have the spec file. Why is your approach > better? Is your script that generates the the spec easier to > maintain then the spec file itself? Is it just as flexible? If > so then Red Hat screwed up designing RPM. I can see the utility > of such as script but I don't see how it helps in this situation. The main thing a specfile generator can accomplish is to automate the generation of the file list so that (for example) when we add a new library module the specfile doesn't have to be hand-edited. -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 From nas at arctrix.com Wed Oct 4 23:43:50 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 14:43:50 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001004144350.A434@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > that's a clue? Rob was kind enough to send me some code to trigger the bug. The winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's program seems to work fine. I think Pmw uses lots of tuples. Looking closely at the code I see that _PyTuple_Resize is almost certainly buggy. I think something is wrong with PyTuple_New as well. I'll have to come up with a patch later as it is much to late now for me to fully understand such hairy code. :( Neil From pf at artcom-gmbh.de Thu Oct 5 07:55:19 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000 3:40:33 pm" Message-ID: Hi, Barry Warsaw : > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669 > > Added Files: > pep-0004.txt > Log Message: > Added PEP 4, Deprecation of Standard Modules, Martin von Loewis > > > ***** Error reading new file: (2, 'No such file or directory') Whenever Barry adds a new file to the CVS, its initial content is invisible on the checkins mailing list due to the error message above. However if for example fdrake adds a new file (for example the support.py recently added to the doc subtree) then this doesn't happen. Is there anybody out there able to fix this for future checkins-mails? Regards, Peter From fdrake at beopen.com Thu Oct 5 08:23:10 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: References: <200010042240.PAA14714@slayer.i.sourceforge.net> Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Peter Funk writes: > Whenever Barry adds a new file to the CVS, its initial content > is invisible on the checkins mailing list due to the error message > above. However if for example fdrake adds a new file (for example the > support.py recently added to the doc subtree) then this doesn't happen. > Is there anybody out there able to fix this for future checkins-mails? Wow! I had noticed the bolluxed messages, but hadn't tied it to Barry! But I just checked the added files for this month and spot-checked the ones from last month, and Barry's all exhibit this problem, and no one else's do. I wonder if something is wrong with his SourceForge account? Barry, check your group memberships, please! If nothing obvious is wrong, submit a support request, because this is definately annoying. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Oct 5 09:09:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:20 -0400 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003161009.B18387@ActiveState.com> Message-ID: [Trent Mick, pointing out that test_popen2 was busted on Windows] > Geez, you are fast Tim! (for others: he patched test_popen.py > after I sent my email but before my email made it to python-dev!) I hate to be honest, but I actually pointed out the test_popen2 failure on Python-Dev last week. However, I was On Vacation(tm) then, so thought merely mentioning it would shame someone else into fixing it. At this point, I'll happily settle for that somebody else eventually *noticed* it! our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs - tim From tim_one at email.msn.com Thu Oct 5 09:09:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:17 -0400 Subject: [Python-Dev] pep42 procedure? In-Reply-To: Message-ID: [Mark Hammond] > That would be a great idea, if only we had a PEP author. To be honest, > I really dont care too much about this issue, and have been doing my > level best to avoid it. But Tim knows that, and delights in assigning > related patches to me ;-) I certainly don't care enough to own a pep > on it. ... I assign them to you because there's barely a line of Windows startup code you didn't write, and you gave Windows the notion of naming the main DLL differently across (some) different releases thus creating the possibility for the problem these patches are trying to solve . That's not to say it's "your problem", but is to say you've thought more about "stuff like this" than anyone else, and have very particular ideas about how you want "stuff like this" done: you're the best qualified. That said, the subject of the PEP shouldn't be competing hacks to worm around Windows-specific startup problems, it should be an actual design for binary compatibility across iterations of the C API, or at least a reliable way for extensions to *know* they're not getting a version of the Python core they can use. we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs - tim From martin at loewis.home.cs.tu-berlin.de Thu Oct 5 09:44:52 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 5 Oct 2000 09:44:52 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> > The main thing a specfile generator can accomplish is to automate > the generation of the file list so that (for example) when we add a > new library module the specfile doesn't have to be hand-edited. That sounds similar to the rationale for having automatically generated dependency files for make, e.g. by gcc -MM. Many projects use this as a convenience, and it kind-of works. However, I still like it better to have dependencies explicitly recorded in the Makefiles. That requires more discipline, but is easier to understand, and the behaviour is more reproducable. So given the option of using an existing hand-written spec file, and having some magic generate one for me, I'd always use the hand-written one. The magic is only good if there is no hand-written one. Regards, Martin From fredrik at pythonware.com Thu Oct 5 09:50:37 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 09:50:37 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> neil wrote: > On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > > that's a clue? > > Rob was kind enough to send me some code to trigger the bug. The > winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's > program seems to work fine. I think Pmw uses lots of tuples. The new version of Tkinter contains a _flatten function written in C, which uses PyTuple_Resize extensively. To check if Rob's program works better without it, you can comment out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or so, iirc). From larsga at garshol.priv.no Thu Oct 5 10:36:33 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 05 Oct 2000 10:36:33 +0200 Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: * Martin von Loewis | | Doesn't xml.sax.saxutils.escape do what you want (together with | htmlentitydefs)? I was going to say that this is quite a small | change to warrant a PEP - but there are two obvious approaches | (working from scratch, or working on top of xml.sax.saxutils.escape | - perhaps modifying and relocating that function), so *some* design | probably needs to be recorded in a PEP. It would probably help, but now that Python has Unicode support there should be some way to convert string data to a legacy encoding and represent all characters not available in that encoding using numeric character references. This would be very useful for both XML and HTML. The difficulty, I assume, lies in figuring out which encodings support what characters. --Lars M. From nas at arctrix.com Thu Oct 5 07:59:38 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 22:59:38 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> Message-ID: <20001004225938.A802@glacier.fnational.com> On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote: > The new version of Tkinter contains a _flatten function written in C, > which uses PyTuple_Resize extensively. > > To check if Rob's program works better without it, you can comment > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > so, iirc). That fixes the crash as well. Neil From bwarsaw at beopen.com Thu Oct 5 15:33:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) References: <200010042240.PAA14714@slayer.i.sourceforge.net> <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Message-ID: <14812.33601.730022.889777@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Wow! I had noticed the bolluxed messages, but hadn't tied Fred> it to Barry! But I just checked the added files for this Fred> month and spot-checked the ones from last month, and Barry's Fred> all exhibit this problem, and no one else's do. I wonder if Fred> something is wrong with his SourceForge account? Barry, Fred> check your group memberships, please! If nothing obvious is Fred> wrong, submit a support request, because this is definately Fred> annoying. I don't understand why this is happening, esp. just for me! My primary group is users and I'm definitely in the python group as well. Why would it be a permission problem anyway, since that's not what the error message is saying? Better log messages in syncmail would help diagnose this, but I haven't got the time right now to hack on that. -Barry From pf at artcom-gmbh.de Thu Oct 5 15:54:58 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000 9:33:53 am" Message-ID: Hi, Barry A. Warsaw: > > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Wow! I had noticed the bolluxed messages, but hadn't tied > Fred> it to Barry! But I just checked the added files for this > Fred> month and spot-checked the ones from last month, and Barry's > Fred> all exhibit this problem, and no one else's do. I wonder if > Fred> something is wrong with his SourceForge account? Barry, > Fred> check your group memberships, please! If nothing obvious is > Fred> wrong, submit a support request, because this is definately > Fred> annoying. > > I don't understand why this is happening, esp. just for me! My > primary group is users and I'm definitely in the python group as > well. Why would it be a permission problem anyway, since that's not > what the error message is saying? > > Better log messages in syncmail would help diagnose this, but I > haven't got the time right now to hack on that. Just speculating: it has something todo with the current directory where the cvs commit command is executed in or it depends on the difference that the PEPs are under nondist and Freds files were under dist. Possible ugly workaround for Barry: for new files first commit an empty file and then the real file just a moment later. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From jeremy at beopen.com Thu Oct 5 16:42:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT) Subject: [Python-Dev] Release candidate schedule Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net> There are still a number of open bugs that need to be addressed before we can issue a release candidate. We plan to issue the release candidate on Monday and the final release a week later. According to the Sourceforge bug report -- http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1 -- the following people still have open bugs: akuchlin (3) bwarsaw (3) dcjim (2) effbot (5) fdrake (4) gvanrossum (12) gward (1) jackjansen (1) jhylton (8) lemburg (2) mhammond (5) nascheme (3) tim_one (5) I don't expect that every bug will be closed before 2.0 final, but there are some open bugs about test failures and build problems with 2.0 beta releases. We should address these if at all possible. Please review your open bugs and make sure you aren't forgetting about something. If you have bugs that will not be fixed for 2.0, make sure they have a fairly low priority. If you have bugs you will not be able to address, assign them to me. Jeremy From effbot at telia.com Thu Oct 5 16:53:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 16:53:48 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002501c02edc$1302b040$766940d5@hagrid> what's the current release schedule, btw? is the repository frozen, or do we still have a chance to fix the GC tuple problem and SRE's "nothing to repeat" bug? From effbot at telia.com Thu Oct 5 16:51:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 16:51:25 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid> > > To check if Rob's program works better without it, you can comment > > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > > so, iirc). > > That fixes the crash as well. in other words, _PyTuple_Resize needs some work... (or does _flatten do something wrong? it starts by creating a tuple, and if it needs more space, it doubles the size one or more times, and ends by calling Resize again to set the final size...) ::: btw, the start of Resize looks a bit strange: should that DECREF really be there? should least be an XDECREF, or am I missing something? if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { *pv = 0; Py_DECREF(v); /* really? what if v is NULL? */ PyErr_BadInternalCall(); return -1; } From mal at lemburg.com Thu Oct 5 17:00:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 05 Oct 2000 17:00:12 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> Message-ID: <39DC977C.89D14AB1@lemburg.com> Andrew Kuchling wrote: > > On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: > >isn't this a distutils thing? see: > >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html > >(lazy programmers just press the "deploy" button, of course ;-) > > It's not immediately obvious that the Distutils 1.0, which after all > mostly aims to support installing Python modules, can be applied to > installing Python itself, what with all the libraries and scripts and > such that Python needs. It certainly is something to aim for, and I > intend to work on this some more after 2.0, but the attempt might run > into missing Distutil features. Whether it's worth adding rules for > RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or > -0, just 0 -- a Nirvana-like state of utter unconcern.) distutils is not useful for installing Python (it needs Python to start with), but it does a pretty good job at finding the needed files and can generate RPMs which can be used without distutils or Python. It even allows adding handcrafted sections to the resulting RPM. If anybody plans to help in this direction, I'd suggest to add those efforts to the build_rpm command in distutils (and the build_deb command for that matter). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Thu Oct 5 17:24:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 5 Oct 2000 11:24:32 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com> Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us> On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote: >distutils is not useful for installing Python (it needs Python >to start with), ... Note that the Distutils doesn't need many C-based modules: _sre, posix, and string are about it. So those modules could be automatically compiled into the Python binary (perhaps being moved from Modules/ into Python/ to signify their new importance) and the resulting binary should have enough marbles to run a setup.py script that would build everything else in Modules/. The downside is that you could no longer compile those 3 modules as dynamically loadable, but the upside is that the setup.py could be smarter about detecting which libraries are available on the system, and compiling everything which can be. This would, one hopes, make Setup file hacking a thing of the past... --amk From tismer at appliedbiometrics.com Thu Oct 5 16:33:54 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Thu, 05 Oct 2000 17:33:54 +0300 Subject: [Python-Dev] Stackless Python Mailing List Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com> Hi Pythoneers (without or not without Stack (yet:)) there have been a couple of interviews, and some articles on Stackless Python are published or in preparation. I recognize an increasing number of individual emails concerning Stackless Python. This lets me take the opportunity to start a mailing list on Stackless Python, an overdue task. The goal of this list is two-fold: On the one hand, people should have a forum to discuss their use of SLP, its further development, concurrency in general, and more. The other reason is to increase the support for SLP, with the final goal to get it merged into Standard Python. There are a couple of ways to help me with that, see http://starShip.python.net/mailman/listinfo/stackless Everybody who is interested in Stackless Python and all the related topics may feel invited to join this discussion group. cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : 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 From nas at arctrix.com Thu Oct 5 10:40:28 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 5 Oct 2000 01:40:28 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> Message-ID: <20001005014028.A1055@glacier.fnational.com> On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote: > in other words, _PyTuple_Resize needs some work... Yup. I've attached a patch which I believe fixes some GC bugs in addition to making it simpler. > btw, the start of Resize looks a bit strange: should that > DECREF really be there? should least be an XDECREF, or > am I missing something? > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > *pv = 0; > Py_DECREF(v); /* really? what if v is NULL? */ > PyErr_BadInternalCall(); > return -1; > } I think your right. Here's a fun little program: from _tkinter import _flatten import random # don't ask me why for x in xrange(10000): print x t = _flatten([(0,)*x]*x) It gives: 0 1 2 3 4 5 Segmentation fault on the two Linux machines I've tested it on. It also crashes with GC disabled. Neil *** Objects/tupleobject.c Thu Oct 5 11:31:30 2000 --- tupleobject.c Thu Oct 5 10:47:44 2000 *************** *** 500,531 **** } else #endif { ! #ifdef WITH_CYCLE_GC ! PyGC_Head *g = PyObject_AS_GC((PyObject *)v); ! PyObject_GC_Fini((PyObject *)v); ! g = (PyGC_Head *) ! PyObject_REALLOC((char *)g, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! if (g == NULL) { ! sv = NULL; ! } else { ! sv = (PyTupleObject *)PyObject_FROM_GC(g); ! } ! #else sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! #endif ! *pv = (PyObject *) sv; if (sv == NULL) { ! PyObject_GC_Init((PyObject *)v); ! v = (PyTupleObject *) PyObject_AS_GC(v); PyObject_DEL(v); PyErr_NoMemory(); return -1; } } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) --- 500,519 ---- } else #endif { ! PyObject_GC_Fini(v); ! v = (PyObject *) PyObject_AS_GC(v); sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); if (sv == NULL) { ! *pv = NULL; PyObject_DEL(v); PyErr_NoMemory(); return -1; } + sv = (PyTupleObject *) PyObject_FROM_GC(sv); + *pv = (PyObject *) sv; } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) From guido at python.org Thu Oct 5 20:22:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:22:49 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400." <14810.51466.486982.938180@anthem.concentric.net> References: <14810.51466.486982.938180@anthem.concentric.net> Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> [Aahz] > Someone just pointed out on c.l.py that we need an HTMLescape() function > that takes a string and converts special characters to entities. I'm > not on python-dev, so could you please forward this and find out whether > I need to run a PEP? Has someone pointed out yet that this is done by cgi.escape()? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:24:20 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:24:20 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST." <20001004024636.A13475@glacier.fnational.com> References: <200010041622.JAA17363@slayer.i.sourceforge.net> <20001004024636.A13475@glacier.fnational.com> Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com> > I aways seem to think harder when reviewing a commit message than > a diff. :( I just realized that this commit subtly modifies > cPickle's behavior. Before the change instances __del__ methods > would be called if allocating __dict__ failed. After the change > they are not. I think the new behavior is better but the > question is will it break existing code? I think probably not. This is goodness. Don't worry about breaking code -- it probably *fixes* code. Most __del__ methods don't know what to do when the instance variables haven't been defined yet! > BTW, pickle seems to follow the new behavior. Even better. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:29:27 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:29:27 -0500 Subject: [Python-Dev] Adding a section to PEP 0042 In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400." <20001004141620.A31293@ludwig.cnri.reston.va.us> References: <20001004141620.A31293@ludwig.cnri.reston.va.us> Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com> > I need to add an entry to PEP 0042 about the lack of cross-compilation > support, because that's a bug report that was assigned to me, and needs > to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems > to me that I should just add a section on "Build/Installation" to the > PEP -- anyone disagree? This might also be a good place to gather > other gripes about Python's build/installation machinery... +1 (I think the "Library" section is growing too big and may be split in "Lib" and "Modules" sections.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:33:47 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:33:47 -0500 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200." <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Whatever the outcome of this discussion, this is too late for 2.0. But I tend to side with Jeremy and Martin -- "explicit is better". I do want Jeremy to check his RPM generation scripts in, so they can be improved in a truly open source project. (Maybe in Tools/rpm?) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:43:30 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:43:30 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200." <002501c02edc$1302b040$766940d5@hagrid> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002501c02edc$1302b040$766940d5@hagrid> Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com> > what's the current release schedule, btw? Let me give that a shot... - Feature Freeze Now. I.e. it's too late for anything even vaguely resembling a feature -- even if it's been discussed to death. - Bugfix Checkin Freeze Saturday (Oct 7) Starting Saturday, all checkins must be coordinated with the releasemeister (still Jeremy). - Release Candidate Monday (Oct 9) - Final Release Monday week (Oct 16) Between the Release Candidate and the Final Release, all checkins must fix bugs and must be approved by the releasemeister. > is the repository frozen, or do we still have a chance to fix > the GC tuple problem and SRE's "nothing to repeat" bug? Simple bugfixes are okay till Saturday. Bugfixes that are complex and may break other stuff should be discussed with the releasemeister, possibly cc'ing python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Thu Oct 5 20:05:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 20:05:54 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com> Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid> neil wrote: > Yup. I've attached a patch which I believe fixes some GC bugs in > addition to making it simpler. don't have the slightest idea how the GC stuff works, but it sure looks right: just go ahead and check it in... > > btw, the start of Resize looks a bit strange: should that > > DECREF really be there? should least be an XDECREF, or > > am I missing something? > > > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > > *pv = 0; > > Py_DECREF(v); /* <- really? what if v is NULL? */ > > PyErr_BadInternalCall(); > > return -1; > > } > > I think your right. Here's a fun little program: > > from _tkinter import _flatten > import random # don't ask me why > for x in xrange(10000): > print x > t = _flatten([(0,)*x]*x) > > It gives: > > 0 > 1 > 2 > 3 > 4 > 5 > Segmentation fault guido? From jim at digicool.com Thu Oct 5 20:10:42 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 05 Oct 2000 14:10:42 -0400 Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR) References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com> Message-ID: <39DCC422.90E4D0D5@digicool.com> Sam Rushing wrote: > > Jim Fulton writes: > > The asyncore main loop should check for this error in it's select > > call and the select module should make this error easier to check > > for. > > It might go better into the event_loop function, which I think of as a > more user-serviceable part. [for example, the default loop vs. the > one in medusa/event_loop.py that supports schedulable events] Don't you think anyone using select on Unix would want this? This isn't really an application-specific thing is it? > > I presume that this works in Python 1.6/2.0, but I > > haven't tried it yet? > > > > This depends on the structure of select.error values > > and requires that we get EINTR from somewhere. (What > > should the value be on NT?) > > If it's a big problem, I guess we could use a different default > event_loop() function for win32 vs. unix. Or we could put this in the poll function and reraise the error on NT, as my change does. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From aahz at panix.com Thu Oct 5 21:52:47 2000 From: aahz at panix.com (aahz at panix.com) Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM Message-ID: <200010051952.PAA05883@panix6.panix.com> > [Aahz] >> Someone just pointed out on c.l.py that we need an HTMLescape() function >> that takes a string and converts special characters to entities. I'm >> not on python-dev, so could you please forward this and find out whether >> I need to run a PEP? > > Has someone pointed out yet that this is done by cgi.escape()? Yeah, I missed that earlier. But after thinking some more, there are a fair number of browser-like bits of software that fail to render many of the special characters correctly (e.g. trademark). This is frequently due to character set issues; entities almost always render correctly, though. Therefore a general translation routine is probably handy. cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape ought to be expanded to handle all characters or a new routine should be added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I have zero familiarity with XML and am waiting for 2.0final. Perhaps this should be taken off-line? -- --- Aahz (Copyright 2000 by aahz at pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 There's a difference between a person who gets shit zie doesn't deserve and a person who gets more shit than zie deserves. --Aahz From skip at mojam.com Thu Oct 5 21:54:56 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net> References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <14812.56464.380651.537610@beluga.mojam.com> Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty Barry> string always returns true. This closes SF bug #115392. There was a big thread recently on the tramp mailing list (similar to efs for remote file editing in Emacs, but uses ssh/scp instead) about trying to find a portable way to test for the existence of a file. After trying all sorts of stuff, the final result was pretty ugly, as I recall. -- Skip Montanaro (skip at mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From guido at python.org Thu Oct 5 23:07:29 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 16:07:29 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST." <200010051952.PAA05883@panix6.panix.com> References: <200010051952.PAA05883@panix6.panix.com> Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com> > Yeah, I missed that earlier. But after thinking some more, there are a > fair number of browser-like bits of software that fail to render many of > the special characters correctly (e.g. trademark). This is frequently > due to character set issues; entities almost always render correctly, > though. Therefore a general translation routine is probably handy. But character set issues also make it impossible to provide such a translation routine: the current party line is that the encoding of 8-bit strings is unknown and that only ASCII can be assumed. > cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape > ought to be expanded to handle all characters or a new routine should be > added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I > have zero familiarity with XML and am waiting for 2.0final. Perhaps > this should be taken off-line? xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read the source (Lib/xml/sax/saxutils.py). It allows you to specify additional things to be replaced by entities by passing in a dictionary mapping chars (or strings) to entities. If you know that you are dealing with Latin-1, you could use the table in htmlentitydefs.py to construct a table. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Thu Oct 5 22:13:34 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051952.PAA05883@panix6.panix.com> References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> <200010051952.PAA05883@panix6.panix.com> Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net> >>>>> "AM" == aahz writes: >> [Aahz] >>> Someone just pointed out on c.l.py that we need an HTMLescape() >>> function that takes a string and converts special characters to >>> entities. I'm not on python-dev, so could you please forward >>> this and find out whether I need to run a PEP? >> >> Has someone pointed out yet that this is done by cgi.escape()? AM> Yeah, I missed that earlier. But after thinking some more, AM> there are a fair number of browser-like bits of software that AM> fail to render many of the special characters correctly AM> (e.g. trademark). This is frequently due to character set AM> issues; entities almost always render correctly, though. AM> Therefore a general translation routine is probably handy. AM> cgi.escape() only handles "&", "<", ">". I'm not sure whether AM> cgi.escape ought to be expanded to handle all characters or a AM> new routine should be added. Martin van Loewis suggested AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML AM> and am waiting for 2.0final. Perhaps this should be taken AM> off-line? Perhaps we should take it to python-list -- or maybe we should form a web-sig and work on it there. There are definitely some tricky issues to work out. I attempted to work out some of the same issues for internationalization support in Mailman's pipermail archives. The escape function in cgi should stay minimal, because it deals with the only truly essential characters. If the browser interprets an HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are going to be rendered properly. You can add an explicit meta tag to the HTML page and the server will return the charset in the headers. This seems quite a bit simpler than trying to escape all characters > chr(127), except if you have to deal with old browsers that don't support the charset specified by the HTTP header. Jeremy From thomas at xs4all.net Thu Oct 5 23:40:22 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 5 Oct 2000 23:40:22 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700 References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <20001005234022.I12812@xs4all.nl> On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007 > Modified Files: > configure configure.in > Log Message: > Change all occurances of > > test -d "$directory" > to > test ! -z "directory" -a -d "directory" > Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string > always returns true. This closes SF bug #115392. > --- 3103,3110 ---- > USE_THREAD_MODULE="#" > else > ! if test ! -z $with_threads -a -d $with_threads > then LDFLAGS="$LDFLAGS -L$with_threads" > fi > ! if test ! -z $withval -a -d $withval > then LDFLAGS="$LDFLAGS -L$withval" > fi Is this really going to work ? I always see 'portable' shell code do something like if [ "X${spam}" != "X" ] ... instead of 'test -z', eventhough even BSDI test has -z. (The portable code I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is minimal, compared to modern day equivalents.) My /bin/sh-knowledge is decidedly less impressive than my Python knowledge, but I thought something like if test ! -z $withval -a -d $withval where $withval is empty, would be parsed as if test ! -z -a -d which would be, uhm, wrong ? But like I said, I don't really know what I'm talking about here, there could be another perfectly valid reason for BSDI to use the roundabout way, instead of using -z. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Fri Oct 6 00:12:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> Whatever the outcome of this discussion, this is too late for GvR> 2.0. But I tend to side with Jeremy and Martin -- "explicit is GvR> better". I do want Jeremy to check his RPM generation scripts GvR> in, so they can be improved in a truly open source project. GvR> (Maybe in Tools/rpm?) I don't actually use a script to generate the RPM. I wrote a .spec file by hand and use it to generate the RPMs using the rpm command. I could check in the spec file, which I would end up changing every time we do a release -- to update the version number, change the Setup.in patch, etc. I should probably also include the patch file along with the .spec file. I also wrote a smal distutils setup script for 2.0b2, which I should check in somewhere. Not sure where... BTW, I've attached the spec file below. You can get it from the .src.rpm on pythonlabs.com, but that's pretty inconvenient if you're merely curious. Jeremy %define name BeOpen-Python %define version 2.0b2 %define release 1 %define __prefix /usr/local Summary: An interpreted, interactive, object-oriented programming language. Name: %{name} Version: %{version} Release: %{release} Copyright: Modified CNRI Open Source License Group: Development/Languages Source: %{name}-%{version}.tar.bz2 Source1: html-%{version}.tar.bz2 Patch0: %{name}-%{version}-Setup.patch BuildRoot: /var/tmp/%{name}-%{version}-root Prefix: %{__prefix} URL: http://www.pythonlabs.com/ Vendor: BeOpen PythonLabs Packager: Jeremy Hylton %description Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes. Python combines remarkable power with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C or C++. It is also usable as an extension language for applications that need a programmable interface. Finally, Python is portable: it runs on many brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the Mac. %changelog * Thu Oct 5 2000 Jeremy Hylton - added bin/python2.0 to files list (suggested by Martin v. L?wis) * Tue Sep 26 2000 Jeremy Hylton - updated for release 1 of 2.0b2 - use .bz2 version of Python source * Tue Sep 12 2000 Jeremy Hylton - Version 2 of 2.0b1 - Make the package relocatable. Thanks to Suchandra Thapa. - Exclude Tkinter from main RPM. If it is in a separate RPM, it is easier to track Tk releases. %prep %setup -n Python-%{version} %patch0 %setup -D -T -a 1 -n Python-%{version} # This command drops the HTML files in the top-level build directory. # That's not perfect, but it will do for now. %build ./configure make %install [ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{__prefix} make prefix=$RPM_BUILD_ROOT%{__prefix} install %clean rm -fr $RPM_BUILD_ROOT %files %defattr(-, root, root) %{__prefix}/bin/python %{__prefix}/bin/python2.0 %{__prefix}/man/man1/python.1 %doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Porting %doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS %doc index.html modindex.html api dist doc ext inst lib mac ref tut icons %dir %{__prefix}/include/python2.0 %{__prefix}/include/python2.0/*.h %dir %{__prefix}/lib/python2.0/ %{__prefix}/lib/python2.0/*.py* %{__prefix}/lib/python2.0/pdb.doc %{__prefix}/lib/python2.0/profile.doc %dir %{__prefix}/lib/python2.0/config %{__prefix}/lib/python2.0/config/Makefile %{__prefix}/lib/python2.0/config/Makefile.pre.in %{__prefix}/lib/python2.0/config/Setup %{__prefix}/lib/python2.0/config/Setup.config %{__prefix}/lib/python2.0/config/Setup.local %{__prefix}/lib/python2.0/config/config.c %{__prefix}/lib/python2.0/config/config.c.in %{__prefix}/lib/python2.0/config/install-sh %{__prefix}/lib/python2.0/config/libpython2.0.a %{__prefix}/lib/python2.0/config/makesetup %{__prefix}/lib/python2.0/config/python.o %dir %{__prefix}/lib/python2.0/curses %{__prefix}/lib/python2.0/curses/*.py* %dir %{__prefix}/lib/python2.0/distutils %{__prefix}/lib/python2.0/distutils/*.py* %{__prefix}/lib/python2.0/distutils/README %dir %{__prefix}/lib/python2.0/distutils/command %{__prefix}/lib/python2.0/distutils/command/*.py* %{__prefix}/lib/python2.0/distutils/command/command_template %dir %{__prefix}/lib/python2.0/encodings %{__prefix}/lib/python2.0/encodings/*.py* %dir %{__prefix}/lib/python2.0/lib-dynload %dir %{__prefix}/lib/python2.0/lib-tk %{__prefix}/lib/python2.0/lib-tk/*.py* %{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so %{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so %{__prefix}/lib/python2.0/lib-dynload/_localemodule.so %{__prefix}/lib/python2.0/lib-dynload/arraymodule.so %{__prefix}/lib/python2.0/lib-dynload/binascii.so %{__prefix}/lib/python2.0/lib-dynload/cPickle.so %{__prefix}/lib/python2.0/lib-dynload/cStringIO.so %{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so %{__prefix}/lib/python2.0/lib-dynload/errnomodule.so %{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so %{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so %{__prefix}/lib/python2.0/lib-dynload/grpmodule.so %{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so %{__prefix}/lib/python2.0/lib-dynload/mathmodule.so %{__prefix}/lib/python2.0/lib-dynload/md5module.so %{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so %{__prefix}/lib/python2.0/lib-dynload/newmodule.so %{__prefix}/lib/python2.0/lib-dynload/operator.so %{__prefix}/lib/python2.0/lib-dynload/parsermodule.so %{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so %{__prefix}/lib/python2.0/lib-dynload/pyexpat.so %{__prefix}/lib/python2.0/lib-dynload/readline.so %{__prefix}/lib/python2.0/lib-dynload/resource.so %{__prefix}/lib/python2.0/lib-dynload/rotormodule.so %{__prefix}/lib/python2.0/lib-dynload/selectmodule.so %{__prefix}/lib/python2.0/lib-dynload/shamodule.so %{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so %{__prefix}/lib/python2.0/lib-dynload/stropmodule.so %{__prefix}/lib/python2.0/lib-dynload/structmodule.so %{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so %{__prefix}/lib/python2.0/lib-dynload/termios.so %{__prefix}/lib/python2.0/lib-dynload/timemodule.so %{__prefix}/lib/python2.0/lib-dynload/ucnhash.so %{__prefix}/lib/python2.0/lib-dynload/unicodedata.so %{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so %dir %{__prefix}/lib/python2.0/lib-old %{__prefix}/lib/python2.0/lib-old/*.py* %dir %{__prefix}/lib/python2.0/plat-linux2 %{__prefix}/lib/python2.0/plat-linux2/*.py* %{__prefix}/lib/python2.0/plat-linux2/regen %dir %{__prefix}/lib/python2.0/site-packages %{__prefix}/lib/python2.0/site-packages/README %dir %{__prefix}/lib/python2.0/test %{__prefix}/lib/python2.0/test/*.py* %{__prefix}/lib/python2.0/test/README %{__prefix}/lib/python2.0/test/audiotest.au %{__prefix}/lib/python2.0/test/greyrgb.uue %{__prefix}/lib/python2.0/test/test.xml %{__prefix}/lib/python2.0/test/testimg.uue %{__prefix}/lib/python2.0/test/testimgr.uue %{__prefix}/lib/python2.0/test/testrgb.uue %dir %{__prefix}/lib/python2.0/test/output %{__prefix}/lib/python2.0/test/output/test_* %dir %{__prefix}/lib/python2.0/xml %{__prefix}/lib/python2.0/xml/*.py* %dir %{__prefix}/lib/python2.0/xml/dom %{__prefix}/lib/python2.0/xml/dom/*.py* %dir %{__prefix}/lib/python2.0/xml/sax %{__prefix}/lib/python2.0/xml/sax/*.py* From fdrake at beopen.com Fri Oct 6 02:14:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> I just got this message from the gcc-announce list. We've seen bug reports related to GCC 2.96 (which may or may not be the problem). We need to be aware that these releases are out there and can be a problem. I've noticed that the version of GCC shipped with Mandrake 7.1 is "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much confidence either. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: Gerald Pfeifer Subject: GCC 2.96 Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST) Size: 3308 URL: From thomas at xs4all.net Fri Oct 6 02:29:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 6 Oct 2000 02:29:11 +0200 Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400 References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> Message-ID: <20001006022910.J12812@xs4all.nl> On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote: > I just got this message from the gcc-announce list. We've seen bug > reports related to GCC 2.96 (which may or may not be the problem). We > need to be aware that these releases are out there and can be a > problem. > I've noticed that the version of GCC shipped with Mandrake 7.1 is > "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much > confidence either. ;( The 'unstable' branch of Debian currently ships with: gcc version 2.95.2 20000220 (Debian GNU/Linux) and it seems to be working fine. I did notice a problem, but it was related to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have caught that one, but I found it on my machine before he checked in that fix ;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h include file: /* Number of bits in a word of type ong int'. */ #if LONG_MAX == 2147483647 # define LONG_BIT 32 #else /* Safe assumption. */ # define LONG_BIT 64 #endif where LONG_MAX was not defined (yet). I fixed it 'manually' for more than just Python by adding #ifndef LONG_MAX #define LONG_MAX 2147483647 #endif above it. I had to laugh, though, when I saw that assuming longs had 64 bits is considered 'a safe assumption'. I guess most people use 64 bit machines nowadays ? :-) I'm not complaining about this, though. Woody (Debian's current unstable tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm also wondering where to send my bugreport, but I think I'll read some documentation before I do that, first ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Fri Oct 6 03:37:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <20001006022910.J12812@xs4all.nl> References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> <20001006022910.J12812@xs4all.nl> Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > The 'unstable' branch of Debian currently ships with: > gcc version 2.95.2 20000220 (Debian GNU/Linux) > > and it seems to be working fine. I did notice a problem, but it was related I understand this to be the latest "stable" version of GCC, and it appearantly it has been accepted as such for a while now. > above it. I had to laugh, though, when I saw that assuming longs had 64 bits > is considered 'a safe assumption'. I guess most people use 64 bit machines > nowadays ? :-) Hey, my machine is 4294967296 bits! Forget those ancient 64 bit machines! ;-) > I'm not complaining about this, though. Woody (Debian's current unstable > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm I'm less concerned about people who know they're deliberatly putting themselves on the bleeding edge than the people that pick up the latest version of some Linux distribution and find they have a buggy compiler because the distribution builders weren't as careful as perhaps they should have been. Putting together a professional grade Linux distro is still a very hard thing. There's no such thing as enough testing here! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH at ActiveState.com Fri Oct 6 05:52:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Fri, 6 Oct 2000 14:52:13 +1100 Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c In-Reply-To: Message-ID: [Me, responding to Jeremy's request I look for potential buffer exploits on Windows...] > I will be happy to look into this. And was :-) If anyone has time over the next day or 2, any holes I either missed, or added(!) in http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547 0 would be appreciated! Thanks, Mark. From thomas.heller at ion-tof.com Fri Oct 6 09:20:56 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Fri, 6 Oct 2000 09:20:56 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> > I don't actually use a script to generate the RPM. I wrote a .spec > file by hand and use it to generate the RPMs using the rpm command. > I could check in the spec file, which I would end up changing every > time we do a release -- to update the version number, change the > Setup.in patch, etc. I should probably also include the patch file > along with the .spec file. > > I also wrote a smal distutils setup script for 2.0b2, which I should > check in somewhere. Not sure where... > Could you post this script? Thomas From loewis at informatik.hu-berlin.de Thu Oct 5 21:49:26 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST) Subject: [Python-Dev] PEP 4: Deprecation of standard modules Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de> I just finished a first draft of a PEP on deprecating (and eventually removing) modules from the standard Python library; it is available from http://python.sourceforge.net/peps/pep-0004.html If you have comments or suggestions on the proposed procedures, or the wording of the text, please send me a message. According to the PEP procedures (PEP 1), this is the preferred way of progressing this PEP (rather than discussing it on these lists), at least initially. Regards, Martin From loewis at informatik.hu-berlin.de Fri Oct 6 14:39:05 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de> > The difficulty, I assume, lies in figuring out which encodings > support what characters. It's not that difficult to write a set of new codecs; with the module below, I can do >>> import xmlenc >>> u'\u0416'.encode('latin-1-xml') 'Ж' >>> unicode('XɅY','latin-1-xml') u'X\u0245Y' The difficulty is that the algorithm is not very efficient if there are many unsupported characters in a string. Regards, Martin # Module implementing a set of new encodings of the form -xml # Copyright Martin v. Löwis # It currently supports hex character references only import codecs class CodecWrapper: def __init__(self,encoder,decoder): self.encoder = encoder self.decoder = decoder def encode(self,input,errors='strict'): try: return self.encoder(input,"strict") except ValueError: l = len(input) if l==1: return "&#x%x;" % ord(input), 1 s1,l1 = self.encode(input[:l/2]) s2,l2 = self.encode(input[l/2:]) return s1+s2,l1+l2 def decode(self,input,errors='strict'): input = str(input) # might be buffer object pos = input.find("&#x") if pos == -1: return self.decoder(input,errors) r1,l1 = self.decode(input[:pos],errors) end = input.find(";",pos) try: if end==-1: raise ValueError # goto failure code below val = int(input[pos+3:end],16) r2,l2 = self.decode(input[end+1:],errors) return r1+unichr(val)+r2,l1+end-pos+l2 except ValueError: # how to deal with errors in decode? r2,l2 = self.decode(input[pos+2:],errors) return r1+"&#x"+r2,l1+3+l2 def mkreader(self): r = codecs.StreamReader() r.decode = self.decode r.encode = self.encode return r def mkwriter(self): r = codecs.StreamWriter() r.decode = self.decode r.encode = self.encode return r def search_function(encoding): if not encoding.endswith("-xml"): return None enc,dec,reader,writer = codecs.lookup(encoding[:-4]) c = CodecWrapper(enc,dec) return c.encode,c.decode,c.mkreader,c.mkwriter codecs.register(search_function) From jeremy at beopen.com Fri Oct 6 16:54:03 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> <003d01c02f65$fb409550$4500a8c0@thomasnotebook> Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net> Here is the setup script I used to build the Tk RPMs. The name and version part is a mess and I would welcome suggestions on how to fix it. The problem is that Tkinter gets built against a particular version of Python and a particular version of Tcl/Tk. I want the name of the RPM to indiciate both versions, but didn't seem an obvious way to accomplish it. Thus, I put the Python version number in the name and the Tcl/Tk version number in the version. Otherwise, I think this is pretty straightforward distutils stuff (although the documentation was out of date last I checked). I've attached three files. I wrote setup.py and setup.cfg. Distutils created MANIFEST. Jeremy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MANIFEST URL: From jeremy at beopen.com Fri Oct 6 21:11:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net> I just fixed a number of major bugs in the undocumented linuxaudiodev module. I ended up spending about an hour reading the excellent Open Sound System (OSS) Programmer's Guide to figure out what the module was trying to do and why it wasn't working on my Linux box. After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python. I propose we develop a Python module for Python 2.1 and call it osslib. There is nothing at all that is Linux-specific about the interface being used. The OSS guide mentions a plethora of platforms that it supports. In the interim, I have fixed some of the most egregious problems. I would appreciate it if Linux users could try out the fixes and the new test case. On my machine it still sounds awful, but at least the sound can be heard. Jeremy From akuchlin at mems-exchange.org Fri Oct 6 21:17:39 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 6 Oct 2000 15:17:39 -0400 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400 References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >After reading the module and the OSS guide, it is clear to me that we >need a complete re-write. The module itself is just a wrapper around >a bunch of read, write, and ioctl calls. It could all be implemented >in pure Python. So, is there any point in releasing linuxaudiodev at all, then, if it needs a complete rewrite? --amk From DavidA at ActiveState.com Fri Oct 6 21:39:21 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: > I propose we develop a Python module for Python 2.1 and call it > osslib. There is nothing at all that is Linux-specific about the > interface being used. The OSS guide mentions a plethora of platforms > that it supports. Have you evaluated http://net.indra.com/~tim/ossmodule/ ? From jeremy at beopen.com Fri Oct 6 21:47:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <20001006151739.A31189@kronos.cnri.reston.va.us> Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >> After reading the module and the OSS guide, it is clear to me >> that we need a complete re-write. The module itself is just a >> wrapper around a bunch of read, write, and ioctl calls. It could >> all be implemented in pure Python. AMK> So, is there any point in releasing linuxaudiodev at all, then, AMK> if it needs a complete rewrite? I would be include to chuck it, except that it also shipped with 1.6. I would hestitate to deprecate it so far into the release process. jeremy From jeremy at beopen.com Fri Oct 6 21:47:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net> I had no idea it existed. Jeremy From jeremy at beopen.com Fri Oct 6 21:54:35 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net> >>>>> "DA" == David Ascher writes: DA> Have you evaluated http://net.indra.com/~tim/ossmodule/ Okay. I took a quick look. It's really old (July 1997). It looks like a more reasonable wrapping than linuxaudiodev, although I would want to review it more carefully against the OSS programmer's guide. I would prefer a pure Python solution, because the code would be shorter and easier to read and maintain. It may be, however, that the ossmodule is still up-to-date; if so, it may be easier to use it than to rewrite it. Jeremy From ping at lfw.org Fri Oct 6 23:13:39 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > After reading the module and the OSS guide, it is clear to me that we > need a complete re-write. The module itself is just a wrapper around > a bunch of read, write, and ioctl calls. It could all be implemented > in pure Python. True. I think your osslib is a good idea. I wanted to take on this sort of project myself a few weeks ago but never had the time to really get started. From playing with the test script, i think all we care about having in C is audioop (and that's just for ulaw conversion). I would like to fix audioop so we can expect it to be present as a standard module; then we can have a module written in Python that provides uniform sound support for all platforms. > On my machine it still sounds awful, but at least the > sound can be heard. It should not sound awful. If it sounds too loud and scratchy, then maybe you need to use audioop to convert from Sun .au (ulaw) to raw samples first. This was the case with the Spanish inquisition clip. -- ?!ng From jeremy at beopen.com Sat Oct 7 00:28:57 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: >> On my machine it still sounds awful, but at least the sound can >> be heard. KPY> It should not sound awful. If it sounds too loud and scratchy, KPY> then maybe you need to use audioop to convert from Sun .au KPY> (ulaw) to raw samples first. This was the case with the KPY> Spanish inquisition clip. I don't think I know how to do that. I tried using sox to convert audiotest.au to audiotest.raw and it sounded just as bad on my machine. Perhaps I have my machine configured incorrectly, although CDs and Real Audio sound fine. Have you tried the new code, BTW? Does the test work on your machine? Jeremy From tim_one at email.msn.com Sat Oct 7 00:28:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 6 Oct 2000 18:28:53 -0400 Subject: [Python-Dev] test_StringIO broken Message-ID: test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' 1 test failed: test_StringIO This on Win98SE, broke sometime late this afternoon (EDT). Working elsewhere? From jeremy at beopen.com Sat Oct 7 00:59:41 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: References: Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net> The test was changed in a number of ways, but whoever checked it in didn't actually run the regression test! Also, the last messsage I see printed is: Failed to catch ValueError writing to closed StringIO. This ain't a case of forgetting to generate new output. This is just plain wrong. Jeremy From thomas at xs4all.net Sat Oct 7 00:56:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:56:08 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: ; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400 References: Message-ID: <20001007005608.K12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote: > test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' > 1 test failed: test_StringIO > This on Win98SE, broke sometime late this afternoon (EDT). Working > elsewhere? No. Fails the same way on my Linux box. And the problem is probably that the test was updated (two tests were uncommented) but the output file wasn't updated. Jim Fulton did the checkin, so he looks like the right person to fix it (and manually check that the generated output file is *correct*, of course ! ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Sat Oct 7 01:01:37 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net> Message-ID: > Okay. I took a quick look. It's really old (July 1997). It looks > like a more reasonable wrapping than linuxaudiodev, although I would > want to review it more carefully against the OSS programmer's guide. > > I would prefer a pure Python solution, because the code would be > shorter and easier to read and maintain. It may be, however, that the > ossmodule is still up-to-date; if so, it may be easier to use it than > to rewrite it. Absolutely. I just remember some announcement about it. I suspect that what I remember is not that old, so it may make sense to do a little more digging than I did in the archives... --david From thomas at xs4all.net Sat Oct 7 00:58:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:58:19 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400 References: <14814.22877.882280.651958@bitdiddle.concentric.net> Message-ID: <20001007005819.L12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: > Also, the last messsage I see printed is: > Failed to catch ValueError writing to closed StringIO. > This ain't a case of forgetting to generate new output. This is just > plain wrong. Hm, are you sure you re-built your modules before doing that ? The output looks okay on my linux box, in any case. The last message is 'Caught expected ValueError writing to closed StringIO: I/O operation on closed file', for me. If you recompiled cStringIO, something odd is going on ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sat Oct 7 01:06:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: <20001007005819.L12812@xs4all.nl> References: <14814.22877.882280.651958@bitdiddle.concentric.net> <20001007005819.L12812@xs4all.nl> Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: >> Also, the last messsage I see printed is: Failed to catch >> ValueError writing to closed StringIO. >> This ain't a case of forgetting to generate new output. This is >> just plain wrong. TW> Hm, are you sure you re-built your modules before doing that ? This is probably what went wrong for me. Jeremy From guido at python.org Sat Oct 7 15:51:12 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 08:51:12 -0500 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST." <200010062309.QAA32052@slayer.i.sourceforge.net> References: <200010062309.QAA32052@slayer.i.sourceforge.net> Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> > Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE). The > parsing functions in support of auto-indent weren't expecting Unicode > strings, but text.get() can now return them (although it remains muddy as > to exactly when or why that can happen). Fixed that with a Big Hammer. I apologize, I should have explained when text.get() returns Unicode: Any string returned from Tcl/Tk that contains a byte with the 8th bit set is translated from UTF-8 into Unicode, unless the translation fails (in which case the original raw 8-bit string is returned as a fallback). This *should* be correct because Tcl/Tk always uses UTF-8 internally. (Even though it is "lenient" when receiving strings -- if a sequence of characters has no valid Unicode representation, it appears to falls back to Latin-1; I don't know the details of this algorithm.) --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Sat Oct 7 20:43:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 7 Oct 2000 14:43:55 -0400 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> Message-ID: >> Fix for next iteration of SF bug 115690 (Unicode headaches in >> IDLE). ... [Guido] > I apologize, I should have explained when text.get() returns Unicode: > > Any string returned from Tcl/Tk that contains a byte with the 8th bit > set is translated from UTF-8 into Unicode, unless the translation > fails (in which case the original raw 8-bit string is returned as a > fallback). Except that's *why* it was muddy : in the specific case that popped up in the bug, text.get() appeared to return a Unicode string of length 1 containing only a newline. No high-bit byte appeared to be involved. However, that was an illusion I didn't unmask until later. All is clear now. > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > (Even though it is "lenient" when receiving strings -- if a sequence > of characters has no valid Unicode representation, it appears to falls > back to Latin-1; I don't know the details of this algorithm.) Dunno, but wouldn't be surprised if they had a notion of default encoding, and that it simply appears to be Latin-1 to us because American Windows uses a superset of Latin-1. If BeOpen would like to buy me a version of Chinese Windows, happy to lend it to you . as-american-as-they-come-ly y'rs - tim From guido at python.org Sun Oct 8 03:41:11 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 20:41:11 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400." <14814.21033.195290.728159@bitdiddle.concentric.net> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com> I think I fixed the linuxaudio test -- see if it sounds reasonable now! The crux of the matter seemed to be that the last, optional argument to setparameters(), meaning "emulate the format if the sound card doesn't support it", is not supported right. It suppresses the error message, and the ioctl to set the format succeeds, but the emulation doesn't work (at least not on my system, or on Jeremy's). So I've used a subterfuge: assuming most sound cards support signed 16-bit native-endian format, I convert the data to that format, and use the appropriate format code: AFMT_S16_LE for little-endian machines, AFMT_S16_BE for big-endian machines. I've only tested little-endian. I use the new sys.byteorder variable to determine the endianness. I use the audioop module to do the conversion. Much simpler than sox! (Oh feeling of nostalgia... I wrote several of the file format handlers for sox, and fixed lots of bugs in it too... I even started the audio file formats FAQ, now maintained by Chris Bagwell, who also took over sox...) Downside: test_linuxaudiodev will now be skipped if you don't have the audioop enabled in your Setup file. But that's fixed easily. By the way -- the checkin freeze for the release candidate should go in just about now... --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Sun Oct 8 12:32:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 06:32:36 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: Blast from the past! [/F] > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) [Tim] > How about instead enhancing existing (?Ppattern) notation, to > set a new match object attribute to name if & when pattern matches? > Then arbitrary info associated with a named pattern can be gotten at > via dicts via the pattern name, & the whole mess should be more > readable. [/F Sent: Sunday, July 02, 2000 6:35 PM] > I just added "lastindex" and "lastgroup" attributes to the match object. > > "lastindex" is the integer index of the last matched capturing group, > "lastgroup" the corresponding name (or None, if the group didn't have > a name). both attributes are None if no group were matched. Reviewing this before 2.0 has been on my todo list for 3+ months, and finally got to it. Good show! I converted some of my by-hand scanners to use lastgroup, and like it a whole lot. I know you understand why this is Good, so here's a simple example of an "after" tokenizer for those who don't (this one happens to tokenize REXX-like PARSE stmts): import re _token = re.compile(r""" (?P \s+) | (?P [a-zA-Z_]\w*) | (?P \.) | (?P \d+) | (?P [-+=()]) | (?P " [^"\\\n]* (?: \\. [^"\\\n]*)* " | ' [^'\\\n]* (?: \\. [^'\\\n]*)* ' ) """, re.VERBOSE).match del re (T_SPACE, T_VAR, T_DONTCARE, T_NUMBER, T_PUNC, T_STRING, T_EOF, ) = range(7) # For debug output. _enum2name = ["T_SPACE", "T_VAR", "T_DONTCARE", "T_NUMBER", "T_PUNC", "T_STRING", "T_EOF", ] _group2action = { "space": (T_SPACE, None), "var": (T_VAR, None), "dontcare": (T_DONTCARE, None), "number": (T_NUMBER, int), "punc": (T_PUNC, None), "string": (T_STRING, eval), } def tokenize(s, tokeneater): i, n = 0, len(s) while i < n: m = _token(s, i) if not m: raise ParseError(s, i) group = m.lastgroup enum, action = _group2action[group] val = m.group(group) if action is not None: val = action(val) tokeneater(enum, val) i = m.end() tokeneater(T_EOF, None) The tokenize function here used to be a mass of if/elif stmts trying to figure out which group had matched. Now it's all table-driven: easier to write, reuse & maintain, and quicker to boot. +1. the-aged-may-be-slow-but-they-never-forget-ly y'rs - tim From effbot at telia.com Sun Oct 8 13:04:50 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 8 Oct 2000 13:04:50 +0200 Subject: [Python-Dev] Tcl and Unicode References: Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid> guido: > > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > > (Even though it is "lenient" when receiving strings -- if a sequence > > of characters has no valid Unicode representation, it appears to falls > > back to Latin-1; I don't know the details of this algorithm.) Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but their 8-bit strings use UTF-8. When converting from external 8-bit strings to unicode, they convert valid UTF-8 sequences to unicode characters just like Python, but "a lead-byte not followed by enough trail-bytes represents itself." (in other words, it's cast from an unsigned char to an unsigned short). And the chance that any reasonable Latin-1 string would contain a UTF-8 lead bytes followed by the right number of UTF-8 trail bytes is close to zero... (in case anyone wonders, Python's codec thinks that "close to zero" isn't good enough, so it raises an exception instead) tim: > Dunno, but wouldn't be surprised if they had a notion of default encoding, > and that it simply appears to be Latin-1 to us because American Windows uses > a superset of Latin-1. They have a system encoding, but it's not used here -- it's just that Latin-1 is a subset of Unicode... From thomas at xs4all.net Sun Oct 8 13:14:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 8 Oct 2000 13:14:33 +0200 Subject: [Python-Dev] Release candidate Message-ID: <20001008131433.M12812@xs4all.nl> Is there any chance we can get the 'release candidate' released on the SF File Module thingy as well ? Mailman uses this for the betas, for instance, and I think it would attract that bit more attention to it. I believe the 'release' gets listed on various SF pages that way. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry at scottb.demon.co.uk Sun Oct 8 16:36:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 8 Oct 2000 15:36:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000401c03135$2ebd4ec0$060210ac@private> Tim, Two requests: 1. Can you ship the .PDB files for the debug images so devo's do not need to build the python sources to debug extensions. And Yes I know the .ZIP will be huge. If you want a compromise only include the .PDB for python20_d.dll. 2. Place the files into libs, pyd etc dirs. I had to extract the groups into the right places which is a bit tedious and error prone. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Tim Peters > Sent: 27 September 2000 23:40 > To: PythonDev; Python list > Subject: [Python-Dev] Python 2.0b2 note for Windows developers > > > Since most Python users on Windows don't have any use for them, I trimmed > the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe > and .dll files. If you want them, they're available in a separate zip > archive; read the Windows Users notes at > > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > for info and a download link. If you don't already know *why* you might > want them, trust me: you don't want them . > > they-don't-even-make-good-paperweights-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From ping at lfw.org Sun Oct 8 20:19:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > > Have you tried the new code, BTW? Does the test work on your machine? Works okay (i updated after Guido's last edit). Sounds fine to me. But it bugs me that some of the descriptions say "audio" and others say "format". This seems arbitrary -- is there a reason? Excerpt of Modules/linuxaudiodev.c: { 8, ??????AFMT_MU_LAW, "Logarithmic mu-law audio" }, { 8, ??????AFMT_A_LAW, "Logarithmic A-law audio" }, { 8,???????AFMT_U8, "Standard unsigned 8-bit audio" }, { 8, ??????AFMT_S8, "Standard signed 8-bit audio" }, { 16, ??????AFMT_U16_BE, "Big-endian 16-bit unsigned format" }, { 16, ??????AFMT_U16_LE, "Little-endian 16-bit unsigned format" }, { 16, ??????AFMT_S16_BE, "Big-endian 16-bit signed format" }, { 16, ??????AFMT_S16_LE, "Little-endian 16-bit signed format" }, If you don't mind, i'd prefer something like: { 8, ??????AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" }, { 8, ??????AFMT_A_LAW, "logarithmic A-law 8-bit audio" }, { 8,???????AFMT_U8, "linear unsigned 8-bit audio" }, { 8, ??????AFMT_S8, "linear signed 8-bit audio" }, { 16, ??????AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" }, { 16, ??????AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" }, { 16, ??????AFMT_S16_BE, "linear signed 16-bit big-endian audio" }, { 16, ??????AFMT_S16_LE, "linear signed 16-bit little-endian audio" }, The above conforms to: "audio" where ::= "logarithmic" ("mu-law" | "A-law") | "linear" ("unsigned" | "signed") ::= "8-bit" | "16-bit" ("big-endian" | "little-endian") -- ?!ng "Simple, yet complex." -- Lenore Snell From tim_one at email.msn.com Sun Oct 8 21:28:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 15:28:55 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private> Message-ID: [Barry] > Two requests: > > 1. Can you ship the .PDB files for the debug images so devo's > do not need to build the python sources to debug extensions. > And Yes I know the .ZIP will be huge. If you want a > compromise only include the .PDB for python20_d.dll. Sure! Most .pdb files are highly compressible, and the zip size hit isn't anything to worry about. > 2. Place the files into libs, pyd etc dirs. I had to extract > the groups into the right places which is a bit tedious > and error prone. No. If you want a directory structure that doesn't match the actual build directory structure, I can't read your mind, and have no reason to believe that the specific artificial structure you have in mind is of use to anyone but you. Don't be so helpless : write a tiny Python script to move the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python themselves and just want to avoid jumping thru all the snaky hoops needed to compile the 3rd-party subprojects (from _tkinter to zlib). alphabetically y'rs - tim From guido at python.org Sun Oct 8 22:52:54 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 08 Oct 2000 15:52:54 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST." References: Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com> > But it bugs me that some of the descriptions say "audio" and others say > "format". This seems arbitrary -- is there a reason? Okay, you're right. (But there are sooooo many other things wrong with the code still... E.g. the bogus reference to "ctl". :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Mon Oct 9 08:04:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 08 Oct 2000 23:04:55 -0700 Subject: [Python-Dev] A standard lexer? References: Message-ID: <39E16007.5F1DDF9A@prescod.net> Tim Peters wrote: > > ... > > Reviewing this before 2.0 has been on my todo list for 3+ months, and > finally got to it. Good show! I converted some of my by-hand scanners to > use lastgroup, and like it a whole lot. I know you understand why this is > Good, so here's a simple example of an "after" tokenizer for those who don't > (this one happens to tokenize REXX-like PARSE stmts): Is there a standard technique for taking a regexp like this and applying it to data fed in a little at a time? Other than buffering the data forever? That's something else I would like in a "standard Python lexer", if that's the goal. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido at beopen.com Thu Oct 5 15:16:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 5 Oct 2000 09:16:14 -0400 Subject: [Python-Dev] htmllib.HTMLescape() References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com> Note that cgi.escape() does this too. --Guido ----- Original Message ----- From: "Martin von Loewis" To: Cc: Sent: Wednesday, October 04, 2000 4:31 PM Subject: [Python-Dev] htmllib.HTMLescape() > > Someone just pointed out on c.l.py that we need an HTMLescape() > > function that takes a string and converts special characters to > > entities. I'm not on python-dev, so could you please forward this > > and find out whether I need to run a PEP? > > Doesn't xml.sax.saxutils.escape do what you want (together with > htmlentitydefs)? I was going to say that this is quite a small change > to warrant a PEP - but there are two obvious approaches (working from > scratch, or working on top of xml.sax.saxutils.escape - perhaps > modifying and relocating that function), so *some* design probably > needs to be recorded in a PEP. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From loewis at informatik.hu-berlin.de Mon Oct 9 16:01:10 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com> (guido@beopen.com) References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com> Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de> > Note that cgi.escape() does this too. Indeed. That justifies a PEP that proposes to concentrate the functionality in one place, deprecating the other places. One approach would be to enhance the codec facilites, so that "string".encode("iso-entities") becomes possible - but that is already in the middle of discussing the PEP. Regards, Martin From jeremy at beopen.com Mon Oct 9 16:35:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36 In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net> References: <200010091418.HAA08765@slayer.i.sourceforge.net> Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net> Thanks. I didn't get to it on Friday. Jeremy From trentm at ActiveState.com Tue Oct 10 00:56:00 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 9 Oct 2000 15:56:00 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200 References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid> Message-ID: <20001009155600.A27929@ActiveState.com> [Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py fail on the overflow checks] [Fredrik gives me a simple test C program to test PyOS_CHeckStack independently (The test program is included at the bottom of this email.)] SOrry I took so long to reply to this but I spent a little bit of time playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated. Here is what I found: - The simple test program shows that PyOS_CheckStack will fire as intended on both Win32 and Win64 with either Visual C's default optimization OR no optimization. - The simple test program will *not* fire as intended with the '-O2' optimization which Python *does* use for pythonrun.c (where PyOS_CheckStack lives). So, likely the '-O2' optimization will optimize-away the _alloca() call. Fine. But why then does it *not* get optimized away when pythonrun.c is compiled? Does the context around other code in the same file affect that optimization? - When I apply this patch to _sre.c on *Win32* (basically the same test as the test file that Fredrik gave me to try) the "callme(0)" call *never* returns -- infinite loop. Note that this happens on the Release *and* Debug builds so nothing is being optimized away. *************** *** 560,565 **** --- 560,569 ---- } #endif + + + void callme(int i); + LOCAL(int) SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level) { *************** *** 578,583 **** --- 582,588 ---- TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level)); #if defined(USE_STACKCHECK) + callme(0); if (level % 10 == 0 && PyOS_CheckStack()) return SRE_ERROR_RECURSION_LIMIT; #endif *************** *** 2337,2340 **** --- 2342,2357 ---- Py_InitModule("_" MODULE, _functions); } + void callme(int i) + { + char buf[100000]; + if (PyOS_CheckStack()) + return; + printf("%d\n", i); + memset(buf, 0, sizeof buf); + callme(i+1); + } + + + #endif /* !defined(SRE_RECURSIVE) */ - I am not smart enough and/or (you decide :) do not have the inclination to figure this out (i.e. start looking at assembly code) just so _sre can use stack checking instead of the existing RECURSION_LIMIT framework (albeit the limited general usefullness of this) on Win64 so that test_sre.py can pass. Would it be alright for me to apply: *** python/dist/src/Include/pythonrun.h Sat Sep 16 09:31:31 2000 --- python/dist/src/Include/pythonrun.h Sun Oct 8 10:20:02 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif to disable stack checking on Win64 until Win64 become more mainstream and others can bang away at this? The important thing, I would think, is getting the test suite passing for Python 2.0. ------- test file mentioned above -------------------------------- #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ----------------------------------------------------- -- Trent Mick TrentM at ActiveState.com From jeremy at beopen.com Tue Oct 10 02:26:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT) Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net> I have placed pre-release copies of the 2.0 release candidate 1 source tarballs at ftp://python.beopen.com/pub/python/2.0c1/. We reserve the right two change these without notice prior to the official release :-). Jeremy From nas at arctrix.com Mon Oct 9 21:06:08 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 9 Oct 2000 12:06:08 -0700 Subject: [Python-Dev] test_import failing Message-ID: <20001009120608.A13588@glacier.fnational.com> I assume the CVS sources are basicly the same as 2.0c1. Anyhow, test_import is failing on my Debian machine. The script is creating "@test.py" and then trying to import it. "." is not in sys.path for some reason. Neil From jeremy at beopen.com Tue Oct 10 04:17:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net> I assume that you are running the test some way other than using "make test." It seems that make test executes python this way -- PYTHONPATH= ./python -- which causes the current directory to be added to the path. If you run python without having the current directory on your path test_import file fail. Unless you are having a different problem, this isn't important enough to fix in 2.0c1, although it seems good to fix for 2.0 final. Jeremy PS We have left GC turned on by default in 2.0c1 and plan to do the same for 2.0 final. From fdrake at beopen.com Tue Oct 10 04:09:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT) Subject: [Python-Dev] test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > test_import is failing on my Debian machine. The script is > creating "@test.py" and then trying to import it. "." is not in > sys.path for some reason. Jeremy & I finally figured this out. "make test" runs python with PYTHONPATH set to '' (an empty string). This is decidedly different from running with PYTHONPATH unset (I consider this a bug that should be fixed in 2.1). The empty string is interpreted as the current directory (as expected), so running "make test" adds the current directory to sys.path, but running the regression test (test_import or regrtest) as a script does not. We decided not to fix this now, since it's too late to be sure it's the right change, and adjusting the test case also means a very late change. So whoever runs the tests is responsible for making sure the current directory is on sys.path. (*Really* bogus!) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Oct 10 04:20:11 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Unless you are having a different problem, this isn't important enough > to fix in 2.0c1, although it seems good to fix for 2.0 final. And it's questionable how many bugs are hiding here as well. I count two: - test_import.py assumes the current directory is on the path; this is just plain fragile, and should explicitly pick the directory off of test_support.TESTFN, and add it to sys.path for the duration of the test (which does indeed fix this bug) - Modules/getpath.c interprets an empty definition of $PYTHONPATH as adding '' to sys.path, where I assert it should not add anything to sys.path. Everywhere else I've recall seeing an environment variable used as a data source, the test is done like this: char *cp = getenv("VARIABLE"); if (cp != NULL && cp[0] != '\0') { ... } (with some spelling variations). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Tue Oct 10 08:52:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT) Subject: [Python-Dev] Python 2.0 release candidate 1 Message-ID: <200010100652.XAA74600@python.beopen.com> Python 2.0c1 is released. The BeOpen PythonLabs and our cast of SourceForge volunteers have fixed many bugs since the beta releases last month. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There's a tarball, a Windows installer, RedHat RPMs, online documentation, and a long list of fixed bugs. The final release of Python 2.0 will be next week. We would appreciate feedback on the release candidate in order to fix any remaining bugs before the final release. Confirmation of build and test success on less common platforms is also helpful.n All major reported bugs have been fixed in the release candidate. We do not plan to make any changes between now and the final release, except to fix bugs reported in the next week. We encourage potential users of Python 2.0 to try the release candidate with their programs and report any remaining bugs. To report a new bug, use the SourceForge bug tracker http://sourceforge.net/bugs/?func=addbug&group_id=5470 Python 2.0 has many new features, including the following: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0, please see the article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: http://starship.python.net/crew/amk/python/writing/new-python/ -- Jeremy Hylton From tismer at appliedbiometrics.com Tue Oct 10 12:33:36 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Tue, 10 Oct 2000 13:33:36 +0300 Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9 Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com> ANNOUNCING: Stackless Python 1.2 A Python Implementation That Does Not Use The C Stack * plus the real toy * Continuation Module 0.9 Continuations as First Class Objects with support for MicroThreads What is it? A plugin-replacement for core Python. It should run any program which runs under Python 1.5.2 . But it does not need space on the C stack. For further info, see the new site at http://www.stackless.com You might also want to join the mailing list at http://starship.python.net/mailman/listinfo/stackless Major changes in this release: Extra reference counting reduces continuation frame creation Better exception handling avoids cycles. Next to come: - A port to Python 2.0 will be the first thing to do. - Long-term project is a complete redesign and rewrite for inclusion with Python 2.1 ciao - Christian Tismer / Mission Impossible 5oftware Team

    Stackless Python 1.2 + Continuations 0.9 - a version of Python 1.5.2 that does not need space on the C stack, first-class callable continuation objects for Python, and Microthread-support. (10-Oct-2000)

    -- http://www.python.org/mailman/listinfo/python-list From guido at python.org Tue Oct 10 15:04:39 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:04:39 -0500 Subject: [Python-Dev] test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400." <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com> > Neil Schemenauer writes: > > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > > test_import is failing on my Debian machine. The script is > > creating "@test.py" and then trying to import it. "." is not in > > sys.path for some reason. > > Jeremy & I finally figured this out. "make test" runs python with > PYTHONPATH set to '' (an empty string). This is decidedly different > from running with PYTHONPATH unset (I consider this a bug that should > be fixed in 2.1). > The empty string is interpreted as the current directory (as > expected), so running "make test" adds the current directory to > sys.path, but running the regression test (test_import or regrtest) as > a script does not. > We decided not to fix this now, since it's too late to be sure it's > the right change, and adjusting the test case also means a very late > change. So whoever runs the tests is responsible for making sure the > current directory is on sys.path. (*Really* bogus!) Proper fix, which I will check in momentarily: put import sys sys.path.insert(0, os.curdir) in front of test_import.py; and add del sys.path[0] to the end. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 10 15:06:54 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:06:54 -0500 Subject: [Python-Dev] Re: test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400." <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com> > And it's questionable how many bugs are hiding here as well. I > count two: > > - test_import.py assumes the current directory is on the path; this > is just plain fragile, and should explicitly pick the directory > off of test_support.TESTFN, and add it to sys.path for the > duration of the test (which does indeed fix this bug) I'll fix this. > - Modules/getpath.c interprets an empty definition of $PYTHONPATH as > adding '' to sys.path, where I assert it should not add anything > to sys.path. Everywhere else I've recall seeing an environment > variable used as a data source, the test is done like this: > > char *cp = getenv("VARIABLE"); > if (cp != NULL && cp[0] != '\0') { > ... > } > > (with some spelling variations). Agreed, but please *don't fix this in 2.0!* Who knows how many other hidden bugs (in 3rd party code) this will trigger... OK to fix it after 2.0final is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Oct 10 14:58:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 14:58:09 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 Message-ID: <39E31261.166F1601@lemburg.com> I've just had a glance at the releas candidate 1. The file LICENSE has grown somewhat, but not as much as I feared... looking at the contents I find the following as only reference to the CNRI license (which holds all the surprises we talked about in the early beta stages): """ CNRI OPEN SOURCE LICENSE AGREEMENT ---------------------------------- Python 1.6 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6 may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1012. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1012. """ Such a note is nice and short, but not legally binding and confusing since it is not clear whether the "handle" for the document will always return the same license text or if it will return a license text at all. It would be more appropriate to include the original CNRI license text, IMHO. Or is there some hidden motivation behind using the handle ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller at ion-tof.com Tue Oct 10 15:06:05 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:06:05 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> There has been some confusion about distutils, especially the bdist_wininst command. I hope I can clarify these things with this post. 1. The current Distutils version 1.0, which is also included in the Python 2.0 release candidate is perfectly usable apart from one bug: You should create windows installers (by running 'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst') ONLY with an external zip utility (info-zip would do). Using the zipfile module results in corrupted installations (all files are created with zero length). Details about the cause for this can be found in the patch I posted to SF. 2. I submitted a patch to SF http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 which corrects this bug. Normally I would have checked this code in immediately, because it is in _my_ code, and that's what my checkin rights are for ;-). I did not because I did not want to interfere with the release process of python 2.0 rc 1. 3. How does bdist_wininst work? bdist_wininst creates a self-extracting zipfile from two components: a stub program (wininst.exe) plus a zip-file containing the code to be distributed. Because I did not liked wininst.exe as binary file checked in into CVS, the actual bytes of this exe are included base64-encoded in the bdist_wininst.py module as string. I'm not sure whether this is a wise design or not, but that is a different topic. The downside of this design is that when the source to wininst.exe changes, it must be recompiled, and bdist_wininst.py must be regenerated. The context-diffs for bdist_wininst.py are so very large. 4. To understand the patch, you should know the following: Distutils is a separate toplevel module in the repository on sourceforge. Parts of this repository are symbolically linked somewhere into the python tree. Thus, this patch must be applied to the distutils _module_ in the repository. Distutils directory structure is as follows: distutils dd distutils command doc dist inst examples sample1 sample2 sample3 misc test text Relevant part of python directory structure: python dist src Lib distutils command The source code for wininst.exe is in CVS in the distutils/misc directory. The patch I posted to SF does not include the compiled wininst.exe, neither does it include the (regenerated) bdist_wininst.py module. 5. If nobody objects, I will check in the changes I made tomorrow, recompile the exe, regenerate the bdist_wininst.py, and everything should be fine again. Greg will then hopefully, when he is back, increase the distutils version number to 1.0.1 (or whatever) and this version will then be delivered with python 2.0 final. Sorry for the confusion. Cheers, Thomas From guido at python.org Tue Oct 10 16:36:57 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:36:57 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200." <39E31261.166F1601@lemburg.com> References: <39E31261.166F1601@lemburg.com> Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com> > I've just had a glance at the releas candidate 1. The file LICENSE > has grown somewhat, but not as much as I feared... Since when? It hasn't changed since it was first released, for 2.0b1. > looking > at the contents I find the following as only reference to the > CNRI license (which holds all the surprises we talked about in > the early beta stages): > > """ > CNRI OPEN SOURCE LICENSE AGREEMENT > ---------------------------------- > > Python 1.6 is made available subject to the terms and conditions in > CNRI's License Agreement. This Agreement together with Python 1.6 may > be located on the Internet using the following unique, persistent > identifier (known as a handle): 1895.22/1012. This Agreement may also > be obtained from a proxy server on the Internet using the following > URL: http://hdl.handle.net/1895.22/1012. > """ > > Such a note is nice and short, but not legally binding and > confusing since it is not clear whether the "handle" for the > document will always return the same license text or if it > will return a license text at all. Why do you say it's not legally binding? The CNRI license explicitly allows you to use this exact text instead of including the whole CNRI license. > It would be more appropriate to include the original CNRI license > text, IMHO. Or is there some hidden motivation behind using the > handle ? I was just trying to save space. ActivePython does the same thing as far as I remember. BTW, I haven't heard from CNRI in two weeks, but the last thing I heard from them was that their lawyers had talked to Stallman's lawyer and that they were optimistic about a successful resolution. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 10 16:41:50 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:41:50 -0500 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200." <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Thomas, thanks for the explanation. I agree that you can check in the changes yourself as you proposed. There's one issue I still don't understand (not having the time to read the full distutils docs): how does a typical Windows developer decide whether to use an external zip utility or the zipfile module? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller at ion-tof.com Tue Oct 10 15:58:32 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:58:32 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook> > Thomas, thanks for the explanation. I agree that you can check in the > changes yourself as you proposed. > > There's one issue I still don't understand (not having the time to > read the full distutils docs): how does a typical Windows developer > decide whether to use an external zip utility or the zipfile module? I'm afraid it is not documented. Distutils first tries to spawn an external zip program, then tries the zipfile module, if nothing is found, a warning is issued. So, the windows developer currently _must_ install zip.exe somewhere in the path. (As often, the default is wrong, because a zip utility is not included in windows). Thomas From mal at lemburg.com Tue Oct 10 16:03:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 16:03:14 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> Message-ID: <39E321A2.2BD99E35@lemburg.com> Guido van Rossum wrote: > > > I've just had a glance at the releas candidate 1. The file LICENSE > > has grown somewhat, but not as much as I feared... > > Since when? It hasn't changed since it was first released, for 2.0b1. Since the old 1.5.2 LICENSE file. > > looking > > at the contents I find the following as only reference to the > > CNRI license (which holds all the surprises we talked about in > > the early beta stages): > > > > """ > > CNRI OPEN SOURCE LICENSE AGREEMENT > > ---------------------------------- > > > > Python 1.6 is made available subject to the terms and conditions in > > CNRI's License Agreement. This Agreement together with Python 1.6 may > > be located on the Internet using the following unique, persistent > > identifier (known as a handle): 1895.22/1012. This Agreement may also > > be obtained from a proxy server on the Internet using the following > > URL: http://hdl.handle.net/1895.22/1012. > > """ > > > > Such a note is nice and short, but not legally binding and > > confusing since it is not clear whether the "handle" for the > > document will always return the same license text or if it > > will return a license text at all. > > Why do you say it's not legally binding? The CNRI license explicitly > allows you to use this exact text instead of including the whole CNRI > license. Sure, but not including the verbatim text will produce an unpleasent feeling of not being sure about the completeness of the license text. In a law suit the above construct would certainly not hold, since URLs only describe the location of information and don't hold any information about the validity or origin of it. The situation would be a little better if CNRI had provided a PGP signature or fingerprint of the license, since this is (in some countries) a legally accepted way of determining those two criteria. Just a side note: the URL given for the license results in a redirect to a different URL - http://www.handle.net/python_licenses/python1.6_9-5-00.html (note the date !): this doesn't really give the impression of persistent unchangeable information. Not that there's much to fear about... but why add any extra areas of uncertainty ? > > It would be more appropriate to include the original CNRI license > > text, IMHO. Or is there some hidden motivation behind using the > > handle ? > > I was just trying to save space. ActivePython does the same thing as > far as I remember. Space?... the download is 3.9 Megs ;-) > BTW, I haven't heard from CNRI in two weeks, but the last thing I > heard from them was that their lawyers had talked to Stallman's lawyer > and that they were optimistic about a successful resolution. Great ! This would be really good news indeed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From just at letterror.com Tue Oct 10 17:47:00 2000 From: just at letterror.com (Just van Rossum) Date: Tue, 10 Oct 2000 16:47:00 +0100 Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9 In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com> Message-ID: In response to the new release of Stackless Python (see http://www.stackless.com/), here's a new stackless binary for MacPython 1.5.2: http://starship.python.net/~just/MacStacklessPython.sit.hqx (The archive contains a replacement for the PythonCore shared library) Just From guido at python.org Tue Oct 10 17:50:07 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 10:50:07 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200." <39E321A2.2BD99E35@lemburg.com> References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> <39E321A2.2BD99E35@lemburg.com> Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com> > > > Such a note is nice and short, but not legally binding and > > > confusing since it is not clear whether the "handle" for the > > > document will always return the same license text or if it > > > will return a license text at all. > > > > Why do you say it's not legally binding? The CNRI license explicitly > > allows you to use this exact text instead of including the whole CNRI > > license. > > Sure, but not including the verbatim text will produce an > unpleasent feeling of not being sure about the completeness > of the license text. > > > > In a law suit the above construct would > certainly not hold, since URLs only describe the location of > information and don't hold any information about the validity > or origin of it. The situation would be a little better if CNRI > had provided a PGP signature or fingerprint of the license, > since this is (in some countries) a legally accepted way of > determining those two criteria. > > Just a side note: the URL given for the license results in a > redirect to a different URL - > http://www.handle.net/python_licenses/python1.6_9-5-00.html > (note the date !): this doesn't really give the impression of > persistent unchangeable information. > > Funny... I agree that's not very confidence-inspiring. CNRI always advertises handles as better than URLs for long-term persistent documents, but it's clear that they didn't think of this! Or maybe (warning: fake conspiracy theory ahead :-) they intend to change the license terms after the fact... > Not that there's much to fear about... but why add any extra areas > of uncertainty ? Agreed. I'll add the full text back in. > > I was just trying to save space. ActivePython does the same thing as > > far as I remember. > > Space?... the download is 3.9 Megs ;-) I meant less text for the reader to wade through. But you've convinced me already. --Guido van Rossum (home page: http://www.python.org/~guido/) From bjorn at roguewave.com Tue Oct 10 20:35:15 2000 From: bjorn at roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 12:35:15 -0600 Subject: [Python-Dev] Re: Python 2.0 release candidate 1 References: <200010100652.XAA74600@python.beopen.com> Message-ID: <39E36163.33291FAB@roguewave.com> Are there any instructions on how to build this for Win64/itanium anywhere? -- bjorn Jeremy Hylton wrote: > > Python 2.0c1 is released. The BeOpen PythonLabs and our cast of > SourceForge volunteers have fixed many bugs since the beta releases > last month. Please pick up the new release at > > http://www.pythonlabs.com/products/python2.0/ > > There's a tarball, a Windows installer, RedHat RPMs, online > documentation, and a long list of fixed bugs. > > The final release of Python 2.0 will be next week. We would > appreciate feedback on the release candidate in order to fix any > remaining bugs before the final release. Confirmation of build and > test success on less common platforms is also helpful.n > > All major reported bugs have been fixed in the release candidate. We > do not plan to make any changes between now and the final release, > except to fix bugs reported in the next week. We encourage potential > users of Python 2.0 to try the release candidate with their programs > and report any remaining bugs. > > To report a new bug, use the SourceForge bug tracker > http://sourceforge.net/bugs/?func=addbug&group_id=5470 > > Python 2.0 has many new features, including the following: > > - Augmented assignment, e.g. x += 1 > - List comprehensions, e.g. [x**2 for x in range(10)] > - Extended import statement, e.g. import Module as Name > - Extended print statement, e.g. print >> file, "Hello" > - Collection of cyclical garbage > > For a fuller discussion of the changes in Python 2.0, please see the > article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: > http://starship.python.net/crew/amk/python/writing/new-python/ > > -- Jeremy Hylton > > -- > http://www.python.org/mailman/listinfo/python-list From trentm at ActiveState.com Tue Oct 10 21:51:55 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 12:51:55 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> Message-ID: <20001010125155.B3221@ActiveState.com> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > Are there any instructions on how to build this for Win64/itanium > anywhere? > Um... not really. I did/am doing the Win64 port but I have not really given the information required to build it, which, I agree, kind of sucks. I have not done so because: - the Python build system on Windows uses DevStudio project files - AFAIK there is no DevStudio yet for Win64 (if there were, building Python would be trivial, just setup a new configuration in DevStudio) - I am currently using a cross-compiler for Win64 provided by Intel (as part of a contract that ActiveState has to port Python to Win64 and other OSes for the IA-64 platform). I don't know if there is a publicly available compiler for Win64 (I haven't looked). - My method for building for Win64 involves: (1) exporting Win32 build makefile from the Python *.dsp files from within DevStudio. (2) running a hack script of my own to convert those to makefile to ones that will build for Win64 (these makefiles are extremely specific to my system, i.e. it is a hack) (3) run those makefiles I *could* checkin this hack script of mine and provide some documentation in Python's standard readme, if the other python-dev'ers would be ammenable to this. [Note: my files would be isolated to one directory, say PCbuild/win64.] As I said, I have not done this because I expected to just wait until DevStudio for Win64 came on the scene and then the build system for it would fit in smoothly to the current .dsp's. I would rather not become a separate provider of the Win64 build scripts because I don't want to support them outside of Python's mechanisms (i.e. through SourceForge). In other words, I'll check them into the Python core if others think that that is okay, otherwise I am afraid the answer is "please wait until DevStudio for Win64 comes along". Trent -- Trent Mick TrentM at ActiveState.com From bjorn at roguewave.com Tue Oct 10 22:24:00 2000 From: bjorn at roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 14:24:00 -0600 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> Message-ID: <39E37AE0.C7380FFD@roguewave.com> To answer some of your questions: - there is no win64 devstudio (and I haven't found a way of getting the current devstudio to use the new compiler) - Intel does have a native compiler for win64 (don't use it, see below). - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the Microsoft compiler. It works MUCH better. It's also binary compatible with the Intel ecl compiler, and they didn't have any problems with us switching. My main interest is in having a python version that runs on the itanium box with socket support (they included socket support in sdk2 didn't they?) I.e. no need to provide a build mechanism for my needs if you can refer me to an executable ;-) -- bjorn Trent Mick wrote: > > On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > > Are there any instructions on how to build this for Win64/itanium > > anywhere? > > > > Um... not really. I did/am doing the Win64 port but I have not really given > the information required to build it, which, I agree, kind of sucks. I have > not done so because: > > - the Python build system on Windows uses DevStudio project files > - AFAIK there is no DevStudio yet for Win64 (if there were, building Python > would be trivial, just setup a new configuration in DevStudio) > - I am currently using a cross-compiler for Win64 provided by Intel (as > part of a contract that ActiveState has to port Python to Win64 and other > OSes for the IA-64 platform). I don't know if there is a publicly > available compiler for Win64 (I haven't looked). > - My method for building for Win64 involves: > (1) exporting Win32 build makefile from the Python *.dsp files from > within DevStudio. > (2) running a hack script of my own to convert those to makefile to ones > that will build for Win64 (these makefiles are extremely specific to > my system, i.e. it is a hack) > (3) run those makefiles > > I *could* checkin this hack script of mine and provide some documentation in > Python's standard readme, if the other python-dev'ers would be ammenable to > this. [Note: my files would be isolated to one directory, say PCbuild/win64.] > As I said, I have not done this because I expected to just wait until > DevStudio for Win64 came on the scene and then the build system for it would > fit in smoothly to the current .dsp's. > > I would rather not become a separate provider of the Win64 build scripts > because I don't want to support them outside of Python's mechanisms (i.e. > through SourceForge). In other words, I'll check them into the Python core > if others think that that is okay, otherwise I am afraid the answer is > "please wait until DevStudio for Win64 comes along". > > Trent > > -- > Trent Mick > TrentM at ActiveState.com From trentm at ActiveState.com Tue Oct 10 22:20:42 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:20:42 -0700 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think Message-ID: <20001010132042.B22561@ActiveState.com> test_poll.py currently fails on Monterey (64-bit AIX) because of a difference in the system poll() function as compared to Linux. On Linux (and as required by the Signle Unix Specification: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()" a bogus file descriptor you get a POLLNVAL return value in the 'revents' field of the structure sent to poll(). This is tested like so in test_poll.py: # returns NVAL for invalid file descriptor FD = 42 try: os.close(FD) except OSError: pass p = select.poll() p.register(FD) r = p.poll() assert r[0] == (FD, select.POLLNVAL) Monterey decided to return -1 instead. [Aside: However, 'revents's type is "short" so the Python interface to poll() (using PyInt_FromLong) actually interprets that as -32768 instead.] Questions: 1. Can anybody offer an opinion if this is Python's or Monterey's problem? 2. Can anybody tell me where I can browse the POSIX spec to see if this breaks POSIX compliance as well? 3. Could someone (Vladimir?) run this test program on a normal AIX box and tell me what the output is (does the return value == POLLNVAL?)? ---------------------------------------------------------------------- #include #include #define NFDS 1 int main(void) { struct pollfd ufds[NFDS]; int pollResult; printf("hello\n"); /* poll for any event on a bogus file descriptor */ ufds[0].fd = 42; ufds[0].events = POLLIN | POLLPRI | POLLOUT; pollResult = poll(ufds, NFDS, -1); if (pollResult != 1) { printf("*** poll result was %d, I expected 1.\n", pollResult); } printf("ufds[0].revents = %hd\n", ufds[0].revents); printf("POLLNVAL = %ld\n", POLLNVAL); return 0; } ---------------------------------------------------------------------- Thanks, Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Tue Oct 10 22:30:03 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:30:03 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com> Message-ID: <20001010133003.C22561@ActiveState.com> On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote: > - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the > Microsoft compiler. It works MUCH better. It's also binary compatible > with the Intel ecl compiler, and they didn't have any problems with us > switching. Yes, I knew that that was there. I remember either some earlier problem with it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for me well enough, I just haven't tried the one in Win64/. > My main interest is in having a python version that runs on the itanium > box with socket support (they included socket support in sdk2 didn't > they?) I.e. no need to provide a build mechanism for my needs if you can > refer me to an executable ;-) Well, Python's test_socket runs on my Win64 box so yes, socket support is there. As far as referring you to an exe, I would rather not go down that distribution road in preference to checking in my build scripts. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Tue Oct 10 22:37:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:37:30 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 Message-ID: <39E37E0A.90176759@lemburg.com> FYI, Here's what gcc -Wall gives on Linux: ceval.c: In function `eval_code2': ceval.c:345: warning: `v' might be used uninitialized in this function ceval.c:346: warning: `w' might be used uninitialized in this function ceval.c:347: warning: `u' might be used uninitialized in this function ceval.c:348: warning: `t' might be used uninitialized in this function errors.c: In function `PyErr_Format': errors.c:409: warning: value computed is not used errors.c:415: warning: value computed is not used -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Oct 10 22:45:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:45:00 +0200 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? Message-ID: <39E37FCC.9925555A@lemburg.com> It was mentioned early in the beta phase that cycle GC would be enabled only during the beta cycle and disabled in the final. Is this still true ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Tue Oct 10 22:47:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:47:06 -0400 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think In-Reply-To: <20001010132042.B22561@ActiveState.com> Message-ID: [Trent Mick] > test_poll.py currently fails on Monterey (64-bit AIX) because of > a difference in the system poll() function as compared to Linux. > > On Linux (and as required by the Signle Unix Specification: > http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if > you "poll()" a bogus file descriptor you get a POLLNVAL return value in > the 'revents' field of the structure sent to poll(). > ... > Monterey decided to return -1 instead. [Aside: However, 'revents's type is > "short" so the Python interface to poll() (using PyInt_FromLong) actually > interprets that as -32768 instead.] > > Questions: > 1. Can anybody offer an opinion if this is Python's or Monterey's > problem? Both. "Another day, another incompatible flavor of Unix(tm)." In the early days, Guido actually hoped he could get away without a massive hack like autoconf . > 2. Can anybody tell me where I can browse the POSIX spec to see if this > breaks POSIX compliance as well? Nowhere: ISO/ANSI stds are generally never available online. They get the bulk of their money from selling standards. http://webstore.ansi.org/ is a good place to buy. There are about 20 POSIX-related stds documents; the C API spec is US$245.00. You may get a cheaper answer on comp.unix.aix, of course. may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs - tim From tim_one at email.msn.com Tue Oct 10 22:58:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:58:54 -0400 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? In-Reply-To: <39E37FCC.9925555A@lemburg.com> Message-ID: [M.-A. Lemburg] > It was mentioned early in the beta phase that cycle GC would be > enabled only during the beta cycle and disabled in the final. > > Is this still true ? No, and it probably never was : the intent of enabling gc during the betas was to determine *whether* to enable it for the final release. The beta experience with gc was very good: a few subtle problems were uncovered, and Neil fixed them quickly. It should probably get a ton of performance testing that never happened, but then so should have all of 2.0 -- no particular reason to pick on gc alone for that. full-cycle-ahead-ly y'rs - tim From fdrake at beopen.com Tue Oct 10 23:13:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <39E37E0A.90176759@lemburg.com> References: <39E37E0A.90176759@lemburg.com> Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function These would be a real tedium to fix, and I'm not convinced the loss of clarity is worth it. From looking at the code in the DUP_TOPX code, I'm led to think that the compiler just isn't smart enough (it should figure out that oparg won't change before the second case statement, and figure it out more carefully. I'll bet *that* would remove these warnings and still right in all cases. > errors.c: In function `PyErr_Format': > errors.c:409: warning: value computed is not used > errors.c:415: warning: value computed is not used Fixed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Wed Oct 11 01:16:42 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:16:42 -0500 Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available! Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> We're experiencing a serious problem with the pythonlabs.com website. Unfortunately the site is down with no estimated time for when it will be back up. Our bestest brains are working on the problem! In the mean time, the Python 2.0c1 source tree can be downloaded from this address: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz The Windows installer is here: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe And the 2.0c1 documentation is still here (on-line browseable and downloadable): http://www.python.org/doc/2.0c1/ If the outage lasts for more than a day, we'll find another place to hold the full distribution. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Oct 11 00:47:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 18:47:19 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: [MAL] > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function [Fred] > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. I'll take this one. It looks easy to fix, and to my eye doing *everything* needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own blocks) would be much clearer than the current distributed trickiness (faster, too -- the code now is branching more than computing). > From looking at the code in the DUP_TOPX code, I'm led to think that > the compiler just isn't smart enough (it should figure out that oparg > won't change before the second case statement, and figure it out more > carefully. I'll bet *that* would remove these warnings and still right > in all cases. I agree, except that it wasn't trivial for *me* to decide the compiler was being stupid. Code that's obviously correct is better than code that's not obviously wrong. >> errors.c: In function `PyErr_Format': >> errors.c:409: warning: value computed is not used >> errors.c:415: warning: value computed is not used Thanks! > Fixed. Thanks! From thomas at xs4all.net Wed Oct 11 00:49:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 00:49:37 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400 References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <20001011004937.Q12812@xs4all.nl> On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote: > M.-A. Lemburg writes: > > ceval.c: In function `eval_code2': > > ceval.c:345: warning: `v' might be used uninitialized in this function > > ceval.c:346: warning: `w' might be used uninitialized in this function > > ceval.c:347: warning: `u' might be used uninitialized in this function > > ceval.c:348: warning: `t' might be used uninitialized in this function > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. From looking at the code in the DUP_TOPX > code, I'm led to think that the compiler just isn't smart enough (it > should figure out that oparg won't change before the second case > statement, and figure it out more carefully. I'll bet *that* would > remove these warnings and still right in all cases. Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall sometime before, and I didn't get those warnings then. Probably depends on the version of gcc. As a colleague of mine would say, "insert clue" (into gcc, that is ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Wed Oct 11 01:57:38 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:57:38 -0500 Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available! In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST." <200010102316.SAA20071@cj20424-a.reston1.va.home.com> References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com> I wrote: > We're experiencing a serious problem with the pythonlabs.com website. > Unfortunately the site is down with no estimated time for when it will > be back up. Our bestest brains are working on the problem! With the help of Digital Creations' bestest brain, Jim Fulton, the site is back up in record time. We'll try not to break it again, Jim! And thanks to Digital Creations for helping us out on such a short notice. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Wed Oct 11 02:57:11 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <20001011004937.Q12812@xs4all.nl> References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> <20001011004937.Q12812@xs4all.nl> Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall > sometime before, and I didn't get those warnings then. Probably depends on > the version of gcc. As a colleague of mine would say, "insert clue" (into > gcc, that is ;) This is very reasonable. I don't think we'll give you too many demerits for this. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Wed Oct 11 06:40:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 00:40:41 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: We need a glibc expert! Anyone qualify? [Huaiyu Zhu] > ... > This is very likely to be a 2.0 bug. Or a 1.5.2 bug. I have to keep saying this stuff is a platform-dependent crap shoot, because it is (I too prefer that Python underflow silently by default, though). > Just to make sure, I have used freshly downloaded source code of > both 1.5.2 and 2.0b2, then > ./configure > make > ./python > > from math import * > exp(-746) > > I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2. > > The file mathmodule.c has quite some differences between the two versions, > mostly related to the ANSIfication. I'm not sure where the problem is. It's not in mathmodule.c. > I haven't tried the 2.0c1 yet, as the site is not available. Can > other Unix users confirm this behavior? I went over to Guido's and forced him to try it. He sees the same behavior: after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries, 1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises OverflowError. But there is no code in Python that accounts for the difference. Running it under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets errno to ERANGE (34) under 2.0. Since the platform exp was the only conceivable cause for this difference, it's not surprising that the debugger confirmed that the platform exp is in fact the cause. So the remaining question is why the same exp from the same library has different errno behavior depending on which version of Python it's called from. *That* one we couldn't answer, after a fruitless time digging thru the Byzantine glibc source code trying to reverse engineer it. Their exp *can* display different error behavior at runtime depending on several obscure things, but they're too obscure to relate back clearly to anything Python is doing. The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what the glibc exp author believes POSIX mandates, and is one of their exp's possible runtime behaviors, and your own little C program (which you posted earlier) suggests that's the default behavior under gcc + glibc. So presumably 1.5.2 config was such as to inhibit the default behavior. However, nobody changed this on purpose, so it smells like an unintended side effect of some other (currently unknown) config change. I don't know what to do next. I can't pursue it myself, and you've seen from the lack of replies to your posts that I'm the only who'll even listen to you . Guido suggests that one big change in 2.0 is that we're including a lot more std headers than we used to. It could well be that one of those #defines some God-forsaken preprocessor symbol one of whose five meanings (documented or not) is "use POSIX-conformant libm error reporting", but which someone #include'd in 2.0 to make (who knows?) sockets work right on some other flavor of Unix. Don't know. Unix config is a mess, and so is glibc. Best hope now is for someone intimately familiar with glibc internals to jump in and own this. staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs - tim From huaiyu_zhu at yahoo.com Wed Oct 11 10:12:37 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim Peters] > We need a glibc expert! Anyone qualify? If there is none here, maybe someone cares to ask in some gcc or gnu news groups? > The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what > the glibc exp author believes POSIX mandates, and is one of their exp's > possible runtime behaviors, and your own little C program (which you posted > earlier) suggests that's the default behavior under gcc + glibc. So > presumably 1.5.2 config was such as to inhibit the default behavior. > However, nobody changed this on purpose, so it smells like an unintended > side effect of some other (currently unknown) config change. So can we set a flag to explicitly discount ERANGE? There are only 19 lines in the source code that contain ERANGE, and 8 lines containing math_error. All the latter are in Modules/{c,}mathmodule.c. Could we just add an ifdef IEEE754 on these 8 lines? This would go a long way to aleviate this problem before we find a perfect solution, if there is one. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. I'm not interested in where this comes from - the only thing that matters is that it worked in 1.5.2 and breaks in 2.0. Whether the 1.5.2 behavior was intended or not, it's not a bug. The 2.0 behavior is a bug. If Posix conflicts with IEEE floating point arithmetic, then confirming to Posix in this regard is a bug. I would suggest the next thing to do is to introduce an IEEE754 flag and let those who do not like it to voice their opinions. Since this is the same behavior as 1.5.2 I doubt any running code would be broken by this. Huaiyu From thomas at xs4all.net Wed Oct 11 10:26:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:26:14 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400 References: Message-ID: <20001011102614.R12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote: > We need a glibc expert! Anyone qualify? No, at least not me ;) > So the remaining question is why the same exp from the same library has > different errno behavior depending on which version of Python it's called > from. *That* one we couldn't answer, after a fruitless time digging thru > the Byzantine glibc source code trying to reverse engineer it. Their exp > *can* display different error behavior at runtime depending on several > obscure things, but they're too obscure to relate back clearly to anything > Python is doing. Well, I've seen & heard about compilers doing slightly different things depending on ANSI or K&R style C, so perhaps the presence of ANSI C definitions triggered this. I sincerely doubt it, though, but you never know, and it's fairly easy to test. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. Actually, there was some activity to define the right combination of _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not sure what the end result was. If any #define changes the behaviour of glibc, these would definately be it ! A simple test might be to compile 1.5.2 with the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, and do some of the above tests. Computers-suck-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Oct 11 10:31:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:31:49 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700 References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <20001011103148.S12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote: > default: > fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg); Hm, this fprintf is stray debugging code, added because I wasn't sure that a SystemError wouldn't crash the interpreter, given that the stack is utterly fu*d up at this point and we don't know what the compiler thinks is the stack size or block size here. (The snippet doesn't show it, but it also raises a SystemError.) Is it okay if I remove/comment this fprintf() before 2.0 final ? (At least it didn't say "awoogah, stray debugging code detected, this machine will self-destruct in 10 seconds" :-) Another-day-another-demerit-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Wed Oct 11 11:52:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 05:52:59 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > So can we set a flag to explicitly discount ERANGE? There are > only 19 lines in the source code that contain ERANGE, and 8 lines > containing math_error. > All the latter are in Modules/{c,}mathmodule.c. Could we just > add an ifdef IEEE754 on these 8 lines? This would go a long way to > aleviate this problem before we find a perfect solution, if there > is one. That would stop the exception on exp() underflow, which is what you're concerned about. It would also stop exceptions on exp() overflow, and on underflow and overflow for all other math functions too. I doubt Guido will ever let Python ignore overflow by default, #ifdef'ed or not. A semantic change that jarring certainly won't happen for 2.0 (which is just a week away). > ... > I'm not interested in where this comes from - the only thing that > matters is that it worked in 1.5.2 and breaks in 2.0. The behavior of underflowing exp() is hardly the only thing that matters, although it's becoming clear it may be the only thing you care about <0.9 wink>. I would like to change that too for 2.0, but give a thought to the other consequences. If some change to the Python config screwed up exp(-1000) for you, what else is going wrong? You're not going to get an answer to that until we know exactly "where this comes from". > Whether the 1.5.2 behavior was> intended or not, it's not a bug. The > 2.0 behavior is a bug. If Posix conflicts with IEEE floating point > arithmetic, then confirming to Posix in this regard is a bug. POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno, as is POSIX on 754 issues. It was Python's decision (not POSIX's) to raise an exception when errno gets set. Python wasn't designed to support 754, and makes no claim to support any part of it, so conformance to 754 may be presented as a feature request, but trying to beat Python over the head with it won't work: there's no bug here, in the strong sense that no documented (or even intended!) behavior has changed. What happened is that one platform accident got changed to a different platform accident. You certainly get sympathy for that, but not enough to buy radical last-minute changes. > I would suggest the next thing to do is to introduce an IEEE754 > flag and let those who do not like it to voice their opinions. Nothing like that will happen without a PEP first. I would like to see *serious* 754 support myself, but that depends too on many platform experts contributing real work (if everyone ran WinTel, I could do it myself ). > Since this is the same behavior as 1.5.2 I doubt any running code would be > broken by this. Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and current code certainly relies on detecting overflows in math functions. It would also break code on platforms that were setting errno to ERANGE all along on underflow (as POSIX appears to require, and ANSI C doesn't appear to forbid; I don't know of such a platform for sure offhand, but to judge from their manpages, HPUX looks like one). In no case can you expect to see overflow ignored in 2.0. I want to know where this comes from, so we have *some* handle on what other surprises may be lurking. If no progress is made on determining the true cause over the next few days, I'll hack mathmodule.c to ignore ERANGE in the specific case the result returned is a zero (which would "fix" your exp underflow problem without stopping overflow detection). Since this will break code on any platform where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a long discussion w/ Guido first. I *believe* that much is actually sellable for 2.0, because it moves Python in a direction I know he likes regardless of whether he ever becomes a 754 True Believer. like-herding-cats-indeed-ly y'rs - tim From tim_one at email.msn.com Wed Oct 11 12:02:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 06:02:05 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011103148.S12812@xs4all.nl> Message-ID: > > default: > > fprintf(stderr, "Invalid argument > to DUP_TOPX: %d!\n", oparg); [Thomas Wouters] > Hm, this fprintf is stray debugging code, added because I wasn't > sure that a SystemError wouldn't crash the interpreter, given that the > stack is utterly fu*d up at this point and we don't know what the > compiler thinks is the stack size or block size here. (The snippet > doesn't show it, but it also raises a SystemError.) Is it okay if I > remove/comment this fprintf() before 2.0 final ? Suggest replacing it with: assert(!"Invalid argument to DUP_TOPX"); Then there's no cost in release mode, but we have a useful check in debug mode. ("assert(!string)" is a handy C debugging idiom more people should know about! It's semantically the same as assert(0) (i.e. will fail if ever reached), but unlike using a comment, using a string gets a useful msg displayed if it ever does fail). > (At least it didn't say "awoogah, stray debugging code detected, this > machine will self-destruct in 10 seconds" :-) Beats "Unto the root this day a brother is born" . > Another-day-another-demerit-ly y'rs, That's a funny thing about working on Python: collect 5 demerits and you can exchange them for 1 brownie point! If you're not leaving crap behind, you're not eating enough Python code. continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs - tim From guido at python.org Wed Oct 11 16:39:06 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:39:06 -0500 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400." References: Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com> Incidentally, math.exp(800) returns inf in 1.5, and raises OverflowError in 2.0. So at least it's consistent. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:38:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT) Subject: [Python-Dev] OS Dependant Bugs Message-ID: Many of the sourceforge bugs are platform dependant. Unfortunately, it is impossible, from the main bugs page, to see which are platform dependant, and which platform the occur on. I suggest that, until SF supports it properly, each bug report we enter will have an optional [Platform] in front, if it seems to be platform dependant. Any opinions? Anyone thinks submitting an SF request to add this field is foolish? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at python.org Wed Oct 11 16:41:47 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:41:47 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400." References: Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> > Suggest replacing it with: > > assert(!"Invalid argument to DUP_TOPX"); Actually, I would recommend Py_FatalError("Invalid argument to DUP_TOPX") It's not quite the same since it also triggers in release mode. If, as Thomas says, this should never happen and can only be caused by garbled bytecode, a fatal error is proper rather than a SystemError. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:41:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > Py_FatalError("Invalid argument to DUP_TOPX") > > It's not quite the same since it also triggers in release mode. If, > as Thomas says, this should never happen and can only be caused by > garbled bytecode, a fatal error is proper rather than a SystemError. Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception. Unless I misunderstand the discussion completely. jumping-to-discussions-in-the-middle-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake at beopen.com Wed Oct 11 15:42:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net> References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com> Tim Peters writes: > Update of /cvsroot/python/python/dist/src/Python > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg, > by making the DUP_TOPX code utterly straightforward. This also gets rid > of all normal-case internal DUP_TOPX if/branches, and allows replacing one > POP() with TOP() in each case, so is a good idea regardless. Tim, There's still one left: gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c -o ceval.o ../../Python/ceval.c ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:346: warning: `w' might be used uninitialized in this function Cruising through this code, it looks like the problem might be in the PRINT_NEWLINE case: case PRINT_NEWLINE: if (stream == NULL || stream == Py_None) { w = PySys_GetObject("stdout"); if (w == NULL) PyErr_SetString(PyExc_RuntimeError, "lost sys.stdout"); } if (w != NULL) { /* If PRINT_NEWLINE is the opcode, w might not be initialized * here (I think), since I don't see it initialize before the * switch. Since we can't initialize it to NULL with the case * (doing so would break the PRINT_NEWLINE_TO case), it would * have to be initialized before the main loop is entered. */ err = PyFile_WriteString("\n", w); if (err == 0) PyFile_SoftSpace(w, 0); } Py_XDECREF(stream); stream = NULL; break; Ok.... yep, initializing that seems to work. I'll check in the fix for this one after I've run the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Wed Oct 11 16:54:14 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:14 -0500 Subject: [Python-Dev] OS Dependant Bugs In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300." References: Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com> > Many of the sourceforge bugs are platform dependant. Unfortunately, it is > impossible, from the main bugs page, to see which are platform dependant, > and which platform the occur on. > > I suggest that, until SF supports it properly, each bug report we enter > will have an optional [Platform] in front, if it seems to be platform > dependant. > > Any opinions? Anyone thinks submitting an SF request to add this field > is foolish? I think it's sufficient (actually better) if the platform name is mentioned in the summary. Note that you can edit the summary of existing bug reports. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 11 16:54:54 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:54 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300." References: Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> > Can't user Python code, fiddling around with bytecode, produce garbled > bytecode? In that case, it seems even better to raise an exception. Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:56:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > > Can't user Python code, fiddling around with bytecode, produce garbled > > bytecode? In that case, it seems even better to raise an exception. > > Yes, they can produce garbled bytecode, and if that is detected, it's > not safe to proceed. So a fatal error is the right thing. The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From akuchlin at mems-exchange.org Wed Oct 11 15:56:50 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 09:56:50 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: >Actually, there was some activity to define the right combination of >_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not >sure what the end result was. If any #define changes the behaviour of glibc, >these would definately be it ! A simple test might be to compile 1.5.2 with That seems the likely cause. Another faint possibility might be threading, since 2.0 automatically uses threads but 1.5.2 needs to have them enabled. (Perhaps Tim remembered this and supplied --with-thread to the 1.5.2 configure script.) --amk From guido at python.org Wed Oct 11 17:03:00 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:03:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300." References: Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > bytecode? In that case, it seems even better to raise an exception. > > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > restricted execution much more difficult. Well, something to think about > for 2.1... Huh? In restricted execution you shouldn't be allowed to mess with bytecode! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 11 17:25:32 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:25:32 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400." <20001011095650.A17931@kronos.cnri.reston.va.us> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Bingo! 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the 1.5.2 link line makes is raise OverflowError too. Adding it to the 2.0 link line makes it return 0.0 for exp(-1000) and inf for exp(1000). Next question: what changed in the configure script, and why? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Wed Oct 11 16:24:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:24:37 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011162436.T12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: [ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ] > Actually, there was some activity to define the right combination of > _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not > sure what the end result was. If any #define changes the behaviour of glibc, > these would definately be it ! A simple test might be to compile 1.5.2 with > the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in > 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can > reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, > and do some of the above tests. Well, that was no success. I do see the difference between 1.5.2 and 2.0, but *damned* if I can figure out where it comes from. It doesn't seem to be any of the properly placed defines, and it doesn't seem to be the changes in mathmodule itself. Not autoconf, either. What I did: old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0 new tree (current CVS): math.exp(-1000) raises OverflowError (No difference between threads enabled and disabled.) Use new config.h in old tree: math.exp(-1000) returned 0.0 Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0 Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000) raises OverflowError Copy new mathmodule.c to old tree (adding an 'include math.h' because the old Python.h isn't doing that): math.exp(-1000) returns 0.0 Copy config.h and Python.h from new tree to old one (removing the include of unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h to make it compile): math.exp(-1000) returns 0.0 So, as far as I can tell, it's not related to any code in mathmodule.c itself, nor any defines in config.h or Python.h. mymath.h isn't used either, as far as I can tell it only contains stuff for broken math stuff on obscure platforms. Sounds like time for that glibc expert right about now ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Wed Oct 11 16:32:23 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 10:32:23 -0400 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: >1.5.2 links with -lieee while 2.0 doesn't. >Next question: what changed in the configure script, and why? The patch from revisions 1.138 to 1.139 of configure.in is: 853c1139,1142 < AC_CHECK_LIB(ieee, __fpu_control) --- > AC_CHECK_FUNC(__fpu_control, > [], > [AC_CHECK_LIB(ieee, __fpu_control) > ]) The check-in comment is "Only link with -lieee when it's necessary". If it only checks for -lieee when the __fpu_control function is defined, perhaps the function disappeared in glibc 2.1. --amk From thomas at xs4all.net Wed Oct 11 16:32:45 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:32:45 +0200 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011163244.U12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). Ack, that's the one thing I didn't check: link libraries ;-P > Next question: what changed in the configure script, and why? Well, that's easy. Old configure.in: # Linux requires this for correct f.p. operations AC_CHECK_LIB(ieee, __fpu_control) New configure.in: # Linux requires this for correct f.p. operations AC_CHECK_FUNC(__fpu_control, [], [AC_CHECK_LIB(ieee, __fpu_control) ]) I remember the patch that did this, on SF. It was titled "don't link with -lieee if it isn't necessary" or something. Not sure what it would break, but mayhaps declaring -lieee necessary on glibc systems is the right fix ? (For the non-autoconf readers among us: the first snippet writes a test program to see if the function '__fpu_control' exists when linking with -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second snippet writes a test program to see if the function '__fpu_control' exists with the current collection of $LIBS. If it doesn't, it tries it again with -lieee, and adds -lieee to $LIBS if it finds it then.) Pesonally, I think the patch should just be reversed... The comment above the check certainly could be read as 'Linux requires -lieee for correct f.p. operations', and perhaps that's how it was meant. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Oct 11 18:31:48 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <14820.38388.827883.710489@beluga.mojam.com> Tim> I'll take this one. It looks easy to fix ... Seems to me like a patch that ought to wait until after 2.0final. It's definitely not a show-stopping bug... Skip From thomas at xs4all.net Wed Oct 11 20:04:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 20:04:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500 References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> Message-ID: <20001011200431.V12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote: > > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > > bytecode? In that case, it seems even better to raise an exception. > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > > restricted execution much more difficult. Well, something to think about > > for 2.1... > Huh? In restricted execution you shouldn't be allowed to mess with > bytecode! Well, I can see what Moshe means. You get a code object passed in, say, an untrusted pickle or some such. You want to execute it, but you don't want it to ruin your life. Causing the entire program to quit could be considered 'ruining'. On the other hand, if you can hand-tweak bytecode streams in that degree, you can f** up a lot more. On the one foot, though, most of the calls to Py_FatalError (as far as I can see) deal with initialization failures, or structures to which tweaked bytecode would not have access. On the other foot, it's probably possible to tweak bytecode to *get* access to those structures, or at least structures that don't like being dereferenced or DECREF'd. And there's probably more to consider, but I haven't got any public appendages left, and there might be children listening ;) All in all, Guido's probably right... If something like this happens, you don't want to continue. If the argument to DUP_TOPX is something other than what compile.c generates (between 1 and 5, inclusive, that is) something strange is going on internally. Better to quit now than delete c:\command.com by 'accident'. If people can do this to code being run in restricted environments, they can probably do worse things, too! Now I just need an OK from Jeremy, as the maitre d', and I'll check it in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Wed Oct 11 23:19:28 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 16:19:28 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200." <20001011163244.U12812@xs4all.nl> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Thanks for digging deeper into this. > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct f.p. > operations', and perhaps that's how it was meant. No, the configure patch is right. Tim will check in a change that treats ERANGE with a return value of 0.0 as underflow (returning 0.0, not raising OverflowError). --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Oct 11 23:02:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:02:16 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: [Tim] > I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy > to fix ... [Skip Montanaro] > Seems to me like a patch that ought to wait until after 2.0final. It's > definitely not a show-stopping bug... Would have been a more interesting argument had you posted this before the patch was checked in . But wngs are non-negotiable with me anyway. This example turned out to be a good one for showing why: the bogus wngs covered up a legitimate "uninitialized vrbl" complaint (see Fred's later discovery and following checkin). I've simply got zero tolerance for wngs or for failures in the std test suite. My view is warped by prior experience, though: the last 6 years, I worked on projects where the compilers were fiddled to treat warnings as fatal errors. So while this may have looked like a harmless batch of wngs to you, as far as I was concerned Python couldn't even be compiled anymore <0.7 wink>. extremism-in-defense-of-simple-best-practice-may-or-may-not-be- vice-but-it's-sure-effective-over-the-long-term-ly y'rs - tim From skip at mojam.com Wed Oct 11 23:07:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: <14820.54942.114086.773609@beluga.mojam.com> Tim> [Tim] >> I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy >> to fix ... Tim> [Skip Montanaro] >> Seems to me like a patch that ought to wait until after 2.0final. >> It's definitely not a show-stopping bug... Tim> Would have been a more interesting argument had you posted this Tim> before the patch was checked in . Agreed, but I posted as soon as I saw it. Can't help it if I can't keep up with all the flurry of activity. Tim> So while this may have looked like a harmless batch of wngs to you, Tim> as far as I was concerned Python couldn't even be compiled anymore Tim> <0.7 wink>. I accept your explanation. ;-) S From jack at oratrix.nl Wed Oct 11 23:10:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 11 Oct 2000 23:10:36 +0200 Subject: [Python-Dev] test_StringIO failing on the Mac Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl> I have one remaining problem (at least, as far as I'm aware:-) with 2.0c1 on the Mac: test_StringIO fails. The reason is that the test_StringIO output file was generated on Unix, and hence it uses the unix form of string.letters (a-zA-Z), whereas the Mac version of string.letters has far more values. As this isn't what the test is about in the first place, shall I fix the test? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tim_one at email.msn.com Wed Oct 11 23:14:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:14:17 -0400 Subject: [Python-Dev] test_StringIO failing on the Mac In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl> Message-ID: [Jack Jansen] > I have one remaining problem (at least, as far as I'm aware:-) with > 2.0c1 on the Mac: test_StringIO fails. > > The reason is that the test_StringIO output file was generated on > Unix, and hence it uses the unix form of string.letters (a-zA-Z), > whereas the Mac version of string.letters has far more values. > > As this isn't what the test is about in the first place, shall I fix > the test? +1 from me on making the test portable. From jeremy at beopen.com Thu Oct 12 01:06:56 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011200431.V12812@xs4all.nl> References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> <20001011200431.V12812@xs4all.nl> Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: [Moshe:] >> > The problem with letting Python code cause fatal errors is that >> > it makes restricted execution much more difficult. Well, >> > something to think about for 2.1... [Guido:] >> Huh? In restricted execution you shouldn't be allowed to mess >> with bytecode! TW> Well, I can see what Moshe means. You get a code object passed TW> in, say, an untrusted pickle or some such. You want to execute TW> it, but you don't want it to ruin your life. Causing the entire TW> program to quit could be considered 'ruining'. On the other TW> hand, if you can hand-tweak bytecode streams in that degree, you TW> can f** up a lot more. Damn straight! If you're using restricted execution mode and accepting bytecode objects that weren't produced by a trusted Python compiler, you're nuts. I am not aware of any effort made to protect the Python VM from attack via malicious bytecode. TW> Now I just need an OK from Jeremy, as the maitre d', and I'll TW> check it in. Your table is ready. A checkin message will be accepted as gratuity. Jeremy From jeremy at beopen.com Thu Oct 12 01:12:15 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT) Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net> I checked in the patch that removed the -lieee link in some cases. I don't remember the details off the top of my head, but I can go digging in the SF patch logs if it's important. As I recall, someone reported problems on a platform (HPUX?) where link with ieee caused problems. I didn't have access to the platform in question. So I applied the patch on a Linux box and ran the regression test; it reported no errors, so I assumed the patch fixed some other platform and did mine no harm. At the moment, I would assume that the patch still helps some other platform but might not be right on Linux. On the other hand, it sounds like Tim has a patch that will cause Linux to do the right thing. It's hard to say much about what should or should not happen since neither the language reference nor the regression tests specifies much about what should happen with fp. Jeremy From thomas at xs4all.net Thu Oct 12 01:15:21 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 01:15:21 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15 In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700 References: <200010112144.OAA20776@slayer.i.sourceforge.net> Message-ID: <20001012011521.X12812@xs4all.nl> On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717 > > Modified Files: > dlmodule.c > Log Message: > > Remove one more gcc -Wall warning. To note, if gcc didn't inherit at least *some* of C's original philosophy of 'the programmer always knows what [s]he is doing', gcc would yell bloody murder at this code. The 'func' function pointer is used to point to symbols loaded from arbitrary shared objects, and the dlmodule has no way of knowing howmany arguments the function expects, or even if it isn't more than 10 (which would result in the function grabbing garbage off the stack, on most architectures, I think.) While on the ANSIfication spree, I ran screaming and hid under my bed after reading this code ;) Is anyone using the dlmodule anymore ? Is it really useful ? Is this *really* how loading and calling arbitrary shared objects should be done ? :P > { > PyObject *name; > ! long (*func)(long, long, long, long, long, > ! long, long, long, long, long); > long alist[10]; > long res; Idle-and-post-2.0-talk-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu at yahoo.com Thu Oct 12 01:33:08 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: On the issue of whether Python should ignore over/underflow on IEEE-enabled platforms: [Tim Peters] > That would stop the exception on exp() underflow, which is what you're > concerned about. It would also stop exceptions on exp() overflow, and on > underflow and overflow for all other math functions too. I doubt Guido will > ever let Python ignore overflow by default, #ifdef'ed or not. A semantic > change that jarring certainly won't happen for 2.0 (which is just a week > away). It can be argued that on IEEE enabled systems the proper thing to do for overflow is simply return Inf. Raising exception is WRONG. See below. [Guido van Rossum] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. That is not consistent at all. Suppose I'm plotting the curve f(x) where x include some singular points of f. In the first case the plot works with some portion of the curve clipped. In the second case it bombs. [Tim Peters] > Nothing like that will happen without a PEP first. I would like to see > *serious* 754 support myself, but that depends too on many platform experts > contributing real work (if everyone ran WinTel, I could do it myself > ). [Guido van Rossum] > Bingo! > > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). If using ieee is as simple as setting such a flag, there is no reason at all not to use it. Here are some more examples: Suppose you have done hours of computation on a problem. Just as you are about to get the result, you get an exception. Why? Because the residual error is too close to zero. Suppose you want to plot the curve of Gausian distribution. Oops, it fails. Because beyond a certain region the value is near zero. With these kinds of problems, vectorized numerical calculation becomes nearly impossible. How do you work in such an environment? You have to wrap every calculation in a try/except structure, and whenever there is an exception, you have to revert to elementwise operations. In practice this simply means Python would not be suitable for numerical work at all. What about the other way round? No problem. It is easy to write functions like isNaN, isInf, etc. With these one can raise exceptions in any place one want. It is even possible to raise exceptions if a matrix is singular to a certain precision, etc. The key point to observe here is that most numerical work involve more than one element. Some of them may be out of mahcine bounds but the whole thing could still be quite meaningful. Vice versa it is also quite possible that all elements are within bounds while the whole thing is meaningless. The language should never take over or subvert decisions based on numerical analysis. [Tim Peters] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. As Guido observed ERANGE is not generated with ieee, even for overflow. So it is the same behavior as 1.5.2. Besides, no correct numerical code should depend on exceptions like this unless the machine is incapable of handling Inf and NaN. Even in the cases where you do want to detect overflow, it is still wrong to use exceptions. Here's an example: x*log(x) approaches 0 as x approaches 0. If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want. But exception is the wrong tool to hangle this, because if x is an array, some of its element may be zero but other's may not. The right way to do it is something like def entropy(probability): p = max(probability, 1e-323) return p*log(p) [Tim Peters] > In no case can you expect to see overflow ignored in 2.0. You are proposing a dramatic change from the behavior of 1.5.2. This looks like to me to need a PEP and a big debate. It would break a LOT of numerical computations. [Thomas Wouters] > I remember the patch that did this, on SF. It was titled "don't link with > -lieee if it isn't necessary" or something. Not sure what it would break, > but mayhaps declaring -lieee necessary on glibc systems is the right fix ? > > (For the non-autoconf readers among us: the first snippet writes a test > program to see if the function '__fpu_control' exists when linking with > -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second > snippet writes a test program to see if the function '__fpu_control' > exists with the current collection of $LIBS. If it doesn't, it tries it > again with -lieee, > > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct > f.p. operations', and perhaps that's how it was meant. The patch as described seems to be based on flawed thinking. The numbers Inf and NaN are always necessary. The -lieee could only be unnecessary if the behavior is the same as IEEE. Obviously it isn't. So I second Thomas's suggestion. [Tim Peters] > If no progress is made on determining the true cause over the next few days, > I'll hack mathmodule.c to ignore ERANGE in the specific case the result > returned is a zero (which would "fix" your exp underflow problem without > stopping overflow detection). Since this will break code on any platform > where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a > long discussion w/ Guido first. I *believe* that much is actually sellable > for 2.0, because it moves Python in a direction I know he likes regardless > of whether he ever becomes a 754 True Believer. [Guido van Rossum] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). What is the reason to do this? It looks like intetionally subverting ieee even when it is available. I thought Tim meant that only logistical problems prevent using ieee. If you do choose this route, please please please ignore ERANGE entirely, whether return value is zero or not. The only possible way that ERANGE could be useful at all is if it could be set independently for each element of an array, and if it behave as a warning instead of an exception, ie. the calculation would continue if it is not caught. Well, then, Inf and NaN serve this purpose perfectly. It is very reasonable to set errno in glibc for this; it is completely unreasonable to raise an exception in Python, because exceptions cannot be set to individual elements and they cannot be ignored. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From pauldubois at home.com Thu Oct 12 02:04:51 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 17:04:51 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: I don't have time to follow in detail this thread about changed behavior between versions. These observations are based on working with hundreds of code authors. I offer them as is. a. Nobody runs a serious numeric calculation without setting underflow-to-zero, in the hardware. You can't even afford the cost of software checks. Unfortunately there is no portable way to do that that I know of. b. Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going. From guido at python.org Thu Oct 12 03:45:30 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 20:45:30 -0500 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST." References: Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> > I don't have time to follow in detail this thread about changed behavior > between versions. These observations are based on working with hundreds of > code authors. I offer them as is. > > a. Nobody runs a serious numeric calculation without setting > underflow-to-zero, in the hardware. You can't even afford the cost of > software checks. Unfortunately there is no portable way to do that that I > know of. > > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > stop, not put a zero and keep going. Thanks, Paul! This behavior has always been what I wanted Python to do (even though it's not always what Python did, depending on the platform) and also what Tim's proposed patch will implement for the specific case of math.exp() (and other math functions that may underflow or overflow), on most reasonable platforms. There are still lots of places where the platform gives Python no choice of creating NaN and Inf, and because there's no platform-independent way to test for these, they are hard to avoid in some cases; but eventually, Tim will find a way to root them out. And for people like Huaiyu, who want to see Inf, there will (eventually) be a way to select this as a run-time option; and ditto for whoever might want underflow to raise an exception. --Guido van Rossum (home page: http://www.python.org/~guido/) From huaiyu_zhu at yahoo.com Thu Oct 12 04:22:54 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> Message-ID: [Paul Dubois] > > > > a. Nobody runs a serious numeric calculation without setting > > underflow-to-zero, in the hardware. You can't even afford the cost of > > software checks. Unfortunately there is no portable way to do that that I > > know of. Amen. > > > > b. Some people use Inf but most people want the code to STOP so they can > > find out where the INFS started. Otherwise, two hours later you have big > > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > > stop, not put a zero and keep going. $ /usr/bin/python Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from math import * >>> exp(777) inf >>> exp(-777) 0.0 >>> sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error This was sane behavior. Are we saying that Python 2.0 has invented something better than IEEE 754? [Guido van Rossum] > Thanks, Paul! This behavior has always been what I wanted Python to > do (even though it's not always what Python did, depending on the > platform) and also what Tim's proposed patch will implement for the > specific case of math.exp() (and other math functions that may > underflow or overflow), on most reasonable platforms. Guido, with due respect to your decisions on Python issues, I simply have to fight this one. It is one thing to accomodate for naive users, but it is another to dumb down every one else. Case 1. Someone writes a flawed numerical routine. Two hours later he finds his array filled with Inf and NaN. Case 2. Someone writes a perfect numerical routine. Two hours later he gets an exception, because the error is near zero. Solution for case 1. Use better algorithm. Use better error control. Raise exceptions when error is too large. These are proper solutions. They are easy and efficient to implement. They are needed anyway - If something's wrong, you want to raise exceptions far earlier than Inf, certainly before you get arrays filled with elements like 1e300. Solution for case 2. Almost impossible. The division between under- and over-flow is artificial. What about 1/x or similar functions? The only way to work on such a platform is to abandon vectorized computation. > There are still lots of places where the platform gives Python no > choice of creating NaN and Inf, and because there's no > platform-independent way to test for these, they are hard to avoid in > some cases; but eventually, Tim will find a way to root them out. And > for people like Huaiyu, who want to see Inf, there will (eventually) > be a way to select this as a run-time option; and ditto for whoever > might want underflow to raise an exception. I can understand that exceptions are the only available choices if IEEE is not available. But is there a compelling reason that Python should behave "better" than IEEE when it's in fact available? If the reason is to protect naive users, I can think of several responses: 1. For people doing one-off interactive work, returning Inf is in fact more informative. 2. For users iterative numerical computations, they need to be educated about error control. Otherwise they won't get corrent results anyway. 3. For really serious work, we could provide good numerical modules so that they don't need to write themselves. To make this happen fast the fewer debacles like this one the better. Case in point: Someone asked for regession modules two weeks ago. I was trying to convert my old matlab programs, which only took a few hours. But I wasted a week of (spare) time fighting for some mysterious "overflow". Turns out that a Guassian is near zero when it's far from center, and Python does not like it. In practice, Inf may be generated more often as a proper value than by mistake. This is not an issue about whether someone "prefers" Inf or exception. It is about whether there is a choice to do proper computation. Returning Inf does not prevent someone to raise exception. Raising exception automatically prevents perfect algorithms to work properly. As Kevin has volunteered to help with IEEE implementation and made a plan, is there a strong reason to drop IEEE for Linux in 2.0? If there is insufficient time to carry out his plan, wouldn't it be prudent to keep things as they were in 1.5.2? Huaiyu From tim_one at email.msn.com Thu Oct 12 04:44:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 22:44:20 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim From sdm7g at virginia.edu Thu Oct 12 05:23:32 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: First: I haven't followed this thread from the beginning -- only the last ten or so posts. Second: One reason I didn't follow it from the start is that I'm not doing any heavy numerical stuff in Python. I've been using Lisp for that, and use Python more for string/symbolic or GUI hacking. But, if I was going to do the sort of numerical stuff I now do in Lisp in Python, I would agree with Huaiya Zhu. I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points in the vector -- they are independent of the bad points. In my case, it's not that these are lengthy calculations. It's that they are interactive and tied to immediate graphical representations. If there are strange zero's or infinities in the result, there is (or should be) a way to backtrack and investigate. ( That's why people want interactive and graphical regression analysis and modeling tools! ) The idea that your calculation should blow up and you should check it and resubmit your job sounds just so ancient-20th-century- Fortran-JCL-and-punched-cards-technology! ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 06:18:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 00:18:19 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011234038.A2322@better.net> Message-ID: [William Park] > On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. I didn't write that. Paul Dubois did. > Hmm... I don't like this. It should stop or return complex. Paul said it should stop. You said it should stop (or return complex). So what is it that you don't like ? 754 mandates that sqrt(x) for x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently doesn't like. [actually Tim] > I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* > have silently returned a NaN (not a zero) without setting errno if it > was *self*-consistent -- anyone care to check that under -lieee?: > > import math > math.sqrt(-1) > > NaN or ValueError? 2.0 should raise ValueError regardless of > what 1.5.2 did here.). [back to William] > It returns 'OverflowError: math range error' in 1.5.2, Ah, that's hilarious ! It's tempting to believe that glibc is violating the IEEE std despite the -lieee flag in this case, but I don't believe that's true: it's almost certainly the case that glibc is actually returning a NaN, *not* setting errno at all, and this other check in Python's mathmodule.c: #define CHECK(x) if (errno != 0) ; \ else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \ else errno = ERANGE is setting errno to ERANGE purely due to an accident of the way gcc happens to compile code for comparing NaN to Inf and -Inf. > and 'ValueError: math domain error' in 2.0. Which is the correct exception, so is another reason for Python to avoid -lieee in 2.0. will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out- what-happens-by-accident-now-ly y'rs - tim From tim_one at email.msn.com Thu Oct 12 08:16:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 02:16:23 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > $ /usr/bin/python > Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux-i386 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from math import * > >>> exp(777) > inf > >>> exp(-777) > 0.0 > >>> sqrt(-1) > Traceback (innermost last): > File "", line 1, in ? > OverflowError: math range error > > This was sane behavior. Are we saying that Python 2.0 has invented > something better than IEEE 754? 754 allows users to choose the behaviors they want. Any *fixed* policy is not 754. So long as we have to fix a single policy, yes, I believe Guido (& know I) would say that raising OverflowError on exp(777), and silently returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not* OverflowError, as shown above), is indeed better than the 754 default behaviors. And 2.0 will do all three of those (& I just checked in the code to make that happen). About the sqrt example above, that's neither 754 behavior nor sane behavior: default 754 behavior on sqrt(-1) is to return a NaN and keep on going. I'm pretty sure that's what glibc linked w/ -lieee actually does, too (if it doesn't, glibc -lieee is violating 754). That 1.5.2 raised an OverflowError instead is insane, and appears purely due to an accident of how gcc compiles code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was fooled by this into setting errno to ERANGE itself). Python should raise a ValueError there instead (corresponding to libm setting errno to EDOM -- this is a domain error, not a range error) -- which it does now under CVS Python. 754-doesn't-work-unless-you've-got-all-of-it-ly y'rs - tim From thomas at xs4all.net Thu Oct 12 10:11:57 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 10:11:57 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400 References: Message-ID: <20001012101157.Y12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. > Nobody has proposed changing anything about libm domain (as opposed to > range) errors (although Huaiyu probably should if he's serious about his > flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on > 1.5.2, but it *should* have silently returned a NaN (not a zero) without > setting errno if it was *self*-consistent -- anyone care to check that > under -lieee?: > import math > math.sqrt(-1) >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do: >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error Consistency-conschmistency-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Thu Oct 12 17:58:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT) Subject: [Python-Dev] (no subject) Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net> Cc xml-sig at python.org Subject: test_minidom non-failure failure? X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: jeremy at beopen.com Comments: Hyperbole mail buttons accepted, v04.18. SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7 J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0 cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4 dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4 dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0 ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3 aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ== From jeremy at beopen.com Thu Oct 12 18:11:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net> Sorry about the previous message; a mail munger somewhere between my display and python.org choked on a very long line... I am getting an occasional, hard-to-reproduce error in test_minidom. When I run the test, it displays about a thousand lines of garbage, but the test suite does not report test_minidom as failed or skipped. The output I see during the test run is this: test_minidom garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': , 'childNodes': None, 'attributes': None, 'parentNode': None, 'data': u'Obsolete but implemented...', 'previousSibling': None}, , {'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a [... many hundreds of lines omitted] At the end of the test, I get a pretty normal result: 95 tests OK. 13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl test_imgfile test_largefile test_nis test_sunaudiodev test_timing test_winreg test_winsound So two questions: Why is test_minidom producing all this output? And why is it only happening intermittently? Why does regrtest.py think that test_minidom is working correctly when it produces all this output? Jeremy From nas at arctrix.com Thu Oct 12 11:31:34 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 02:31:34 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <20001012023134.A18254@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > I am getting an occasional, hard-to-reproduce error in test_minidom. > When I run the test, it displays about a thousand lines of garbage, > but the test suite does not report test_minidom as failed or skipped. > > The output I see during the test run is this: > > test_minidom > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': This is most likely the garbage collector. regrtest.py contains the following code: if findleaks: gc.collect() if gc.garbage: print "garbage:", repr(gc.garbage) found_garbage.extend(gc.garbage) del gc.garbage[:] findleaks is true if the -l option is specified (TESTOPS in the makefile includes it). Something is producing cyclic garbage. Neil From guido at python.org Thu Oct 12 19:39:40 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 12:39:40 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST." <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com> > On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > > I am getting an occasional, hard-to-reproduce error in test_minidom. > > When I run the test, it displays about a thousand lines of garbage, > > but the test suite does not report test_minidom as failed or skipped. > > > > The output I see during the test run is this: > > > > test_minidom > > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': [Neil] > This is most likely the garbage collector. regrtest.py contains > the following code: > > if findleaks: > gc.collect() > if gc.garbage: > print "garbage:", repr(gc.garbage) > found_garbage.extend(gc.garbage) > del gc.garbage[:] > > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. Of course something is producing cyclic garbage! The DOM tree is full of parent and child links. Does this output mean that the GC works correctly? Or does it mean that there is a reason why this garbage cannot be disposed of? In the latter case, could that be because there are __del__ methods? --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Thu Oct 12 18:55:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > This is most likely the garbage collector. regrtest.py contains > the following code: ... > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. This is definately the problem. Lars, Paul: This looks like a problem in the unlink() method of the DOM. Could you please check that the unlink() method is updated to handle the latest version of the other changes? Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Oct 12 18:59:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is test_minidom producing all this output? And why is it only > happening intermittently? It isn't. See Neil's excellent explanation. > Why does regrtest.py think that test_minidom is working correctly when > it produces all this output? The test is passing just fine, and is complete before the test for garbage is performed. The unlink() method on DOM objects is the culprit; it is updating the Node.allnodes dictionary correctly, but not the Node instances. I've already asked Paul & Lars to fix this; it should work just fine with or without GC once they've seen the report. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Thu Oct 12 12:24:48 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 03:24:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> Message-ID: <20001012032448.A18407@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote: > Of course something is producing cyclic garbage! > > The DOM tree is full of parent and child links. > > Does this output mean that the GC works correctly? Or does it > mean that there is a reason why this garbage cannot be disposed > of? In the latter case, could that be because there are > __del__ methods? The -l option tries to find any cyclic garbage produced by the tests. I don't think that that option should be enabled default. The output means that the GC is working and is finding stuff that would not be freed by reference counting alone. I can't tell if the GC would free this garbage. The -l option sets the DEBUG_SAVEALL option which causes all garbage found to end up in gc.garbage, not just garbage the can't be cleaned up. I don't have pyexpat installed here so I can't test it. If you want to find out if test_minidom is creating garbage the collector can't free you should comment out the: gc.set_debug(gc.DEBUG_SAVEALL) line in regrtest.py and run: regrtest.py -l test_minidom If that does what I think it does and you still get the "garbage: " line then the test is creating evil things. :) Neil From hinsen at dirac.cnrs-orleans.fr Thu Oct 12 19:24:18 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Thu, 12 Oct 2000 19:24:18 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: (sdm7g@virginia.edu) References: Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr> > The idea that your calculation should blow up and you should > check it and resubmit your job sounds just so ancient-20th-century- > Fortran-JCL-and-punched-cards-technology! Long-running jobs are still with us, even there's neither Fortran nor JCL in them. And for these applications, stopping is better than going on with nonsense values. On the other hand, as you point out, exceptions for math errors are a bit of a pain for interactive work. So how about making this a run-time option? I'd choose exceptions by default and Infs and Nans by specifying a command-line option, but there are certainly others who would prefer it the other way round. What matters most to me is that the choice is possible somehow. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From sdm7g at virginia.edu Thu Oct 12 20:25:44 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr> Message-ID: On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote: > > The idea that your calculation should blow up and you should > > check it and resubmit your job sounds just so ancient-20th-century- > > Fortran-JCL-and-punched-cards-technology! > > Long-running jobs are still with us, even there's neither Fortran nor > JCL in them. And for these applications, stopping is better than going > on with nonsense values. On the other hand, as you point out, exceptions > for math errors are a bit of a pain for interactive work. > > So how about making this a run-time option? I'd choose exceptions by > default and Infs and Nans by specifying a command-line option, but > there are certainly others who would prefer it the other way round. > What matters most to me is that the choice is possible somehow. > I agree entirely! Maybe I was being a bit too glib, but I didn't mean to imply that wanting it to halt or throw an exception on errors is wrongheaded. I just wanted to make sure the counter-case to what Paul was saying also got heard: Yes-- underflows or infinities where they aren't expected are usually a sign that something is very wrong somewhere. But in the case where the vector holds independent observations or data points, then usually what it means is that there's something wrong with *that* data point -- miscallibrated or mislabeled -- but no reason not to complete the calculations for all of the other points. Scaling or doing projections for interactive graphics is another case where bad points are often better than throwing an exception. ( And it's a pain to have to remember to lambda wrap all the function calls with some sort of guard when you'ld be happy to get NaNs. ) I also mostly agree with Tim, except that I'm not sure that bad or incomplete ieee support is always better than none at all. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From thomas at xs4all.net Thu Oct 12 21:14:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 21:14:37 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700 References: <200010121711.KAA00584@slayer.i.sourceforge.net> Message-ID: <20001012211436.Z12812@xs4all.nl> On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote: [ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ] > There is one known warning at this time, caught by the -Wstrict-prototypes > option. In Modules/main.c, the declaration of getopt() without parameters > gets a complaint (rightly) that it is not a proper prototype. The lack of > a complete prototype information should be corrected when the right > portability conditions have been identified. I already looked at this before, and the problem is that the prototype for getopt is not portable (because of quirks in the ANSI C standard regarding 'compatible' pointer types.) Some systems define it as 'const char **' (or 'char const **'), some perhaps as 'char **', and some as 'char * const *'. 'const char **' and 'char const **' are the same, but 'char * const *' is something else, and so is 'char **'. 'char * const *' and 'char **' are equivalent types, meaning that conforming compilers should be able to intermix them without problems, but 'const char **' is a different type, and ANSI C either demands or strongly suggests a warning. (Why exactly it's a different type is mostly a choice of language, though I'm sure there are people who would defend the choice. What it means it that you can't mix two layers of indirection with qualifiers like 'const' or 'volatile', without paying close attention to assignment and prototypes :P) As a result, no matter what prototype we think up, we're always screwing either the one type of platform or the other. And not with a warning; the conflicting prototype would generate an error, nto a warning. The only solution I can think of is adding the proper prototype to the pyport.h header file, inside a proper #ifdef. For generated code it doesn't really matter which of the prototypes is used, but if the system headers do provide a prototype, and it doesn't match in indirect-constness, compilation will fail. (In other words, even on the platforms that are missing it, close attention should be paid to the manual pages, trying to guess what the prototype is going to look like if that particular system would ever grow a prototype in a system header. From what I read in the getopt(3) manpage on my linux box the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) Does anyone have a system where the prototype to getopt() is not defined in header files ? My Solaris 2.x testbox has that problem, but the box in question is one huge mess, and I doubt it has anything to do with Solaris in particular. I only use it to reproduce reported bugs, not report any myself ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Thu Oct 12 22:10:50 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012032448.A18407@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> The -l option tries to find any cyclic garbage produced by the NS> tests. I don't think that that option should be enabled NS> default. The output means that the GC is working and is finding NS> stuff that would not be freed by reference counting alone. NS> I can't tell if the GC would free this garbage. The -l option NS> sets the DEBUG_SAVEALL option which causes all garbage found to NS> end up in gc.garbage, not just garbage the can't be cleaned up. NS> I don't have pyexpat installed here so I can't test it. If you NS> want to find out if test_minidom is creating garbage the NS> collector can't free you should comment out the: NS> gc.set_debug(gc.DEBUG_SAVEALL) NS> line in regrtest.py and run: NS> regrtest.py -l test_minidom NS> If that does what I think it does and you still get the NS> "garbage: " line then the test is creating evil things. :) The test is not creating evil things. I commented out the DEBUG_SAVEALL line and got no error report. The question, then, is what to do about the -l option. I assume we should remove the -l option from the Makefile, so that "make test" doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in some way so that it still reports on tests that create evil things? Jeremy From nas at arctrix.com Thu Oct 12 15:20:10 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:20:10 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <20001012062010.A19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote: > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? This is a policy decision. Is it okay for the test suite to create garbage that is not collectable by reference counting? If yes, what about garbage that is not collectable by the (current) GC? Neil From guido at python.org Thu Oct 12 23:21:39 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:21:39 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400." <14822.6858.920988.167252@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com> > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. This seems to make sense, yes. Since the "leaked" objects that are found will be released by the GC code, I see no point in reporting these during the regression test. This can only confuse people (like it did Jeremy :-). > Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? Any form of evilness that can be detected without *too* much effort is worth it... I have no idea what kind of evil we're looking for here or how to detect is, so I can't answer yes or no. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Thu Oct 12 22:18:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT) Subject: [Python-Dev] New development documentation up... Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com> I don't normally post when I've updated the development copy of the documentation, but there are a couple of big additions there now. Martin von L?wis contributed substantial SAX2 documentation, which I've now integrated. Thanks, Martin! Chris Barker is working on new documentation for the Macintosh manual; I've only just started to look at it, but there's definately a *lot* of new material. That's not checked into CVS yet, but will be once I've had more time to go over it. Thanks, Chris! ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Thu Oct 12 15:28:04 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:28:04 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> Message-ID: <20001012062804.B19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote: > Any form of evilness that can be detected without *too* much effort is > worth it... I have no idea what kind of evil we're looking for here > or how to detect is, so I can't answer yes or no. That would be reference cycles with finalizers (ie. instances with __del__ methods). The current garbage collector does not free such structures but instead appends them to gc.garbage. Sorry for not being clear. In any case, regrtest should probably print a more clueful message when objects are found in gc.garbage. That would go a long way in clearing up the confusion. I'll see about a patch. Neil From guido at python.org Thu Oct 12 23:26:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:26:49 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST." <20001012062010.A19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com> > This is a policy decision. Is it okay for the test suite to > create garbage that is not collectable by reference counting? I don't see why that should be forbidden. After all some of the code we test has such leaks -- we haven't declared those absolute bugs. > If yes, what about garbage that is not collectable by the (current) > GC? Can you give an example of how such garbage can be created? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Thu Oct 12 22:38:29 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012062804.B19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> <20001012062804.B19026@glacier.fnational.com> Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> In any case, regrtest should probably print a more clueful NS> message when objects are found in gc.garbage. That would go a NS> long way in clearing up the confusion. I'll see about a patch. I think there is some value to issueing reports when a test creates trash that can't be cleaned up by the GC, but it doesn't make sense to report this by default. If "make test" reports an error, it should mean that something has gone wrong with the user's build and the interpreter is broken. That's not the case here. The build was fine; it's just the test that is iffy. I think we should turn of the -l option by default *and* patch it so that the output is more useful. I would suggest printing a count of the objects, perhaps organized by type/class name. Something like this: Test created 6 uncollectable objects 4 foo.Bar instances 2 foo.Baz instances Jeremy From tim_one at email.msn.com Thu Oct 12 22:33:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 16:33:41 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages . Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas , asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great . all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). From nas at arctrix.com Thu Oct 12 15:43:09 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:43:09 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> Message-ID: <20001012064309.C19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote: > > This is a policy decision. Is it okay for the test suite to > > create garbage that is not collectable by reference counting? > > I don't see why that should be forbidden. After all some of the code > we test has such leaks -- we haven't declared those absolute bugs. Again, "-l" should probably not be a default. I don't know who added it to TESTOPTS but it wasn't me. > Can you give an example of how such garbage can be created? Look at test_gc. Here is an example: class Foo: def __del__(self): pass foo = Foo() foo.foo = foo del foo Theoretically this structure could be collected without problem but the GC is too simple minded to realize that there is only one finalizer involved. Here's a better example: foo = Foo() bar = Foo() foo.bar = bar bar.foo = foo del foo, bar The GC cannot safely break this cycle so it punts and adds the instance objects involved to gc.garbage and forgets about it. Neil From tim_one at email.msn.com Thu Oct 12 23:38:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 17:38:13 -0400 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <20001012211436.Z12812@xs4all.nl> Message-ID: [Thomas Wouters, on getopt] > ... > From what I read in the getopt(3) manpage on my linux box the > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) I bet it's actually talking about Interpretation 150 to POSIX.2, here (while you can't read the std online, you can read the complaints online!): http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. html Doesn't have anything to do with the prototype, alas. > Does anyone have a system where the prototype to getopt() is not > defined in header files ? My Solaris 2.x testbox has that problem, but > the box in question is one huge mess, and I doubt it has anything to do > with Solaris in particular. ... Sure: Windows doesn't have a getopt; getopt isn't std C (not even in C99). Assorted derived stds demand that a getopt protoptype appear in stdlib.h, and others that it appear in unistd.h. I have a different suggestion: screw it. getopt keeps creating problems on GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU getopt shuffles all the "option strings" to the front, making a mess of, e.g., python myprog.py -v The Python source tree already has its own getopt implementation (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we like, and have Python use that instead on all systems. Every second we've spent tracking down problems with platform-supplied getopts has been a waste of time. they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- ly y'rs - tim From jack at oratrix.nl Fri Oct 13 00:03:57 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 13 Oct 2000 00:03:57 +0200 Subject: [Python-Dev] MacPython 2.0c1 available Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl> MacPython 2.0c1 is available, both as binary installer and in source form. You can find it through http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive please let me know whether it works, and, in the unlikely event it doesn't:-) what the problems are. Thanks, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From guido at python.org Fri Oct 13 01:07:28 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 18:07:28 -0500 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400." References: Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com> > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of, > e.g., > > python myprog.py -v > > The Python source tree already has its own getopt implementation > (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get > rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we > like, and have Python use that instead on all systems. Every second we've > spent tracking down problems with platform-supplied getopts has been a waste > of time. Excellent. After 2.0. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Fri Oct 13 00:18:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 00:18:01 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: ; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400 References: <20001012211436.Z12812@xs4all.nl> Message-ID: <20001013001801.A12812@xs4all.nl> On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote: > [Thomas Wouters, on getopt] > > ... > > From what I read in the getopt(3) manpage on my linux box the > > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) > > I bet it's actually talking about Interpretation 150 to POSIX.2, here (while > you can't read the std online, you can read the complaints online!): > http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. > html > Doesn't have anything to do with the prototype, alas. Ah, that sounds about right. Nifty link, too. I thought it had something to do with the prototype because of this comment: CONFORMING TO getopt(): POSIX.2, provided the environment variable POSIXLY_CORRECT is set. Otherwise, the elements of argv aren't really const, because we permute them. We pretend they're const in the prototype to be compatible with other systems. > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of [ a lot of things ] Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when necessary. Funny, I've seen that file a number of times, and read it, and read the getopt autoconf test as well, but somehow I never connected it with the loose prototype in main.c. I'm +1 on doing what you suggested, then. Wonder why it hasn't been done yet, though... we have no use for a system-wide getopt, except for a slightly smaller binary on systems that do have a 'good' system getopt. We can't use enhancements made to system getopt or anything, anyway. > they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- > ly y'rs - tim what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules- ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From m.favas at per.dem.csiro.au Fri Oct 13 02:47:25 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 13 Oct 2000 08:47:25 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au> Just a little unreality check - the whole world is not (yet) Linux - or even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour of 2.0 - OverflowError: math range error. Thus, on these platform, the proposed fixes _will_ change behaviour. But that's cool - I like Tim's proposed, um, steps to "rationalizing" fp behaviour, and will do what I can to help in the future. -- Email - m.favas at per.dem.csiro.au CSIRO Exploration & Mining From tim_one at email.msn.com Fri Oct 13 07:15:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:15:13 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au> Message-ID: [Mark Favas] > Just a little unreality check - the whole world is not (yet) Linux - or > even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on > Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour > of 2.0 - OverflowError: math range error. This is unfortunate. Guido never intended for Python to raise exceptions on underflow (and especially not *Over*flowError(!)), but he apparently didn't run on any platforms where this happened (I never have!), and AFAIK nobody ever mentioned this before. > Thus, on these platform, the proposed fixes _will_ change behaviour. See "unfortunate" above <0.5 wink>. > But that's cool - I like Tim's proposed, um, steps to "rationalizing" > fp behaviour, and will do what I can to help in the future. Want to fund a crack group of 754 experts for a year? Didn't think so. Constructive complaints will help a lot. So will beta testing. For example, I'm very keen to know whether the current CVS version of Python (2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or Tru64 Unix boxes. Running the (current CVS) std test suite will tell you: test_libm will pass or fail accordingly. If it's still busted on one of your systems, we've only got about a day to fix it (2.0 final is shipping early next week, and we have to let the codebase settle down for a couple days before building the final release). but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not- losing-much-sleep-over-it-ly y'rs - tim From tim_one at email.msn.com Fri Oct 13 07:18:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:18:52 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim hallucinated ...] > ... I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. Sorry for contradicting myself within a single sentence: I couldn't care less what happens in 2.0c1 anymore. Like I clearly said at the start, "current CVS version" is the question. From bwarsaw at beopen.com Fri Oct 13 07:33:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> Message-ID: <14822.40645.656159.493390@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> Again, "-l" should probably not be a default. I don't know NS> who added it to TESTOPTS but it wasn't me. I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I think (but don't really remember) that LEAK_DEBUG had different semantics than it does now. No matter. This was useful when gc was spankin' new and only semi-tested. It's probably fine to turn off -l in "make test" by default for the 2.0 release. -Barry From tim_one at email.msn.com Fri Oct 13 10:01:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 04:01:16 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim] > ... > We cannot consider this to be a bug since Python has had no *intended* > behavior whatsoever wrt 754 gimmicks. We can and do consider gripes > about these accidents to be feature requests. [Huaiyu Zhu] > Yes it varies widely in Python. But isn't that precisely because Python > does not support IEEE? Yes, but that's darned near tautological <0.5 wink>. > If Python does not actively undermine IEEE on platforms that have it, > would it still vary widely across these platforms? Yes. Your own -lieee example showed that math.sqrt(-1) computes not only a non-754 result, but a senseless result, on your platform under 1.5.2. If I show you a platform, how are you going to decide whether it "has" IEEE? 754 is a very involved std, and it's still rare to find a platform C that supports it correctly. On platform C's that do support it correctly, I know of none that do so without requiring platform-specific tricks. Python has *nothing* portable it can rely on, and its mass of utterly non-754-aware code building on haphazard C implementations adds up to the random x-platform crap we have today. ... [T] > The patch to stop setting -lieee was contributed by a Python user who > claimed it fixed bugs on *their* platform. That's "the reason". > We don't want to screw them either. [H] > Q: What bug? Which platform? Maybe there is another way that has less > impact on others? How to find out? I didn't check it in, and you can search the CVS archives as easily as I can (I'm not inclined to, since I don't think it can affect the outcome of this). Jeremy Hylton may, or may not, remember more about it (IIRC, he said he checked it in). > ... > If there is a way to fix the bug on that other platform while still keep > -lieee on Linux, would that be acceptable? No: Guido *wants* overflow to raise OverflowError by default, and *wants* sqrt(-1.0) to raise ValueError by default. Python's x-platform fp numerics today are an utter mess, and the best we can do for 2.0 is to make them as consistent as we have time to make them, despite that we know it will break some of your code (but you can still link with -lieee if you feel you must), and that Mark Favas has confirmed it will break code under both his Solaris and Tru64 Unix systems (but for a reason opposite of yours: he's been getting OverflowError on underflow since 1.5.2, and we're taking that away from him, and he'll have *no* way to go back). At this point we favor forcing consistency over maintaining platform accidents, no matter how attached people have gotten to them; else we'll be stuck with them forever. [oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/] > Interesting! I've glanced through some of Prof Kahan's writings. He is an entertaining writer, although his rhetoric is often more extreme than either of ours . > It appears that he favors raising flags that can be checked optionally, and > he is against mandatary raising exceptions. Have you read the 754 std? He's in favor of the 754 std. [quotes snipped, except for my favorite, which I've paraphrased many times over the years on c.l.py] > ... > They are called "Exceptions" because to any policy for handling them, > imposed in advance upon all programmers by the computer system, some > programmers will have good reason to take exception. > ... > From these quotes and others I understand that he wants f.p. exceptions to > be merely messanges, not errors that force programmers to take extra > actions, unless the programmer choose to. So what aspect of Java did he > think is deficient? It is the "Trap" style exception that mandate a users > action. His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5 main gripes about Java in bullet points at the top of page 3. The paper runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink>, reducing it to a bogus claim about Java that Kahan didn't make (Java has neither "Trap" nor "Flag" style fp exception signaling). > He told "A cautionary Tale of the Ariane 5", Which has nothing to do with Java -- the software in question was written in Ada, which (unlike Java) has "Trap" style. Why he put it in a paper about Java is a bit of a mystery; I write it off to rhetorical excess. > the European rocket that mulfunctioned after lift off. It turned out > that a piece of software produced an unimportant exception that is > not caught by a handler and caused debugging data to be dumped to a > critical memory location. This would have been avoided if the exception > merely raised a flag and returned a NaN, and the program continued. Actually, that was impossible to do, and he didn't suggest that. What he wrote is Had overflow merely obeyed the IEEE 754 default policy, the recalibration software would have raised a flag and delivered an invalid result both to be ignored by the motor guidance programs, and the Ariane 5 would have pursued its intended trajectory. Note that he didn't say NaN. He couldn't, because this was overflow in a conversion from Float to Integer. Despite his cheery optimism here, 754 is approximately useless in this case, since there is no generally accepted "invalid result" in integer formats (and 754 doesn't define one either -- the result of overflow in converting floats to ints is ill-defined in 754; 754 doesn't even require that it set the overflow flag). > So do we want every Python program to bomb whenever there is a floating > point value outside bound and is not trapped by try/except? By default, yes, Guido does, but for overflow, not underflow. If you read the following section of Kahan's paper, you should have noticed that he is *just* as critical of just returning Infs and NaNs (which is all Java does, and which is the accidental Python behavior you're arguing we keep in glibc) as he is of just trapping! His conclusion: "Without Traps nor Flags, Java? s floating-point is Dangerous": Without flags, detecting rare creations of Inf and NaN before they disappear requires programmed tests and branches that, besides duplicating tests already performed by the hardware, slow down the program and impel a programmer to make decisions prematurely in many cases. Worse, a plethora of tests and branches undermines a program?s modularity, clarity and concurrency. I agree with him there wholeheartedly: without the 754-mandated flags, *and* without raising exceptions, the subset of 754 remaining sucks. >> ironically, 754 is hardest to sell to those who could benefit from >> it the most. > So far the only concern from number-crunchers voiced here is that it might > allow sqrt(-1)==0, which is not the case. Gimme a break! In the very msg Paul Dubois said that, he also said "Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened.". I'm starting to drop my assumption of good faith on your part: what you remember and how you paraphrase (whether it's Paul or Kahan) is extremely selective, beyond normal bounds of zeal-inspired distortion. > I was a fortran programmer before. I switched to using IEEE ten years > ago as soon as it was available on the machine I was using. So there > are different opinions. Certainly, and good 754 support will cater to most of them. I don't believe your opinion (or mine, for that matter) reflects anything even close to the majority view here, though. As I said in my reply to Paul, my observations (based on 15 years on the vendor side of the fp biz) matched his exactly (based on his experience with hundreds of numeric code authors): a vast majority still want divide-by-0, invalid operation, and overflow to raise an exception the vast majority of the time. > ... > Obviously we agree on the benefit of having a choice. But we > have different perspective on what choice means. Your want a choice > to force user to take explicit action, I want a choice to ignore these > events. No. I want exactly the choices 754 lays out: user-settable sticky flags and user-maskable exceptions. We're not getting that for 2.0. And we're *never* getting it if 2.0 doesn't do *something* to start disabusing people of the notion that their historical numeric platform accidents in Python will be faithfully preserved forever more. > The ideal solution might be to have a sys.fp_exception class. Each > exception would set a flag like fp_exception.overflow so that user can > check them. There could also be a variable like fp_exception.force_trap, > which when set, could make each f.p. exception to produce a Python > exception. This would confirm to IEEE 754 and give both of us a choice > we want. Kinda, except that each of the 5 754-defined traps must be individually maskable. 754 spells out what's needed. A PEP will be required to spell out the Python- and C-level APIs. I've corresponded (just -- no time now) a little with Kevin Jacobs about that offline. > Now that we are in feature freeze for 2.0, we can't get both choices. > Can we adopt the one that does not break behaviors on previous official > release, even if that's only by accident? Not as far as Guido or I are concerned, no. You can link with -lieee yourself if you must, although I can't recommend perpetuating the x-platform confusion here. We want to say that, e.g., math.exp works substantially the same way on *all* platforms under 2.0, not repeat the same decade-old "umm, don't know, and no way to guess -- try it on your platform and see what it does" yet again. I don't expect 2.0 will actually achieve that on all platforms, but it should on the primary ones. > ... > So now I know why people reported that NaN and Inf were broken on HPUX > and Windows and some others. If Python had simply ignored the flags ... Then we would have broken 754 subsets in slightly subtler ways, and still wildly varying across platforms. > ... > Could you please point a URL to "presubstitution"? In the paragraphs I > quoted the only mention of presubstitute is with NaNs and Inf, etc. Sorry, I don't save URLs, and don't recall whether this was in a paper or on David Hough's "Numeric Interest" mailing list in the early 90's. A Google search on "presubstitution Kahan" turns up 4 promising-looking hits I'll leave you to pursue. The basic idea is that the programmer gets to specify, via library calls (whatever), which particular fp value each 754 exceptional case returns. So, e.g., if it made sense for some part of the app, the programmer could say they wanted +- pi returned instead +- Inf, if and whenever overflow happened. Then set it back to +- Inf (or anything else they needed) later. This would be best if supported in HW directly, of course. > ... > You are not confirming to 754 until you allow all the exceptions to go > through with well defined values as default. I know that, but don't care. As I said, enabling overflow + invalid + div0 by default is the only scheme that can be *sold*. If you can find two NumPy users in favor of disabling them all by default, I'll be mildly astonished. 754 did itself enormous harm by insisting on that trivial point (it's trivial because, with proper support, anyone can change the defaults to anything they like with one line of code): I worked in the supercomputer biz at the time 754 was adopted, and for a decade after, and the "non stop" defaults were *universally* opposed by customers. Scared the hell out of language stds committees too, which goes a lot farther than the 754 folks would like to admit toward explaining why language committees stayed away from 754 bindings in droves. C99 is 15 years(!) after the fact. > Raising Python exceptions on some of them does not confirm to 754, as > the default IEEE 754 behavior on f.p. exception is not a Python exception, > but just a raised flag. See above. > Before that happens, what is the motive to make IEEE less usable for those > who have it (pretty much every one nowadays), even if just by accident? I think I've repeated the reasons to death already, and you've repeated to death that you'll never agree. So no more from me on that. > ... > But just to clarify some wordings you quoted in another post: I meant that > sqrt(-1)==0 is insane, whether silent or not. I agree. > Raising an exception is sane, Not according to 754's default rules, which you wanted me to take as sacred just a few paragraphs ago . > although OverflowError is not so reasonable. I'd say it's insane. > Raising a ValueError is reasonable. I expect we'll have to make InvalidOperationError a subclass of ValueError for that reason, when 754 support materializes. > But just returning NaN without a fuss is even better. You're going to find that's a very lonely position. > My favorite is returning 1j, as MatPy does. Then you should use cmath.sqrt instead of math.sqrt. Even $3 business calculators have a sqrt key these days, and you do not want to be on the other end of email when trying to explain to a businessperson why their crappy std deviation program returned a complex number <0.1 wink>. > if-it-ain't-broke-don't-fix-it-ly y'rs it-it-weren't-broke-we-wouldn't-ly y'rs - tim From fgranger at altern.org Fri Oct 13 12:08:23 2000 From: fgranger at altern.org (Francois Granger) Date: Fri, 13 Oct 2000 12:08:23 +0200 Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl> Message-ID: on 13/10/00 0:03, Jack Jansen at jack at oratrix.nl wrote: > MacPython 2.0c1 is available, both as binary installer and in source > form. You can find it through > http://www.cwi.nl/~jac/macpython.html. This one works better. http://www.cwi.nl/~jack/macpython.html -- Fran?ois Granger fgranger at altern.org From nas at arctrix.com Fri Oct 13 08:37:17 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 23:37:17 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> Message-ID: <20001012233717.A20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote: > I think (but don't really remember) that LEAK_DEBUG had > different semantics than it does now. Nope. LEAK_DEBUG prints to stderr information about all garbage the GC finds, even stuff the GC can free. The thinking was that GC would be an option and people would want to find applications that leak when only using reference counting. > No matter. This was useful when gc was spankin' new and only > semi-tested. It's probably fine to turn off -l in "make test" by > default for the 2.0 release. I've left -l enabled for now. Detecting tests that create uncollectable garbage is probably a good thing. It doesn't cost much and the message should be fairly clear now. Neil From fdrake at beopen.com Fri Oct 13 15:34:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012233717.A20054@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I've left -l enabled for now. Detecting tests that create > uncollectable garbage is probably a good thing. It doesn't cost > much and the message should be fairly clear now. Perhaps one thing that could be done is to reduce the volume of the output; perhaps just list the first 1K or 2K of the repr? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Fri Oct 13 09:09:48 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 00:09:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400 References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Message-ID: <20001013000948.C20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote: > Perhaps one thing that could be done is to reduce the volume of the > output; perhaps just list the first 1K or 2K of the repr? It just prints the number of object found now. Neil From fdrake at beopen.com Fri Oct 13 16:06:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001013000948.C20054@glacier.fnational.com> References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> <20001013000948.C20054@glacier.fnational.com> Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > It just prints the number of object found now. Ok, I must have missed the checkin that changed that. This is fine in my book as well. Thanks for staying on top of this work! I think you've really done a great job with the GC effort. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Fri Oct 13 17:18:23 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach I tried sending a message with the output of ./configure and make attached, but it was over the 40K limit. If anybody wants to see these, email me. From nas at arctrix.com Fri Oct 13 10:28:49 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 01:28:49 -0700 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013012849.C20168@glacier.fnational.com> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Unresolved: > __pthread_mutex_init [...] What is the LIBS variable set to in Modules/Makefile? It looks your missing something like "-lpthread". Neil From cgw at fnal.gov Fri Oct 13 17:35:52 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013012849.C20168@glacier.fnational.com> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013012849.C20168@glacier.fnational.com> Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov> Neil Schemenauer writes: > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > > Unresolved: > > __pthread_mutex_init > [...] > > What is the LIBS variable set to in Modules/Makefile? It looks > your missing something like "-lpthread". Hehehe. I might be kinda thick sometimes, but I think I would have caught that. Here's a little more of the "make" output: cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. From thomas at xs4all.net Fri Oct 13 18:34:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 18:34:36 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013183436.B12812@xs4all.nl> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Sorry, I don't have time to investigate this fully right now. Maybe > this weekend. For now this is just a heads-up. Hopefully, something > is just misconfigured on this system. > The machine in question is running OSF1 V4.0 878 alpha That's a former DEC alpha, right ? Perhaps running configure with '--with-dec-threads' will solve the problem ? I'm not sure if that will work alone, so you might need '--with-dec-threads --with-threads=no' to disable 'normal' thread-checking. You can also try this by hand; after running configure, edit Modules/Makefile.pre, and change LDLAST= into LDLAST= -threads (not -lthreads, just -threads) That seems to be the only difference --with-dec-threads uses. I looked at this before, but don't have an alpha or anything else that needs --with-dec-threads, so I couldn't detect this automatically. I do think it should be done automatically, though. Perhaps I can figure it if you can send me, for instance, config.log and the output of configure, and find the time to run a few tests later. > I can only build Python from current CVS sources on OSF/1 if I specify > --without-thread. If I don't specify this I get the following errors > at link time: > Unresolved: > __pthread_mutex_init > I tried sending a message with the output of ./configure and make > attached, but it was over the 40K limit. If anybody wants to see > these, email me. If the above doesn't fix it, I can take a look at the output of configure and config.log. No need to see the output of make just yet. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From cgw at fnal.gov Fri Oct 13 20:31:34 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013183436.B12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov> Thomas Wouters writes: > > That's a former DEC alpha, right ? Perhaps running configure with > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > alone, so you might need '--with-dec-threads --with-threads=no' to disable > 'normal' thread-checking. Thank you, that indeed solves the problem. Sorry for the noise. It would be nice if configure were smart enough to figure this out! From cgw at fnal.gov Fri Oct 13 20:38:26 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <200010131453.JAA23050@buffalo.fnal.gov> Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov> Tim Peters wrote: > I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. I just repeated this test, on the following 4 platforms: 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 2) OSF1 V4.0 878 alpha DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) 3) IRIX64 6.5 07151432 IP27 MIPSpro Compilers: Version 7.2.1 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 gcc version 2.95.2 19991024 (release) On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) raises an exception, and test_math.py completes successfully. Testing-ly (not to be confused with testily) yr's, cgw From tim_one at email.msn.com Fri Oct 13 20:56:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 14:56:43 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: [Charles G Waldman] > I just repeated this test, on the following 4 platforms: > > 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise > cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 > > 2) OSF1 V4.0 878 alpha > DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) > > 3) IRIX64 6.5 07151432 IP27 > MIPSpro Compilers: Version 7.2.1 > > 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 > gcc version 2.95.2 19991024 (release) > > On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) > raises an exception, and test_math.py completes successfully. Excellent! Note that test_math.py was augmented to verify that: 1. exp(-huge) returns 0 without exception. 2. exp(+huge) raises OverflowError. 3. sqrt(-1) raises ValueError. None of those were reliable across platforms before, and I'm afraid there's strong reason to suspect one or more still won't work right under Mandrake Linux when Python is compiled with -O (this based on the output of a C program someone posted to c.l.py yesterday). But it's a world better than it used to be. > Testing-ly (not to be confused with testily) yr's, You bet -- everyone leave testily to me on this one. I'm bitter enough about floating-point in stinking C for everyone combined <0.9 wink>. From thomas at xs4all.net Fri Oct 13 21:19:38 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 21:19:38 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> Message-ID: <20001013211938.C12812@xs4all.nl> On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > > > That's a former DEC alpha, right ? Perhaps running configure with > > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > > alone, so you might need '--with-dec-threads --with-threads=no' to disable > > 'normal' thread-checking. > Thank you, that indeed solves the problem. Sorry for the noise. No problem. When I went over the README file a few weeks back, and sent Guido an update, this particular issue was one of the biggest problems for me: the old README, which assumed threads were not default, was quite adamant about using --with-dec-threads for OSF/1 and its incarnations. Unfortunately, it doesn't say why :) And the configure script only says that it's necessary to get threadsafe libraries. > It would be nice if configure were smart enough to figure this out! Configure is as smart as we make it. configure is made by autoconf, which is moderately intelligent, and we just have to add the extra geniality to configure.in. If the only check we need is 'does this system call itself OSF1', we can easily add that. See the attached patch (configure.in version only. Let me know if you need a patched configure as well, I don't know if OSF systems come with autoconf. It's pretty large, though, and you don't need to generate configure on the same system as you run it on. Just apply the configure.in patch, type 'autoconf', and copy the resulting configure script to your OSF1 machine.) The question is, is this enough ? Will this detect all the OSF platforms that need '-threads', and will it only add it to those platforms ? It wouldn't be particularly nice of configure if it insisted on adding '-threads' on platforms that don't need it, or worse, break because of it. For instance, the patch uses 'OSF*', which might be too generic... but 'OSF1' might be too restrictive :-) A better fix would probably be to write a test program that explicitly uses threads & the -threads arguments, but that could fail for a large number of reasons, which doesn't mean -threads isn't needed :P (Configure is really amusing like that. For instance, if your compile system is broken, like when you unpacked a new linux kernel source tree in /usr/src/linux, but forgot to type 'make symlinks', configure will assume the worst (every check is negative, after all.) If you're lucky, it will complain because you miss an essential feature... If you're unlucky, it finishes cleanly, writes the config.cache file, your compile fails, you figure out the problem, and you keep compiling using the wrong autoconf 'settings'. And re-configuring doesn't fix it, because the config.cache file is just fine ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.172 diff -c -r1.172 configure.in *** configure.in 2000/10/12 17:11:38 1.172 --- configure.in 2000/10/13 19:15:11 *************** *** 805,810 **** --- 805,819 ---- LIBS="$LIBS -lthread" LIBOBJS="$LIBOBJS thread.o" USE_THREAD_MODULE=""]) + + if test "$USE_THREAD_MODULE" != "#" + then + # If the above checks didn't disable threads, (at least) OSF1 + # needs this '-threads' argument during linking. + case $ac_sys_system in + OSF*) LDLAST=-threads;; + esac + fi fi # Check for GC support From skip at mojam.com Fri Oct 13 21:39:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: <14823.25854.786347.542654@beluga.mojam.com> Tim> None of those were reliable across platforms before, and I'm afraid Tim> there's strong reason to suspect one or more still won't work right Tim> under Mandrake Linux when Python is compiled with -O (this based on Tim> the output of a C program someone posted to c.l.py yesterday). But Tim> it's a world better than it used to be. After executing cvs update -d . ./configure make clean make OPT=-O3 I get the following output from regrtest.py regarding test_math: % ./python Lib/test/regrtest.py test_math test_math 1 test OK. This is on a Mandrake 7.1 system. Here are the bits I think are relevant to identify my environment: % cat /etc/issue.net Linux Mandrake release 7.1 (helium) Kernel 2.2.16-9mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -q -a | egrep glibc glibc-devel-2.1.3-15mdk compat-glibc-5.3-2.0.7.6mdk glibc-2.1.3-15mdk If you have a C test program you'd like me to try, shoot it over. I'll be glad to run it and shoot back the results. Skip From fdrake at beopen.com Fri Oct 13 21:41:46 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: The test passes for me as well on Mandrake 7.1. Here's the environment info: % ./python -tt ../Lib/test/regrtest.py test_math test_math 1 test OK. % cat /etc/issue.net Welcome to %h Linux Mandrake release 7.1 (helium) Kernel 2.2.15-4mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -qa | egrep glibc nedit-5.1.1-1.glibc glibc-profile-2.1.3-5mdk glibc-2.1.3-5mdk compat-glibc-5.3-2.0.7.6mdk glibc-devel-2.1.3-5mdk > If you have a C test program you'd like me to try, shoot it over. I'll be > glad to run it and shoot back the results. Same here... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Fri Oct 13 21:52:44 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: > % gcc -v > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs > gcc version 2.95.3 19991030 (prerelease) AFAIK, this version of GCC was never "blessed" by the GCC maintainers and should not be being used for any production work. I think Mandrake did a bad thing by shipping this version. Not quite as bad as what RedHat did by shipping the completely not-for-general-use gcc-2.96, but nonetheless still a bad thing. When will distribution builders learn that having a higher version number is not necessarily a good thing? Why do they keep second-guessing the good advice of the GCC Steering Committee? Sigh... In any case, I don't think we should put effort into chasing down bugs that are caused by bogus C compilers. Any reports coming in from RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. From fdrake at beopen.com Fri Oct 13 21:58:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> <14823.26636.59174.832572@buffalo.fnal.gov> Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com> Charles G Waldman writes: > AFAIK, this version of GCC was never "blessed" by the GCC maintainers > and should not be being used for any production work. I think > Mandrake did a bad thing by shipping this version. Not quite as bad I agree. > In any case, I don't think we should put effort into chasing down bugs > that are caused by bogus C compilers. Any reports coming in from > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. I think Skip & I were showing that there isn't a bug for Mandrake 7.1. I don't know what version of GCC shipped with Mandrake 7.0, which may have been the version Tim received the report for (I recall he said "Mandrake 7", which isn't specific). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From larsga at garshol.priv.no Fri Oct 13 22:08:05 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 13 Oct 2000 22:08:05 +0200 Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Message-ID: * Fred L. Drake, Jr. | | This looks like a problem in the unlink() method of the DOM. Could | you please check that the unlink() method is updated to handle the | latest version of the other changes? It seems that the current unlink() does not remove sibling cycles. Patch #101897 adds a line to set sibling references to None, which seems to make regrtest.py -l happy. --Lars M. From prescod at prescod.net Fri Oct 13 22:12:38 2000 From: prescod at prescod.net (Paul) Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT) Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Message-ID: Right, I just checked in the fix to that. Paul Prescod On 13 Oct 2000, Lars Marius Garshol wrote: > > * Fred L. Drake, Jr. > | > | This looks like a problem in the unlink() method of the DOM. Could > | you please check that the unlink() method is updated to handle the > | latest version of the other changes? > > It seems that the current unlink() does not remove sibling cycles. > Patch #101897 adds a line to set sibling references to None, which > seems to make regrtest.py -l happy. > > --Lars M. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From tim_one at email.msn.com Fri Oct 13 22:23:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 16:23:31 -0400 Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> Message-ID: The original source of my concern was this c.l.py post from David Cooke: http://www.deja.com/getdoc.xp?AN=680840594 He ran a little C program that Huaiyu Zhu had posted earlier in the thread. According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ... without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt *never* set errno, regardless of input. In which case what Python does with the platform NaN result from math.sqrt(-1.) is an accident (and probably ends up setting errno to ERANGE itself by mistake), and an overflowing exp would let the platform +Inf result pass thru silently. So, if David's report is correct, and best I understand it you were all using 7.1 too with at least some level of optimization, it's A Mystery why CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would probably fail; its new math.exp(+huge) test would almost certainly fail). I'm anal enough about this stuff that I'd try to figure out why if I had a Mandrake system, but in the cosmic scheme of things I doubt it's important enough for anyone else to burn time on. From jeremy at beopen.com Sat Oct 14 01:05:02 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT) Subject: [Python-Dev] build problems large and small on FreeBSD Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net> I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE FreeBSD). There are a number of compiler warnings, all having to do with redefinitions, plus some linker warnings and a test failure. I don't have time to investigate further, but thought I'd let people know in case someone else has time to take a look. test_math failed -- overflowing exp() didn't trigger OverflowError Python 2.0c1 (#2, Oct 13 2000, 15:50:26) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.exp(1200) Inf The warnings from the linker seem harmless enough. I don't know why it is complaining about setkey and des_setkey. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() The compiler-time warnings look like they are caused by a configure problem. If so, I don't know how to fix it :-). gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c In file included from /usr/include/unistd.h:42, from ../../Python/thread.c:28: /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined ../config.h:136: warning: this is the location of the previous definition In file included from ../../Python/thread.c:118: ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined /usr/include/pthread.h:158: warning: this is the location of the previous definition ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined /usr/include/pthread.h:157: warning: this is the location of the previous definition ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined /usr/include/pthread.h:156: warning: this is the location of the previous definition Jeremy From jeremy at beopen.com Sat Oct 14 01:11:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT) Subject: [Python-Dev] warnings --with-pydebug Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net> If you configure using '--with-pydebug' you get a lot of compile-time warnings. ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:672: warning: value computed is not used ../../Python/ceval.c:675: warning: value computed is not used ../../Python/ceval.c:678: warning: value computed is not used ../../Python/ceval.c:680: warning: value computed is not used ../../Python/ceval.c:681: warning: value computed is not used [etc.] I assume these are caused by the definition of Py_INCREF #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) Is there some way to change this macro so that the warnings are silenced? Jeremy From thomas at xs4all.net Sat Oct 14 01:28:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:28:19 +0200 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400 References: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <20001014012819.D12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote: > The warnings from the linker seem harmless enough. I don't know why > it is complaining about setkey and des_setkey. That's probably due to 'crypt()' being used, or some other library call that Python uses indirectly. If you want crypt(), you need to install a seperate DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all crypt purposes by default, because of the US Counter-Espionage Protection Plan or something :) If you don't want to install those, don't enable the crypt module. There are a couple of pure python crypt() implementations around, by the way, which always use pure DES crypt(). > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. This one is weirdish. I don't see any gets() call in Python, so I have to assume it's in some library or header file Python includes. A good candidate would be readline, which has appalled me before :) but who knows :P I'm inclined to think it isn't a library that comes with FreeBSD by default, since they are usually pretty picky about such things. (especially if it generates a linker warning each time it's used!) > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Yes, I've seen this before. Debian-unstable (I think ?) complains about tmpnam() and tempnam() as well. The manpages just say 'don't use this function, use mkstemp(3)'. It doesn't mention a reason, but it's probably because the files/directories created by these functions are predictable, which means you shouldn't use them for security-by-obscurity. The mktemp() warning doesn't come from Python, looks like. Probably another library that is included. If you really care about which it is, you'll have to comment them out one by one (I'd suggest starting with the oldest and least FreeBSDish one, i.e. readline :) but I don't think it's going to really matter. Python does use 'tempnam' and 'tmpnam', but only in the posixmodule, to provide Python versions. I'm not sure if we can just change these functions to use mkstemp (or tempfile, see below) internally, without breaking code, though I expect it'll be alright. What's more, these functions are new since 1.5.2. And also, I just noticed a bug/typo in the tempnam docstring. The one funny bit, though, is that these three functions point to mkstemp(), and the mkstemp() manpage reads this: Don't use this function, use tmpfile(3) instead. It's better defined and more portable. "When does the hurting stop ?" > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. And this falls in the 'it wasn't us' category again. > The compiler-time warnings look like they are caused by a configure > problem. If so, I don't know how to fix it :-). > gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c > In file included from /usr/include/unistd.h:42, > from ../../Python/thread.c:28: > /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined > ../config.h:136: warning: this is the location of the previous definition Hm, yes. This looks like an unfortunate clash between a Python internal #define and a FreeBSD libc internal #define. I'm not sure if this is really the case, maybe the Python one serves exactly the same purpose as the FreeBSD one, but in that case, configure shouldn't redefine it. We can either rename the #define in Python, as it's only used to determine which thread functionality is available, or adjust the configure tests to see if it is #defined and not redefine it if so. (Or rather, to be sure that it defines the right thing, configure would have to test for posix threads, check the #define (if any), and if they don't match up, scream its head off. So perhaps renaming is the smarter thing.) On the other hand, the fact that you only got a warning, and not an error, means that Python isn't defining it to a different value than FreeBSD did, so it's not really a problem. It might be a problem if Python #defines it, but FreeBSD does not, but FreeBSD does have code that checks that #define, and starts doing weird things... > In file included from ../../Python/thread.c:118: > ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined > /usr/include/pthread.h:158: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined > /usr/include/pthread.h:157: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined > /usr/include/pthread.h:156: warning: this is the location of the previous definition Not sure about these, because I don't know enough about the various types of posix thread standards, and almost-posix thread almost-standards. I'm not sure if those names are reserved in any way, but they are apparently clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code that does the defines like Python does, too. A simple '#undef' or '#ifndef' would suffice, here, I think, but I'm not sure. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sat Oct 14 01:33:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:33:59 +0200 Subject: [Python-Dev] warnings --with-pydebug In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400 References: <14823.38542.908547.275077@bitdiddle.concentric.net> Message-ID: <20001014013359.E12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote: > If you configure using '--with-pydebug' you get a lot of compile-time > warnings. > ../../Python/ceval.c: In function `eval_code2': > ../../Python/ceval.c:672: warning: value computed is not used > ../../Python/ceval.c:675: warning: value computed is not used > ../../Python/ceval.c:678: warning: value computed is not used > ../../Python/ceval.c:680: warning: value computed is not used > ../../Python/ceval.c:681: warning: value computed is not used > [etc.] > I assume these are caused by the definition of Py_INCREF > #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) > Is there some way to change this macro so that the warnings are > silenced? Yes, prefix it with '(void)': #define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++) However, that means that the 'return value' of Py_INCREF() must never be used anywhere. (If it does, it'll generate an error.) The return value of Py_INCREF() is not terribly useful, though. Both in debug and in normal mode, it expands to the refcount of the object *before* it was INCREF'd. I still consider this kind of warning (I've seen it before, always with macros that do several things by using the otherwise fairly useless tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements have sideeffects, and it's obvious we want to throw away the first result, so why worry about the second ? But at least it isn't screwing up floating-point operations, and nobody's perfect :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu at yahoo.com Sat Oct 14 02:25:49 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: Tim, Thank you for the explanations. We actually agree more than it appears: - Full IEEE 754 support in Python is good, which should allow the user to decide when to use raised flags and when to use Python exceptions. - If the user default can be changed with one line of code, it does not matter if Python default use exceptions, even if that's not strict compliance in words. The "factory default" might as well set for the benefit of newbies. - Without IEEE 754 support, or with just partial support, f.p. computation is a mess. Following are some contentious issues: I am not so sure that even with 754, there would still be a great variety. I see you giving one example: sqrt(-1) in 1.5.2. But wasn't that caused by extra Python checking? I say this because errno==0 in C. Maybe I'm missing something. Or, do you mean that glibc itself is deficient, because it should have set the flag? My worry concerns the decision to unify 2.0 f.p. behavior in a specific way before full IEEE 754 support. I understand that you say this does not count as a changed behavior because the previous one is accidental. But I don't see the particular fixed subset chosen as any better than any other. I agree that I do have a choice of using -lieee, though. It is interesting to know that someone actually relies on OverflowError to detect underflow. But why not let them continue that as well, given that all of these would be available in the future anyway? > At this point we favor forcing consistency over maintaining platform > accidents, no matter how attached people have gotten to them; else we'll > be stuck with them forever. I do not understand. Once there is full IEEE 754, everyone would have a choice, which pretty much includes all the things people are doing now. Before that happens, why consistency accross platform is deemed more important than consistency accross releases? My naive thinking is that people port more from 1.5.2 to 2.0 than from one platform to another, isn't it? :-) Following does not have much new to say, just some clarification. You are right to emphasise that Kahan does not favor any subset of IEEE 754: > > They are called "Exceptions" because to any policy for handling them, > > imposed in advance upon all programmers by the computer system, some > > programmers will have good reason to take exception. Yes. And that's what's happening. :-) > His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5 > main gripes about Java in bullet points at the top of page 3. The paper > runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink>, > reducing it to a bogus claim about Java that Kahan didn't make (Java has > neither "Trap" nor "Flag" style fp exception signaling). Thank you for correcting me on this one. I did "glance over" all the pages. I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and got Exception in thread "main" java.lang.ArithmeticException: / by zero But now I see that 1/0.0 is Infinity. So is Math.exp(777). And so on. So that teaches me to test, test, test, ... > > He told "A cautionary Tale of the Ariane 5", > > Which has nothing to do with Java -- the software in question was written in > Ada, which (unlike Java) has "Trap" style. Why he put it in a paper about > Java is a bit of a mystery; I write it off to rhetorical excess. You are right it does not apply to Java. I guess he meant that as a warning that changing to the other side might be equally bad. > > So do we want every Python program to bomb whenever there is a floating > > point value outside bound and is not trapped by try/except? > > By default, yes, Guido does, but for overflow, not underflow. That's the harsh reality I have to live with, I suppose. <0.9wink> > If you read > the following section of Kahan's paper, you should have noticed that he is > *just* as critical of just returning Infs and NaNs (which is all Java does, > and which is the accidental Python behavior you're arguing we keep in glibc) > as he is of just trapping! His conclusion: "Without Traps nor Flags, Java? > s floating-point is Dangerous": > > Without flags, detecting rare creations of Inf and NaN before they > disappear requires programmed tests and branches that, besides > duplicating tests already performed by the hardware, slow down the > program and impel a programmer to make decisions prematurely in many > cases. Worse, a plethora of tests and branches undermines a program?s > modularity, clarity and concurrency. > > I agree with him there wholeheartedly: without the 754-mandated flags, > *and* without raising exceptions, the subset of 754 remaining sucks. That is true, but all these problems apply to "without raising flags", whether with or without "raising exceptions". Silent overflow forces programmers to do extra checking if they need to find them. Mandatory exception forces programmer to do extra checking if they don't want them to stop the program. Which is more common? It depends on programming style. In my programs, intentional NaN is far more than NaN by mistake. As to whether it is dangerous, I would say that if an overflow is really an error, good programming style requires that it be detected much earlier than the actual overflow. I agree this cannot be expected of everyone, though. > >> ironically, 754 is hardest to sell to those who could benefit from > >> it the most. > > > So far the only concern from number-crunchers voiced here is that it might > > allow sqrt(-1)==0, which is not the case. > > Gimme a break! In the very msg Paul Dubois said that, he also said "Some > people use Inf but most people want the code to STOP so they can find out > where the INFS started. Otherwise, two hours later you have big arrays of > Infs and no idea how it happened.". I'm starting to drop my assumption of > good faith on your part: what you remember and how you paraphrase (whether > it's Paul or Kahan) is extremely selective, beyond normal bounds of > zeal-inspired distortion. Well, I was talking about whether anyone has shown a concern to oppose 754. I was not talking about whether exception is prefered to flags. See the line I was replying to? Actually, thinking about it, Paul was not talking about concerns over 754, either. So there appears zero resistence to 754 from number crunchers here. > > Obviously we agree on the benefit of having a choice. But we > > have different perspective on what choice means. Your want a choice > > to force user to take explicit action, I want a choice to ignore these > > events. > > No. I want exactly the choices 754 lays out: user-settable sticky flags > and user-maskable exceptions. We're not getting that for 2.0. And we're > *never* getting it if 2.0 doesn't do *something* to start disabusing people > of the notion that their historical numeric platform accidents in Python > will be faithfully preserved forever more. Let me make it clear that we agree on all essential points about full 754 support. The difference only exists in the period before that. Since both the 1.5.2 accidental behaviors and the one you want to unify to are just subsets of the full support, it does not appear to me that disabling several of them is a prerequisite for the full support. > Kinda, except that each of the 5 754-defined traps must be individually > maskable. 754 spells out what's needed. A PEP will be required to spell > out the Python- and C-level APIs. I've corresponded (just -- no time now) a > little with Kevin Jacobs about that offline. Great! If the true IEEE 754 support could come soon, all my gripe is moot. So I'll stop disturbing you on the good work. :-) OK, I see that you want consistency above anything else before that good day comes. Well, consistency is good. Whether the price is too high is a subjective judgement. So I'll just use the -lieee hack for myself, then. [On presubstitution] Ok, I found it. It looks good. [On whether 754 default uses flags or exceptions] I agree with you: the system default matters very little as long as users can set their own defaults easily. > I expect we'll have to make InvalidOperationError a subclass of ValueError > for that reason, when 754 support materializes. That'll be handy. > > My favorite is returning 1j, as MatPy does. > > Then you should use cmath.sqrt instead of math.sqrt. Thanks. Huaiyu From skip at mojam.com Sat Oct 14 02:29:06 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT) Subject: [Python-Dev] Simple xml.sax example? Message-ID: <14823.43218.337621.157021@beluga.mojam.com> Is there a simple example available that demonstrates how to use elements of the new xml.sax package? I'd prefer something that doesn't require me to install anything other than what comes with the Python 2.0 distribution? Thanks, Skip From cbarker at jps.net Sat Oct 14 03:22:28 2000 From: cbarker at jps.net (Chris Barker) Date: Fri, 13 Oct 2000 18:22:28 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) References: Message-ID: <39E7B554.29A168E3@jps.net> Incomplete vs. non-at-all IEEE 754 support is a non argument. If you have full IEEE support (which it seems everyone here thinks would be good, but difficult), it is clear what you have. If not, you are not consistent with a standard, and therefor making up your own. That being the case, it's a matter of what we want the Python standard to be. I, for one think that NaN and Inf are fantastic!!! I think the best argument for them here is that it is almost impossible to do a lot of array based calculations without them, and you can't do serious number crunching in Python without array based calculations. I've come to Python from MATLAB for numerics, and I really appreciated MATLAB's way of handling all this. I don't think MATLAB has true 754 support, as I don't think you can change the behaviour, but you do get a consistent result across platforms (including non-iee machines like the Cray?---I have no idea). I have not yet heard a decent response to the question of what to do when a single value in a large array is bad, and causes an exception. This really does render Python essentially useless for Numerics for me. I suspect all those number crunchers that want an exception rather than an Inf are NOT using array-oriented languages. My goal is to dump MATLAB for Python, but this may prevent me from doing that. Does anyone know what other array-oriented languages use? I know what MATLAB does: >> exp(-777) ans = 0 >> exp(777) ans = Inf >> sqrt(-1) ans = 0 + 1.0000i Hey! I like that! Python is dynamic, why can't we just get the actual answer to sqrt(-1), without using cmath, that always returns a complex ? sorry, other subjet, not meant to be raised at the moment. >> 54/0 Warning: Divide by zero. ans = Inf Here we get a warning, but also a result that won't crash the computation. >> a = 0/0 Warning: Divide by zero. a = NaN >> b = a b = NaN >> a == b ans = 0 So comparing two NaNs yields a false, as it should, and though Python won't do it now, it could. One thing that a numerical routine should NEVER do is give an incorrect answer. No answer is often bad, but an incorrect one is much worse. NaN == NaN must return false. Does anyone know what FORTRAN 90 specifies (if anything)? What other array-oriented languages are there? I think what MATLAB does is what Tim is calling "bad *and* incomplete 754 support" Incomplete is surely true, "bad" is clearly a matter of opinion. It seems we have a variety of users of numerics in Python, that I break into three broad catagories: Casual users: mostly doing non-numeric stuff, with the occasional calculation: This group could use any non-cryptic handling of over/underflow, it just doesn't matter. Mid-level number crunchers: This is the group I put myself in. We crunch a lot of numbers, really like the array semantics (and speed) of NumPy, and are doing things like graphing functions, statistical calculations, etc. We have probably only taken one of two (at most) numerical analysis courses, and many don't know what the heck IEE 754 is. (The one Numerical Analysis course I did take, happened to be with Kahan, which is why I know what it is) For this group, the incomplete IEEE support is probably the best way to go. We're more likely to be annoyed by our whole computation stopping because of one bad data point, than we are to be pissed off that it didn't stop when it started to compute garbage. Hard Core Number crunchers: These are the folks that do things like write optimised routines for particular architectures, adn teach numerical analysis courses. These folks want either FULL IEEE, or plain old "classic" overflow and underflow errors, that they can handle themselves. Do these folks really use Python as other than a glue language? Are they really doing massive number crunching in Python itself, rather than in C (or whatever) extensions? If so, I'd be surprised is they didn't find Huaiyu's argument compelling when doing array based calculations. Tim pointed out that Python was not designed with 754 in mind, so for 2.0, what he is doing is probably our best bet, but it seems to not be the best ultimate solution, I hope using NaN and Inf will be considered for future versions, even if it is incomplete 754 compliance. Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible without custom re-compiling your own interpreter? If so, is there any chance that it will come any time soon (2.1 ?) , so we don't have to have this discussion at all? Thanks for all of your work on this, Python just keeps getting better!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cgw at fnal.gov Sat Oct 14 04:44:42 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov> Chris Barker writes: > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? You have to import the sqrt function from somewhere. Either you import it from math or from cmath, depending on which flavor you need. Anybody sophisticated enough to know what complex numbers are, and sophisticated enough to want to get complex values as a result of a calculation, should be sophisticated enough to be able to type "cmath". From larsga at garshol.priv.no Sat Oct 14 12:19:20 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 14 Oct 2000 12:19:20 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com> References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: * Skip Montanaro | | Is there a simple example available that demonstrates how to use | elements of the new xml.sax package? Here are a couple from an internal seminar I recently gave on this. I could make the slides available as well, if there is interest. --Lars M. --- elem_count.py import sys from xml.sax import make_parser, handler class FancyCounter(handler.ContentHandler): def __init__(self): self._elems = 0 self._attrs = 0 self._elem_types = {} self._attr_types = {} def startElement(self, name, attrs): self._elems = self._elems + 1 self._attrs = self._attrs + len(attrs) self._elem_types[name] = self._elem_types.get(name, 0) + 1 for name in attrs.keys(): self._attr_types[name] = self._attr_types.get(name, 0) + 1 def endDocument(self): print "There were", self._elems, "elements." print "There were", self._attrs, "attributes." print "---ELEMENT TYPES" for pair in self._elem_types.items(): print "%20s %d" % pair print "---ATTRIBUTE TYPES" for pair in self._attr_types.items(): print "%20s %d" % pair parser = make_parser() parser.setContentHandler(FancyCounter()) parser.parse(sys.argv[1]) --- roundtrip.py """ A simple demo that reads in an XML document and spits out an equivalent, but not necessarily identical, document. """ import sys, string from xml.sax import saxutils, handler, make_parser # --- The ContentHandler class ContentGenerator(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out # ContentHandler methods def startDocument(self): self._out.write('\n') def startElement(self, name, attrs): self._out.write('<' + name) for (name, value) in attrs.items(): self._out.write(' %s="%s"' % (name, saxutils.escape(value))) self._out.write('>') def endElement(self, name): self._out.write('' % name) def characters(self, content): self._out.write(saxutils.escape(content)) def ignorableWhitespace(self, content): self._out.write(content) def processingInstruction(self, target, data): self._out.write('' % (target, data)) # --- The main program parser = make_parser() parser.setContentHandler(ContentGenerator()) parser.parse(sys.argv[1]) --- rss2html.py import sys from xml.sax import make_parser, handler # --- Templates top = \ """ %s

    %s

    """ bottom = \ """
Converted to HTML by sax_rss2html.py.
""" # --- The ContentHandler class RSSHandler(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out self._text = "" self._parent = None self._list_started = 0 self._title = None self._link = None self._descr = "" # ContentHandler methods def startElement(self, name, attrs): if name == "channel" or name == "image" or name == "item": self._parent = name self._text = "" def endElement(self, name): if self._parent == "channel": if name == "title": self._out.write(top % (self._text, self._text)) elif name == "description": self._out.write("

%s

\n" % self._text) elif self._parent == "item": if name == "title": self._title = self._text elif name == "link": self._link = self._text elif name == "description": self._descr = self._text elif name == "item": if not self._list_started: self._out.write("
    \n") self._list_started = 1 self._out.write('
  • %s %s\n' % (self._link, self._title, self._descr)) self._title = None self._link = None self._descr = "" if name == "rss": self._out.write(bottom) def characters(self, content): self._text = self._text + content # --- Main program parser = make_parser() parser.setContentHandler(RSSHandler()) parser.parse(sys.argv[1]) From thomas at xs4all.net Sat Oct 14 13:05:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:05:41 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> Message-ID: <20001014130541.F12812@xs4all.nl> On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote: > On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: [ DEC threads (OSF1) are not automatically detected, causing a compilation failure on such systems ] > > It would be nice if configure were smart enough to figure this out! > ... we can easily add that. See the attached patch ... Charles, if you get a chance to test this patch before monday, please do. I think it's important to try and get the thread compiling right, now that threads are on by default. This is going to create a lot of confusion with OSF-users that don't read the README all the way through! If you can't test it, perhaps we can apply it before 2.0 none the less. I personally think there are more systems calling themselves OSF1 that do need the -threads argument than there are that don't need it (if any) and the patch only adds -threads if threads are really enabled. (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be conservative.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Oct 14 13:35:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 14 Oct 2000 13:35:29 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Thomas Wouters wrote: > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > in the case stmt, to be conservative.) are there really any others? (that "1" is part of the original name, it's not a version number) From thomas at xs4all.net Sat Oct 14 13:28:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:28:20 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Message-ID: <20001014132820.Y12776@xs4all.nl> On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote: > Thomas Wouters wrote: > > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > > in the case stmt, to be conservative.) > are there really any others? Don't know. That's why I asked it :) > (that "1" is part of the original name, it's not a version number) Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1) in others: case $ac_sys_system in OSF1) CC=cc without_gcc=;; versus if test -z "$LDSHARED" then case $ac_sys_system/$ac_sys_release in [..] OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; [..] I guess the OSF*) action is specific enough (most likely to lead to errors on systems that call themselves, say, OSFORME) that we don't really have to worry about it right now. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sat Oct 14 14:32:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT) Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Lars Marius Garshol writes: > Here are a couple from an internal seminar I recently gave on this. I > could make the slides available as well, if there is interest. Could we include this in Demos/xml/ ? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Sat Oct 14 15:08:30 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001014130541.F12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov> Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > think it's important to try and get the thread compiling right, now that > threads are on by default. OK, I just tried it and it worked for me. (I only tested it on one OSF/1 system, but I suppose that's better than nothing). Thanks for patching this, I think you are right that it will save a lot of confusion (at least for that handful of people running this OS!) From m.favas at per.dem.csiro.au Sat Oct 14 15:11:11 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sat, 14 Oct 2000 21:11:11 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au> [Huaiyu Zhu, replying to Tim...] >It is interesting to know that someone actually relies on >OverflowError to detect underflow. But why not let them continue that >as well, given that all of these would be available in the future >anyway? I think I'm the someone referred to - but I _don't_ rely on this at all. I was reporting that, on my platforms, the behaviour of exp(-666) did _not_ change between 1.5.2 and 2.0, both of which raised an OverflowError (for underflow). I prefer Tim's change so that exp(-huge) will produce 0, and that exp(huge) produces an OverflowError, even though this changes the behaviour when moving from 1.5.2 to 2.x... [Huaiyu Zhu again] >Before that happens, why consistency accross platform is deemed more >important than consistency accross releases? My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it? :-) In spite of the smiley, I'd have to say (politely) "Rubbish!". One of the many attractions of Python to me _is_ cross-platform consistency - more so than up-version consistency. In my previous life as a computational chemist I spent a lot of effort in writing code that was portable - indeed, we developed a pre-processor language (which spat out FORTRAN) to try to more easily handle OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first came up against IEEE stuff in the early 80's, and I agree with Tim - as a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I was used to my code stopping when I divided by zero - it usually indicated a coding or algorithmic error. When (if) Python supports access to masking/unmasking 754 exceptions, that'll be good - in the meantime, from my POV, the steps taken by Tim/Guido are in the right direction. -- Mark Favas - m.favas at per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA From thomas at xs4all.net Sat Oct 14 19:12:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 19:12:34 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov> Message-ID: <20001014191234.G12812@xs4all.nl> On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > > think it's important to try and get the thread compiling right, now that > > threads are on by default. > OK, I just tried it and it worked for me. (I only tested it on one > OSF/1 system, but I suppose that's better than nothing). Yeah, I already tested it on the ther platforms I have. Not really necessary, since the patch is really tiny and can only really be a problem on platforms that have a 'system name' that matches 'OSF*' but don't need '-threads'. Thanx for testing that it works, though. Jeremy, are you OK on checking this autoconf change in ? Is it in time for 2.0-final ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sun Oct 15 00:11:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sat, 14 Oct 2000 18:11:30 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56 In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net> Message-ID: Greg, Do you intend these most recent changes to be included in 2.0 final on Monday? Just giving you a heads up in case you didn't realize what the release schedule is. The only changes we should be making are critical bugs fixes for mainline code (non-demo, tools, etc.). Also, there is some code in the top-level of the CVS repository that hasn't been put in the previous source tarballs; at least the C code for the Windows installer, but maybe other things as well. Can you recommend how to include this in the source distribution for the final release? We'd like to include *all* the source code for distutils. Jeremy From barry at scottb.demon.co.uk Sun Oct 15 01:28:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 15 Oct 2000 00:28:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000001c03636$7f5b5600$060210ac@private> > -----Original Message----- > From: Tim Peters [mailto:tim_one at email.msn.com] > Sent: 08 October 2000 20:29 > To: Barry Scott; PythonDev; Python list > Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers > > > [Barry] > > Two requests: > > > > 1. Can you ship the .PDB files for the debug images so devo's > > do not need to build the python sources to debug extensions. > > And Yes I know the .ZIP will be huge. If you want a > > compromise only include the .PDB for python20_d.dll. > > Sure! Most .pdb files are highly compressible, and the zip size hit isn't > anything to worry about. Thanks > > > 2. Place the files into libs, pyd etc dirs. I had to extract > > the groups into the right places which is a bit tedious > > and error prone. > > No. If you want a directory structure that doesn't match the actual build > directory structure, I can't read your mind, and have no reason to believe > that the specific artificial structure you have in mind is of use to anyone The structure I refer to is the one used by the Python Windows installer. > but you. Don't be so helpless : write a tiny Python script to move I comment not because I'm lazy but because it seemed that every developer would need to reorganise the files. > the files where you want them after unpacking. What I upload will be an > exact image of the build directory structure. Most feedback I've gotten is > that people want exactly that, because they *want* to compile Python I'd not thought of that. MY assumption was that I build the release windows code against the files installed by the python windows installer. And that the debug settings would logically point into the same structure. > themselves and just want to avoid jumping thru all the snaky hoops needed to > compile the 3rd-party subprojects (from _tkinter to zlib). > > alphabetically y'rs - tim Barry From MarkH at ActiveState.com Sun Oct 15 01:53:03 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Sun, 15 Oct 2000 10:53:03 +1100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry] > I'd not thought of that. My either. I must admit mild surprise at that. If people want the debug files in the same tree as the build tree, it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries? My experience with people wanting debug binaries is that they either don't want to, or can not build. When people need debug binaries, they go one of 2 routes - try and find pre-built debugs, or build them themselves. I can't see when people ever do both. For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different. Just-FWIW ly, Mark. From nick at nickbower.com Sun Oct 15 07:09:26 2000 From: nick at nickbower.com (Nick Bower) Date: Sun, 15 Oct 2000 05:09:26 GMT Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <20001015.5092600@cricket.> > Does anyone know what other array-oriented languages use? I know what > MATLAB does: I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's Space Science Ceter is split down the middle between this and MatLab, but python/numpy is definitely on the increase). As you can see from results below, like MatLab over/under-flows in IDL are reported but do not stop execution. This is the best (only) possible scenario for an interactive arrays and visualization environment. IDL> print, exp(-777) 0.00000 % Program caused arithmetic error: Floating underflow IDL> print, exp(777) Inf % Program caused arithmetic error: Floating overflow IDL> print, sqrt(-1) -NaN % Program caused arithmetic error: Floating illegal operand IDL> print, 54/0 54 % Program caused arithmetic error: Integer divide by 0 From martin at loewis.home.cs.tu-berlin.de Sun Oct 15 17:57:18 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 15 Oct 2000 17:57:18 +0200 Subject: [Python-Dev] Mandrake vs glibc Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de> > So, if David's report is correct, and best I understand it you were > all using 7.1 too with at least some level of optimization, it's A > Mystery why CVS test_math.py succeeds on that system (its new > math.sqrt(-1) test would probably fail; its new math.exp(+huge) test > would almost certainly fail). I'm anal enough about this stuff that > I'd try to figure out why if I had a Mandrake system, but in the > cosmic scheme of things I doubt it's important enough for anyone > else to burn time on. Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I get Python 2.0 (#104, Oct 15 2000, 15:47:19) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> math.exp(800) inf >>> math.exp(-800) 0.0 It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That is implemented as _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_; in this version of glibc, which in turn changes the behaviour of double __exp(double x) /* wrapper exp */ { double z; z = __ieee754_exp(x); if(_LIB_VERSION == _IEEE_) return z; if(__finite(x)) { if(x>o_threshold) return __kernel_standard(x,x,6); /* exp overflow */ else if(x > Can you recommend how to include this in the source distribution for > the final release? Even though I was not asked, I still answer :-) I think having the source code for the installer is essential, just so that people won't get frightened by the potential for a Trojan Horse in front of the gates (or, rather, the windows?-) I'd put the installer (i.e. all of distutils/misc except for get_metadata.py) into Tools/wininst. (I'd actually preferred to see the wininst sources in distutils in a different directory as well). In case you need some descripting text as well, here's my proposal. In Tools/README, maybe it would be wininst Sources for Windows installer of distutils.command.bdist_wininst. For Tools/wininst/README, see the text below. One complication is that invoking bdist_wininst as a program will regenerate the module, but it expects the installer binary in ../../misc/wininst.exe; I'm not sure whether it is worth the effort to change that for the Python distribution. Regards, Martin THE WINDOWS INSTALLER ===================== The distutils support the command bdist_wininst, which will produce a windows auto-installing executable using the information in the setup function. The executable consists of a user interface program, concatenated with a zip archive of the distributed files. This directory contains the sources of the user interface program. The bdist_wininst command itself does not need the sources, instead, it has an embedded copy of the installer binary file. If the installer program is modified, bdist_wininst.py must be updated by invoking it as a program (i.e. "python bdist_wininst.py") Building the installer ---------------------- To build the installer, you need a copy of Microsoft Visual C++ version 6; the project file is wininst.dsp. You may also use the executable compressor UPX, which is available from http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is not strictly required - it just reduces the size of the installation program itself. Using the bdist_wininst command ------------------------------- To create an binary distribution of your package for Windows, simply invoke "python setup.py bdist_wininst" in your package directory. If your package does not contain C modules, you may invoke this command on any system; if it does contain C modules, bdist_wininst will need the C compiler used to build Python (typically MSVC++). It will not need MSVC++ or UPX to build the setup program. To build the ZIP file contained in the installer, bdist_wininst will first try an external zip program (zip.exe) that understands the -rq option, such as Info-ZIP (http://www.info-zip.org/pub/infozip/Zip.html). If no such program is found, it will next try the zipfile module, which is available if Python was build with zlib support. From larsga at garshol.priv.no Sun Oct 15 19:52:16 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 15 Oct 2000 19:52:16 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> References: <14823.43218.337621.157021@beluga.mojam.com> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Message-ID: * Lars Marius Garshol | | Here are a couple from an internal seminar I recently gave on this. | I could make the slides available as well, if there is interest. * Fred L. Drake, Jr. | | Could we include this in Demos/xml/ ? Sure. Do whatever you like with them. --Lars M. From hinsen at cnrs-orleans.fr Sun Oct 15 21:04:27 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun, 15 Oct 2000 21:04:27 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13 Oct 2000 18:22:28 -0700) References: <39E7B554.29A168E3@jps.net> Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr> > I've come to Python from MATLAB for numerics, and I really appreciated > MATLAB's way of handling all this. I don't think MATLAB has true 754 MATLAB is fine for simple interactive data processing, and its behaviour is adapted to this task. I don't think anyone would use MATLAB for developing complex algorithms, its programming language isn't strong enough for that. Python is, so complex algorithms have to be considered as well. And for that kind of application, continuing a calculation with Infs and NaNs is a debugging nightmare. > I have not yet heard a decent response to the question of what to do > when a single value in a large array is bad, and causes an exception. I'd like to have at least the option of raising an exception in that case. Note that this is not what NumPy does today. > >> sqrt(-1) > ans = > 0 + 1.0000i > > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? For the same reason that makes 2/3 return zero instead of a float division result. Like C or Fortran, Python treats integers, floats, and complex numbers as different data types. And the return type of a function should depend only on the types, but not the values, of its parameters (for consistency, not because of any implementational limitation). So sqrt(a) for a of type float can either always return a float (math, Numeric) and crash for negative arguments, or always return a complex (cmath). The "right" solution, in my opinion, would be to have a single "number" type of which integers, float, and complex numbers are simply different internal representations. But such a change cannot be introduced without breaking a lot of code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tim_one at email.msn.com Sun Oct 15 21:22:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 15:22:09 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry Scott] > I'd not thought of that. [Mark Hammond] > My either. I must admit mild surprise at that. Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree. > If people want the debug files in the same tree as the build tree, Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count. > it seems all they are trying to do is avoid the initial huge build. If > they intend compiling, why are they asking for the binaries? The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours. > My experience with people wanting debug binaries is that they either don't > want to, or can not build. If they can't build, it's hard to take their claim to be developing extension modules seriously . > ... > For the last year or so, I have been making Debug builds of win32all > available to registered users. This has always been made available in > the "install" structure - quite a bit different than the source/build > structure. I've never been asked for anything different. Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over-ly y'rs - tim From tim_one at email.msn.com Sun Oct 15 22:35:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 16:35:27 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr> Message-ID: [cbarker at jps.net] >> I've come to Python from MATLAB for numerics, and I really appreciated >> MATLAB's way of handling all this. I don't think MATLAB has true 754 ... [Konrad Hinsen] > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. A non-constructive (because futile) speculation: the first time I saw what 754 was intending to do, my immediate reaction was "hmm -- the exponent field is too narrow!". With a max (double) val in the ballpark of 1e300, you get an infinity as soon as you square something as small as 1e150, and once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and Inf/Inf). The dynamic range for 754 singles is much smaller still. There's no doubt about Cray arithmetic being hard to live with, but while Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's exponent field (vs. 11 for 754). As a result, overflows were generally a non-issue on Cray boxes, and *nobody* complained (in my decade there) about Cray HW raising a fatal exception if one occurred. In return, you got only 48 bits of precision (vs. 53 for 754). But, for most physical problems, how accurate are the inputs? 10 bits on a good day, 20 bits on a great day? Crays worked despite their sloppy numerics because, for most problems to which they were applied, they carried more than twice the precision *and* dynamic range than the final results needed. >> I have not yet heard a decent response to the question of what to do >> when a single value in a large array is bad, and causes an exception. I'd usually trace back and try to figure out how it got "bad" to begin with ... > I'd like to have at least the option of raising an exception in that > case. Note that this is not what NumPy does today. Does NumPy use the fpectl module? I suppose not. LLNL contribued that code, but we hear very little feedback on it. It arranges to (in platform-dependent ways) convert the 754 overflow, divide-by-0 and invalid-operation signals into Python exceptions. In core Python, this is accomplished at the extraordinary expense of doing a setjmp before, and a function call + double->int conversion after, every single fp operation. A chief problem is that SIGFPE is the only handle C gives us on fp "errors", and the C std does not allow returning from a SIGFPE handler (the result of trying to is undefined, and indeed varies wildly across platforms); so if you want to regain control, you have to longjmp out of the handler. The NumPy implementation could use the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros to brackete entire array operations, though, and so pay for the setjmp etc only once per array op. This is difficult stuff, but doable. >> >> sqrt(-1) >> ans = >> 0 + 1.0000i >> >> Hey! I like that! Python is dynamic, why can't we just get the actual >> answer to sqrt(-1), without using cmath, that always returns a complex ? > For the same reason that makes 2/3 return zero instead of a float > division result. Like C or Fortran, Python treats integers, floats, > and complex numbers as different data types. You know I'm in general agreement with you on this one, but I have to draw a distinction here: Guido thinks that 2/3 returning 0 was a design mistake, but not that math.sqrt(-1) raising an exception is a mistake. Most Python users won't know what to do with a complex number, so it's "an error" to them. I would like to view this in P3K (if not earlier) as being akin to 754 exceptions: some people are delighted to have 1e300**2 return +Inf, while others want to see OverflowError instead, and still others want to see +Inf *and* have a sticky flag set saying "an overflow occurred". We could treat f(x) (for f == sqrt and everything else) the same way wrt to a new ComplexResultFromNonComplexInputsError: define "non-stop" complex results, let the user choose whether to do nonstop or raise an exception, and a supply a sticky flag saying whether or not any complex results were generated from non-complex inputs. > ... > The "right" solution, in my opinion, would be to have a single > "number" type of which integers, float, and complex numbers are simply > different internal representations. But such a change cannot be > introduced without breaking a lot of code. The current distinction between ints and longs (unbounded ints) should also get swallowed by this. A way to get from here to there is especially irksome at the C API level, since, e.g., many C API functions pass Python ints as C longs directly. A smaller number pass Python floats as C doubles directly. it's-wonderful-that-p3k-will-solve-everything-ly y'rs - tim From MarkH at ActiveState.com Mon Oct 16 01:49:19 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 10:49:19 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. Message-ID: I just struck this, and wonder if it is intentional: * Adding 2 buffer objects together yields a string. Fair enough. * Adding a buffer and a string yields a type error! Eeek. This yields the following strange behaviour: >>> a=buffer('a') >>> a+a 'aa' >>> a+a+a Traceback (innermost last): File "", line 1, in ? TypeError: cannot add type "buffer" to string >>> That doesnt seem correct to me? Mark. From rob at hooft.net Mon Oct 16 07:39:13 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18 In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net> References: <200010091242.FAA02671@slayer.i.sourceforge.net> Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl> Just checking my E-mail coming back from holidays, I see: diff -C2 -r1.17 -r1.18 *** calendar.py 2000/08/30 14:01:28 1.17 --- calendar.py 2000/10/09 12:42:04 1.18 *************** *** 55,60 **** def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2 and no funny (non-leap century) years.""" ! return (y2+3)/4 - (y1+3)/4 def weekday(year, month, day): --- 55,62 ---- def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2.""" ! y1 -= 1 ! y2 -= 1 ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) def weekday(year, month, day): I am worried about the use of "-=" here. The code basically says: "if the arguments are mutable numeric types, I'd like to modify them in place". In c.l.py it has been stressed multiple times that "-=" is not the same as "= -". I think this is clearly a place where "= -" is preferable over "-=". Even though you might think people will always call this with python integers, you can never be sure enough. Rob -- ===== rob at hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From pf at artcom-gmbh.de Mon Oct 16 09:23:11 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST) Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext) In-Reply-To: Message-ID: Hi Ulf, Ulf Betlehem: [...] > ok, I compiled 2.0c1 and tried gettext. Now, there seems to be > a bug in the "normalize and expand" code that can prevent > gettext from finding an existing .mo file. The normalization > is done using a dictionary and therefore the languages get > reordered (as dict keys do). Later when selecting language the > function returns None if 'C' happens to come before the > required languages. I've included a patch to fix this. Your patch looks good to me. Thanks for taking the time to test and contributing the patch. I've submitted your bug report and your patch to sourceforge. See: https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470 https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 Regards, Peter P.S.: Cc to python-dev -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal at lemburg.com Mon Oct 16 09:50:22 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 09:50:22 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAB33E.35B72EA4@lemburg.com> Mark Hammond wrote: > > I just struck this, and wonder if it is intentional: > > * Adding 2 buffer objects together yields a string. Fair enough. > * Adding a buffer and a string yields a type error! Eeek. This just seems plain wrong. Adding two buffers should yield a new buffer -- in the long run, buffers should replace strings wrt to holding binary data. If not even buffers themselves implement this idea, I don't see any perspective for ever getting there... > This yields the following strange behaviour: > > >>> a=buffer('a') > >>> a+a > 'aa' > >>> a+a+a > Traceback (innermost last): > File "", line 1, in ? > TypeError: cannot add type "buffer" to string > >>> > > That doesnt seem correct to me? Neither to me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller at ion-tof.com Mon Oct 16 11:14:49 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Mon, 16 Oct 2000 11:14:49 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> IMHO, the whole buffer interface is weird. - Only the Buffer_FromObject() function is exposed to the python level (as buffer()), the other functions are missing. This means that one could only use the buffer interface in extension modules. Was this intentional? - No way a python class can expose the buffer interface - There is a bug in the buffer interface (which prevented recently that I could use buffer objects at all, I had to implement my own) PyObject *base = PyBuffer_New(100); PyObject *buffer = PyBuffer_FromObject(base, 0, 100); Py_DECREF(base); After this code is executed, buffer points to deallocated memory (because buffer does not hold a reference to base anymore). (Guido classified this as a wish, but at least it contradicts the documentation) Thomas From MarkH at ActiveState.com Mon Oct 16 11:38:26 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 20:38:26 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> Message-ID: > IMHO, the whole buffer interface is weird. I'm not sure that weird is the correct term for your points (it is for my spelling, though :-) > - Only the Buffer_FromObject() function is exposed to the ... > - No way a python class can expose the buffer interface These are simply oversights, I would suggest. Nothing in the design prevents this. > - There is a bug in the buffer interface (which > prevented recently that I could use buffer objects > at all, I had to implement my own) This looks like quite a simple bug. bufferobject.c, line 77: /* if the base object is another buffer, then "deref" it */ if ( PyBuffer_Check(base) ) base = ((PyBufferObject *)base)->b_base; if the condition was changed to: if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base) Then I think this one would be solved? A more serious design flaw is the one Fredrik pointed out quite some time ago. If you have (eg.) an "array" object and query for its buffer, life is good. If the array then resizes itself, your pointer is now dangling. The simplest solution to this is probably to simply define the lifetimes of these pointers as very very short ;-) Mark. From mal at lemburg.com Mon Oct 16 12:14:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 12:14:46 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAD516.7EA34C20@lemburg.com> Mark Hammond wrote: > [Problems with the buffer interface] > If you have (eg.) an "array" object and query for its buffer, life is > good. If the array then resizes itself, your pointer is now dangling. The > simplest solution to this is probably to simply define the lifetimes of > these pointers as very very short ;-) ...or disable the buffer interface for mutable types altogether ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Oct 16 15:01:26 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 06:01:26 -0700 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200 References: <39EAB33E.35B72EA4@lemburg.com> Message-ID: <20001016060126.X347@lyra.org> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > Mark Hammond wrote: >... > > This yields the following strange behaviour: > > > > >>> a=buffer('a') > > >>> a+a > > 'aa' > > >>> a+a+a > > Traceback (innermost last): > > File "", line 1, in ? > > TypeError: cannot add type "buffer" to string > > >>> > > > > That doesnt seem correct to me? > > Neither to me. It is caused by the non-commutative aspect of Python types. You end up with a string, and that type doesn't know how to add a buffer to itself. Ideally, it might be nice to allow a string to append any object that exports the buffer-interface. But when somebody goes and writes "abc"+my_array ... hoo boy, will we hear complaints. The alternative is to allow the buffer to resolve the type conflict and do the appending within the buffer code. Of course, the choice of returning a string (from buf+buf) rather than a buffer was arguably the wrong choice. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Mon Oct 16 16:30:44 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 09:30:44 -0500 Subject: [Python-Dev] mutable integers In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200." <14826.38017.352907.716552@temoleh.chem.uu.nl> References: <200010091242.FAA02671@slayer.i.sourceforge.net> <14826.38017.352907.716552@temoleh.chem.uu.nl> Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com> Rob W. W. Hooft: > Just checking my E-mail coming back from holidays, I see: [...] > def leapdays(y1, y2): > """Return number of leap years in range [y1, y2). > ! Assume y1 <= y2.""" > ! y1 -= 1 > ! y2 -= 1 > ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) > > I am worried about the use of "-=" here. The code basically says: "if the > arguments are mutable numeric types, I'd like to modify them in place". In > c.l.py it has been stressed multiple times that "-=" is not the same as > "= -". I think this is clearly a place where "= -" is preferable over > "-=". Even though you might think people will always call this with > python integers, you can never be sure enough. Hmm... Your fear sounds a little paranoid for this particular case, but I can't say that I totally disagree in general. This is definitely something to keep in mind when writing polymorphic functions for which a NumPy array might be an acceptable input argument. I don't think it's worth checking in a patch in this case. --Guido van Rossum (home page: http://www.python.org/~guido/) From hinsen at cnrs-orleans.fr Mon Oct 16 17:52:43 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 16 Oct 2000 17:52:43 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr> > > I'd like to have at least the option of raising an exception in that > > case. Note that this is not what NumPy does today. > > Does NumPy use the fpectl module? I suppose not. LLNL contribued that No. Perhaps it should, but it doesn't make sense unless fpectl works on a large number of platforms. I confess I have never looked at it. I want my code to be portable, so I don't even consider using packages that aren't. > > For the same reason that makes 2/3 return zero instead of a float > > division result. Like C or Fortran, Python treats integers, floats, > > and complex numbers as different data types. > > You know I'm in general agreement with you on this one, but I have to draw a > distinction here: Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Well, that would be a good occasion to learn about complex numbers! I remember having learned about generalized inverses by using APL in high school (in a very similar way: I was amazed that it could invert non-square matrices), and that turned out to be very useful knowledge later on. Perhaps that's a topic for the EDU-SIG... Anyway, I don't care what math.sqrt(-1) does, but I would definitely prefer Numeric.sqrt(-1) to return a complex result. And I think that someone who uses NumPy has probably heard about complex numbers. > I would like to view this in P3K (if not earlier) as being akin to > 754 exceptions: some people are delighted to have 1e300**2 return +Inf, > while others want to see OverflowError instead, and still others want to see > +Inf *and* have a sticky flag set saying "an overflow occurred". We could > treat f(x) (for f == sqrt and everything else) the same way wrt to a new > ComplexResultFromNonComplexInputsError: define "non-stop" complex results, > let the user choose whether to do nonstop or raise an exception, and a > supply a sticky flag saying whether or not any complex results were > generated from non-complex inputs. There is, however, one difference: in properly debugged production code, there should be no overflow situations, so it doesn't matter much how they are treated. Complex number can (do!) occur in production code, but there could also be production code relying on exceptions for sqrt(-1) (e.g. for input error checking). Therefore a program using several libraries might be impossible to run with either setting. Since this concerns only the math module, I'd prefer to keep separate module versions for the two cases, which can be used in parallel. > > The "right" solution, in my opinion, would be to have a single > > "number" type of which integers, float, and complex numbers are simply > > different internal representations. But such a change cannot be > > introduced without breaking a lot of code. > > The current distinction between ints and longs (unbounded ints) should also > get swallowed by this. A way to get from here to there is especially > irksome at the C API level, since, e.g., many C API functions pass Python > ints as C longs directly. A smaller number pass Python floats as C doubles > directly. I don't see the problem in that direction, it's rather C API functions that *return* numbers in C data types that would be difficult to adapt. But then, why should be C API not be allowed in P3K? it's-wonderful-that-anything-may-be-changed-in-p3k'ly Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From guido at python.org Mon Oct 16 20:08:07 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:08:07 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST." <20001016060126.X347@lyra.org> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> The buffer interface is one of the most misunderstood parts of Python. I believe that if it were PEPped today, it would have a hard time getting accepted in its current form. There are also two different parts that are commonly referred by this name: the "buffer API", which is a C-only API, and the "buffer object", which has both a C API and a Python API. Both were largely proposed, implemented and extended by others, and I have to admit that I'm still uneasy with defending them, especially the buffer object. Both are extremely implementation-dependent (in JPython, neither makes much sense). The Buffer API -------------- The C-only buffer API was originally intended to allow efficient binary I/O from and (in some cases) to large objects that have a relatively well-understood underlying memory representation. Examples of such objects include strings, array module arrays, memory-mapped files, NumPy arrays, and PIL objects. It was created with the desire to avoid an expensive memory-copy operation when reading or writing large arrays. For example, if you have an array object containing several millions of double precision floating point numbers, and you want to dump it to a file, you might prefer to do the I/O directly from the array's memory buffer rather than first copying it to a string. (You lose portability of the data, but that's often not a problem the user cares about in these cases.) An alternative solution for this particular problem was consdered: object types in need of this kind of efficient I/O could define their own I/O methods, thereby allowing them to hide their internal representation. This was implemented in some cases (e.g. the array module has read() and write() methods) but rejected, because a simple-minded implementation of this approach would not work with "file-like" objects (e.g. StringIO files). It was deemed important that file-like objects would not place restrictions on the kind of objects that could interact with them (compared to real file objects). A possible solution would have been to require that each object implementing its own read and write methods should support both efficient I/O to/from "real" file objects and fall-back I/O to/from "file-like" objects. The fall-back I/O would have to convert the object's data to a string object which would then be passed to the write() method of the file-like object. This approach was rejected because it would make it impossible to implement an alternative file object that would be as efficient as the real file object, since large object I/O would be using the inefficient fallback interface. To address these issues, we decided to define an interface that would let I/O operations ask the objects where their data bytes are in memory, so that the I/O can go directly to/from the memory allocated by the object. This is the classic buffer API. It has a read-only and a writable variant -- the writable variant is for mutable objects that will allow I/O directly into them. Because we expected that some objects might have an internal representation distributed over a (small) number of separately allocated pieces of memory, we also added the getsegcount() API. All objects that I know support the buffer API return a segment count of 1, and most places that use the buffer API give up if the segment count is larger; so this may be considered as an unnecessary generalization (and source of complexity). The buffer API has found significant use in a way that wasn't originally intended: as a sort of informal common base class for string-like objects in situations where a char[] or char* type must be passed (in a read-only fashion) to C code. This is in fact the most common use of the buffer API now, and appears to be the reason why the segment count must typically be 1. In connection with this, the buffer API has grown a distinction between character and binary buffers (on the read-only end only). This may have been a mistake; it was intended to help with Unicode but it ended up not being used. The Buffer Object ----------------- The buffer object has a much less clear reason for its existence. When Greg Stein first proposed it, he wrote: The intent of this type is to expose a string-like interface from an object that supports the buffer interface (without making a copy). In addition, it is intended to support slices of the target object. My eventual goal here is to tweak the file object to support memory mapping and the buffer interface. The buffer object can then return slices of the file without making a new copy. Next step: change marshal.c, ceval.c, and compile.c to support a buffer for the co_code attribute. Net result is that copies of code streams don't need to be copied onto the heap, but can be left in an mmap'd file or a frozen file. I'm hoping there will be some perf gains (time and memory). Even without some of the co_code work, enabling mmap'd files and buffers onto them should be very useful. I can probably rattle off a good number of other uses for the buffer type. I don't think that any of these benefits have been realized yet, and altogether I think that the buffer object causes a lot of confusion. The buffer *API* doesn't guarantee enough about the lifetime of the pointers for the buffer *object* to be able to safely preserve those pointers, even if the buffer object holds on to the base object. (The C-level buffer API informally guarantees that the data remains valid only until you do anything to the base object; this is usually fine as long as you don't release the global interpreter lock.) The buffer object's approach to implementing the various sequence operations is strange: sometimes it behaves like a string, sometimes it doesn't. E.g. a slice returns a new string object unless it happens to address the whole buffer, in which case it returns a reference to the existing buffer object. It would seem more logical that a subslice would return a new buffer object. Concatenation and repetition of buffer objects are likewise implemented inconsistently; it would have been more consistent with the intended purpose if these weren't supported at all (i.e. if none of the buffer object operations would allocate new memory except for buffer object headers). I would have concluded that the buffer object is entirely useless, if it weren't for some very light use that is being made of it by the Unicode machinery. I can't quite tell whether that was done just because it was convenient, or whether that shows there is a real need. What Now? --------- I'm not convinced that we need the buffer object at all. For example, the mmap module defines a sequence object so doesn't seem to need the buffer object to help it support slices. Regarding the buffer API, it's clearly useful, although I'm not convinced that it needs the multiple segment count option or the char vs. binary buffer distinction, given that we're not using this for Unicode objects as we originally planned. I also feel that it would be helpful if there was an explicit way to lock and unlock the data, so that a file object can release the global interpreter lock while it is doing the I/O. But that's not a high priority (and there are no *actual* problems caused by the lack of such an API -- just *theoretical*). For Python 3000, I think I'd like to rethink this whole mess. Perhaps byte buffers and character strings should be different beasts, and maybe character strings could have Unicode and 8-bit subclasses (and maybe other subclasses that explicitly know about their encoding). And maybe we'd have a real file base class. And so on. What to do in the short run? I'm still for severely simplifing the buffer object (ripping out the unused operations) and deprecating it. --Guido van Rossum (home page: http://www.python.org/~guido/) From cbarker at jps.net Mon Oct 16 19:38:11 2000 From: cbarker at jps.net (Chris Barker) Date: Mon, 16 Oct 2000 10:38:11 -0700 Subject: [Python-Dev] Re: numpy, overflow, inf, ieee, and rich comparison References: Message-ID: <39EB3D03.A00C78B6@jps.net> > >> I have not yet heard a decent response to the question of what to do > >> when a single value in a large array is bad, and causes an exception. > > I'd usually trace back and try to figure out how it got "bad" to begin with And from Konrad Hinsen >I'd like to have at least the option of raising an exception in that >case. Note that this is not what NumPy does today. Exactly. This was Huaiyu's point. The problem is that for your code to be usable for folks other than yourself, you'd have to have a lot of checks in there, and essentially revert to elementwise code, which would kill you. With the addition of the occasional "isnan" and something like Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of A are NaNs) you could set up your code to raise an exception in the middle of computation. If, on the other hand the Code definiately raises an exception, than you are stuck with a lot of elementwise coding. > over/under-flows in IDL are reported but do > not stop execution. This is the best (only) possible scenario for an > interactive arrays and visualization environment. Exactly!!! ("the best (only) possible scenario" part) > IDL> print, 54/0 > 54 > % Program caused arithmetic error: Integer divide by 0 This, however, is wierd!! 54/0 == 54 ??? I'd much rather see a NaN or Inf here! > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. People do some pretty complex algorith develpment with MATLAB. I'm also no so sure about "continuing a calculation with Infs and NaNs is a debugging nightmare" I'm don't think it's any more of a nighmare than having your calculation on an entire array stop because of one Inf. It's just a different trade off. Sprinkle a few "isnan"'s in there and and you can get the behaviour you want, while not forcing it on all calculations. Of course, the best option is to have it switchable, but that may prove to be very difficult. Are people doing the kind of numeric programming with "complex algorithms" using Python that Konrad refers to? More importantly, how many people? > Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Guido's philosophy is clearly that Python defaults should be geared to "Most Python users". I agree, and as I wrote in an earlier post, the only users for whom the "exception raising only" option is best are the users Konrad refers to as writing "complex algorithms". I would argue that those users are few, and the group most able to deal with a less-that-optimum system. Maybe we can have true 754 compliance in Py3k, and we can all be happy!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From effbot at telia.com Mon Oct 16 19:47:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 16 Oct 2000 19:47:55 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid> guido wrote: > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. agreed. (does this mean that we're in post-2.0 mode? ;-) From mal at lemburg.com Mon Oct 16 19:42:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 19:42:15 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <39EB3DF7.459A1BC1@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > > Mark Hammond wrote: > >... > > > This yields the following strange behaviour: > > > > > > >>> a=buffer('a') > > > >>> a+a > > > 'aa' > > > >>> a+a+a > > > Traceback (innermost last): > > > File "", line 1, in ? > > > TypeError: cannot add type "buffer" to string > > > >>> > > > > > > That doesnt seem correct to me? > > > > Neither to me. > > It is caused by the non-commutative aspect of Python types. You end up with > a string, and that type doesn't know how to add a buffer to itself. The problem is that buffer() objects coerce to strings in the first place... they should return new buffer objects instead of strings -- then we wouldn't have the above problems. > ... > Of course, the choice of returning a string (from buf+buf) rather than a > buffer was arguably the wrong choice. Right :-/ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Mon Oct 16 20:51:51 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:51:51 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200." <00f601c03799$39f2c7b0$3c6340d5@hagrid> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com> > guido wrote: > > What to do in the short run? I'm still for severely simplifing the > > buffer object (ripping out the unused operations) and deprecating it. > > agreed. > > (does this mean that we're in post-2.0 mode? ;-) Yes :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Oct 16 20:03:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 20:03:15 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <39EB42E3.B76F37EB@lemburg.com> Guido van Rossum wrote: > ... > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. I used the buffer object since I thought that buffer() objects were to replace strings as container for binary data. The buffer object wraps a memory buffer into a Python object for the purpose of decoding it into Unicode. 8-bit string objects would have worked just as well... > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. It would be nice to have an object for "copy by reference" rather than "malloc + copy". This would be useful for strings (e.g. to access substrings of a large string), Unicode and binary data. The buffer object almost does this... it would only have to stick to always returning buffer objects in coercion, slicing etc. I also think that the name "buffer" is misleading, since it really means "reference" in the context published by the Python interface (the C API also has a way of defining new malloc areas and referencing them through the buffer interface, but that is not published in Python). The other missing data type in Python is one for binary data. Currently, string objects are in common use for this kind of data. The problems with this are obvious: in some contexts strings are expected to contain text data in other binary data. When the two meet there's great confusion. I'd suggest either making arrays the Python standard type for holding binary data, or creating a completely new type (this should then be called something like "buffer"). > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. True. > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). How about adding a generic low-level lock type for these kind of tasks. The interpreter could be made aware of these types to allow a much more fine-grained lock mechanism, e.g. to check for acquired locks of certain objects only. > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. Great... but 3000 is a long way ahead :-( > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. Since it isn't all that known anyway, how about streamlining the buffer object implementations of the various protocols and removing the distinction between "s" and "t" ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jcollins at endtech.com Mon Oct 16 22:22:22 2000 From: jcollins at endtech.com (Jeff Collins) Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: All this just when I was getting accustomed to the thought of using buffer objects in the Palm Python port... I need buffer objects for many the same reasons as Greg Stein originally proposed, as you quoted below. The on the Palm, the datamanager heap (used for permanent database storage and limited by the physical memory size) already stores the compiled python module. Directly referencing the data of objects like bytecodes and strings would greatly reduce the dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM or greater) requirements. Buffer objects seem like a natural choice. A record in a Palm database is just chunk of contiguous memory. Representing this chunk as a buffer object would allow the direct referencing it and any of it's slices. So, the co_code of code objects could be unmarshalled with a reference to permanent storage. Further, with the appropriate modifications, string objects (char *ob_sval?) could access this memory as well, though this additional optimization is probably only appropriate for small platforms. I think that buffer object is fairly important. They provide a mechanism for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), something that no other python object does, AFIAK. Perhaps clarifying the interface (such as the slice operator returning a buffer, as suggested below) and providing more hooks from Python for creating buffers (via newmodule, say) would be helpful. On Mon, 16 Oct 2000, Guido van Rossum wrote: > The buffer interface is one of the most misunderstood parts of > Python. I believe that if it were PEPped today, it would have a hard > time getting accepted in its current form. > > There are also two different parts that are commonly referred by this > name: the "buffer API", which is a C-only API, and the "buffer > object", which has both a C API and a Python API. > > Both were largely proposed, implemented and extended by others, and I > have to admit that I'm still uneasy with defending them, especially > the buffer object. Both are extremely implementation-dependent (in > JPython, neither makes much sense). > > The Buffer API > -------------- > > The C-only buffer API was originally intended to allow efficient > binary I/O from and (in some cases) to large objects that have a > relatively well-understood underlying memory representation. Examples > of such objects include strings, array module arrays, memory-mapped > files, NumPy arrays, and PIL objects. > > It was created with the desire to avoid an expensive memory-copy > operation when reading or writing large arrays. For example, if you > have an array object containing several millions of double precision > floating point numbers, and you want to dump it to a file, you might > prefer to do the I/O directly from the array's memory buffer rather > than first copying it to a string. (You lose portability of the data, > but that's often not a problem the user cares about in these cases.) > > An alternative solution for this particular problem was consdered: > object types in need of this kind of efficient I/O could define their > own I/O methods, thereby allowing them to hide their internal > representation. This was implemented in some cases (e.g. the array > module has read() and write() methods) but rejected, because a > simple-minded implementation of this approach would not work with > "file-like" objects (e.g. StringIO files). It was deemed important > that file-like objects would not place restrictions on the kind of > objects that could interact with them (compared to real file objects). > > A possible solution would have been to require that each object > implementing its own read and write methods should support both > efficient I/O to/from "real" file objects and fall-back I/O to/from > "file-like" objects. The fall-back I/O would have to convert the > object's data to a string object which would then be passed to the > write() method of the file-like object. This approach was rejected > because it would make it impossible to implement an alternative file > object that would be as efficient as the real file object, since large > object I/O would be using the inefficient fallback interface. > > To address these issues, we decided to define an interface that would > let I/O operations ask the objects where their data bytes are in > memory, so that the I/O can go directly to/from the memory allocated > by the object. This is the classic buffer API. It has a read-only > and a writable variant -- the writable variant is for mutable objects > that will allow I/O directly into them. Because we expected that some > objects might have an internal representation distributed over a > (small) number of separately allocated pieces of memory, we also added > the getsegcount() API. All objects that I know support the buffer API > return a segment count of 1, and most places that use the buffer API > give up if the segment count is larger; so this may be considered as > an unnecessary generalization (and source of complexity). > > The buffer API has found significant use in a way that wasn't > originally intended: as a sort of informal common base class for > string-like objects in situations where a char[] or char* type must be > passed (in a read-only fashion) to C code. This is in fact the most > common use of the buffer API now, and appears to be the reason why the > segment count must typically be 1. > > In connection with this, the buffer API has grown a distinction > between character and binary buffers (on the read-only end only). > This may have been a mistake; it was intended to help with Unicode but > it ended up not being used. > > The Buffer Object > ----------------- > > The buffer object has a much less clear reason for its existence. > When Greg Stein first proposed it, he wrote: > > The intent of this type is to expose a string-like interface from > an object that supports the buffer interface (without making a > copy). In addition, it is intended to support slices of the target > object. > > My eventual goal here is to tweak the file object to support > memory mapping and the buffer interface. The buffer object can > then return slices of the file without making a new copy. Next > step: change marshal.c, ceval.c, and compile.c to support a buffer > for the co_code attribute. Net result is that copies of code > streams don't need to be copied onto the heap, but can be left in > an mmap'd file or a frozen file. I'm hoping there will be some > perf gains (time and memory). > > Even without some of the co_code work, enabling mmap'd files and > buffers onto them should be very useful. I can probably rattle off > a good number of other uses for the buffer type. > > I don't think that any of these benefits have been realized yet, and > altogether I think that the buffer object causes a lot of confusion. > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. (The > C-level buffer API informally guarantees that the data remains valid > only until you do anything to the base object; this is usually fine as > long as you don't release the global interpreter lock.) > > The buffer object's approach to implementing the various sequence > operations is strange: sometimes it behaves like a string, sometimes > it doesn't. E.g. a slice returns a new string object unless it > happens to address the whole buffer, in which case it returns a > reference to the existing buffer object. It would seem more logical > that a subslice would return a new buffer object. Concatenation and > repetition of buffer objects are likewise implemented inconsistently; > it would have been more consistent with the intended purpose if these > weren't supported at all (i.e. if none of the buffer object operations > would allocate new memory except for buffer object headers). > > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. > > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. > > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. > > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). > > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. > > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > -- Jeffery D. Collins Sr. Software Developer Endeavors Technology, Inc. From akuchlin at cnri.reston.va.us Mon Oct 16 21:35:13 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Mon, 16 Oct 2000 15:35:13 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500 References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us> On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote: >> (does this mean that we're in post-2.0 mode? ;-) >Yes :-) Then this is a good time to ask what strategy will be followed post-2.0. Do you want a moratorium on massive checkins for a time while 2.0 shakes out, re-opening the tree for larger changes in a few months? Or will you try to live with a CVS branch for 2.0 and re-open the tree immediately? --amk From fdrake at beopen.com Mon Oct 16 21:37:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT) Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com> Andrew M. Kuchling writes: > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? I think a maintenance branch for 2.0.1 (or whatever) should be created as part of the release process in case we need a quick release for critical bug fixes. The tree should be re-opened after the release via a message to python-dev after the release is published. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Mon Oct 16 22:46:22 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 15:46:22 -0500 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400." <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com> > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? If we need to issue a patch release, we'll use a branch. That seems the only reasonable approach. The tree will be open for checkins as soon as 2.0 is released (tonight is looking good!), but I hope the people exercise some restraint and discuss their plans for significant checkins on the python-dev list first. A lot of things should probably be discussed in the form of PEPs too! --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Mon Oct 16 21:47:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 16 Oct 2000 15:47:05 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out ... It's not a great time to ask, as we're still balls-to-the-wall *building* the release and doing last-second checkins (things like NEWS, not code). So there's an absolute ban on any checkins until further notice (on Python-Dev), excepting for those explicitly approved by Jeremy. After that, I agree with Fred that we should make a 2.0.1 branch simultaneous with the release. From jeremy at beopen.com Tue Oct 17 00:11:49 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT) Subject: [Python-Dev] Python 2.1 Release Schedule (tentative) Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net> FYI: In anticpation of the Python 2.0 final release this evening, we just created a new PEP describing the release schedule for Python 2.1. Jeremy PEP: 226 Title: Python 2.1 Release Schedule Version: $Revision: 1.1 $ Author: Jeremy Hylton Status: Incomplete Type: Informational Created: 16-Oct-2000 Python-Version: 2.1 Post-History: Abstract This document describes the post Python 2.0 development and release schedule. According to this schedule, Python 2.1 will be released in mid-March of 2001. The schedule primarily concerns itself with PEP-size items. Small bug fixes and changes will occur up until the first beta release. Tentative Release Schedule 16-Oct-2000: Python 2.0 final release These dates represent goals, not commitments. 16-Dec-2000: 2.1 PEPs ready for review 01-Feb-2001: First 2.1 beta release 16-Mar-2001: 2.1 final release Guidelines for making changes for Python 2.1 The guidelines and schedule will be revised based on discussion in the python-dev at python.org mailing list. The PEP system was instituted late in the Python 2.0 development cycle and many changes did not follow the process described in PEP 1. The development process for 2.1, however, will follow the PEP process as documented. The first eight weeks following 2.0 final will be the design and review phase. By the end of this period, any PEP that is proposed for 2.1 should be ready for review. This means that the PEP is written and discussion has occurred on the python-dev at python.org and python-list at python.org mailing lists. The next six weeks will be spent reviewing the PEPs and implementing and testing the accepted PEPs. When this period stops, we will end consideration of any incomplete PEPs. Near the end of this period, there will be a feature freeze where any small features not worthy of a PEP will not be accepted. Before the final release, we will have six weeks of beta testing and a release candidate or two. Bug fix releases before 2.1 We may have to issue Python 2.0.1 for critical bug fixes. If we need to issue a bug fix release, we will use a CVS branch. General guidelines for submitting patches and making changes Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SourceForge (SF) Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, must include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you should write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database (if you have access to the bug database). It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it must be fixed within 24 hours or it will be backed out. All contributed C code must be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code must follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From greg at cosc.canterbury.ac.nz Tue Oct 17 01:09:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz> Guido: > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. This seems like a fatal flaw to me, which should have prevented the buffer object in its present form from ever having been implemented. I suggest that this problem MUST be fixed, or the buffer object removed entirely. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From gstein at lyra.org Tue Oct 17 03:57:09 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 18:57:09 -0700 Subject: [Python-Dev] The buffer interface In-Reply-To: ; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700 References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <20001016185709.J25097@lyra.org> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: >... > I think that buffer object is fairly important. They provide a mechanism > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > something that no other python object does, AFIAK. Perhaps clarifying the > interface (such as the slice operator returning a buffer, as suggested > below) and providing more hooks from Python for creating buffers (via > newmodule, say) would be helpful. There have been quite a few C extensions (and embedding Python!) where the buffer objects have been used in this fashion. For example, if you have a string argument that you wish to pass into Python, then you can avoid a copy by wrapping a Buffer Object around it and passing that. Many of the issues with the buffer object can be solved with simple changes. For example, the "mutable object" thing is easily dealt with by having the object not record the pointer, but just fetch it every time that it wants to do an operation. [ and if we extend the buffer API, we could potentially optimize the behavior to avoid the ptr refetch on each operation ] I don't recall the motivation for returning strings. I believe it was based on an attempt to make the buffer look as much like a string as possible (and slices and concats return strings). That was a poor choice :-) ... so, again, some basic changes to return slices and concats as buffer objects would make sense. Extending the buffer() builtin to create writeable buffer objects has been a reasonably common request. What seems to happen instead is that people developing C extensions (which desire buffer objects as their params) just add a new function to the extension to create buffer objects. Re: the buffer API: At the time the "s"/"t" codes were introduced (before 1.5.2 was released), we had a very different concept of how Unicode objects would be implemented. At that time, Unicode objects had no 8-bit representation (just 16-bit chars), so the difference was important. I'm not clued in enough on the ramifications of torching the difference in the API, but it would be a nice simplification. Buffers vs arrays: this is a harder question. Which is the "recommended binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. Arrays maintain their own memory. I believe the two models are needed, so I'd initially offer that both buffers and arrays need to be maintained. However, given that... what is the purpose of the array if a buffer can *also* maintain its own memory? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Tue Oct 17 05:35:02 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com> I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Oct 17 06:53:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT) Subject: [Python-Dev] CVS repository open for business Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com> The Python CVS repository is now open for further development. If critical patches are needed to the 2.0 release, they should be developed against the branch tagged "release20-maint", and should be posted at SourceForge and discussed here on python-dev before checking them into the branch. Thanks to all the Python developers for your hard work and contributions! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Oct 17 10:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 17 Oct 2000 10:16:56 +0200 Subject: [Python-Dev] The buffer interface References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <20001016185709.J25097@lyra.org> Message-ID: <39EC0AF8.5FA79E97@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: > >... > > I think that buffer object is fairly important. They provide a mechanism > > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > > something that no other python object does, AFIAK. Perhaps clarifying the > > interface (such as the slice operator returning a buffer, as suggested > > below) and providing more hooks from Python for creating buffers (via > > newmodule, say) would be helpful. > > There have been quite a few C extensions (and embedding Python!) where the > buffer objects have been used in this fashion. For example, if you have a > string argument that you wish to pass into Python, then you can avoid a copy > by wrapping a Buffer Object around it and passing that. Perhaps we ought to flesh out the current uses of buffer objects and then decide how to proceed ?! IMHO, the problem with buffer objects (apart from the sometimes strange protocol behaviour) is that there too many "features" built into it. Simplification and possibly diversification is needed: instead of trying to achieve every possible C hack with buffer objects we should try to come up with a reasonably small set of types which allow only very basic tasks, e.g. 1. wrapping C memory areas with the possibility of accessing the raw bytes in a read-only way (this should be buffer()), 2. providing a non-copying object reference type (I'd call this reference()) and 3. maintaining a writeable C memory buffer (arrays provide this feature). The buffer object currently tries to do all three. > Many of the issues with the buffer object can be solved with simple changes. > For example, the "mutable object" thing is easily dealt with by having the > object not record the pointer, but just fetch it every time that it wants to > do an operation. > [ and if we extend the buffer API, we could potentially optimize the > behavior to avoid the ptr refetch on each operation ] Please don't extend the buffer API: the whole design is flawed since it undermines data encapsulation in very dangerous ways. If at all, we should consider a new API at abstract API level which doesn't return raw C pointers, but real Python objects (e.g. type 2 reference objects). > I don't recall the motivation for returning strings. I believe it was based > on an attempt to make the buffer look as much like a string as possible (and > slices and concats return strings). That was a poor choice :-) ... so, > again, some basic changes to return slices and concats as buffer objects > would make sense. +1. > Extending the buffer() builtin to create writeable buffer objects has been a > reasonably common request. What seems to happen instead is that people > developing C extensions (which desire buffer objects as their params) just > add a new function to the extension to create buffer objects. Please don't. Instead either suggest to use arrays or come up with some new type with the sole purpose of providing read-write access to a chunk of bytes. > Re: the buffer API: At the time the "s"/"t" codes were introduced (before > 1.5.2 was released), we had a very different concept of how Unicode objects > would be implemented. At that time, Unicode objects had no 8-bit > representation (just 16-bit chars), so the difference was important. I'm not > clued in enough on the ramifications of torching the difference in the API, > but it would be a nice simplification. Well, think of it this way: Unicode was the first object to actually try to make a difference between "s" and "t" -- and failed badly. In the end, we reverted the decision to make any difference and now special case Unicode objects in the getargs.c parser (so that "s" and "t" work virtually the same for Unicode). +1 on the idea of removing the difference altogether in 2.1. If anyone needs to a special representation of an object, the object should provide a clearly defined C API for this instead. E.g. Unicode has lots of APIs to encode Unicode into quite a few new repesentations. > Buffers vs arrays: this is a harder question. Which is the "recommended > binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. > Arrays maintain their own memory. I believe the two models are needed, so > I'd initially offer that both buffers and arrays need to be maintained. > However, given that... what is the purpose of the array if a buffer can > *also* maintain its own memory? Right and that's the problem: buffers shouldn't be able to own memory. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From barry at scottb.demon.co.uk Tue Oct 17 10:40:52 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 17 Oct 2000 09:40:52 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <001201c03815$f54c4960$060210ac@private> The FreeBSD ports collection had to be updated to support importing C++ extensions with Python 1.5.2. (You get things like cout not defined when importing). Are the nessesary compile/link changes in 2.0? BArry From gstein at lyra.org Tue Oct 17 12:48:27 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 17 Oct 2000 03:48:27 -0700 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: ; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200 References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <20001017034827.F26804@lyra.org> [ moving from xml-sig to python-dev ] Reality check time... On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote: > [maintaining a pythonforge.org would take time and ressources] > > Yes. But I understand a commercial company (BeOpen) has taken over python > development. I think it is the kind of free services they could give > back to the python community. If VA Linux is already offering the service, then how does the community benefit from BeOpen offering the same thing? More importantly: how is BeOpen going to benefit from it? How do they get a business return on that investment? That *will* come into play, you know. Somebody has to pay for those sysadmins and hardware and connectivity. > > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-) > > > > I'd personally hope that python.org becomes accessible in that > > way. You could probably have all of the current content there, and > > then also have python.org/projects/pyxml; python.org/users/someone; > > xml.python.org (and whatever other gimmicks they offer). The last I heard, the intent was to move python.org from CNRI to a machine at VA Linux. The content would then become available for the community to work on; possibly through SourceForge facilities. > > One advantage of taking things off SF is that responsiveness of that > > system was really bad. That seems to have improved recently; > > My concern is not about responsiveness as much as distribution (as in > Internet is a distributed system). SourceForge is a great service. Good. > Now are we to host every single open source project on SourceForge ? If we > do so, the day SourceForge closes or changes its policy, or whatever, > every single open source project will be halted or maybe discontinued. There is no way that SF is ever going to close and take all of those projects with it. VA Linux would be see their business instantly vaporized. As ESR is fond to point out: VA Linux has built their business on trust from the community. *ANY* failure to meet that trust will kill their biz. > The people at SourceForge know their job: they provide a good service and > the tools (code+doc) to implement that same service at other places. > > Why wouldn't a community as big an active as python's put up ressources in > common to offer such a useful service, but dedicated to python > development ? There use to be a python.starship.net, maintained by > volunteers, that is now hosted by BeOpen. Why not take the next step ? python.starship.net has historically been a disaster area. Poorly maintained or (even worse) maintained by a whole bunch of people. Have you ever seen what happens when you give 20 people root access? Then there was the time that a drive crashed. The machine was *gone* for months. Oh, and the network connectivity loss. A month offline, maybe? The community is way to busy to run a service. Sorry. That is why I like SF so much. They are ready and willing to run a service and to fund that operation. And to all appearances, they are running it very well (and continually upgrading it!). > > if anybody is to host a similar server, they need to be aware that it > > is probably hard to compete with SF in terms of provided services. For > > example, I trust that SF has a reasonable backup strategy - they They do. It is somewhere on their site. They have a complete backup strategy. In fact, a while back, they lost a drive and restored most of it from backup. I forget if there was any actual material lost. > > simply can't risk a desaster. Anybody hosting a server for just a few > > projects would not get the same sort of trust from me. > > That's why I think we shouldn't look for someone able to host a server for > a few projects but for some company(ies) able to put up the ressources for > "python projects" and volunteers that help them. Idealistic, but it won't happen. starship.net is my case in point. > That would also make it easier for people to look for python ressources: > code in development would be at something.python.org and 3rd party > software at www.vex.net/parnassus. But I would agree that's a weak > argument as long as www.python.org continues to be well-maintained with > no broken links and stays the central hub for python information. When python.org moves, then it will be maintained much better. I don't recall the status of that, but I presume that Guido is still pushing to see it happen. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Tue Oct 17 05:35:02 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 17 16:06:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 09:06:00 -0500 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100." <001201c03815$f54c4960$060210ac@private> References: <001201c03815$f54c4960$060210ac@private> Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> > The FreeBSD ports collection had to be updated to support > importing C++ extensions with Python 1.5.2. (You get things > like cout not defined when importing). > > Are the nessesary compile/link changes in 2.0? Tell you what: I have no idea. :-( I believe there were some changes to the Makefile and/or config file to support C++, but I don't know if this works on FreeBSD. I'm not a big C++ user myself, so I rarely try this... Can you try it? If it doesn't work out of the box, let's sit down together and figure out a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Oct 17 15:59:46 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> [Moved to python-dev, since the shift has begun.] Nicolas Chauvat writes: > I'm sure several people from PythonLabs are on this list. What is their > opinion ? I rather like letting the SourceForge crew take care of running the service. Running a website that needs constant updates is no trivial matter, and SourceForge is *much* more complex than that! I have a great deal of respect for the hard work that I know goes into running SourceForge, and would rather see that effort bolstered by volunteers & contributions (docs, code, whatever) by people who are able, than to see the efforts splintered. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Nicolas.Chauvat at logilab.fr Tue Oct 17 16:07:36 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> Message-ID: > I have a great deal of respect for the hard work that I know goes > into running SourceForge, and would rather see that effort bolstered > by volunteers & contributions (docs, code, whatever) by people who are > able, than to see the efforts splintered. Hum, maybe I did not explain myself correctly and I don't want a misunderstanding: I never meant "let's create a SourceForge-like tool, SourceForge is bad", but only "why not host a python specific service using the SourceForge code and tools", as www.bioinformatics.org does for projects related to bio-ingeneering. -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From guido at python.org Tue Oct 17 17:26:31 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 10:26:31 -0500 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200." References: Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> > Hum, maybe I did not explain myself correctly and I don't want a > misunderstanding: I never meant "let's create a SourceForge-like tool, > SourceForge is bad", but only "why not host a python specific service > using the SourceForge code and tools", as www.bioinformatics.org does for > projects related to bio-ingeneering. Why not indeed? Why spend time running a service that SourceForge is already providing, and very well at that? This has come up occasionally at BeOpen but the only argument for it that was ever brought up (by the marketing folks, of course :-) was the hope that it would help sell banner ads -- not that there would be an advantage for the community. What would be the advantage for the community or running our own? What's wrong with using SourceForge? I say, if it ain't broke don't fix it. (And then again, there may be a very good reason to run our own, and maybe I just don't see it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Tue Oct 17 17:11:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 17 Oct 2000 17:11:11 +0200 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500 References: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> Message-ID: <20001017171111.K12812@xs4all.nl> On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote: > > Hum, maybe I did not explain myself correctly and I don't want a > > misunderstanding: I never meant "let's create a SourceForge-like tool, > > SourceForge is bad", but only "why not host a python specific service > > using the SourceForge code and tools", as www.bioinformatics.org does for > > projects related to bio-ingeneering. > What would be the advantage for the community or running our own? > What's wrong with using SourceForge? I say, if it ain't broke don't > fix it. (And then again, there may be a very good reason to run our > own, and maybe I just don't see it. :-) There is no advantage that I know of. I know a lot about keeping machines and websites up and running (that's what I do for a living(*), after all) and I can tell you you need a big (or very dedicated) sysadmin staff to be able to offer anything as reliable as SourceForge. So the website & CVS tree itself could be run on a low-end machine. Say a PII-300 with 128 MB RAM. You need at least two, preferably three machines, regardless of performance, to be able to offer 'reliable' services. Preferably load-balanced by something like a smart switch (we use Alteon Layer-4 ethernet switches for that task, and you can do cool things with them. They're also pretty expensive.) And you need a way to back it up. A tape library or DAT streamer of some kind. Preferably a separate machine to do the actual backups. Live or fast-cycled backups can also be a lifesaver, which either requires another machine or two with speedy disks, or storing your data on something dedicated like a NetApp Filer. (Very cool machine, a dedicated NFS and CIFS (SMB) fileserver with excellent live backups, 'snapshots', as many as you want/need. Only costs you diskspace. Oh, and this quality comes at a price, too, of course.) And then there's the reliable network access, reliable system room (with reliable and preferably redundant power), and the 24/7 warning system that wakes up stand-by sysadmins to fix problems. And for the specialized hardware and software, you need a few people who know how to handle them. You need several people anyway, to cover all bases even in the face of illness, vacations and the famous bus accidents. We have a crew of 12 now, with a few new additions, and even then we run into trouble with vacations. I dare say we offer more reliable services than SourceForge does, but we also cost more :-) In short, the only advantage to not using SourceForge is that you can do things SourceForge can't or won't. Run software SourceForge won't, for instance. However, I would strongly suggest making such software 'non-essential', keeping most of the stuff on SourceForge, spend lots less money on the technical setup, and suffer a bit when the service is down. *) Where living is defined as 'making enough money to stay breathing and work on Python', and 'work on Python' has higher importance, of course :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Tue Oct 17 18:47:34 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 12:47:34 -0400 Subject: [Python-Dev] Publicity for 2.0 release? Message-ID: Is BeOpen doing any publicity for the release of 2.0? For example, issuing a press release and sending it to lots of different publications, such as DDJ, Web Development, Windows programming magazines, whatever that XML magazine is called, etc.? (Hmm... www.beopen.com hasn't been updated to mention the new release -- nor even 2.0c1.) --amk From pf at artcom-gmbh.de Tue Oct 17 19:21:19 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST) Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm" Message-ID: Andrew Kuchling: > Is BeOpen doing any publicity for the release of 2.0? For example, > issuing a press release and sending it to lots of different > publications, such as DDJ, Web Development, Windows programming magazines, > whatever that XML magazine is called, etc.? > > (Hmm... www.beopen.com hasn't been updated to mention the new release > -- nor even 2.0c1.) Really bad marketing! ;-) But not as bad as it could have been: Other places hopping into my mind were: http://slashdot.org/ (already done, see below) http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) http://www.newsforge.com/ (didn't see Python mentioned there yet) and not to forget http://www.python.org/ (already done) quoting from slashdot: """Python 2.0 Released Posted by timothy on 5:34 Tuesday 17 October 2000 from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept. atallah writes: "It would appear that the long awaited Python 2.0 was finally released today. The front page of the Web site has the announcement." According to that announcement, Python 2.0 will receive minor-version updates around every 6 months, even as work begins on the shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list includes "full XML support and several forms of new syntax," as well as the BeOpen label. ( Read More... | 164 comments ) """ Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From akuchlin at mems-exchange.org Tue Oct 17 19:33:22 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 13:33:22 -0400 Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200 References: Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us> On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote: > http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) By Jeremy, actually. I'm not sure why it lists my name instead -- Freshmeat bug? --amk From hinsen at cnrs-orleans.fr Tue Oct 17 22:27:10 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:10 +0200 Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16 Oct 2000 10:38:11 -0700) References: <39EB3D03.A00C78B6@jps.net> Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr> > Are people doing the kind of numeric programming with "complex > algorithms" using Python that Konrad refers to? More importantly, how > many people? At least one: me. > > Guido thinks that 2/3 returning 0 was a design mistake, > > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > > users won't know what to do with a complex number, so it's "an error" to > > them. > > Guido's philosophy is clearly that Python defaults should be geared to > "Most Python users". I agree, and as I wrote in an earlier post, the It's difficult to say what "most Python users" want; it's not a static community. I'd say the basic principle is "no bad surprises". 2/3 == 0 is a bad surprise for anyone who knows elementary math but is not familiar with certain programming languages, especially since the program goes on silently with a "wrong" intermediate result. > Maybe we can have true 754 compliance in Py3k, and we can all be happy!! Py3k forever! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Nicolas.Chauvat at logilab.fr Wed Oct 18 10:35:02 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de> Message-ID: On Tue, 17 Oct 2000, Martin v. Loewis wrote: [about my suggestion concerning a SourceForge dedicated to python] That was only a suggestion, not a demand as someone stated. I would love to set up a pythonforge myself if I had the resources, unfortunately I don't... maybe in a few months? Time will tell. For now I'll just go back to hacking and keep quiet. Cheers, :) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From barry at scottb.demon.co.uk Wed Oct 18 11:57:04 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 18 Oct 2000 10:57:04 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> Message-ID: <001401c038e9$c4cabbd0$060210ac@private> O.k. will do, hopefully this weekend. BArry > -----Original Message----- > From: guido at cj20424-a.reston1.va.home.com > [mailto:guido at cj20424-a.reston1.va.home.com]On Behalf Of Guido van > Rossum > Sent: 17 October 2000 15:06 > To: Barry Scott > Cc: jeremy at beopen.com; python-dev at python.org > Subject: Re: [Python-Dev] build problems large and small on FreeBSD > > > > The FreeBSD ports collection had to be updated to support > > importing C++ extensions with Python 1.5.2. (You get things > > like cout not defined when importing). > > > > Are the nessesary compile/link changes in 2.0? > > Tell you what: I have no idea. :-( > > I believe there were some changes to the Makefile and/or config file > to support C++, but I don't know if this works on FreeBSD. I'm not a > big C++ user myself, so I rarely try this... > > Can you try it? If it doesn't work out of the box, let's sit down > together and figure out a fix. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > From mal at lemburg.com Wed Oct 18 18:03:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 18 Oct 2000 18:03:16 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? Message-ID: <39EDC9C4.7D61454@lemburg.com> Before starting to work on postponed patches and checking them in: is the current CVS tree ready for new checkins (tags applied, etc.) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Wed Oct 18 18:29:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <39EDC9C4.7D61454@lemburg.com> References: <39EDC9C4.7D61454@lemburg.com> Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Before starting to work on postponed patches and checking them > in: is the current CVS tree ready for new checkins (tags applied, > etc.) ? Yes; I posted a note re-opening the tree yesterday (or late Monday night; I can't remember that far back). We've just been too tired to do a lot since the release. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Wed Oct 18 18:52:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 12:52:52 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > We've just been too tired to do a lot since the release. ;) LOL! You're the very soul of diplomacy, Fred -- but I guess, overall, it really is prudent not to mention all our recent suicide attempts . my-wrists-are-killing-me-ly y'rs - tim From skip at mojam.com Wed Oct 18 19:19:25 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: <14829.56221.303087.523464@beluga.mojam.com> Tim> my-wrists-are-killing-me-ly y'rs - tim You need my typing watcher: http://www.musi-cal.com/~skip/python/watch.py Only problem is I never figured out how to make it watch keystrokes directly. It detects mouse movement. Since I do most of my typing in Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the mouse a little... I've tried, so far unsuccessfully, to make this a SourceForge project. I've even asked for help from SF, but their response wasn't helpful, and the round-trip time for a response is too long to make pursuing that path worthwhile. The watch project is at http://sourceforge.net/projects/watch/ All I have is a CVSROOT/modules file. Nothing I've tried has successfully imported the one project file into cvs. If anyone has any suggestions for kickstarting this thing, it would be much appreciated. Thx, Skip From thomas at xs4all.net Wed Oct 18 20:43:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 18 Oct 2000 20:43:19 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> Message-ID: <20001018204319.L12812@xs4all.nl> On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote: > Tim> my-wrists-are-killing-me-ly y'rs - tim > You need my typing watcher: Given his remark about suicide attempts, I'm not sure if Tim really meant 'RSI' when he wrote that :-) > http://www.musi-cal.com/~skip/python/watch.py > Only problem is I never figured out how to make it watch keystrokes > directly. It detects mouse movement. Since I do most of my typing in > Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the > mouse a little... Funny, a colleague of mine has a similar tool. Also written in Python, I think, though it may have been created in his Perl Period. On a linux box, you can determine keystrokes by using /proc/interrupts. At least, if your keyboard has an interrupt all for itself. (Pretty likely, really :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Oct 18 21:11:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <20001018204319.L12812@xs4all.nl> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> Message-ID: <14829.62936.109759.567547@beluga.mojam.com> Thomas> On a linux box, you can determine keystrokes by using Thomas> /proc/interrupts. At least, if your keyboard has an interrupt Thomas> all for itself. (Pretty likely, really :) Thanks, Neil S. sent me a patch for that already. I'll try to work it into the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or other Unix flavors? I suspect I'll just have to bite the bullet and work in platform-dependent code for this. Skip From esr at thyrsus.com Wed Oct 18 21:36:01 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 18 Oct 2000 15:36:01 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <20001018153601.A18127@thyrsus.com> Skip Montanaro : > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Might this monitoring function be a candidate for the Python library when it's done? -- Eric S. Raymond A man with a gun is a citizen. A man without a gun is a subject. From cgw at fnal.gov Wed Oct 18 21:53:09 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov> Skip Montanaro writes: > > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Can't tell you about Windows or Mac, but for Unix I'd read the file driver/timers.c in the XScreensaver distribution (www.jwz.org). This code is pretty sophisticated and runs on all the major Unix flavors. From skip at mojam.com Wed Oct 18 22:22:45 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> <14829.65445.421622.258893@buffalo.fnal.gov> Message-ID: <14830.1685.932659.181060@beluga.mojam.com> Charles> ... but for Unix I'd read the file driver/timers.c in the Charles> XScreensaver distribution (www.jwz.org). This code is pretty Charles> sophisticated and runs on all the major Unix flavors. Thanks, Charles. I will check it out. Those of you who are former (or current) od users will appreciate Jamie Zawinski's home page even if you're not interested in this topic. I revisit his site periodically. I'm never disappointed... Skip From est at hyperreal.org Wed Oct 18 22:30:46 2000 From: est at hyperreal.org (est at hyperreal.org) Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro at "Oct 18, 2000 03:22:45 pm" Message-ID: <20001018203047.27215.qmail@hyperreal.org> Skip Montanaro discourseth: > > Those of you who are former (or current) od users will appreciate Jamie > Zawinski's home page even if you're not interested in this topic. I revisit > his site periodically. I'm never disappointed... Looks more like emacs hexl-mode to me. Hmm..I guess you got this thread off topic. :) E From martin at loewis.home.cs.tu-berlin.de Wed Oct 18 23:09:36 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 18 Oct 2000 23:09:36 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> What is the reason for not publishing Python 2.0 on SF for download? SF certainly wouldn't be the primary source, but I think at least the source distribution should be available there, with the release notes telling where to get binary distributions (BeOpen, ActiveState, who else?) Regards, Martin From tim_one at email.msn.com Wed Oct 18 23:34:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 17:34:38 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: [Martin v. Loewis] > What is the reason for not publishing Python 2.0 on SF for download? From gstein at lyra.org Thu Oct 19 00:44:13 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 18 Oct 2000 15:44:13 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400 References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: <20001018154413.A31010@lyra.org> On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote: > [Martin v. Loewis] > > What is the reason for not publishing Python 2.0 on SF for download? > > >From BeOpen.com's POV, so long as they were paying major bills, they would > rather have download traffic tickle their ad banners than SF's ad banners. > > >From our (PythonLabs) POV, another publishing site is more work, and one URL > is about as good as any other. Besides, rising to the top of SF's "most > active" list has not been an explicit life goal for any of us . And here is where the larger community can help. Presuming that non-admins can publish files, then we could take on the burden of publishing the files via SF. > > SF certainly wouldn't be the primary source, but I think at least the > > source distribution should be available there, with the release notes > > telling where to get binary distributions (BeOpen, ActiveState, who > > else?) > > I didn't see any advantage claimed for publishing on SF. Without an > advantage, the work/benefit ratio is infinite. Work == 0 for you guys, presuming that non-admins can publish. [ off to take a look... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at mems-exchange.org Thu Oct 19 18:20:37 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 12:20:37 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us> Before we all become focused on new features for Python 2.1, it would be nice to do a bit more work on raising awareness of the new features in 2.0. There's little point in developing software if you don't actually tell anyone about it, after all. I'd like to suggest that people try to write some brief articles, just a few pages long, each covering a particular feature in some detail. Looking through the list of new stuff, the most significant features are: * Unicode support. (Perl's UTF-8 support still seems incomplete, with developers referring to it as "unusable", so we should definitely try and point out that we have working Unicode support right now.) * Distutils: an introduction to writing setup scripts for simple Python modules, packages, and C extensions. * The new XML tools. * The new gettext support. * Maybe the linuxaudiodev module, too. Any other suggestions? If the story of how a particular feature was implemented is interesting, then that would also make a fine topic for a more developer-oriented publication such as DDJ. SRE or Unicode may be the best candidates for this sort of thing, as their implementation presented various tricky technical problems along the way. Any volunteers? --amk From gvwilson at nevex.com Thu Oct 19 18:53:31 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > Before we all become focused on new features for Python 2.1, it would be > nice to do a bit more work on raising awareness of the new features in 2.0. "Doctor Dobb's Journal" would be very interested in articles --- 3000 words (plus or minus), plus some code examples and diagrams. > * Unicode support. (Perl's UTF-8 support still seems incomplete, with > developers referring to it as "unusable", so we should definitely try and > point out that we have working Unicode support right now.) Definitely --- the practical details of implementing Unicode, and a Unicode-aware regular expression engine, would be very interesting to our readers. However, please steer clear of saying, "And anyway, Perl is broken." (I just got a review copy of Hunt and Thomas's book on Ruby. There are three places in the first two chapters where they say, "And Ruby has more users in Japan than Python." I'll finish the book anyway.) > * Distutils: an introduction to writing setup scripts for simple > Python modules, packages, and C extensions. Possibly interesting; would be more so if Distutils could be applied/was being applied to installation problems in other languages. > * The new XML tools. Definitely. > * The new gettext support. > * Maybe the linuxaudiodev module, too. These are both probably too specialized... > Any other suggestions? The garbage collector: Java and Ruby both score points by having full garbage collection, so its availability in Python 2.0 (along with a discussion of the things that might break or change as a result) would be very interesting. Thanks, Greg (a contributing editor with DDJ) From nas at arctrix.com Thu Oct 19 12:09:52 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 19 Oct 2000 03:09:52 -0700 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019030952.A32671@glacier.fnational.com> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: > The garbage collector: Java and Ruby both score points by having full garbage > collection, so its availability in Python 2.0 (along with a discussion of the > things that might break or change as a result) would be very interesting. This is on my todo list. I think there are some interesting implementation issues. Also, the article would be useful documentation for python-dev type people. Neil From akuchlin at mems-exchange.org Thu Oct 19 19:32:08 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:32:08 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >"Doctor Dobb's Journal" would be very interested in articles --- 3000 words >(plus or minus), plus some code examples and diagrams. I was thinking more about on-line places such as oreillynet.com/python/, but DDJ would be better still. >The garbage collector: Java and Ruby both score points by having full garbage >collection, so its availability in Python 2.0 (along with a discussion of the >things that might break or change as a result) would be very interesting. Arising out of lunch-time discussion, a comparison of how different FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection would be interesting, though perhaps unsuitable for DDJ, since the topic is a rather unfocused one. --amk From martin at loewis.home.cs.tu-berlin.de Thu Oct 19 19:31:58 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 19 Oct 2000 19:31:58 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> [Tim Peters] > From BeOpen.com's POV, so long as they were paying major bills, they > would rather have download traffic tickle their ad banners than SF's > ad banners. Even though this should have been clear to me all the time, stating it explicitly triggers alarms for me. I just checked, and it appears that Python 2.0 is not available for download via ftp. In particular, it is not available via ftp from ftp.python.org! If it was there, mirrors all over the world would pick it up and bring it in a location near me (ftp.fu-berlin.de would be nearest) (*). So while making it available on SF may indeed give no advantage, making it available on python.org would provide users with alternative download locations, so that I don't feel the bandwidth limitation that Web download from pythonlabs.com produces. That would be a clear advantage to me, at least. Of course, having ftp mirrors would mean that many downloads do not tickle anybody's ad banners - which would probably be in the interest of other users as well, just not in the interest of BeOpen. So I'm curious how this conflict of interest is resolved... Regards, Martin (*) ftp://ftp.python.org/python/src/README does not even mention Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Note that some mirrors only collect the this directory (src), and the doc and contrib siblings, while the ftp master site, , has much more. "Much more" may be true, just nothing recent... I probably should ask ftpmaster.python.org to put Python-2.0.tar.gz in that directory. From akuchlin at mems-exchange.org Thu Oct 19 19:42:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:42:19 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >(*) ftp://ftp.python.org/python/src/README does not even mention >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Unless one of the BeOpen Pythoneers is already going to do this, I'll go ahead and drop the relevant files into places. Guys? While we're at it, how about making the filenames for the source code consistent? -rw-r--r-- 1 guido psa 2533053 Apr 13 1999 py152.tgz -rw-r--r-- 1 1103 psa 2259957 Oct 31 1998 pyth151.tgz -rw-r--r-- 1 guido psa 1907724 May 31 1995 python1.2.tar.gz -rw-r--r-- 1 guido psa 2037062 Oct 12 1995 python1.3.tar.gz -rw-r--r-- 1 guido psa 2252481 Oct 25 1996 python1.4.tar.gz -rw-r--r-- 1 guido psa 2904353 Jan 3 1998 python1.5.tar.gz I like pythonX.X.tar.gz best, and will change the filenames (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. Though isn't the standard GNU naming convention more like python-1.5.tar.gz? --amk From esr at thyrsus.com Thu Oct 19 20:05:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 19 Oct 2000 14:05:48 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019140548.A21315@thyrsus.com> Andrew Kuchling : > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? It is, and I wish we'd move to it as did the Perl guys. It makes life substantially easier to have really uniform naming conventions, especially for programs like the Metalabs file clerk. -- Eric S. Raymond Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' From mwh21 at cam.ac.uk Thu Oct 19 20:01:29 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Oct 2000 19:01:29 +0100 Subject: [Python-Dev] 2.0 articles In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400" References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Before we all become focused on new features for Python 2.1, it would > be nice to do a bit more work on raising awareness of the new features > in 2.0. There's little point in developing software if you don't > actually tell anyone about it, after all. > > I'd like to suggest that people try to write some brief articles, just > a few pages long, each covering a particular feature in some detail. [snip] > Any volunteers? It's not as exciting as Unicode or XML, but I've thrashed out a few hundred words on the new "setdefault" dictionary method. It's up here: http://starship.python.net/crew/mwh/hacks/setdefault.html Tell me what you think! There's the beginning of a longer example in a comment at the bottom, but I felt it was getting a bit long-winded to be of interest. Cheers, M. -- If i don't understand lisp, it would be wise to not bray about how lisp is stupid or otherwise criticize, because my stupidity would be archived and open for all in the know to see. -- Xah, comp.lang.lisp From gstein at lyra.org Thu Oct 19 20:52:53 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:52:53 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019115253.W31108@lyra.org> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >... > Of course, having ftp mirrors would mean that many downloads do not > tickle anybody's ad banners - which would probably be in the interest > of other users as well, just not in the interest of BeOpen. So I'm > curious how this conflict of interest is resolved... Stating that a "conflict of interest" even EXISTS is a rather sorry statement on things. -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Oct 19 20:54:36 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:54:36 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019115436.X31108@lyra.org> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: > On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: > >(*) ftp://ftp.python.org/python/src/README does not even mention > >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says > > Unless one of the BeOpen Pythoneers is already going to do this, I'll > go ahead and drop the relevant files into places. Guys? Please... just do it. >... > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? I'm with Eric -- go for the GNU standard. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at mems-exchange.org Thu Oct 19 21:11:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 15:11:42 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote: >On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> Unless one of the BeOpen Pythoneers is already going to do this, I'll >> go ahead and drop the relevant files into places. Guys? >Please... just do it. I charged ahead and did it anyway; the Pythoneers can spank me for it later. (Worse, maybe they'll do something *bad* to me...) There were already doc/1.6/ and doc/2.0/ directories, and binaries (Windows, RPMs) were in /pub/python/2.0/, along with the source. So I only touched /pub/python/src/. All the releases and betas are now consistently named python-X.Y.Z.tar.gz. I've left symlinks in place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final releases, but didn't bother making links for releases older than 1.5.1 or for beta versions, so any FTP URLs pointing directly to those files will be broken. --amk From jeremy at alum.mit.edu Fri Oct 20 18:28:19 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >> >(*) ftp://ftp.python.org/python/src/README does not even mention >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says >> >> Unless one of the BeOpen Pythoneers is already going to do this, >> I'll go ahead and drop the relevant files into places. Guys? GS> Please... just do it. In the interest of making the distribution as widely available as possible, I've placed files on SourceForge and at http://www.python.org/2.0/ >> ... I like pythonX.X.tar.gz best, and will change the filenames >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless >> vetoed. Though isn't the standard GNU naming convention more >> like python-1.5.tar.gz? GS> I'm with Eric -- go for the GNU standard. I used the file name conventions that we used throughout the 2.0 release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU standard or not (didn't realize it was a standard; don't know where to find said standard; or is it just a custom?) Jeremy From jeremy at alum.mit.edu Fri Oct 20 18:31:47 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us> References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >> "Doctor Dobb's Journal" would be very interested in articles --- >> 3000 words (plus or minus), plus some code examples and diagrams. AMK> I was thinking more about on-line places such as AMK> oreillynet.com/python/, but DDJ would be better still. And, of course, there's the Python conference: http://python9.org/ >> The garbage collector: Java and Ruby both score points by having >> full garbage collection, so its availability in Python 2.0 (along >> with a discussion of the things that might break or change as a >> result) would be very interesting. AMK> Arising out of lunch-time discussion, a comparison of how AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with AMK> garbage collection would be interesting, though perhaps AMK> unsuitable for DDJ, since the topic is a rather unfocused one. A comparison of different FFIs with respect to garbage collection might be interesting; hard to say without seeing what the conclusions are. Jeremy From akuchlin at mems-exchange.org Fri Oct 20 18:26:56 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:26:56 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote: >release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU >standard or not (didn't realize it was a standard; don't know where to >find said standard; or is it just a custom?) See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24 Though I think here the standard is just codifying an existing custom that's proved convenient. www.fsf.org seems unresponsive at the moment, hence the strange link; is *every* Web site in the world breaking today for some reason? --amk From akuchlin at mems-exchange.org Fri Oct 20 18:28:10 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:28:10 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net> Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote: >And, of course, there's the Python conference: http://python9.org/ That's preaching to the converted, though. --amk From fdrake at acm.org Fri Oct 20 18:51:44 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ There's a separate python-rpms "Package"; the RPM files should go there (I think). -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From thomas at xs4all.net Fri Oct 20 22:21:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 20 Oct 2000 22:21:18 +0200 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: ; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100 References: Message-ID: <20001020222118.M12812@xs4all.nl> On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote: > "Jean-Claude Levieux" writes: > > I just tried to compile Python 2.0. > > on BSDI BSD/OS 4.0.1 [ Sorry, missed the original message. Used the Archive to find it, tho ] > Random guess, but you are using a ANSI C compiler, aren't you? Python > 2.0 now demands that. BSDI uses gcc, so that's not the problem. Neither are these three warnings: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype /usr/include/wchar.h:17: warning: function declaration isn't a prototype (or any other warnings regarding 'function decl isn't a prototype) They are a result of Python using '-Wstrict-prototypes' by default, if the compiler is gcc. It just means BSDI declares a few functions without specifying argument lists (prototypes) and has nothing to do with Python (other than that Python always defines CFLAGS to contain -Wstrict-prototypes.) There isn't an easy way to get this 'fixed', unfortunately. If you want to quench the warnings, you'll have to edit ./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile, and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly, because it's overwritten by the 'makesetup' script, which parses the Setup file.) As for the other error, that's really an error :( ../libpython2.0.a(fileobject.o): In function portable_fseek': /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined reference to `TELL64' The problem is that BSDI has an 'off_t' type that is larger than the 'long' type, and Python's configure makes the flawed assumption that this means BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug is even present with BSDI 4.1, and probably more platforms. You can fix this by editing './config.h' after running './configure', and commenting out the HAVE_LARGEFILE_SUPPORT line; changing this: #define HAVE_LARGEFILE_SUPPORT 1 into something like this: /* #define HAVE_LARGEFILE_SUPPORT 1 */ (You can just remove the line as well.) The downside of both these 'hacks' (excuse me, 'hotfixes'), is that you'll have to reedit the files again after running configure again (or something that runs configure, like 'config.status'.) I see a total of three bugs here: Python adds -Wstrict-prototypes even though it can generate a lot of warnings that aren't related to Python; there is no way to override the CFLAGS variable (you can pass it to configure, and it uses it at first, but then just overwrites it); and mis-detecting large file support. I can't decide which of the last two is the biggest bug :-) I would write a patch for the lot of 'm, but I'm in the middle of getting ready to head to London for the Apache conference (any other Pythonistas going ? :) and Have I Got News For You is about to start on BBC1. If you don't do it, Jean-Claude, I'll submit bugreports on these when I'm back, next Thursday. (Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1. You can leave them on for 4.1, but 4.0.1 has very broken threads, and it will cause lots of problems in the signal module if you leave them on. You can disable them by using '--with-threads=no' -- this is also listed in the README, by the way. And note that BSDI 4.1 only has the large file support problem, none of the others, and I strongly suggest upgrading for other reasons as well.) Python-dev: CC'd because this is material for a bugfix-release. There are likely to be other platforms hit by the large filesupport misdetection. Don't think this is enough to warrant a bugfix release (it's not *that* brownbaggy) but it should definately go in if there is one ;P If I or someone else didn't fix it by the time a bugfix release is considered, please hit me. I also appologize for not properly testing Python 2.0 on BSDI 4.0.1 or 4.1... We still have those machines, but we are using less and less of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux :) BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all- -those-good-sides-too-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at ActiveState.com Fri Oct 20 22:54:59 2000 From: trentm at ActiveState.com (Trent Mick) Date: Fri, 20 Oct 2000 13:54:59 -0700 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200 References: <20001020222118.M12812@xs4all.nl> Message-ID: <20001020135459.C1562@ActiveState.com> On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote: > As for the other error, that's really an error :( > > ../libpython2.0.a(fileobject.o): In function portable_fseek': > /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined > reference to `TELL64' > > The problem is that BSDI has an 'off_t' type that is larger than the 'long' > type, and Python's configure makes the flawed assumption that this means > BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug > is even present with BSDI 4.1, and probably more platforms. You can fix this > by editing './config.h' after running './configure', and commenting out the > HAVE_LARGEFILE_SUPPORT line; changing this: > > #define HAVE_LARGEFILE_SUPPORT 1 > > into something like this: > > /* #define HAVE_LARGEFILE_SUPPORT 1 */ > > (You can just remove the line as well.) The downside of both these 'hacks' > (excuse me, 'hotfixes'), is that you'll have to reedit the files again after > running configure again (or something that runs configure, like > 'config.status'.) This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see a pattern) http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 It was fixed by adding a hack in fileobject.c to *define* TELL64. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470 For the quickfix, the same hack could be used for BSDI. As you suggest Thomas, the proper fix is to patch configure.in such that it does not report that these system support largefiles. I don't have the time to do this right away, nor do I have one of these boxes on which to test it. I can try to make a patch though. We don't you file a bug and assign it to me. Trent -- Trent Mick TrentM at ActiveState.com From martin at loewis.home.cs.tu-berlin.de Fri Oct 20 22:54:02 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 20 Oct 2000 22:54:02 +0200 Subject: [Python-Dev] This Project Has Released Files Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de> > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ Thanks! also to anybody else contributing to the release process, in particular to amk for his ongoing maintainance of various pieces on python.org, and his efforts in getting the word out. Regards, Martin From cgw at fnal.gov Fri Oct 13 17:11:03 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach Below find the output of cc -V as well as the output of ./configure and make (sorry for the flood, I assume too much detail is better than not enough) creating cache ./config.cache checking MACHDEP... osf1V4 checking for --without-gcc... checking for --with-cxx=... no checking for gcc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for --with-suffix... checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... cc -E checking for AIX... no checking for minix/config.h... no checking whether cc accepts -OPT:Olimit=0... no checking whether cc accepts -Olimit 1500... yes checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... no checking for poll.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for db_185.h... no checking for db.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for pty.h... yes checking for libutil.h... no checking for ndbm.h... yes checking for db1/ndbm.h... no checking for gdbm/ndbm.h... no checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of char... 1 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking size of fpos_t... 8 checking for long long support... yes checking size of long long... 8 checking for uintptr_t support... no checking size of off_t... 8 checking whether to enable large file support... no checking size of time_t... 4 checking for pthread_t... yes checking size of pthread_t... 8 checking for --with-next-framework... no checking for --with-dyld... no checking SO... .so checking LDSHARED... ld -shared -expect_unresolved "*" checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... no checking for shl_load in -ldld... no checking for --with-pydebug... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for --with-libs... no checking for --with-dec-threads... no checking for --with-threads... yes checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... yes checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking for --with-cycle-gc... yes checking for --with-libdb... yes checking for dbopen... no checking for --with-wctype-functions... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for dlopen... yes checking DYNLOADFILE... dynload_shlib.o checking for alarm... yes checking for chown... yes checking for clock... yes checking for confstr... yes checking for ctermid... yes checking for ctermid_r... no checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... yes checking for fpathconf... yes checking for ftime... yes checking for ftruncate... yes checking for getgroups... yes checking for getlogin... yes checking for getpeername... yes checking for getpid... yes checking for getpwent... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for mremap... no checking for nice... yes checking for pathconf... yes checking for pause... yes checking for plock... yes checking for poll... yes checking for pthread_init... no checking for putenv... yes checking for readlink... yes checking for select... yes checking for setegid... yes checking for seteuid... yes checking for setgid... yes checking for setlocale... yes checking for setregid... yes checking for setreuid... yes checking for setsid... yes checking for setpgid... yes checking for setuid... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... yes checking for strftime... yes checking for strptime... yes checking for symlink... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for tempnam... yes checking for timegm... no checking for times... yes checking for tmpfile... yes checking for tmpnam... yes checking for tmpnam_r... no checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for _getpty... no checking for openpty... yes checking for forkpty... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... yes checking for ftell64... no checking for ftello... no checking for statvfs... yes checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... yes checking for setpgrp... yes checking for gettimeofday... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for member tm_zone in aggregate type struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for inline... __inline checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... yes checking gethostbyname_r with 6 args... yes checking for __fpu_control... no checking for __fpu_control in -lieee... no checking for --with-fpectl... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for genuine getopt... yes checking what malloc(0) returns... null checking for wchar.h... yes checking for usable wchar_t... no checking whether byte ordering is bigendian... no checking whether right shift extends the sign bit... yes checking for socklen_t... no updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Grammar/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.config creating config.h (cd Modules; make -f Makefile.pre Makefile) + cp ./Setup.in Setup rm -rf ../libpython2.0.a /bin/sh ./makesetup Setup.config Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Grammar `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo yes >hassignal; break; fi; done cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ./Grammar Compiling (meta-) parse tree into NFA grammar Making DFA for 'single_input' ... Making DFA for 'file_input' ... Making DFA for 'eval_input' ... Making DFA for 'funcdef' ... Making DFA for 'parameters' ... Making DFA for 'varargslist' ... Making DFA for 'fpdef' ... Making DFA for 'fplist' ... Making DFA for 'stmt' ... Making DFA for 'simple_stmt' ... Making DFA for 'small_stmt' ... Making DFA for 'expr_stmt' ... Making DFA for 'augassign' ... Making DFA for 'print_stmt' ... Making DFA for 'del_stmt' ... Making DFA for 'pass_stmt' ... Making DFA for 'flow_stmt' ... Making DFA for 'break_stmt' ... Making DFA for 'continue_stmt' ... Making DFA for 'return_stmt' ... Making DFA for 'raise_stmt' ... Making DFA for 'import_stmt' ... Making DFA for 'import_as_name' ... Making DFA for 'dotted_as_name' ... Making DFA for 'dotted_name' ... Making DFA for 'global_stmt' ... Making DFA for 'exec_stmt' ... Making DFA for 'assert_stmt' ... Making DFA for 'compound_stmt' ... Making DFA for 'if_stmt' ... Making DFA for 'while_stmt' ... Making DFA for 'for_stmt' ... Making DFA for 'try_stmt' ... Making DFA for 'except_clause' ... Making DFA for 'suite' ... Making DFA for 'test' ... Making DFA for 'and_test' ... Making DFA for 'not_test' ... Making DFA for 'comparison' ... Making DFA for 'comp_op' ... Making DFA for 'expr' ... Making DFA for 'xor_expr' ... Making DFA for 'and_expr' ... Making DFA for 'shift_expr' ... Making DFA for 'arith_expr' ... Making DFA for 'term' ... Making DFA for 'factor' ... Making DFA for 'power' ... Making DFA for 'atom' ... Making DFA for 'listmaker' ... Making DFA for 'lambdef' ... Making DFA for 'trailer' ... Making DFA for 'subscriptlist' ... Making DFA for 'subscript' ... Making DFA for 'sliceop' ... Making DFA for 'exprlist' ... Making DFA for 'testlist' ... Making DFA for 'dictmaker' ... Making DFA for 'classdef' ... Making DFA for 'arglist' ... Making DFA for 'argument' ... Making DFA for 'list_iter' ... Making DFA for 'list_for' ... Making DFA for 'list_if' ... Adding FIRST sets ... Writing graminit.c ... Writing graminit.h ... cp graminit.h ./../Include/graminit.h cp graminit.c ./../Python/graminit.c cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"' ./getplatform.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"' -DPREFIX='"/usr/local"' -DEXEC_PREFIX='"/usr/local"' -DVERSION='"2.0"' -DVPATH='""' ./getpath.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c if test ! -f libpython2.0.a; then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true; else true; fi for i in Parser Grammar Objects Python Modules; do (cd $i; make VERSION="2.0" add2lib); done ar cr ../libpython2.0.a acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o myreadline.o if test ! -f ../Modules/hassignal; then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o; else echo leaving intrcheck.o out; fi leaving intrcheck.o out touch add2lib ar cr ../libpython2.0.a abstract.o bufferobject.o classobject.o cobject.o complexobject.o fileobject.o floatobject.o frameobject.o funcobject.o intobject.o listobject.o longobject.o dictobject.o methodobject.o moduleobject.o object.o rangeobject.o sliceobject.o stringobject.o tupleobject.o typeobject.o unicodeobject.o unicodectype.o touch add2lib ar cr ../libpython2.0.a bltinmodule.o exceptions.o ceval.o compile.o codecs.o errors.o frozen.o frozenmain.o getargs.o getcompiler.o getcopyright.o getmtime.o getplatform.o getversion.o graminit.o import.o importdl.o marshal.o modsupport.o mystrtoul.o pyfpe.o pystate.o pythonrun.o structmember.o sysmodule.o traceback.o dynload_shlib.o thread.o if test ! -f ../Modules/hassignal; then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o; else echo leaving sigcheck.o out; fi leaving sigcheck.o out touch add2lib if test -f hassignal; then echo removing sigcheck.o intrcheck.o; ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null; else echo leaving sigcheck.o intrcheck.o in; fi removing sigcheck.o intrcheck.o *** Exit 2 (ignored) ar cr ../libpython2.0.a threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o touch add2lib echo 0 >buildno cd Modules; make OPT="-O -Olimit 1500" python.o cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c expr `cat buildno` + 1 >buildno1 mv -f buildno1 buildno cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` ./Modules/getbuildinfo.c ar cr libpython2.0.a getbuildinfo.o ranlib libpython2.0.a true cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) /usr/lib/cmplrs/cc/ld: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $ $RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $ $RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $ $RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $ $RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $ $RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $ $RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $ $RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $ $RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $ $RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $ $RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $ $RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $ $RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $ $RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $ $RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $ $RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $ $RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $ $RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $ $RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $ $RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $ $RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $ $RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $ $RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $ $RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $ $RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $ $RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $ $RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $ $RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $ $RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $ $RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $ $RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $ $RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $ $RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $ $RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $ $RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $ $RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $ $RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $ $RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $ $RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $ $RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $ $RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $ $RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $ $RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $ $RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $ $RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $ $RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $ $RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $ $RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $ $RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $ $RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $ $RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $ $RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $ $RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $ habitat_id = realtime_12:1991 $RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $ $RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $ $RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $ $RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $ $RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $ $RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $ /usr/lib/cmplrs/cc/ftoc: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ /usr/lib/cmplrs/cc/cord: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ ldtbread.c: 1.1 1/7/82 /usr/lib/cmplrs/cc/crt0.o: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ cc (cc) Digital UNIX Compiler Driver 3.11 From effbot at telia.com Mon Oct 23 19:44:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 19:44:49 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid> looks like Tcl's parent company has ceased to be: http://biz.yahoo.com/bw/001020/ca_interwo.html "The Ajuba team will be assimilated into Interwoven's existing technical staff much as the Neonyoyo team was immediately after its acquisition in June. The Ajuba product line will be discontinued." From guido at python.org Mon Oct 23 22:12:49 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 15:12:49 -0500 Subject: [Python-Dev] Starship down ? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200." <39F43EAC.1A518A27@lemburg.com> References: <39F43EAC.1A518A27@lemburg.com> Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! Yeah, this is very unfortunate. It's the same problem that's keeping pytholabs.com down. The BeOpen systems staff is working on it, but I don't know what the problem is or when it will be fixed. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr at thyrsus.com Mon Oct 23 21:40:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 15:40:16 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> Message-ID: <20001023154016.A2722@thyrsus.com> Fredrik Lundh : > looks like Tcl's parent company has ceased to be: This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support? It seems to me that the Tcl world has been in increasing disarray for the last two years. Its growth doesn't seem to have matched Perl's or Python's; no strong community site analogous to python.org or CPAN has emerged; and John Osterhout's attempt to commercialize the language have led to a series of false starts and erratic moves. And Osterhout cheerfully acknowledges that on a technical level that Tcl has been pushed past the natural limits of applicability for its design approach. Tcl's long-term prognosis looks, to me, increasingly poor. Which suggests to me that some move toqwards making Python less dependent on Tk would be a good thing. I understand that we can't simply drop Tkinter. But I think it might be worth another look at alternatives (notably wxPython) to consider bringing one into the core distribution during 2.x, so that later on we can plan to move Tk to "unsupported -- legacy". -- Eric S. Raymond You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948) From guido at python.org Mon Oct 23 23:08:13 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 16:08:13 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400." <20001023154016.A2722@thyrsus.com> References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> [ESR] > This raises anew a question I've been meaning to bring up for the last > week: is it finally time to move away from Python's dependence on > Tcl/Tk for GUI support? > > It seems to me that the Tcl world has been in increasing disarray for > the last two years. Its growth doesn't seem to have matched Perl's or > Python's; no strong community site analogous to python.org or CPAN has > emerged; and John Osterhout's attempt to commercialize the language > have led to a series of false starts and erratic moves. And Osterhout > cheerfully acknowledges that on a technical level that Tcl has been > pushed past the natural limits of applicability for its design > approach. > > Tcl's long-term prognosis looks, to me, increasingly poor. Which > suggests to me that some move toqwards making Python less dependent > on Tk would be a good thing. > > I understand that we can't simply drop Tkinter. But I think it > might be worth another look at alternatives (notably wxPython) to > consider bringing one into the core distribution during 2.x, so that > later on we can plan to move Tk to "unsupported -- legacy". Yes, it may be time to have this discussion again. Of course, Tcl/Tk still has a much larger following than wxWindows, and it is more stable too. (For example, it's easy to cause crashes -- not just exceptions -- by leaving out an initialization call in wxPython.) Plus, Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc. The Scintilla text widget comes close (and surpasses Tkinter in some respects, while coming short in others), but I know of no widget in a popular widget set that offers anything close to the Canvas widget. There are other choices too, all of which have Python support already: gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Mon Oct 23 22:21:18 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:21:18 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us> Fredrik Lundh wrote: > looks like Tcl's parent company has ceased to be: I checked out comp.lang.tcl after hearing about this. Ousterhout posted to say that an official statement will be coming out today or tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see what he says the core team is going to do... On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote: >This raises anew a question I've been meaning to bring up for the last >week: is it finally time to move away from Python's dependence on >Tcl/Tk for GUI support? It seems to me that supporting MacOS is the big problem for cross-platform GUIs. There are several different systems such as Qt that aim for portability across Windows and Unix, but add in the MacOS and the options really decrease. How good is wxWindows support for MacOS? Or will MacOS X fix the problem? I know MacOS X uses a BSD-based underlying kernel, but don't know if it will support X Windows out of the box. If people can only use MacOS-specific GUI APIs, then software such as Tk would still need to be ported specially to MacOS X. --amk From akuchlin at mems-exchange.org Mon Oct 23 22:30:11 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:30:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: >The Scintilla text widget comes close (and surpasses Tkinter in some >respects, while coming short in others), but I know of no widget in a >popular widget set that offers anything close to the Canvas widget. I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a fork of the Tk widget that was then substantially enhanced to be a general-purpose display engine, with antialiasing, alpha compositing, more attention to performance, and other fancy features. I don't know if the corresponding text widget (which is Pango, www.pango.org, I think) is equally featureful. --amk From gvwilson at nevex.com Mon Oct 23 22:33:48 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT) Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com> Message-ID: > Fredrik Lundh : > > looks like Tcl's parent company has ceased to be: > Eric Raymond: > This raises anew a question I've been meaning to bring up for the last week: > is it finally time to move away from Python's dependence on Tcl/Tk for GUI > support? Yes please. > It seems to me that the Tcl world has been in increasing disarray for the > last two years. Its growth doesn't seem to have matched Perl's or Python's; > no strong community site analogous to python.org or CPAN has emerged; I have been told by two different publishers that they can't even give Tcl books away any longer. It's also interesting that the new Ruby book from Hunt and Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or Perl (I saw three mentions in the first ten minutes of the fact that Ruby is more widely used in Japan than Python). Also interesting that the Ruby GUI toolkit they describe is Tk-based... > I understand that we can't simply drop Tkinter. But I think it might be > worth another look at alternatives (notably wxPython) to consider bringing > one into the core distribution during 2.x, so that later on we can plan to > move Tk to "unsupported -- legacy". I thought about using wxPython in the most recent run of my Python course, but decided to stick to Tkinter because: - There isn't a wxWindows/wxPython book (matters a lot when organizations are trying to decide what to adopt for long-term use). - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. - There aren't as many tools on top of wxPython as there are on top of Tkinter. In particular, I think that a vector drawing package on top of wxPython that did what Sketch does, but on Windows as well as Linux, would make a great subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Thanks, Greg From effbot at telia.com Mon Oct 23 23:02:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:02:58 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... from an open-source perspective, Tcl might be more alive than ever: http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-) From esr at thyrsus.com Mon Oct 23 23:15:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:15:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023171503.B2889@thyrsus.com> Guido van Rossum : > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). I'm glad you brought up GTK+. Of all the alternatives you mentioned, it seems to me the most likely to attract long-term cross-platform support by lots of developers (GNOME, Nautilus and Sun Microsystems seem like a tough trio to beat on this score). Thus, GTK+ may be be the safest alternative in terms of being least likely to strand us N years down the road. The GTK+ API seems like a nice clean design, and there is already a Python binding. Any comment from anybody on how stable it is? Are the text and canvas widgets anywhere near competitive with Tk's? There are hints of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port? -- Eric S. Raymond .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) From trentm at ActiveState.com Mon Oct 23 23:06:41 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 23 Oct 2000 14:06:41 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023140641.A3899@ActiveState.com> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: > There are other choices too, all of which have Python support already: ... > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). XUL. Though slappin' a GUI together in XUL is not all the same as for the other toolkits. Layout with XML, functionality with JavaScript and Python (and/or Perl of C++). Trent -- Trent Mick TrentM at ActiveState.com From effbot at telia.com Mon Oct 23 23:33:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:33:02 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... they just updated their site: http://www.ajubasolutions.com/company/whatsnew.html "Tcl is not a core technology at Interwoven, and Interwoven will not invest in the development of Tcl. However, Ajuba has transferred responsibility for Tcl core development to the newly formed Tcl Core Team /.../ We expect the Tcl Core Team to evolve Tcl at a much faster rate than any single organization could achieve by itself. "Over the next few weeks Ajuba will release in open- source form many of the Tcl packages that we deve- loped for our products. Stay tuned for more info... From akuchlin at mems-exchange.org Mon Oct 23 23:26:18 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 17:26:18 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: ; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400 References: <20001023154016.A2722@thyrsus.com> Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us> Some details begin to emerge at http://www.ajubasolutions.com/company/whatsnew.html It looks like some of their proprietary code will be released as open source, possibly including the TclPro development environment. The new company will not be funding Tcl/Tk development, and instead it's up to the 14 members of the recently-formed Tcl core team. I don't know if any of those people are being paid to work on Tcl, but probably at least some of them are. I expect this will cause a good deal disruption, perhaps even a fatal amount, particularly if core developers such as Jeffrey Hobbs no longer work on Tcl full-time. --amk From esr at thyrsus.com Mon Oct 23 23:58:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:58:20 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400 References: <20001023154016.A2722@thyrsus.com> <20001023172618.A23898@kronos.cnri.reston.va.us> Message-ID: <20001023175820.A3117@thyrsus.com> Andrew Kuchling : > Some details begin to emerge at > http://www.ajubasolutions.com/company/whatsnew.html > > It looks like some of their proprietary code will be released as open > source, possibly including the TclPro development environment. The > new company will not be funding Tcl/Tk development, and instead it's > up to the 14 members of the recently-formed Tcl core team. I don't > know if any of those people are being paid to work on Tcl, but > probably at least some of them are. I expect this will cause a good > deal disruption, perhaps even a fatal amount, particularly if core > developers such as Jeffrey Hobbs no longer work on Tcl full-time. Not necessarily... Good for Tcl: they *have* a core team now Bad for Tcl: at 14 it's too big, unless there's some inner core of no more than three or four architects. Good for Tcl: Much of the proprietary code will go open. Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are on the new core team. Not clear whether their time available will increase or decrease. Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users. With good leadership, they could manage the transition to something resembling the Apache Software Foundation's organization. If so, Tcl might actually improve. -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From robin at alldunn.com Tue Oct 24 01:03:44 2000 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:03:44 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES> I'm not on python-dev so please be sure to copy me on replies. "Greg Wilson" wrote: > > I thought about using wxPython in the most recent run of my Python course, but > decided to stick to Tkinter because: > > - There isn't a wxWindows/wxPython book (matters a lot when organizations are > trying to decide what to adopt for long-term use). > This is something I am hoping to change in the near future. I have a lot of ideas, have been putting an outline together, and have a phone conference with a potential publisher tomorrow. > - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. > > - There aren't as many tools on top of wxPython as there are on top of Tkinter. > In particular, I think that a vector drawing package on top of wxPython that > did what Sketch does, but on Windows as well as Linux, would make a great > subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Hint received and understood... "Andrew Kuchling" akuchlin at mems-exchange.org wrote: > > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. There are several different systems such as Qt > that aim for portability across Windows and Unix, but add in the MacOS > and the options really decrease. How good is wxWindows support for > MacOS? My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. It's in use in at least a few commercial applications around the world. The next step I guess is getting it wrapped up in wxPython, which should just be a matter of porting some of the low level startup and helper code, and putting some ifdef's in the SWIG interface files for things that may be different in the Mac version of wxWindows. Unfortunately, given the current state of the amount of my spare time and relative Mac-illiterate-ness, it's either going to require someone else to work on it and be wxPython-Mac's champion, or somebody needs to fund my ramp-up and development time so I can cut back on other things. The good news is that I have been loaned a Mac and CodeWarior and such to play with, I just haven't found the time to play much lately. "Guido van Rossum" guido at python.org wrote: > Plus, Tk has two very high quality widgets: the Canvas and Text > widgets are unsurpassed in functionality and robustness by other > widget sets. You can draw more lines or characters per second in most > toolkits, but few toolkits offer the convenience of marks and tags, > not having to deal with refresh events, being able to group objects, > move them around, change attributes, etc., etc., etc. > > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), Just in case anybody didn't know already, wxWindows/wxPython has a wrapper around Scintilla available called wxStyledTextCtrl. > but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. wxWindows has a canvas widget in development right now. I've been trying to nudge the developers working on it towards features found in the tk canvas and the GNOME canvas widget. I have high hopes for it but I'm not sure how long it will be before it gets to the same level as the others. -- Robin Dunn Software Craftsman robin at AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From esr at thyrsus.com Tue Oct 24 01:29:54 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 19:29:54 -0400 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700 References: <036501c03d45$81aefae0$3225d2d1@ARES> Message-ID: <20001023192954.A3313@thyrsus.com> Robin Dunn : > Unfortunately, given the current > state of the amount of my spare time and relative Mac-illiterate-ness, it's > either going to require someone else to work on it and be wxPython-Mac's > champion, or somebody needs to fund my ramp-up and development time so I can > cut back on other things. This is exactly what CoSource and SourceXchange are for. Post your Mac port as a project there and see who ponies up money. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From MarkH at ActiveState.com Tue Oct 24 01:19:33 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 10:19:33 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001023140641.A3899@ActiveState.com> Message-ID: Trimmed all CCs [Guido] > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). [Trent "David Ascher" Mick responds] > XUL. Though slappin' a GUI together in XUL is not all the same as for > the other toolkits. Layout with XML, functionality with > JavaScript and Python (and/or Perl of C++). As a fairly irrelevant (at this point in time) observation: Something about the Mozilla XUL engine seems "right". It is large and complex, but their XML based layout engine, and powerful "code-less" widget creation has a lot of potential IMO. It is very very new and rough. It is very tightly bound with Mozilla itself and javascript, although efforts are underway to separate it from both. It is huge, and constantly changing. It has been designed for tomorrow, and struggles along today. But it may well turn out to be and expressive and compelling model for the future. So, if we can just continue to disagree for the next 2 or 3 years, it may well become something worth considering ;-) Mark. From robin at alldunn.com Tue Oct 24 01:56:59 2000 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:56:59 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com> Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES> > > This is exactly what CoSource and SourceXchange are for. Post your Mac port > as a project there and see who ponies up money. Now why didn't I think of that??? Thanks for the idea! -- Robin Dunn Software Craftsman robin at AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From DavidA at ActiveState.com Tue Oct 24 06:00:51 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. > > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). The mozilla toolkits has more names than I care to remember. =) The most generic name is XPFE, although there are some parts of it with nicer names like XUL (pronounced Zool) and XBL. It also heavily uses XML, DTDs, CSS, etc. Mozilla is definitely a long-term investment in our part. For example, currently it's not possible to have Python code inline in the XUL (XML) code, and JavaScript is the only option there. We'll be working w/ the Netscape and Mozilla crowds to fix that, but it's not there yet. That said, Mozilla does have a fairly strong vision for the future, allows some of the benefits of the web technologies to transfer to the GUI world (designers, not coders, can do the UI work). In terms of the closest equivalent to the Canvas widget, apart from XUL itself, which is very hierarchical, there is the promise of SVG support, which will give you a lot more than the Canvas. That, too, is not quite ready for prime time yet. Hope this is helpful, --david From cgw at fnal.gov Tue Oct 24 06:32:04 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov> David Ascher writes: > > That said, Mozilla does have a fairly strong vision for the future, allows > some of the benefits of the web technologies to transfer to the GUI world > (designers, not coders, can do the UI work). Sounds great for the future, but I want to inject a few of my unsolicated, opinionated observations - today, in 2000, the Mozilla stuff is *far* from usable. If you want to produce nice, professional looking GUI apps which fit nicely with the desktop (rather that having their own completely different look-and-feel) it's hard to beat Gtk+ or Tkinter. Tkinter is still quite viable, especially if cross-plaform support is important. Some of the examples in Grayson's book are quite beautiful. It will be a long time until XPFE/XUL/whatchamacallit gets to this level of viability. Also consider that Sun (and HP?) now ship Gnome by default, rather than CDE (or so I hear, anyway). I predict that Gnome compatibility will become more and more of a desirable feature. Evidence of the above is the "Galeon" project. It's widely perceived that Mozilla has a nice rendering engine (Gecko) wrapped up in a dreadful GUI (XPFE). So the Galeon project places the Gecko engine inside a Gtk+/Gnome GUI, which provides a much more pleasant user experience. There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/ And, finally, IMO, the work being done on PyGtk is of high quality. I'm using it currently in production code. From DavidA at ActiveState.com Tue Oct 24 07:12:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: > There's also a (preliminary) port of Gtk+ to Win32: > http://www.gimp.org/~tml/gimp/win32/ FWIW, the last time I checked, this was useless. I'd be glad to be wrong, but I'm not holding my breath. Not surprisingly, the GTK crowd, which is rooted in Linux tradition (!), has little interest in Win32 ports, and even less experience in that world. Until that happens, a lot of platform-agnostic projects and vendors will have a hard time w/ GTK. I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included). --david From tim_one at email.msn.com Tue Oct 24 07:20:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:20:07 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: [ESR] > ... > and John Osterhout's attempt to commercialize the language have led to > a series of false starts and erratic moves. We don't want to criticize anyone for that: PythonLabs' attempts *not* to commercialize Python may yet make Tcl's path look as straight and true as a laser beam . obliquely y'rs - tim From tim_one at email.msn.com Tue Oct 24 07:31:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:31:07 -0400 Subject: [Python-Dev] Starship down ? In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> Message-ID: [MAL] > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! [GvR] > Yeah, this is very unfortunate. It's the same problem that's keeping > pytholabs.com down. The BeOpen systems staff is working on it, but I > don't know what the problem is or when it will be fixed. FYI, pythonlabs.com is up again, but Starship is still down. We only said it's the same problem because we didn't know what either problem was. And, we still don't! long-distance-ly y'rs - tim From cgw at fnal.gov Tue Oct 24 07:34:23 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov> David Ascher writes: >cgw> There's also a (preliminary) port of Gtk+ to Win32: >cgw> http://www.gimp.org/~tml/gimp/win32/ > > FWIW, the last time I checked, this was useless. That's what I meant by "preliminary" ;-) > I don't mean to diss GTK, just pointing out that cross-platform solutions > are important to a whole lot of communities (Python included). Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face. Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win, seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and they will just hate it. (Yes, this is based on observations of actual paying customers). I have a little bit of experience with cross-platform development - having used a lot of these tools - at my last job, after evaluating just about everything, we bought into (against my advice!) a doomed commercial product called Visix Galaxy (for which I immediately created a set of Python bindings). The problem with all of these things, of course, is that the more cross-platform they are, the more "lowest-common-denominator" they are forced to become. Tkinter, with widgets like Canvas, was really pretty amazing - for its day - feature-rich *and x-platform. But even this broke down if you started using fancy features like drawing with dashed lines - works on X, not on Windows (last time I checked, anyway) - the more you start pushing the limits of the toolkit, the more the portability breaks down. Tkinter-is-dead-long-live-Tkinter'ly yrs, -C From MarkH at ActiveState.com Tue Oct 24 07:48:34 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 16:48:34 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov> Message-ID: > Right. Cross-platform is very important, but so is native > look-and-feel, and this is where (IMO) XPFE falls flat on its face. Actually, my experience with XPFE from a look-and-feel POV has been pretty positive. It is true they have re-implemented most widgets rather than use native ones, and also true that you can make these widgets look nothing like native LAF - but generally, my experience with Mozilla and the "classic" skin is that it is close enough that it is very hard to tell. It looks more like "subtle enhancements", in the same way IE provides "subtle enhancements" > seems like it could be a real winner. If the x-platform GUI doesn't > use native dialog boxes and filechoosers, users REALLY notice this and Agreed. However, XPFE works fine here IMO. Again, I do not want to propose XPFE as viable today, and I agree it may never be viable. Most other critisisms posted are valid, but I don't think that LAF is one such problem with XPFE. Mark. From paul at prescod.net Tue Oct 24 08:29:42 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:29:42 -0700 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> Message-ID: <39F52C56.214B28A1@prescod.net> Fredrik Lundh wrote: > >... > > http://sourceforge.net/projects/tcl > http://sourceforge.net/projects/tktoolkit > > and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo > will rock ;-) Perhaps this could be an opportunity to split Tcl and Tk more cleanly. People like Fredrick and his Perl/Ruby/... equivalents could get more deeply involved in setting direction. It would be interesting to contrast the number of Tcl versus Tk users right now. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Tue Oct 24 08:40:49 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:40:49 -0700 Subject: [Python-Dev] Gradual migration Message-ID: <39F52EF1.A201C6D9@prescod.net> Python 3K. It is the repository for our hopes and dreams. We tend to invoke it in three different situations: 1. in delaying discussions of gee-whiz features (e.g. static type checking) 2. in delaying hairy implementation re-factoring that we don't want to undertake right now. 3. in delaying painful backwards-compatibility breakage I think it is somewhat debatable whether we really need to or should do these three things all at once but that's a separate discussion for another day. (the other experiment may inform our decision) I want to focus on "3" -- breakage. Rather than delaying painful backwards-compatibility breakage I thing we should make it less painful. We should decide where we are going long before we ask our users to move there. I think we should start including alternatives to syntaxes and features that we know are broken. Once people move to the alternatives we can "reassign" or remove the original syntax with much less pain. In other words, rather than telling people "here's a new version, your code is broken, sorry." We should tell them: "we're going to break code. Here's an alternative syntax that you can use that will be interpreted the same in the old and new versions -- please move to this new syntax as quickly as possible." I'll outline some examples of the strategy. You may or may not like details of the particular proposals but you might still agree with the strategy. Also, I don't claim that all of the proposals are fully fleshed-out...again, it's the strategy I'm most interested in. I don't even agree with every feature change I describe below -- they are just some I've heard of for Python 3000. In other words ** this is not a design document for Python 3000! ** Separating byte arrays from strings: 1. immediately introduce two new functions: binopen("foo").read() -> byte array stropen("foo","UTF-8".read() -> u"...." 2. warn about string literals that have embedded non-Unicode characters 3. deprecate extension modules that return "old fashioned" string arrays 4. after a period where all strings have been restricted to Unicode-compatibility, merge the Unicode and string types. 5. deprecate the special Unicode u"" syntax as an imperialist anachronism Reclaiming the division operator from truncating integer division: 1. immediately introduce new functions: div() that does division as we wish it was. 2. add a warning mode to Python (long overdue) 3. with the warning mode on, old-fashioned division triggers a deprecation warning. 4. after three years as a warning situation we expect all in-use Python scripts to have been upgraded to use the new operations and to explicitly truncate integer division when that is what is wanted. 5. at that point we can re-assign the division operator to be a floating point division if we wish. Case insensitivity: 1. Warn whenever a module or class has two __dict__ entries that differ only by case 2. Eventually, disallow that form of name-clash altogether 3. After a period, allow case variations to be equivalent. Unifying types and classes (more vague): 1. Add something like extension class to make type subclassing easier. 2. Informally deprecate modules that do not incorporate it. 3. Replace or fix details of the language and implementation that behave differently for types and classes. (e.g. the type() operator) -- Paul Prescod - Not encumbered by ActiveState consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From pf at artcom-gmbh.de Tue Oct 24 09:47:03 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST) Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm" Message-ID: Hi, Paul Prescod wrote on python-dev at python.org: [...] > Reclaiming the division operator from truncating integer division: [...] Bruce Sherwood and David Scherer suggested a IMHO very clever solution to this particular problem in March/April this year. This thread was first posted to idle-dev and afterwards X-posted to python-dev: http://www.python.org/pipermail/idle-dev/2000-April/000138.html http://www.python.org/pipermail/idle-dev/2000-April/000140.html http://www.python.org/pipermail/python-dev/2000-April/010029.html Unfortunately I'm no native english speaker and have not enough time to make a Python-2.1 PEP from it. May be somebody else wants to go for it? I still believe, this was a very clever Python enhancement, which should be officially proposed. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal at lemburg.com Tue Oct 24 10:45:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 10:45:03 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <39F54C0F.25798309@lemburg.com> Paul Prescod wrote: > > Python 3K. It is the repository for our hopes and dreams. We tend to > invoke it in three different situations: > > 1. in delaying discussions of gee-whiz features (e.g. static type > checking) > > 2. in delaying hairy implementation re-factoring that we don't > want to undertake right now. > > 3. in delaying painful backwards-compatibility breakage > > I think it is somewhat debatable whether we really need to or should do > these three things all at once but that's a separate discussion for > another day. (the other experiment may inform our decision) I think will simply be a consequence of doing a complete rewrite of the interpreter for Py3K. AFAIR, the only truely feasable solution would be doing the rewrite in a widely portable subset of C++ and then managing classes at that level. Moving to a common and very low-level strategy for classes will allows us to put even the most basic types (strings and numbers) into an inheritence tree. Differences like the ones between Unicode and 8-bit strings would then flesh out as two different subclasses of a generic string type which again is based on a generic sequence type. The same could be done for dictionaries: special ones for just string keys, case insensitive lookups, etc. could all be subclasses of a generic mapping class. Dito for numbers (and division strategies). By following this principle there won't be all that much breakage, since the old functionality will still be around, only the defaults will have changed. Add to this pluggable compilers and ceval loops, plus a nice way of configuring the lot on a per-module basis and you're set. (Ok, it's a fluffy clouds image, but you get the picture ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 24 17:57:43 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 10:57:43 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200." <39F54C0F.25798309@lemburg.com> References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com> > Paul Prescod wrote: > > > > Python 3K. It is the repository for our hopes and dreams. We tend to > > invoke it in three different situations: > > > > 1. in delaying discussions of gee-whiz features (e.g. static type > > checking) > > > > 2. in delaying hairy implementation re-factoring that we don't > > want to undertake right now. > > > > 3. in delaying painful backwards-compatibility breakage > > > > I think it is somewhat debatable whether we really need to or should do > > these three things all at once but that's a separate discussion for > > another day. (the other experiment may inform our decision) Marc-Andre Lemburg replied: > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. > > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. > > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. > > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. > > Dito for numbers (and division strategies). > > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. > > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Good job in channeling me, Marc-Andre! I'm sure that's not exactly how it's going to be, but on the face of it, this sure sounds like a reasonable possible route. Do you want to be the author for PEP-3000? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 24 18:13:37 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 11:13:37 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST." <39F52EF1.A201C6D9@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com> > I want to focus on "3" -- breakage. Rather than delaying painful > backwards-compatibility breakage I thing we should make it less painful. > We should decide where we are going long before we ask our users to move > there. I think we should start including alternatives to syntaxes and > features that we know are broken. Once people move to the alternatives > we can "reassign" or remove the original syntax with much less pain. Absolutely. Whenever possible, we should try to plan for migration in Python 2.x. > In other words, rather than telling people "here's a new version, your > code is broken, sorry." We should tell them: "we're going to break code. > Here's an alternative syntax that you can use that will be interpreted > the same in the old and new versions -- please move to this new syntax > as quickly as possible." It would also help if we could produce automatic translation tools that will convert the old syntax into the new. This desire may restrict our choices however: the translation tools don't have runtime information to go by. It's easy enough to change obsolete syntax into new syntax, but it's hard to decide whether a particular "/" operator should be changed into an integer divide ("//") or left alone. > I'll outline some examples of the strategy. You may or may not like > details of the particular proposals but you might still agree with the > strategy. Also, I don't claim that all of the proposals are fully > fleshed-out...again, it's the strategy I'm most interested in. I don't > even agree with every feature change I describe below -- they are just > some I've heard of for Python 3000. In other words ** this is not a > design document for Python 3000! ** I think the proper approach is to start a separate migration process for each of these proposed changes. Each should be paced separately (the pace may depend on how hard to swallow the change is for users as well as how hard it is to implement the new functionality) and for each, a separate PEP in the 3000 series should be started. I can even see that several PEPs will be needed in some cases (e.g. one to describe the new syntax, one to to flesh out the implementation, and one to decide on the migration steps). I won't comment on Paul's examples, that's for the various PEP processes. --Guido van Rossum (home page: http://www.python.org/~guido/) From cgw at fnal.gov Tue Oct 24 17:21:45 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.14407.954185.466011@buffalo.fnal.gov> Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov> Mark Hammond writes: > > > Agreed. However, XPFE works fine here IMO. > > > cgw> "Here" means on MS-Win, right? Maybe that's why our perceptions are > cgw> so different. > > Correct. Although I have run it under Linux a few times, I wouldnt really > know LAF issues if I tripped over them there ;-) > > Mark. It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not agree!) Gnome is gathering momentum, especially now that Sun has joined the Gnome Foundation. With outfits like Eazel, Helix Code, etc, turning out high-quality products, things are moving fast in the Gnome/Gtk+ world and it seems clear to me that this will be the major desktop platform for Unix machines in the upcoming decade. Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up. OK, enough off-topic rambling (for now), -C From akuchlin at mems-exchange.org Tue Oct 24 17:43:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 11:43:26 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote: >It's certainly true that the lack of a consistent look and feel for >Linux apps has been somewhat of a problem historically. However, with >the emergence of Gnome, it seems that there is finally some >convergence. (Althought people in the KDE/Qt camp will certainly not Careful... while people may try to port GTk+ to Windows, porting GNOME is a different kettle of wax, because GNOME needs GTk+ but also entails gnome-libs and gnome-vfs and Bonobo and esound and lots of other things, which provide services such as object embedding that wouldn't be required -- or would be very different -- on Windows. I don't know if anyone is trying to tease apart GNOME into a Windows-suitable subset; it seems like it would be a difficult task. Qt is at least a toolkit that aims at cross-platform portability, though there again, the KDE environment built on top of it is not going to be portable to anything that isn't Unix. Both the Qt and GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only real possibilities. This is why, every time this debate comes up, we end up sticking with Tk; it may suck, but all the other systems don't support everything... Maybe the best approach is to follow /F's lead with Tkinter3000, and reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that *is* what Tkinter3000 is, right?) What's the problem we're trying to solve here? * Is it that the problem that the Tkinter module is a bad API for GUI programming? * Or is it that the Tk implementation is slow or bulky? * Or do we just dislike having to require Tcl as well as Tk? Can someone articulate why Tk should be replaced? --amk From gvwilson at nevex.com Tue Oct 24 17:52:00 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > What's the problem we're trying to solve here? > > * Is it that the problem that the Tkinter module is a bad API for > GUI programming? > > * Or is it that the Tk implementation is slow or bulky? > > * Or do we just dislike having to require Tcl as well as Tk? > > Can someone articulate why Tk should be replaced? I can articulate why I'm unhappy with the current set-up: 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los Alamos before my first Python course cost me several hours, and I had to do it again two months' later. I've run into similar problems with multiple Tcl installations on Windows machines (personal use). 2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python). Performance doesn't really matter --- I've never had students complain about speed, although I've never asked them to build something large enough that refresh would be an issue. I don't have experience teaching wxPython, so I can't comment on the relative teachability of its API vs. Tk's. Hope this helps, Greg From paul at prescod.net Tue Oct 24 18:12:12 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:12:12 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <39F5B4DC.C226D8F6@prescod.net> "M.-A. Lemburg" wrote: > >... > > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. I disagree for a variety of reasons: * implementation language and Python inheritance semantics are almost completely distinct. After all, we have Python implementations in a variety of languages with minor incompatibilities. Python could have a proper type/class merging even if it were written in assembly language. So let's leave implementation language aside. * there is a hell of a lot we can do to make the type/class split less visible without a major rewrite. For instance, lists could have a __getitem__ method so that they "act like" instances. Instances could return their methods in a dir() so that they "act like" built-in objects. So there is no reason to wait for a complete rewrite to start on this path. * It may even be the case that we can get from here to complete merged type/class semantics WITHOUT a rewrite. If a mad genious had not written stackless Python I would have sworn up and down that stackless Python would require a Python rewrite. It didn't. If another slightly less mad genious had not integrated ints and longs I would never have believed it possible without another rewrite. Someone needs to do an analysis of what it takes to merge types and classes and *demonstrate* that it requires a rewrite rather than *asserting* that it requires a rewrite. In other words, let's stop sprinkling the "major rewrite" pixie dust on hard problems and instead decide where we want to go and how we want to get there! > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. I don't know what you mean by a "low-level strategy" for classes. It's not like we can somehow use C++ vtables without giving up Python's dynamicity. Python's class handling is about as low-level as it can get in my humble opinion. > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. Of course that's where we want to go but it doesn't avoid the backwards compatibility problems. We can do this today using proxying. > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. We can easily do this today. > Dito for numbers (and division strategies). There's no way I'm going to let you get away with that little sleight of hand. How is inheritance holy water going to allow us to change the semantics of: 5/2 without breaking code?? The same goes for a.b = 5 versus a.B = 5 C++ does not help. Inheritance does not help. Pluggable compilers do not help. We *will* break code. We just need to decide whether to do it in a thoughtful way that gives people a chance to migrate or put off decisions until the last possible moment and then spring it on them with no between-version upgrade path. > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. When you change defaults you break code. Keeping the old functionality around is barely helpful. Nobody has EVER proposed a change to Python where something that was previously possible is now made impossible. So whatever our strategy, the PROBLEM is changing defaults. The solution is telling people what defaults are changing in what timeline and discouraging them from depending on the old defaults. > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Sounds mythical. I'm trying to take it out of the realm of fluffy clouds and bring it into the world that people can plan their businesses and coding strategies around. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Tue Oct 24 18:30:17 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:30:17 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> Message-ID: <39F5B919.4B80A526@prescod.net> Guido van Rossum wrote: > > ... > > I think the proper approach is to start a separate migration process > for each of these proposed changes. I agree. As a more concrete extension to my last email, I propose the following doctrine: """ No major documented feature should be removed or have changed semantics in Python 3000 or any other new version of Python until users have had a year (preferably MORE!) of upgrade time. Upgrade time entails the following parts: 1. the released Python version has a new recommended way to accomplish the task in a manner that will remain available in the "breakage version" e.g. a div() function that people can use for a few years while the semantics of "/" are in transition. 2. the mechanism/syntax that will be removed is formally deprecated. The documentation would say, e.g. "You should not use '/' for now. It is changing semantics in the future." 3. the released Python version sports a runtime warning to tell users that the mechanism/syntax is going away. "CompatibilityError: Future versions of Python will have different semantics for the '/' operator. Please use div() instead." The actual "right" amount of upgrade time depends on the extent of the breakage and its ease of detection. """ I can PEP this if people agree. I think that the user community would appreciate our effort to promise not to break code suddenly and capriciously. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry at wooz.org Tue Oct 24 18:26:13 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? References: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.47141.817450.488896@anthem.concentric.net> >>>>> "GW" == Greg Wilson writes: GW> 2. (Lack of) native look and feel. This is a complete GW> show-stopper for many of the outfits I've dealt with (and not GW> just with Python). On the other hand, it's incredibly easy to whip together a GUI in Tk for simple applications. Yes, Tk gets painful as applications grow, but I'd hate to abandon such a simple, well-known toolkit for a complicated, hard-to-learn but powerful native look-and-feel one. You don't /always/ care about strict native LAF. Or to restate: I'd hate to have to make that choice. If we can't satisfy both requirements (mandatory-native-LAF and rapid prototyping friendliness), we may need to continue to support multiple toolkits. the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs, -Barry From guido at python.org Tue Oct 24 19:39:38 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:39:38 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400." References: Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los > Alamos before my first Python course cost me several hours, and I had > to do it again two months' later. I've run into similar problems with > multiple Tcl installations on Windows machines (personal use). For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and install our own Tcl/Tk binaries, in a place that doesn't affect or require existing Tcl/Tk installations. Maybe we can do the same for Unix binary distributions? I believe Jeremy has already had to create a separate RPM for _tkinter because there are too many different versions of Tcl/Tk out there -- it shouldn't be hard to install our own altogether. > 2. (Lack of) native look and feel. This is a complete show-stopper for > many of the outfits I've dealt with (and not just with Python). Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much. Or are you saying that IDLE isn't designed as a typical Microsoft app? That's quite a separate issue from the widget look-and-feel! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at wooz.org Tue Oct 24 18:40:50 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <14837.48018.547379.464959@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> * implementation language and Python inheritance semantics PP> are almost completely distinct. After all, we have Python PP> implementations in a variety of languages with minor PP> incompatibilities. Python could have a proper type/class PP> merging even if it were written in assembly language. So PP> let's leave implementation language aside. Jython experience backs this up. It would be incredibly convenient if we could just map Java classes to Python classes, so that for example, we'd have in Java a PyException class that is exceptions.Exception with minimal or no Java wrappings. And Finn nearly did this. The problem that we ran into with Java is that it allows only single inheritance. So you couldn't create a Python exception that multiply inherited from two or more other Python exceptions. Doesn't happen often, but it does happen, so is that an acceptable tradeoff? C++ might be better in this particular respect, but there will be other issues, because as soon as you start transparently showing the implementation's classes into Python, you inherit their semantics and restrictions as well. Just saying that it's tricky. -Barry From guido at python.org Tue Oct 24 19:54:39 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:54:39 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST." <39F5B919.4B80A526@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> <39F5B919.4B80A526@prescod.net> Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com> > As a more concrete extension to my last email, I propose the following > doctrine: > > """ > No major documented feature should be removed or have changed semantics > in Python 3000 or any other new version of Python until users have had a > year (preferably MORE!) of upgrade time. Upgrade time entails the > following parts: > > 1. the released Python version has a new recommended way to > accomplish the task in a manner that will remain available in the > "breakage version" e.g. a div() function that people can use for a few > years while the semantics of "/" are in transition. > > 2. the mechanism/syntax that will be removed is formally deprecated. > The documentation would say, e.g. "You should not use '/' for now. It is > changing semantics in the future." > > 3. the released Python version sports a runtime warning to tell > users that the mechanism/syntax is going away. "CompatibilityError: > Future versions of Python will have different semantics for the '/' > operator. Please use div() instead." > > The actual "right" amount of upgrade time depends on the extent of the > breakage and its ease of detection. > """ > > I can PEP this if people agree. I think that the user community would > appreciate our effort to promise not to break code suddenly and > capriciously. Go for it. I have little bandwidth to think about this deeply, but what you're proposing here sounds like a good approach. Certainly it will make it easier if I can point to this PEP when I get the next FUD email about "should I bother to learn Python 2.0 when Py3K is going to be all different?"... --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Tue Oct 24 19:07:12 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 19:07:12 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid> paul wrote: > Perhaps this could be an opportunity to split Tcl and Tk more cleanly. > People like Fredrick and his Perl/Ruby/... equivalents could get more > deeply involved in setting direction. I'm waiting for the Tcl/Tk developers to grow up -- they still fear that any attempt to make it easier to use Tk from other languages would be to "give up the crown jewels" :-( From effbot at telia.com Tue Oct 24 18:59:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 18:59:23 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid> andrew wrote: > Maybe the best approach is to follow /F's lead with Tkinter3000, and > reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that > *is* what Tkinter3000 is, right?) nope -- at least not initially. the first two steps are a new Tk glue layer, and an extension API that allows you to write new widgets in pure Python. also see: http://w1.132.telia.com/~u13208596/tkinter/index.htm ::: I have plans for how to take the Tkinter API *and* the new extension API beyond Tk, but let's save that for another day... ::: > Can someone articulate why Tk should be replaced? beats me ;-) From cgw at fnal.gov Tue Oct 24 18:54:35 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov> Andrew Kuchling writes: > > Careful... while people may try to port GTk+ to Windows, porting GNOME > is a different kettle of wax, because GNOME needs GTk+ but also > entails gnome-libs But I was never seriously advocating Gtk+ on Windows. This was just a footnote. I shouldn't have even mentioned the Windows Gtk+ port because it just muddied the water. The major point I was trying to make is that toolkits like Tkinter and WxWindows, which try to delegate to the native widget sets whenever possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which reimpliment all the widgets from scratch, are doomed to fail. (IMO, of course). What I believe we need is a suitable abstraction which uses MFC on MS-Win platforms and Gtk+ on Unix. And which also doesn't, due to the abstraction, take away too many features. I don't know that much about MFC, but for a simple example - Gtk+ offers an option for its canvas widget to do all drawing in antialised mode (by the way, this is slow but produces very nice looking results). It would be a shame if the abstraction layer didn't allow for things like this to be used. > This is why, every time this debate comes up, we > end up sticking with Tk; it may suck, but all the other systems don't > support everything... Right. FWIW, in my day-to-day work, if it has to run on MS-Win I use Tkinter, and if MS-Win is not an issue I use PyGtk. Fermilab will be showing some network monitoring software at the Supercomputing 2000 conference next month, and it's mostly all stuff I whipped up a few days using Tkinter. From gmcm at hypernet.com Tue Oct 24 19:14:42 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 13:14:42 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F58B42.26855.490B8F73@localhost> Paul Prescod wrote: ... > .... It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. But that's exactly what COM does. not-to-be-taken-as-an-endorsement-ly y'rs - Gordon From akuchlin at mems-exchange.org Tue Oct 24 19:15:14 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 13:15:14 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid> Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote: >I'm waiting for the Tcl/Tk developers to grow up -- they still >fear that any attempt to make it easier to use Tk from other >languages would be to "give up the crown jewels" :-( In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. --amk From gvwilson at nevex.com Tue Oct 24 19:58:59 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson: > > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. > Guido van Rossum: > For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and > install our own Tcl/Tk binaries OK. > > Greg Wilson: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > Guido van Rossum: > Really? Are you sure that's not just general resistence against new things? Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development. Thanks, Greg From guido at python.org Tue Oct 24 21:04:55 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 14:04:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400." References: Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> > Well, my students' resistance to novelty is low enough that they're > willing to take a Python course :-). This comes up every time I > teach; no idea whether it has any impact on the usability of > completed applications, but I believe it makes people less likely to > choose Tkinter when starting development. Can you elaborate on the line of argument that you typically hear? What do you say to dispel it? --Guido van Rossum (home page: http://www.python.org/~guido/) From nas at arctrix.com Tue Oct 24 13:56:11 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 04:56:11 -0700 Subject: [Python-Dev] A small step to removing the type/class split Message-ID: <20001024045611.B9993@glacier.fnational.com> I've run into a problem with ExtensionClass which I believe can only be fixed by modifying Python. I will try to explain. I have an ExtensionClass which defines __cmp__. Depending on the objects being compared, the __cmp__ method may never be called. This is due to code in object.c that looks like this: if (PyInstance_Check(v) || PyInstance_Check(w)) { try to use use __cmp__ method } else { try number coerce and fall back on type name comparison } Extension classes can never pass the PyInstance_Check predicate. I've searched for all occurances of PyInstance_Check in the 2.0 source. In many places that PyInstance_Check occurs a more general "is this an instance-like type" check would seem to be more suitable. Here is my proposal: * Define a new type flag Py_TPFLAGS_INSTANCE. * Create a new predicate Py_IsInstance which checks for this flag. * Set this flag on PyInstance_Type. * Replace most occurances of PyInstance_Check with Py_IsInstance. Extension types (like ExtensionClass) can then define the type flag Py_TPLAGS_INSTANCE and be treated as an instance type by the Python interpreter. This should make it quite a bit easier to make extension types behave like "real" classes. Comments? Neil From mal at lemburg.com Tue Oct 24 21:37:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:37:30 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F5E4FA.9FD6D35@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > >... > > > > I think will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. AFAIR, the only truely feasable > > solution would be doing the rewrite in a widely portable > > subset of C++ and then managing classes at that level. > > I disagree for a variety of reasons: > > * implementation language and Python inheritance semantics are almost > completely distinct. After all, we have Python implementations in a > variety of languages with minor incompatibilities. Python could have a > proper type/class merging even if it were written in assembly language. > So let's leave implementation language aside. Hey, think of it as opportunity: we can reuse much of C++'s optimizations and the integration of Python and C++ applications will get *much* easier. A rewrite shouldn't scare anyone away -- much of the existing code can be reused since only the Python C APIs of the various types will have to be rewritten, not the logic behind the types. Besides, Py3K will be a project which runs in parallel to the 2.x development (at least that's what I've read on some BeOpen webpage), so there's really not much to worry about wrt to breakage, etc. People will be able to test-drive Py3K while using the 2.x series. > * there is a hell of a lot we can do to make the type/class split less > visible without a major rewrite. For instance, lists could have a > __getitem__ method so that they "act like" instances. Instances could > return their methods in a dir() so that they "act like" built-in > objects. So there is no reason to wait for a complete rewrite to start > on this path. Right. I didn't want to say that things cannot be done prior to the rewrite, only that a rewrite will give us much more options that we currently have. > * It may even be the case that we can get from here to complete merged > type/class semantics WITHOUT a rewrite. If a mad genious had not written > stackless Python I would have sworn up and down that stackless Python > would require a Python rewrite. It didn't. If another slightly less mad > genious had not integrated ints and longs I would never have believed it > possible without another rewrite. Someone needs to do an analysis of > what it takes to merge types and classes and *demonstrate* that it > requires a rewrite rather than *asserting* that it requires a rewrite. > > In other words, let's stop sprinkling the "major rewrite" pixie dust on > hard problems and instead decide where we want to go and how we want to > get there! See above. > > Moving to a common and very low-level strategy for classes > > will allows us to put even the most basic types (strings and > > numbers) into an inheritence tree. > > I don't know what you mean by a "low-level strategy" for classes. It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. Python's class handling is about as low-level as it can get > in my humble opinion. With "low-level" I meant trying to build Python classes and instances on top of a very thin layer on top of C++ classes, e.g. all slots could be implemented using true C++ methods with additional logic to override them using dynamically bound Python method objects. > > Differences like the > > ones between Unicode and 8-bit strings would then flesh > > out as two different subclasses of a generic string type which > > again is based on a generic sequence type. > > Of course that's where we want to go but it doesn't avoid the backwards > compatibility problems. Huh ? I was talking about clear design... not ways to avoid b/w compatibility. Merging Unicode and strings will hurt one way or another. This is simply a consequence of using strings as binary containers where Unicode is meant for text only use. > We can do this today using proxying. Could you explain this ? > > The same could be done for dictionaries: special ones for > > just string keys, case insensitive lookups, etc. could all > > be subclasses of a generic mapping class. > > We can easily do this today. No we can't: Python's use of pointer compares to find out which type it is dealing with prevent this. > > Dito for numbers (and division strategies). > > There's no way I'm going to let you get away with that little sleight of > hand. How is inheritance holy water going to allow us to change the > semantics of: > > 5/2 > > without breaking code?? > > The same goes for > > a.b = 5 > > versus > > a.B = 5 > > C++ does not help. Inheritance does not help. Pluggable compilers do not > help. We *will* break code. We just need to decide whether to do it in a > thoughtful way that gives people a chance to migrate or put off > decisions until the last possible moment and then spring it on them with > no between-version upgrade path. Just tell Python to use the correct class for what the code was written for (and this could be done by plugging in a 2.0 compiler). The instances of those classes would still work together with other semantics by virtue of exposing the same interface, yet the internals would work differently, e.g. a module using case insensitive lookup would be compiled using case insensitive dictionaries as namespaces. > > By following this principle there won't be all that much > > breakage, since the old functionality will still be around, > > only the defaults will have changed. > > When you change defaults you break code. Keeping the old functionality > around is barely helpful. Nobody has EVER proposed a change to Python > where something that was previously possible is now made impossible. So > whatever our strategy, the PROBLEM is changing defaults. The solution is > telling people what defaults are changing in what timeline and > discouraging them from depending on the old defaults. All true. I was just referring to the possibility of keeping the old semantics around in case some module relies on them. In this ideal world, a simple "define pythonlevel=2.0" would suffice to make the old module work with Py3k. > > Add to this pluggable compilers and ceval loops, plus a nice > > way of configuring the lot on a per-module basis and you're > > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) > > Sounds mythical. I'm trying to take it out of the realm of fluffy clouds > and bring it into the world that people can plan their businesses and > coding strategies around. Hmm, wasn't Py3k meant as sandbox for new experiments ? The 2.x series is for doing business with, IMHO at least. At the current dev speed we'll have plenty of time to get Py3k rock solid. Then we can add all the backward compatibility layers we want to it. If the design is a good, adding these layers won't pose much of a problem. Why spoil all the fun when we haven't even started thinking about all the possibilities we could use to make Py3k a success ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Oct 24 21:54:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:54:39 +0200 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F5E8FF.5F18C71E@lemburg.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Sounds fine, except that the "isinstance()" behaviour would have to be defined somewhere / somehow... a mapping of slots to __special_methods__ would be a good start. BTW, mxProxy does some of this mapping already... you may want to have a look. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm at hypernet.com Tue Oct 24 22:01:25 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 16:01:25 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F5B255.22108.49A43169@localhost> Greg Wilson: > > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > > many of the outfits I've dealt with (and not just with Python). > > > Guido van Rossum: > > Really? Are you sure that's not just general resistence against new things? > > Well, my students' resistance to novelty is low enough that they're willing to > take a Python course :-). This comes up every time I teach; no idea whether it > has any impact on the usability of completed applications, but I believe it > makes people less likely to choose Tkinter when starting development. As I see it, Tk, like SQL, has the property that it's dead easy to get something crappy running, but it takes a real expert (like /F) to make it good. With wxPython, though, it's easy (if somewhat tedious) to get something good - at least as far as normal "forms" style GUIs. I'm not taking sides - I dabble in both and will never be an expert at either. But for clients using Windows, I use wxPython because it's indistinguishable from native Win32. (BTW, MFC is lagging further and further behind native Win32 - I believe MS considers it "legacy".) - Gordon From barry at wooz.org Tue Oct 24 22:06:23 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT) Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <14837.60351.887533.801888@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> I've run into a problem with ExtensionClass which I believe NS> can only be fixed by modifying Python. I will try to explain. NS> I have an ExtensionClass which defines __cmp__. Depending on NS> the objects being compared, the __cmp__ method may never be NS> called. This is due to code in object.c that looks like this: | if (PyInstance_Check(v) || PyInstance_Check(w)) { | try to use use __cmp__ method | } | else { | try number coerce and fall back on type name comparison | } I hit a similar wall when I tried (a long time ago) to take a boolean class I'd written in Python and make it a built-in type. The problem was that in Python I could compare a Boolean instance against any other object for truth equivalence, but because of this hack, I couldn't do the same with the built-in type. | * Define a new type flag Py_TPFLAGS_INSTANCE. | * Create a new predicate Py_IsInstance which checks for this | flag. | * Set this flag on PyInstance_Type. | * Replace most occurances of PyInstance_Check with | Py_IsInstance. NS> Extension types (like ExtensionClass) can then define the type NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by NS> the Python interpreter. This should make it quite a bit NS> easier to make extension types behave like "real" classes. I'm not sure how well this addresses what I ran into. Would PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set? Does that actually make sense? How does this interact with the rich comparisons idea? Seems like this is a hack that doesn't quite get at the heart of the matter, worthwhile as it may be given the current implementation. -Barry From barry at wooz.org Tue Oct 24 22:11:54 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] getting at the current frame Message-ID: <14837.60682.437334.797392@anthem.concentric.net> I've been playing around with ideas for internationalizing Mailman, which naturally leads to string interpolation. To see why, think about making the following code translatable: def trade(yours, mine): print 'if you give me %s, i will give you %s' % (yours, mine) Because the order of the interpolated values may change in the translated string, you really have to do something like: def trade(yours, mine): print 'if you give me %(yours)s, i will give you %(mine)s' % { 'yours': yours, 'mine' : mine, } which actually will look something like this in real code: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % { 'yours': yours, 'mine' : mine, } The string wrapped in _() is what gets translated here. Okay, we all know that's a pain, right? Lots of people have proposed solutions. I've looked briefly at !?ng's Itpl.py, but I think it probably does too much by adding evaluation. I can define _() to make the problem somewhat more convenient: def _(s): try: raise Exception except Exception: frame = sys.exc_info()[2].tb_frame.f_back d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d Now I can write the code like this: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') All well and good and doable in Python today, except getting the current frame with the exception raising trick is slooow. A simple proposed addition to the sys module can improve the performance by about 8x: def _(s): frame = sys.getcaller(1) d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d The implementation of sys.getcaller() is given in the below patch. Comments? I think this particular addition is too small for a PEP, although ?!ng still owns PEP 215 (which needs filling in). -Barry -------------------- snip snip -------------------- Index: sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.78 diff -u -r2.78 sysmodule.c --- sysmodule.c 2000/09/01 23:29:28 2.78 +++ sysmodule.c 2000/10/24 17:50:30 @@ -15,6 +15,8 @@ */ #include "Python.h" +#include "compile.h" +#include "frameobject.h" #include "osdefs.h" @@ -284,6 +286,38 @@ } #endif +static char getcaller_doc[] = +"getcaller([depth]) -> frameobject\n\ +\n\ +By default, return the frame object at the top of the call stack. If an\n\ +integer depth is given, return the frame object that many calls below the\n\ +top of the stack. If that is deeper than the call stack, a ValueError is\n\ +raised."; + + +static PyObject * +sys_getcaller(PyObject *self, PyObject *args) +{ + PyFrameObject *f = PyThreadState_Get()->frame; + int depth = -1; + + if (!PyArg_ParseTuple(args, "|i:getcaller", &depth)) + return NULL; + + while (depth > 0 && f != NULL) { + f = f->f_back; + --depth; + } + if (f == NULL) { + PyErr_SetString(PyExc_ValueError, + "call stack is not deep enough"); + return NULL; + } + Py_INCREF(f); + return (PyObject*)f; +} + + #ifdef Py_TRACE_REFS /* Defined in objects.c because it uses static globals if that file */ extern PyObject *_Py_GetObjects(PyObject *, PyObject *); @@ -313,6 +347,7 @@ {"getrefcount", sys_getrefcount, 1, getrefcount_doc}, {"getrecursionlimit", sys_getrecursionlimit, 1, getrecursionlimit_doc}, + {"getcaller", sys_getcaller, 1, getcaller_doc}, #ifdef USE_MALLOPT {"mdebug", sys_mdebug, 1}, #endif From nas at arctrix.com Tue Oct 24 15:45:35 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 06:45:35 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400 References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net> Message-ID: <20001024064535.A10253@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote: [on Py_TPLAGS_INSTANCE] > I'm not sure how well this addresses what I ran into [with a > boolean extension type]. Would PyBooleanObject then have to > have it's Py_TPFLAGS_INSTANCE flag set? Does that actually > make sense? I think it would address your problem but I don't know if the name of the flag makes sense. Code around PyInstance_Check() usually looks like this: if (PyInstance_Check(obj)) { PyObject *foo = PyObject_GetAttrString(obj, "__foo__"); ... } else { ... } There is not a lot of code that assumes (obj->ob_type == PyInstance_Type) after a PyInstance_Check(). That's encouraging. > How does this interact with the rich comparisons idea? I don't know. I think I am trying to a address a deeper problem here. > Seems like this is a hack that doesn't quite get at the heart > of the matter, worthwhile as it may be given the current > implementation. Yes, I have that feeling as well. More deep thinking is probably required. :) Neil From mal at lemburg.com Tue Oct 24 22:45:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 22:45:28 +0200 Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <39F5F4E8.1188E1E0@lemburg.com> "Barry A. Warsaw" wrote: > [...] > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. I have a similar function in mxTools. I would use a different name though... something like "sys.getframe()". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 24 23:50:32 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 16:50:32 -0500 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST." <20001024045611.B9993@glacier.fnational.com> References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com> > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Good analysis of a problem -- but I disagree on the solution. Rather than formalizing the exceptions made for instances, we should work on eradicating the differences between classes and types. I believe that the plans for rich comparisons would or could also take care of this. I hope I'll have more time soon to explore this. --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at wooz.org Tue Oct 24 22:49:04 2000 From: barry at wooz.org (barry at wooz.org) Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <39F5F4E8.1188E1E0@lemburg.com> Message-ID: <14837.62912.897422.392307@anthem.concentric.net> >>>>> "M" == M writes: M> I have a similar function in mxTools. I would use a different M> name though... something like "sys.getframe()". Works for me. Thanks, -Barry From guido at python.org Wed Oct 25 00:16:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 17:16:00 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400." <14837.63819.667508.794728@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com> > GvR> Agreed. I think it's good to have the functionality > GvR> available, but it's also good to make it *real* clear not to > GvR> mess with it unless you really know what you're doing. Maybe > GvR> it should be in a separate module or at least have a leading > GvR> _underscore. > > I think you're fairly safe from mischief since the only writable > attributes of a frame object are f_trace, f_exc_type, f_exc_value, and > f_exc_traceback. The same caveats about f_globals and f_locals apply > as with the dicts returned by locals() and globals(). It's not so much that it's easy to do damage with. I have a philosophical problem with making this a feature that people can use whenever they feel like. It's a messy feature and its use should limited as an implementation aid for language features like variable substitution. The other, perhaps more major, problem with this it is that you can't easily wrap functions that use it in other functions. Normally, if there's a function foo(arg) that does something, I can write a function wrapfoo(arg) that does something else, then calls foo(arg), and then does another thing. But if foo() uses getframe(), that's not so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame. A way around this would be to implement foo as a call to (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()). Then _wrapfoo(arg, frame) could be defined as a wrapper around _foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()). This is another reason to be very selective in the use of getframe(). --Guido van Rossum (home page: http://www.python.org/~guido/) From nas at arctrix.com Tue Oct 24 16:37:12 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 07:37:12 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500 References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <20001024073712.A10539@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote: > Rather than formalizing the exceptions made for instances, we > should work on eradicating the differences between classes and > types. Yes, I see this now. Those PyInstance_Check() calls should really go away. Instead, the type should be responsible for providing different behavior. > I believe that the plans for rich comparisons would or could > also take care of this. I've just briefly looked at the proposal. It consists of two parts. One is splitting __cmp__ into __gt__, __lt__, etc. That is a separate issue to the one we are dicussing. The other part is directly related. In order for types to define their own comparison behavior, it proposes that types have an optional pointer to a rich comparison function in the type structure. I think this is the right idea but it doesn't go far enough. Every operation should be implementable by the type. Code like: if (PyString_Check(obj)) { something } else if (PyInstance_Check(obj)) { something else } ... should disappear unless it is need for performance reasons. I think we are close to achieving this goal. I'll try to come up with a proposal. Neil From barry at wooz.org Tue Oct 24 23:34:54 2000 From: barry at wooz.org (barry at wooz.org) Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> Message-ID: <14838.126.77589.541148@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> The other, perhaps more major, problem with this it is that GvR> you can't easily wrap functions that use it in other GvR> functions. Normally, if there's a function foo(arg) that GvR> does something, I can write a function wrapfoo(arg) that does GvR> something else, then calls foo(arg), and then does another GvR> thing. But if foo() uses getframe(), that's not so easy: the GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame. GvR> A way around this would be to implement foo as a call to GvR> (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, GvR> sys.getframe()). Then _wrapfoo(arg, frame) could be defined GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as GvR> _wrapfoo(arg, sys.getframe()). Darn good point. So where could we put it? It's a useful introspection device. If it goes in a separate module, should that perhaps be called `reflection'? Or maybe `runtime'? Or maybe "sys._getframe()" is good enough. -Barry From guido at python.org Wed Oct 25 01:13:43 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 18:13:43 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400." <14838.126.77589.541148@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com> > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. sys._getframe() is good enough. --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA at ActiveState.com Wed Oct 25 01:08:28 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: > Back in my former life, when I was still worrying about Windows, the > company I worked for bought into a commerical x-platform GUI toolkit > called Galaxy (I mentioned this earlier). Galaxy re-implemented all > the native widgets, kind of like XPFE does. One issue with this was > that MS seemed to change something about the widgets in every release > - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came > out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, > Win98 came out. Now I hear there's something called Windows ME. Have > they changed the look-and-feel again? Seems to me like all the > widget-reimplementors are doomed to playing eternal catch-up. Back in a former life of _mine_, I was one of two people who understood the architecture of Neuron Data's Open Interface Toolkit. It used the same strategy. Not sure what that has to do with Python, though it was a very fun project. It was also fun to turn on the Mac 'theme' on a Decwindows box (we're talking 1989 or so =). The funniest story about that job involves Cray and black and white monitors, but that's a story for another time, another place. --da From greg at cosc.canterbury.ac.nz Wed Oct 25 01:18:59 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT) Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Andrew Kuchling : > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. It appears that we can't rely on anyone else to provide and support a GUI properly across all three platforms. If we want one, it looks like we'll have to do it ourselves. How about reviving and building upon stdwin? I quite liked stdwin, despite its limitations, because it was small and simple, and it worked on both Mac and Unix. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From est at hyperreal.org Tue Oct 24 23:58:43 2000 From: est at hyperreal.org (est at hyperreal.org) Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT) Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org" at "Oct 24, 2000 05:34:54 pm" Message-ID: <20001024215843.7507.qmail@hyperreal.org> barry at wooz.org discourseth: > > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. Hmm..I'd think `reification' instead of `reflection'. My understanding was that reification involves taking an implicit language entity and making it an expressed value (e.g., getframe() or call_with_current_continuation()) while reflection goes in the opposite direction (e.g., eval()). pedantically, e From greg at cosc.canterbury.ac.nz Wed Oct 25 03:14:52 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT) Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <20001024073712.A10539@glacier.fnational.com> Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Neil Schemenauer : > Those PyInstance_Check() calls should really go away. Instead, the > type should be responsible for providing different behavior. Yes, that's the crux of the problem, I think. Another place where this is a nuisance is where it assumes that if x has any tp_as_sequence slots and y has any tp_as_number slots, then x*y is a sequence replication operation. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From esr at thyrsus.com Wed Oct 25 06:56:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 21:56:27 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid> Message-ID: <20001024215627.B1147@thyrsus.com> Fredrik Lundh : > > Can someone articulate why Tk should be replaced? > > beats me ;-) My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become effectively unmaintained in the foreseeable future. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr at thyrsus.com Wed Oct 25 07:29:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 22:29:17 -0700 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300 References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Message-ID: <20001024222917.I1147@thyrsus.com> Greg Ewing : > It appears that we can't rely on anyone else to provide and > support a GUI properly across all three platforms. If we > want one, it looks like we'll have to do it ourselves. I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance. -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From barry at wooz.org Wed Oct 25 05:11:54 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> Message-ID: <14838.20346.451094.231019@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. Cool, I'll upload the patch to SF. -Barry From barry at wooz.org Wed Oct 25 05:44:10 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> <14838.20346.451094.231019@anthem.concentric.net> Message-ID: <14838.22282.676715.200546@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. BAW> Cool, I'll upload the patch to SF. Patch #102106 http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 (includes doc patch) -Barry From tim_one at email.msn.com Wed Oct 25 09:10:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 03:10:36 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F54C0F.25798309@lemburg.com> Message-ID: [MAL] > ... > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. Not just to be my usual self , but I do see a from-scratch rewrite as being less likely as the years go by. There's nothing I know of in Guido's plans that can't be done incrementally instead -- and if he doesn't either, selling a total- rewrite project to an employer is probably impossible. The most successful projects I've seen and been on *did* rewrite all the code routinely, but one subsystem at a time. This happens when you're tempted to add a hack, realize it wouldn't be needed if an entire area were reworked, and mgmt is bright enough to realize that hacks compound in fatal ways over time. The "ain't broke, don't fix" philosophy is a good guide here, provided you've got a very low threshold for insisting "it's broke" <0.4 wink>. if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means- *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs - tim From moshez at math.huji.ac.il Wed Oct 25 09:49:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 24 Oct 2000, Guido van Rossum wrote: > Maybe we can do the same for Unix binary distributions? I don't know what you mean by "UNIX" binary distributions: each UNIX has its own sets of horrors in the distribution arena. Personally, I don't care what we do about RPMs, since I'm not a Red Hat user. However, this should probably be more Red Hat's job then ours. Debian, on the other hand, would probably do this much better then Python-Dev can, without gratutitous Tcl/Tk installations. For other unices, most people install from sources anyway, which mostly means I should get off my butt and start working on the Sumo interpreter. > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. I don't know how to break this to you, but you're not the average computer user . -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal at lemburg.com Wed Oct 25 10:10:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 25 Oct 2000 10:10:46 +0200 Subject: [Python-Dev] Gradual migration References: Message-ID: <39F69586.E017DA7E@lemburg.com> Tim Peters wrote: > > [MAL] > > ... > > I think this will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. > > Not just to be my usual self , but I do see a from-scratch rewrite as > being less likely as the years go by. There's nothing I know of in Guido's > plans that can't be done incrementally instead -- and if he doesn't either, > selling a total- rewrite project to an employer is probably impossible. > > The most successful projects I've seen and been on *did* rewrite all the > code routinely, but one subsystem at a time. This happens when you're > tempted to add a hack, realize it wouldn't be needed if an entire area were > reworked, and mgmt is bright enough to realize that hacks compound in fatal > ways over time. The "ain't broke, don't fix" philosophy is a good guide > here, provided you've got a very low threshold for insisting "it's broke" > <0.4 wink>. As I mentioned in the posting, the idea was from the "fluffy clouds" area. The rewrite would only involve the core type system and perhaps the core interpreter layout (parser, compiler, etc. all wrapped in classes) -- most of the existing code would be reusable. The idea behind this is somewhat like what you do when starting out a project based on a few simple functions and then reorganizing the code into a class-based approach. There's no need to rewrite all the type internals, just the type interfaces. Python has long reached a level of complexity that is counter- productive when it comes to adding new extension types. Just think of all the problems people have with coercion, the integration of user defined and internal types, the missing links between types and classes, etc. etc. BTW, why all the talk about "employers" ? Much of Python's code base was written without any employer knowing about it ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Wed Oct 25 12:40:56 2000 From: jim at interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:40:56 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <39F6B8B8.E3242929@interet.com> Andrew Kuchling wrote: > Can someone articulate why Tk should be replaced? I don't know whether Tk should replaced, but I can explain why I don't use it for our commercial Python application. It is just too big and complicated. Windows comes with a built-in GUI, and I hesitate to install another scripting language (Tcl) and its libraries, and then install a big system which has frequently been out of phase with Python releases just to access the Windows GUI. What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks. JimA From jim at interet.com Wed Oct 25 12:47:05 2000 From: jim at interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:47:05 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F6BA29.3CAB4C0E@interet.com> Guido van Rossum wrote: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. In the past I have resolutely demanded native Windows look and feel in my apps. In fact, I have been tiresome on the topic. Now I am changing my mind. Lots of prominent Windows apps now depart from Microsoft LAF, and I have the impression that users are getting used to it. I still think the usual File menu items and file open/save dialogs should be standard, but I am less concerned about other controls. For a look at how to really do controls, check out software for kids. Just my 1.e-2$. JimA From guido at python.org Wed Oct 25 14:11:35 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:11:35 -0500 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST." <20001024222917.I1147@thyrsus.com> References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> <20001024222917.I1147@thyrsus.com> Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com> > Greg Ewing : > > It appears that we can't rely on anyone else to provide and > > support a GUI properly across all three platforms. If we > > want one, it looks like we'll have to do it ourselves. Eric Raymond: > I fear this is much too big a job to be practical -- not just in the > additional code but the downstream maintainance. Well said. The "roll your own" approach has been attempted before, but simply isn't worth the time and effort. After all, Python is a glue language! (And stdwin would really look pathetic in this time.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 25 14:25:29 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:25:29 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400." <39F6B8B8.E3242929@interet.com> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> > Andrew Kuchling wrote: > > > Can someone articulate why Tk should be replaced? Jim Ahlstrom replied: > I don't know whether Tk should replaced, but I > can explain why I don't use it for our commercial > Python application. > > It is just too big and complicated. Windows comes > with a built-in GUI, and I hesitate to install > another scripting language (Tcl) and its libraries, > and then install a big system which has frequently been > out of phase with Python releases just to access the > Windows GUI. To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers. > What if a user calls with a problem? Why should I > have to debug their Tcl library path problems? No > thanks. The Tcl library paths are all taken care of by the new installer strategy. Really, give it a try. It Just Works! (SM) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 25 14:27:28 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:27:28 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400." <39F6BA29.3CAB4C0E@interet.com> References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com> > In the past I have resolutely demanded native Windows look > and feel in my apps. In fact, I have been tiresome on the topic. > > Now I am changing my mind. Lots of prominent Windows apps now > depart from Microsoft LAF, and I have the impression that users > are getting used to it. I still think the usual File menu > items and file open/save dialogs should be standard, but I > am less concerned about other controls. For a look > at how to really do controls, check out software for > kids. Just my 1.e-2$. Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player? --Guido van Rossum (home page: http://www.python.org/~guido/) From jim at digicool.com Wed Oct 25 14:21:41 2000 From: jim at digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:21:41 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <39F6D055.584C4FEA@digicool.com> Guido van Rossum wrote: > (snip) > Rather than formalizing the exceptions made for instances, we should > work on eradicating the differences between classes and types. Yee ha! I couldn't agree more. :) > I believe that the plans for rich comparisons would or could also take > care of this. I assume that rich comparison's have new slots with signatures that don't assume objects of the same type. > I hope I'll have more time soon to explore this. Me too. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jim at digicool.com Wed Oct 25 14:25:53 2000 From: jim at digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:25:53 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F6D151.70F47CFF@digicool.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: (snip) I think you got some good answers later in the thread. I'll point out that a work around is to make your ExtensionClass a numeric type. Numeric types have different comparison semantics that allow you to get around this limitation. I did this a few months back for acquisition wrappers. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From gvwilson at nevex.com Wed Oct 25 14:38:12 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> Message-ID: > Guido van Rossum: > Can you elaborate on the line of argument that you typically hear > [objections to Tkinter]? What do you say to dispel it? From guido at python.org Wed Oct 25 15:53:48 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 08:53:48 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400." References: Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> > From some feedback forms from old runs of my Python course (with spelling > corrections :-) > > 1. "My users don't care what programs are written in. They just care > if they're easy to use. They won't care if Python programs have > the same look and feel on different computers, because they won't > ever think of [name of program] as a Python program. To them, it > will be a Windows program that looks funny." > > 2. "You said three times in the intro lecture this morning that the > most important thing in a GUI was consistency. Then you told us to > write GUIs that look different from everything else on the desktop." > > 3. "I'm confused: I didn't realize that Python was a library on top of > TCL." > > I spent a minute drawing blob diagrams to answer #3; I think most students > understood, but the person who asked the question was clearly still confused. > > I didn't try to dispel #1 or #2, because I agree with them: my > experience is that consistent look and feel are crucial for making > non-programmers less afraid of pressing the wrong button or making > the program "do weird things". Other people with more experience > creating end-user applications may have different views. This is helpful. Can you elaborate on what elements of the Windows look-and-feel are missing in Tkinter? As far as I know, the menu bars, file selection dialogs, scroll bars, dialog boxes and so on have a thoroughly native look-and-feel, since Tk implements these as wrappers around the native widgets. IDLE doesn't look very different from Notepad! So what's missing? A toolbar with icons? That would be easy to add using existing Tk controls (Pmw has it too). The multiple document interface? It sucks -- and even Word 2000 has gone away from that! What kind of GUIs did you teach them exactly? If you started with basic Tkinter widgets, sure, it looks different than anything else. But that depends on the widget layout in the program, not on the widget library used! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at scottb.demon.co.uk Wed Oct 25 15:55:40 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 25 Oct 2000 14:55:40 +0100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <002301c03e8b$42cbc280$060210ac@private> I choose to use wxPython over TK because: 1. wxPython has a reasonable event model 2. wxPython allows me build one object hierarchy 3. TK requires I manage two object hierarchies, TK's and my classes 4. Hooking events to TK seems clumsy from Python As others have said better docs on wxPython would be nice and its to easy to crash the world from wxPython. Barry From claird at starbase.neosoft.com Wed Oct 25 16:58:53 2000 From: claird at starbase.neosoft.com (Cameron Laird) Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters Message-ID: <200010251458.JAA77237@starbase.neosoft.com> I can rarely afford to dip into Python-Dev. My head is exploding too much of the time as it is. Maybe I can help with the recent Tkinter discussions, though. 1. Tcl's going to be around for a long time. Here's the insider scoop on what the Ajuba Solutions announcement means: insiders don't know. That is, *nobody* is sure how Tcl will develop. It'll survive, though, for quite a while. Do NOT worry that it'll suddenly dry up and blow away. I'm working on a more detailed explanation of Tcl processes. It'll probably take a few weeks, though. In the meantime, just ignore the mess, and understand that the Tcl Core Team includes bright people who'll land on their feet somehow. 2. I agree that MacOS is the thorny problem for the standard Pysolution. I'd be happy to discuss the possibilities (Tkinter? wxWindows? Qt?!? GTK+?!!?!? ...) with a smaller group, and, of course, Fredrik, Robin, Guido, ... all are quite knowledgeable about these matters. There are a few things you should know about the Tcl side. The bad is that Tk is barely maintained for MacOS. It's really rather miserable. On the other hand, Jim Ingham is now an Apple employee, and things could change in a hurry, at any time. The good is that Tk starts far ahead of any competitor. It has already solved most of the hard problems. All it needs is a little maintenance. 3. Is there a way to have Tk without contamination by Tcl? More than ever. This is what makes me most cheerful about Tkinter's prospects. The Tcl Core Team has largely given up its hangups about co-operating with foreigners (or its hangups that barbarians have hangups about co- operating with Tcl). This is a *very* good time for someone like Fredrik to establish a working relationship, and get CVS access. I really think Tk can be maintained by a different group than Tcl. Perl, Ruby, ... folks are also receptive to the idea (I've talked with them). For pointers to some of what's happening in this area, see Also, you should know that my favorite enhancement to Tk is a remodularization called TkGS. This should improve performance under Win*, make it more portable to BeOS, improve access by Python, and so on. 4. Greg's right that some publishers are dumping Tcl. Not all, though. If it matters, we can go into details. 5. Pango is indeed cool, but it's different from [text]. The world is probably moving to Pango and similar implementations. The world will be missing much of what [text] offers. 6. ANYONE with an urge to get out a Python-related idea should pursue it. *DDJ*'s a great outlet. It's far from the only one. If people have ideas about articles, but are held back by lack of time/ fluency/contacts/..., *please* get in touch with me. I'll find a way at least to give articles a fair chance at being published. Cameron Laird +1 281 996 8546 FAX http://starbase.neosoft.com/~claird/misc.writing/publications.html From cgw at fnal.gov Wed Oct 25 17:31:38 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com> References: <200010251458.JAA77237@starbase.neosoft.com> Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov> Cameron Laird writes: > I can rarely afford to dip into Python-Dev. My head is exploding > too much of the time as it is. > > Maybe I can help with the recent Tkinter discussions, though. > 2. I agree that MacOS is the thorny problem for > the standard Pysolution. What is the impact of the fact that MacOS X will run X? Doesn't this open the door to a lot of new possibilities, at least if we don't need to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just way too big to even think about dropping (or deprecating) support for it? From tim_one at email.msn.com Wed Oct 25 18:23:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 12:23:30 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: [Guido, on finding Tcl/Tk under Windows] > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. That's different -- > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > installer was optionally run. The version issues are also resolved > this way: you are guaranteed to get exactly the Tcl/Tk version that > was tested by the developers. Unless you're Fredrik, alas . Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course). >> What if a user calls with a problem? Why should I >> have to debug their Tcl library path problems? No >> thanks. > The Tcl library paths are all taken care of by the new installer > strategy. > > Really, give it a try. It Just Works! (SM) I'll second that! "Mystery startup errors" from the Python+Tcl+Tk+Windows combo were at least weekly questions on c.l.py for 1.5.2, often daily. I've seen none for 1.6 or 2.0. and-all-it-took-was-avoiding-ms's-recommended-practices-ly y'rs - tim From guido at python.org Wed Oct 25 19:46:55 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 12:46:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400." References: Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com> > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. [Tim] > Unless you're Fredrik, alas . Apparently Tcl still honors library > envars first if they exist, and if some other installation or use of Tcl/Tk > set those, you can still end up w/ a mix. *Much* better than before, though, > and I don't recall ay instance of this happening in real life so far apart > from /F (who had no problem figuring it out, of course). Hm... In FixTk, TCL_LIBRARY is set explicitly. Perhaps it should set TK_LIBRARY explicitly too? --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm at ActiveState.com Wed Oct 25 19:11:42 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 25 Oct 2000 10:11:42 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400 References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <20001025101142.B8625@ActiveState.com> On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote: > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. > > Unless you're Fredrik, alas . ...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it. Trent -- Trent Mick TrentM at ActiveState.com From pf at artcom-gmbh.de Wed Oct 25 19:02:45 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST) Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am" Message-ID: Hi, Charles G Waldman: > > 2. I agree that MacOS is the thorny problem for > > the standard Pysolution. > > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? It will take years, before MacOS X will find its way onto the desk of the average Apple Mac user. The Mac s mostly used in the graphics and printing industry (our cutsomers) where people normally don't even think about a OS upgrade, if they don't have to. They usually run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other so called creative software on the version of the OS they had on the machine when they bought it. THese machines are usually used through a period of at least four years. So MacOS X might simplify things for software vendors from 2004 on and later. Regards, Peter From guido at python.org Wed Oct 25 20:21:58 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:21:58 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST." <20001025101142.B8625@ActiveState.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> > ...Or anybody installing ActivePython for that matter. We give instructions > that the latest version of Tcl/Tk has to be installed separately, but Tk is > *not* bundled with it. And that's a shame. Any chance that will be fixed any time soon? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at alum.mit.edu Wed Oct 25 15:36:46 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> ...Or anybody installing ActivePython for that matter. We give >> instructions that the latest version of Tcl/Tk has to be >> installed separately, but Tk is *not* bundled with it. GvR> And that's a shame. Any chance that will be fixed any time GvR> soon? I think a version of Tkinter packaged with a distutils setup script is the best answer for Unix platforms. As a Linux user, I do *not* want to install a second copy of Tcl/Tk. If we have a distutil-Tkinter, e.g. ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz then a user can download it and run "python setup.py install" to build a Tkinter against their installed version of Tk. This will be straightforward on many Linux systems, because they ship with Tk installed. Jeremy From jeremy at alum.mit.edu Wed Oct 25 15:41:30 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT) Subject: [Python-Dev] build problems under Solaris Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net> There are two bug reports about build problems under Solaris (117508 and 117606). I don't have access to a Solaris machine, so I can't do anything to help these users. Since ActivePython is shipped for Solaris, I assume that you (or someone else at AS) does have access to a Solaris machine. Can you take a look at these problems? Or assign them to someone else who can? Jeremy From guido at python.org Wed Oct 25 20:50:07 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:50:07 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400." <14838.57838.841831.632628@bitdiddle.concentric.net> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> > I think a version of Tkinter packaged with a distutils setup script is > the best answer for Unix platforms. As a Linux user, I do *not* want > to install a second copy of Tcl/Tk. Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was, so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself, one for Python+Tkinter, one for Perl/Tk (that's a separate code base anyway so you already have this today -- if you install Perl/Tk, that is), and one for Ruby. Given modern disk sizes I don't think it's a problem. We do the same for Windows, for good reasons: so we can be independent of whatever Tcl/Tk version is already installed. > If we have a distutil-Tkinter, e.g. > ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz > then a user can download it and run "python setup.py install" to build > a Tkinter against their installed version of Tk. This will be > straightforward on many Linux systems, because they ship with Tk > installed. Of course that's easier. But less robust. (And why is there an "8.0" in the filename if it works with other Tcl/Tk versions???) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Wed Oct 25 20:11:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:11:34 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> Message-ID: <39F72256.C7F93BFB@prescod.net> "M.-A. Lemburg" wrote: > > ... > > > * implementation language and Python inheritance semantics are almost > > completely distinct. After all, we have Python implementations in a > > variety of languages with minor incompatibilities. Python could have a > > proper type/class merging even if it were written in assembly language. > > So let's leave implementation language aside. > > Hey, think of it as opportunity: we can reuse much of C++'s > optimizations and the integration of Python and C++ applications > will get *much* easier. We could make integrating C++ and Python easier through CXX or Py_Cpp. Perhaps we should ship one of those with Python 2.1. Anyhow, integrating C++ and Python is not really so hard, in my experience. > A rewrite shouldn't scare anyone away -- much of the existing > code can be reused since only the Python C APIs of the various > types will have to be rewritten, not the logic behind the types. I wasn't really addressing the issue of backwards compatibility of extensions -- I was talking about Python programs. Nevertheless, I can't resist: Porting your app to the Python APIs is often the majority of the work in a particular extension. A lot of Python extensions consist only of API glue! > Besides, Py3K will be a project which runs in parallel to the > 2.x development (at least that's what I've read on some BeOpen > webpage), so there's really not much to worry about wrt to > breakage, etc. People will be able to test-drive Py3K while > using the 2.x series. I don't see how that helps. If you can't write programs that work both on the old interpreter and the new one then you need to have a "switch over" day. The whole point of my doctrine is that Python 3K should run all code that the version of Python immediately before it did. The most it can do in terms of breakage is to warn about error messages. In that case it doesn't matter much whether Python 3K is available at the same time as 2.X or emerges from Guido's head fully formed. > > * there is a hell of a lot we can do to make the type/class split less > > visible without a major rewrite. For instance, lists could have a > > __getitem__ method so that they "act like" instances. Instances could > > return their methods in a dir() so that they "act like" built-in > > objects. So there is no reason to wait for a complete rewrite to start > > on this path. > > Right. I didn't want to say that things cannot be done prior > to the rewrite, only that a rewrite will give us much more > options that we currently have. Okay, so do you agree with the rule expressed here: http://www.python.org/pipermail/python-dev/2000-October/016785.html > > I don't know what you mean by a "low-level strategy" for classes. It's > > not like we can somehow use C++ vtables without giving up Python's > > dynamicity. Python's class handling is about as low-level as it can get > > in my humble opinion. > > With "low-level" I meant trying to build Python classes and > instances on top of a very thin layer on top of C++ classes, > e.g. all slots could be implemented using true C++ methods with > additional logic to override them using dynamically bound > Python method objects. I don't think that there is really interesting magic in a C++ compiler. A vtable is an array of pointers to functions. We've already implemented the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and smart pointers are a little more interesting from a code maintenance and simplicity point of view. But even then I think that we could get to a C++ implementation through incremental rewrites. > > > Differences like the > > > ones between Unicode and 8-bit strings would then flesh > > > out as two different subclasses of a generic string type which > > > again is based on a generic sequence type. > > > > Of course that's where we want to go but it doesn't avoid the backwards > > compatibility problems. > > Huh ? I was talking about clear design... not ways to avoid > b/w compatibility. But the whole point of my original article was backwards compatibility!!! I didn't address an implementation strategy for Py3K at all. > Merging Unicode and strings will hurt one > way or another. This is simply a consequence of using strings > as binary containers where Unicode is meant for text only use. The question I wanted to address is how we can *minimize the pain*. > ... > > C++ does not help. Inheritance does not help. Pluggable compilers do not > > help. We *will* break code. We just need to decide whether to do it in a > > thoughtful way that gives people a chance to migrate or put off > > decisions until the last possible moment and then spring it on them with > > no between-version upgrade path. > > Just tell Python to use the correct class for what the > code was written for (and this could be done by plugging in > a 2.0 compiler). The instances of those classes would still work > together with other semantics by virtue of exposing the same > interface, yet the internals would work differently, e.g. > a module using case insensitive lookup would be compiled using > case insensitive dictionaries as namespaces. A mode switch solutiion is fraught with dangers. First there is the issue of the correct default for the mode switch. http://www.python.org/pipermail/python-dev/2000-April/010029.html Second, there are dangers cutting and pasting between modules. Anyhow, even if we allow a mode switch we need to be able to help people to upgrade their modules in a reasonable time. That's what the message I cited advocates. >... > Why spoil all the fun when we haven't even started thinking > about all the possibilities we could use to make Py3k a > success ? Asking for a map of where we are going and how we will get here is "spoiling all of the fun?" I'm not sure what you are reacting to -- I didn't advise one implementation strategy or another -- I just said that we should employ a strategy that minimizes sudden and surprising code breakage. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From fdrake at acm.org Wed Oct 25 20:06:50 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From paul at prescod.net Wed Oct 25 20:18:16 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:18:16 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <39F723E8.2AC6787@prescod.net> Charles G Waldman wrote: > > ... > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? Would Mac users go for: "first install X. Then you can run Python." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido at python.org Wed Oct 25 21:14:57 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 14:14:57 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400." <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com> > > Why not? Because if every app using Tcl/Tk did that there would be > > hundreds of copies of Tcl/Tk on your disk? I don't think that > > argument flies; only a few other major languages use Tcl/Tk this was, > > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? Of course not, but large and important ones may. Some already do, e.g. Alice, Zope, Ultraseek. I have no problem with this. (The saving grace is that none of these needs to recursively include Tcl. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From gvwilson at nevex.com Wed Oct 25 20:17:24 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT) Subject: [Python-Dev] Gradual migration In-Reply-To: <39F72256.C7F93BFB@prescod.net> Message-ID: > Paul Prescod: > Anyhow, integrating C++ and Python is not really so hard, in my experience. ...unless you are using heavily-templated code, e.g. every damn class you've been asked to wrap up seems to be derived from something in the STL... Greg From cgw at fnal.gov Wed Oct 25 20:18:56 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <39F723E8.2AC6787@prescod.net> References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov> Paul Prescod writes: > > Would Mac users go for: "first install X. Then you can run Python." > I should probably just shut up, because I really don't know enough about Mac OS X, but what I was wondering is whether OS X will actually *use* the X Window System. Of course we don't want to tell users that they have to go install X on their own. From tim_one at email.msn.com Wed Oct 25 20:18:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 14:18:55 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: [Guido] > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, [Fred Drake] > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? So long as Python doesn't guarantee binary compatibility across releases, that's the only thing that works. Play PySol lately ? From paul at prescod.net Wed Oct 25 20:27:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:27:33 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov> Message-ID: <39F72615.40B38862@prescod.net> Charles G Waldman wrote: > >... > > I should probably just shut up, because I really don't know enough > about Mac OS X, but what I was wondering is whether OS X will actually > *use* the X Window System. Of course we don't want to tell users that > they have to go install X on their own. And become just another Unix? Then how would they get people to pay the Macintosh usability premium? Seriously, maybe someday as a "Linux compatibility mode" but I don't think it is officially proposed. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Wed Oct 25 20:30:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:30:34 -0700 Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) References: Message-ID: <39F726CA.9D472E50@prescod.net> Peter Funk wrote: > > .. > > Bruce Sherwood and David Scherer suggested a IMHO very clever solution to > this particular problem in March/April this year. This thread was first > posted to idle-dev and afterwards X-posted to python-dev: > > http://www.python.org/pipermail/idle-dev/2000-April/000138.html > http://www.python.org/pipermail/idle-dev/2000-April/000140.html > http://www.python.org/pipermail/python-dev/2000-April/010029.html Tim's last message on it doesn't sound overwhelmingly positiive to me! Also, don't forget that Python is also a command line so "version pragmas" cause additional complexity there. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From DavidA at ActiveState.com Wed Oct 25 20:59:35 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time) Subject: [Python-Dev] build problems under Solaris In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net> Message-ID: On Wed, 25 Oct 2000, Jeremy Hylton wrote: > There are two bug reports about build problems under Solaris (117508 > and 117606). I don't have access to a Solaris machine, so I can't do > anything to help these users. Since ActivePython is shipped for > Solaris, I assume that you (or someone else at AS) does have access to > a Solaris machine. Can you take a look at these problems? Or assign > them to someone else who can? Sure, we'll take a look. --david From akuchlin at mems-exchange.org Wed Oct 25 23:51:40 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 17:51:40 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: I'd like to begin writing an article about 2.0's Unicode support. Before beginning, has anyone else already begun this task? If yes, please let me know... (Incidentally, did a 2.0 press release ever go out? Is someone going to write one?) --amk From MarkH at ActiveState.com Thu Oct 26 00:18:27 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 09:18:27 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: [Trent] > > ...Or anybody installing ActivePython for that matter. We > > give instructions that the latest version of Tcl/Tk has to > > be installed separately, but Tk is *not* bundled with it. [Guido] > And that's a shame. Any chance that will be fixed any time soon? Not presuming to speak for anyone, least of all the ActivePython product manager :-) I don't think it will be "fixed", as it is not considered "broken". It was an explicit choice to leave out Tcl/Tk. And my recollection is that the "feedback" address sees more requests for wxPython than Tcl/Tk. We make it pretty clear Tcl/Tk is not included - I assume that everyone who cares about that simply uses BeOpen releases or source tarballs. [When I say "wont be fixed", I mean it is unlikely to appear in the core ActivePython release. It almost certainly will be supported as an add-on, whatever that turns out to mean exactly ;-] Mark. From guido at python.org Thu Oct 26 02:15:31 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 19:15:31 -0500 Subject: [Python-Dev] 2.0 articles In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400." References: Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) No; and not me... --Guido van Rossum (home page: http://www.python.org/~guido/) From MarkH at ActiveState.com Thu Oct 26 01:29:52 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 10:29:52 +1100 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: [From a mail in idle-dev - dropped idle-dev and all CCs] [idle-dev poster] > > >>> import sys > > >>> f = open('some-output-file', 'w') > > >>> sys.stdout = f > > >>> # do some stuff > > >>> sys.stdout = sys.__stdout__ > > > > Because on entry, sys.stdout is already redirected > > (not reflected in sys.__stdout__) [Guido] > Where did you get this idiom? You should never use sys.__stdout__ > this way! The proper idiom is > > save_stdout = sys.stdout > try: > sys.stdout = f > # do some stuff > finally: > sys.stdout = save_stdout > > If you know of any places that are promoting direct use of __stdout__, > please let them know this is wrong. If you are contemplating to use > this in code examples you intend to distribute, please don't! I admit that I first became aware of sys.__stdout__ after seeing this exact same idiom in other peoples code. I always assumed that this is _exactly_ what sys.__stdout__ was to be used for! The following examples exist: * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. * Tools/il8n/pygettext.py - ditto * Tools/idle/PyParse.py - disabled, debugging output function - presumably to get around sys.stdout redirection - but this sounds suspect as an idiom to me too! So what _is_ it intended for? Mark. From greg at cosc.canterbury.ac.nz Thu Oct 26 02:16:02 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz> > If you started with basic Tkinter widgets, sure, it looks different > than anything else. But that depends on the widget layout in the > program, not on the widget library used! This is one of my main gripes about the Tk API. The default behaviours of all its layout managers suck. In order to get a layout that looks pleasant and/or conforms to some style guide, you have to set a whole slew of options every time you place a widget. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From barry at wooz.org Thu Oct 26 02:17:38 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.30754.217582.20441@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> * Tools/il8n/pygettext.py That's embarassing. ;) Here's a patch, but I'm not going to check it in because I think a /much/ better idiom to adopt is to use extended print instead. I need to make some updates to pygettext.py soon, so I'll probably just 2.0-ify it at the same time. -Barry -------------------- snip snip -------------------- Index: pygettext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v retrieving revision 1.9 diff -u -r1.9 pygettext.py --- pygettext.py 2000/05/02 19:28:30 1.9 +++ pygettext.py 2000/10/26 00:16:22 @@ -283,6 +283,7 @@ options = self.__options timestamp = time.ctime(time.time()) # common header + stdout = sys.stdout try: sys.stdout = fp # The time stamp in the header doesn't have the same format @@ -314,7 +315,7 @@ print 'msgid', normalize(k) print 'msgstr ""\n' finally: - sys.stdout = sys.__stdout__ + sys.stdout = stdout def main(): From gmcm at hypernet.com Thu Oct 26 02:39:14 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 25 Oct 2000 20:39:14 -0400 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <39F744F2.17759.4FC8E6D4@localhost> > [Guido] > > > Where did you get this idiom? You should never use sys.__stdout__ > > this way! The proper idiom is > > > > save_stdout = sys.stdout > > try: > > sys.stdout = f > > # do some stuff > > finally: > > sys.stdout = save_stdout [Mark] > So what _is_ it intended for? A fail-safe. The recommended idiom might also be called "plays well with others"; a barbarian notion that fortunately has not infected most import hacks or program exits... works-for-me-so-buzz-off-ly y'rs - Gordon From akuchlin at mems-exchange.org Thu Oct 26 04:40:03 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 22:40:03 -0400 Subject: [Python-Dev] 2.0 press release In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500 References: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us> On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote: >> (Incidentally, did a 2.0 press release ever go out? Is someone going >> to write one?) >No; and not me... Little-known fact: Guido actually does nothing but sit in his pyjamas (with feet!) all day, drinking cocoa, eating Hostess Twinkies and watching Tiny Toons, while his long-suffering co-workers implement and debug the fantastically complex algorithms that go into Python. Here's some rough text: Can someone with a clue about writing a good press release give this a look? --amk Reston, VA, Oct 25 2000: The Python development team today announced the release of version 2.0 of the Python programming language. Version 2.0 adds a number of significant new features: * Unicode support, in the form of a new Unicode data type, library additions for conversion to/from various encodings, and support for displaying Unicode strings in Tk widgets. * New language features: garbage collection of cycles, list comprehensions, augmented assignment, string methods. * Distutils, a new system for making Python modules and extensions easily available to a wider audience with very little overhead for build/release/install mechanics. * Improved XML support, including support for the Simple API for XML (SAX2), a miniature Document Object Model (DOM), and the Expat parser. * Many library improvements, including HTTP/1.1 support, an enhanced curses module, the ability to read and write ZIP-format files, support for the Windows registry, and many more minor improvements. * Ports to new platforms: 64-bit Windows on the Itanium processor, Windows CE, and Darwin/MacOS X. Python is an interpreted, object-oriented, high-level programming language. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for rapid application development, as well as for use as a scripting or glue language to connect existing components together. Python's simple, easy to learn syntax emphasizes readability and therefore reduces the cost of program maintenance, and it supports modules and packages, encouraging program modularity and code reuse. Many extension modules for Python have been written to interface with other libraries and applications. Some of the available modules include: * Support for many relational databases (Oracle, Sybase, MySQL) * GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME) * Internet protocols (LDAP, WebDAV, XML-RPC, SOAP) * Mathematics (Numeric Python) Python is used for many different purposes, particularly cross-platform rapid development, Web development, and scripting of scientific applications. Some of the applications using Python include: * Zope, the leading Open Source web application server * The Mailman mailing list manager * The Reportlab PDF document generation toolset * XXX suggestions? XXX too darn many lists here? The Python interpreter and the extensive standard library are available free of charge and are distributed under an open-source license. Ports have been made to all major platforms, such as Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.) New versions are developed collaboratively by a core group of over 20 developers. About BeOpen: About Python: More information about Python can be obtained from the official Python website, http://www.python.org. (XXX Do you include About sections for the companies that provide quotes?) Press contacts: XXX whose address? From guido at python.org Thu Oct 26 06:02:11 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 23:02:11 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100." References: Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com> > So what _is_ it intended for? Example: IDLE redirects sys.stderr so that it gets displayed in the Python Shell window with a different text color. But occasionally I need to debug IDLE and the bug is in the text drawing. Then it's nice if I can write to __stderr__, which goes to the console. Or suppose I'm in a regular interactive session and I've managed to screw myself by assigning a bogus file object to sys.stdout (it happens :-). If I know that, I can type sys.stdout = sys.__stdout__ at the >>> prompt and save myself -- so I don't have to restart the session and perhaps lose valuable data. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at acm.org Thu Oct 26 05:55:13 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Mark Hammond writes: > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. > * Tools/il8n/pygettext.py - ditto I've just fixed these two; too bad checkin messages aren't getting sent. ;( > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > to get around sys.stdout redirection - but this sounds suspect as an idiom > to me too! I've left this one for someone with a good idea about what to do about it. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake at acm.org Thu Oct 26 06:31:33 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <20001025222406.A8389@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> [Moved over from a discussion in the bugs list; this relates to bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470 Please be sure to CC: Jon on all replies.] Jon Ribbens writes: > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without > changes is unexpected enough to warrant mentioning in a paragraph of its > own, completely explicitly. The '.in' suffix is usually used for files which > autoconf is going to use to create a new file from - you cannot usually > simply copy the file yourself. An experienced admin installing Python is > more likely to believe the README is wrong than what it tells them to do > is correct. Why does the Setup.in file exist in the first place? Surely it > should be named 'Setup.dist' (and an identical file 'Setup' exist right from > the start). Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. Since this doesn't help if the source and build directories differ, configure.in can be modified to create Setup if (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. I have the changes to configure.in, configure, Setup*, and Modules/Makefile.pre.in ready, but I still need to update the instructions in the README & possibly elsewhere. Does this sound agreeable? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From effbot at telia.com Thu Oct 26 09:15:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 09:15:45 +0200 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid> mark wrote: > > If you know of any places that are promoting direct use of __stdout__, > > please let them know this is wrong. If you are contemplating to use > > this in code examples you intend to distribute, please don't! > > I admit that I first became aware of sys.__stdout__ after seeing this exact > same idiom in other peoples code. I always assumed that this is _exactly_ > what sys.__stdout__ was to be used for! > > The following examples exist: and several examples in the eff-bot guide. guess I'll have to fix it in the second edition... From ping at lfw.org Thu Oct 26 10:09:44 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: On Tue, 24 Oct 2000, Barry A. Warsaw wrote: > > Okay, we all know that's a pain, right? Lots of people have proposed > solutions. I've looked briefly at !?ng's Itpl.py, but I think it > probably does too much by adding evaluation. Do you think a variant of Itpl that only looked up variable names would solve your problem? > I can define _() to make the problem somewhat more convenient: > > def _(s): > try: > raise Exception > except Exception: > frame = sys.exc_info()[2].tb_frame.f_back > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d How about this routine to get the current frame: inspect.currentframe(). Could i humbly re-request approval for inspect.py in the standard library? http://lfw.org/python/inspect.py It's been up there for a long time, there's lots of good stuff in it, and previous feedback on this list has all been fairly positive -- there just hasn't been an explicit approval for inclusion. This is probably because we were busy trying to get 2.0 released (even though inspect.py was proposed here before ascii.py, and ascii.py did get accepted). I think the functionality it provides is important to supporting the language definition. It abstracts away the special secret attributes and protects us from future changes in the internals. If there are changes that need to be made before it can be accepted, i'd be happy to make them. -- ?!ng From effbot at telia.com Thu Oct 26 10:36:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 10:36:14 +0200 Subject: [Python-Dev] getting at the current frame References: Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py > > It's been up there for a long time hey, you still haven't fixed the *2 bug... > I think the functionality it provides is important to supporting the > language definition. It abstracts away the special secret attributes > and protects us from future changes in the internals. agreed. > inspect.py was proposed here before ascii.py, and ascii.py did get > accepted as part of the curses package, yes. From ping at lfw.org Thu Oct 26 10:53:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid> Message-ID: On Thu, 26 Oct 2000, Fredrik Lundh wrote: > > It's been up there for a long time > > hey, you still haven't fixed the *2 bug... Sorry -- looks like an older version than the one i have on my local disk, which did get fixed. The one on the website is now up to date. http://lfw.org/python/inspect.py -- ?!ng From jon+sourceforge at unequivocal.co.uk Thu Oct 26 11:39:01 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 10:39:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <20001026103901.A11873@snowy.squish.net> "Fred L. Drake, Jr." wrote: > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > Does this sound agreeable? Sounds cool. I would mention in the first part of the install instructions about the Setup file, that you edit it to change the available modules (this concept is not obvious if you don't know how Python works!), that you can edit it now but if you have not installed Python before it is best to try building without editing it first and that there are more instructions further down the README. You might like to mention 'readline' here too to head-off newsgroup questions about why up-arrow doesn't work ;-). Cheers Jon From guido at python.org Thu Oct 26 13:38:34 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:38:34 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400." <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> > > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > > to get around sys.stdout redirection - but this sounds suspect as an idiom > > to me too! > > I've left this one for someone with a good idea about what to do > about it. Don't touch it! This one is needed because at this point sys.stdout and sys.stderr are redirected to a window where you don't want the parser debug output to show up. (I mentioned this example in my previous post.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 26 13:45:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:45:49 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400." <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com> [Fred] > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > I have the changes to configure.in, configure, Setup*, and > Modules/Makefile.pre.in ready, but I still need to update the > instructions in the README & possibly elsewhere. > Does this sound agreeable? Sure, except I'm not comfortable with having two files with identical contents under CVS control. How about not checking in Setup, but creating it in configure if it doesn't exist? This is necessary also for the following reason: when you build in a different tree than the source tree, you should get a fresh copy of Setup in the build tree -- another copy of Setup in the source tree is useless. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 26 13:48:20 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:48:20 -0500 Subject: [Python-Dev] getting at the current frame In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST." References: Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py To avoid that we forget about this again, and to make sure it gets proper treatment, could you submit it through the patch manager? No need to turn it into a context diff, just upload the entire file. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Thu Oct 26 12:21:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:21:05 +0200 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300 References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Message-ID: <20001026122105.N12812@xs4all.nl> On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote: > Neil Schemenauer : > > Those PyInstance_Check() calls should really go away. Instead, the > > type should be responsible for providing different behavior. > Yes, that's the crux of the problem, I think. > Another place where this is a nuisance is where it > assumes that if x has any tp_as_sequence slots and y > has any tp_as_number slots, then x*y is a sequence > replication operation. This is screwed in more than one way. The logic of which 'type' operation has precedence isn't even internally consistent. The case of 'x*y' and 'x+y' check the tp_as_number and tp_as_sequence slots in a *different order*, so 'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way 'round, I forget. I'm also struggling to catch up on my mail since Apachecon had little to no connectivity, so I don't feel like checking :) Brainwashed-into-Apache-2.0-forever-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Oct 26 12:51:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:51:30 +0200 Subject: [Python-Dev] ViewCVS on Sourceforge Message-ID: <20001026125130.O12812@xs4all.nl> I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon Travis and Gregory Trubetskoy where there as well, but my memory is a bit hazy) and since he's probably in some airplane over the atlantic right now, I'll run away and steal his idea ;) We were kind of reflecting how nice it would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and it doesn't need write access to the repository itself. So how about we run ViewCVS on python.sourceforge.net ourselves ? We could do it now, in fact, with the complete CVS snapshot that gets made every once in a while (that *does* still get made & backupped, right ?) though it would obviously be a lot more useful if ViewCVS just had direct access to the repository. I'm not sure how accessible that repository is, however. Cursory searches on shell.sourceforge.net doesn't show anything, except that the python-cvs.tgz that's in /home/projects/python is apparently the one used for the move to sourceforge :-) Can we get access to the repository directly, even if it's only semi-realtime ? (I wouldn't mind doing a couple of rsync's in cron to keep it up to date) If anything, running ViewCVS will show SourceForge how much nicer it is... ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jon+sourceforge at unequivocal.co.uk Thu Oct 26 13:01:27 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 12:01:27 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> Message-ID: <20001026120127.B11873@snowy.squish.net> Guido van Rossum wrote: > Sure, except I'm not comfortable with having two files with identical > contents under CVS control. How about not checking in Setup, but > creating it in configure if it doesn't exist? I think that would be fine so long as the README file makes it clear that you edit the Setup file after './configure' but before 'make'. Cheers Jon From mal at lemburg.com Thu Oct 26 13:23:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 13:23:19 +0200 Subject: [Python-Dev] 2.0 articles References: Message-ID: <39F81427.FF4223C2@lemburg.com> Andrew Kuchling wrote: > > I'd like to begin writing an article about 2.0's Unicode support. > Before beginning, has anyone else already begun this task? If yes, > please let me know... I've already started something in that direction. The plan is to write down the story of adding Unicode support to Python, the pifalls, solutions, hacks, etc. I'll probably submit it to DDJ. A article about *using* Unicode support would of course be a nice complement to get a feeling of how it's like working with the implementation :-) > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at acm.org Thu Oct 26 14:21:08 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> <200010261138.GAA04678@cj20424-a.reston1.va.home.com> Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com> I wrote: > I've left this one for someone with a good idea about what to do > about it. Guido van Rossum replied: > Don't touch it! This one is needed because at this point sys.stdout > and sys.stderr are redirected to a window where you don't want the > parser debug output to show up. See, I knew someone would come up with a better idea! ;) -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From skip at mojam.com Thu Oct 26 14:31:36 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <14840.9256.408848.728486@beluga.mojam.com> Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. I don't like the idea that a file I am supposed to edit (Setup) would be in the CVS repository where it could conceivably get messed with by a "cvs up" command. The current makefile target that emits a warning if Setup.in (.dist) is newer than Setup should be sufficient to alert users when Setup needs to be looked at. -- Skip Montanaro (skip at mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From skip at mojam.com Thu Oct 26 14:34:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.9409.491061.671168@beluga.mojam.com> Ping> Could i humbly re-request approval for inspect.py in the standard Ping> library? Ping> http://lfw.org/python/inspect.py +1. I've written functions over the years to do some small bits of what inspect.py does. I'd much rather have those things in a standard place with more eyeballs checking them for correctness. Skip From akuchlin at mems-exchange.org Thu Oct 26 14:56:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 26 Oct 2000 08:56:26 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200 References: <39F81427.FF4223C2@lemburg.com> Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us> On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote: >A article about *using* Unicode support would of course >be a nice complement to get a feeling of how it's like working And that's what I want to write, so it works out nicely; great! Finn, your comment has been noted; I'll take note of any differences with Jython's Unicode support. A draft will be announced on python-dev, whenever it actually gets done. --amk From mal at lemburg.com Thu Oct 26 15:07:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 15:07:35 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> Message-ID: <39F82C97.12D04C85@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > > * implementation language and Python inheritance semantics are almost > > > completely distinct. After all, we have Python implementations in a > > > variety of languages with minor incompatibilities. Python could have a > > > proper type/class merging even if it were written in assembly language. > > > So let's leave implementation language aside. > > > > Hey, think of it as opportunity: we can reuse much of C++'s > > optimizations and the integration of Python and C++ applications > > will get *much* easier. > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > C++ and Python is not really so hard, in my experience. Ok, you can use SWIG to get most of the work done, but the interface between the C++ object world and the Python object world is one big mess -- all implementations I've seen use shadow objects or proxies to interface from one to the other... with lots of temporary objects used for the linkup. Having Python itself written in C++ we could do *much* better. But that's only a nice side-effect. The real argument here is that we can push the type logic one layer further down. Ideal would be a level of integration such as the one implemented in JPython or Jython. > > A rewrite shouldn't scare anyone away -- much of the existing > > code can be reused since only the Python C APIs of the various > > types will have to be rewritten, not the logic behind the types. > > I wasn't really addressing the issue of backwards compatibility of > extensions -- I was talking about Python programs. Nevertheless, I can't > resist: > > Porting your app to the Python APIs is often the majority of the work in > a particular extension. A lot of Python extensions consist only of API > glue! True, but we're lucky, since we could provide a compatibility layer on top of the new API. BTW, I think I now know what your main concern is: the Python level compatibility. I was talking of what goes on under the hood and still think that Py3K should be used as a chance to simplify the Python backend. As simplification often means generalization, we'll open up new doors for future developments along the way. > > > I don't know what you mean by a "low-level strategy" for classes. It's > > > not like we can somehow use C++ vtables without giving up Python's > > > dynamicity. Python's class handling is about as low-level as it can get > > > in my humble opinion. > > > > With "low-level" I meant trying to build Python classes and > > instances on top of a very thin layer on top of C++ classes, > > e.g. all slots could be implemented using true C++ methods with > > additional logic to override them using dynamically bound > > Python method objects. > > I don't think that there is really interesting magic in a C++ compiler. > A vtable is an array of pointers to functions. We've already implemented > the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and > smart pointers are a little more interesting from a code maintenance and > simplicity point of view. But even then I think that we could get to a > C++ implementation through incremental rewrites. Naa, the whole type slot interface is one big mess (sorry, Guido :-). some slots are packaged, some are not, some are NULL, some are not, there are oodles of sometimes weird dependencies between the slots which are not really documented, etc. etc. The slot design has serious drawbacks and should be replaced by something more reliable, preferably C++ methods. That way, we'll get some more "type" safety into Python and its extensions. Note that porting old extensions won't be all that hard: a class reusing the existing slot functions as methods should suffice in many cases. > > Why spoil all the fun when we haven't even started thinking > > about all the possibilities we could use to make Py3k a > > success ? > > Asking for a map of where we are going and how we will get here is > "spoiling all of the fun?" I'm not sure what you are reacting to -- I > didn't advise one implementation strategy or another -- I just said that > we should employ a strategy that minimizes sudden and surprising code > breakage. Ok, we've been talking about different things here: with "spoiling the fun" I meant putting ropes on possible changes to the C backend. You are talking about the frontend and I agree with you that there should be a clear upgrade path from the 2.x series to Py3K w/r to the Python side of things. So I guess it's time for some PEPs now... the upgrade path PEP and the fluffy clouds PEP. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Thu Oct 26 16:42:40 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 09:42:40 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100." <20001026120127.B11873@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com> > I think that would be fine so long as the README file makes it clear that > you edit the Setup file after './configure' but before 'make'. One thing -- it's perfectly fine to edit Setup after running Make for the first time. You just have to run Make again. The Makefiles are designed for this. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Thu Oct 26 15:56:40 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 06:56:40 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> Message-ID: <39F83818.38EA64AE@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Having Python itself written in C++ we could do *much* better. Agree. > ... > > The slot design has serious drawbacks and should be replaced by > something more reliable, preferably C++ methods. That way, we'll > get some more "type" safety into Python and its extensions. I agree that the slot stuff is broken but my solution would be to junk it and use the same mechanism for looking up "type methods" and "instance methods". I can think of two ways to make that perform reasonably: one is method caching and the other is by building interface objects where methods are invoked by index -- basically vtables. But if the same mechanism is going to accelerate Python and C types alike then it can't really use C++ vtables because how do you generate a vtable at runtime for a new Python class? (you could also think of it as a COM interface object) > So I guess it's time for some PEPs now... the upgrade path > PEP and the fluffy clouds PEP. Good timing. I just finished the first draft of the upgrade path PEP. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry at wooz.org Thu Oct 26 15:24:49 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <14840.9409.491061.671168@beluga.mojam.com> Message-ID: <14840.12449.241947.715016@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> Could i humbly re-request approval for inspect.py in the Ping> standard library? Ping> http://lfw.org/python/inspect.py SM> +1. I've written functions over the years to do some small SM> bits of what inspect.py does. I'd much rather have those SM> things in a standard place with more eyeballs checking them SM> for correctness. I've downloaded it, and will take a look. From jim at interet.com Thu Oct 26 16:03:43 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:03:43 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <39F839BF.DD1B86BF@interet.com> Guido van Rossum wrote: > To me this all sounds like FUD. True, but FUD is real and I have no apologies. > Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. We don't use the Python Windows installer. Our app has to use its own installer, and I would then have to run two installers, one of which I don't understand. Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors. JimA From jim at interet.com Thu Oct 26 16:06:02 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:06:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> Message-ID: <39F83A4A.26E543A3@interet.com> Guido van Rossum wrote: > Even Microsoft is violating its own (boring) style guide, when they > think it appeals to a specific audience. Have you seen their Media > Player? Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design. JimA From gward at mems-exchange.org Thu Oct 26 16:18:50 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 10:18:50 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us> On 26 October 2000, James C. Ahlstrom said: > Guido van Rossum wrote: > > > Even Microsoft is violating its own (boring) style guide, when they > > think it appeals to a specific audience. Have you seen their Media > > Player? > > Yes, very slick. My daughter has an app where you click on > doors to access parts of the program. Nice design. This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end. Go look for "User Interface Hall of Shame" at your friendly neighbourhood search engine for many enjoyable rants against bad GUI design, including the "emulate the real world" school of thought. Anyways, this is not a usability mailing list... back to our regularly scheduled python-dev... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From paul at prescod.net Thu Oct 26 16:28:12 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:28:12 -0700 Subject: [Python-Dev] Gradual migration PEP Message-ID: <39F83F7C.2241158F@prescod.net> PEP: XXX Title: Guidelines for introducing backwards incompatibilities Version: $Revision: 1.0 $ Author: Paul Prescod Status: Draft Type: Standards Track Python-Version: All Created: 25-Oct-2000 Abstract In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behaviour of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. Implementation Details Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. Scope These guidelines apply to future versions of Python that introduce backward-incompatible behaviour. Backward incompatible behaviour is a major deviation in Python interpretation from an earlier behaviour described in the standard Python documentation. Removal of a feature also constitutes a change of behaviour. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! Steps For Introducting Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. Local Variables: mode: indented-text indent-tabs-mode: nil End: From paul at prescod.net Thu Oct 26 16:35:48 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:35:48 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F84144.105D1754@prescod.net> Mark Hammond wrote: > >... > > I don't think it will be "fixed", as it is not considered "broken". It was > an explicit choice to leave out Tcl/Tk. And my recollection is that the > "feedback" address sees more requests for wxPython than Tcl/Tk. That's all true. We also make it very easy to find the right version of Tcl/Tk and will probably go even farther in this direction in the future. Built-in Tcl/Tk support is not out of the question but there are various user confusion issues: "Why are there two GUI frameworks in this development environment? Why are there two development environments in this development environment? Doesn't ActiveState have yet another GUI framework and development environment under development?" "Why do I need Tcl at all? What is its relationship with Python? There are clear benefits to including Tcl/Tk but there are also costs and its possible we'll weigh them differently in the future. BTW: ActivePython does include Tkinter. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From gmcm at hypernet.com Thu Oct 26 16:49:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 10:49:20 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <39F80C30.5448.52D32F94@localhost> [Paul] > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. ... or a number of others (but SWIG falls very short when it comes to things like C++ references)... [Marc-Andre] > Ok, you can use SWIG to get most of the work done, but the interface > between the C++ object world and the Python object world is one > big mess -- all implementations I've seen use shadow objects > or proxies to interface from one to the other... with lots of > temporary objects used for the linkup. While I agree it's messy, those are not the objectionable qualities. Any refcounted C++ system is going to have proxies (smart pointers / refcounting stack-safe "reference" objects to the real heap-based objects). And while I think we'd be better off with a C++ implementation, I would warn that C++'s notion of inheritence is in conflict with Python's. It won't be "as above, so below" (unless we screw interpreting and go straight to native code). Assuming that the class / type dichotomy actually gets healed, that is. > ... The real argument here is > that we can push the type logic one layer further down. Ideal would > be a level of integration such as the one implemented in JPython > or Jython. Nope. If you heal the class / type split, there's really only one underlying type object. Unless you go the other way, and write "native" code (as JPython does). All of the existing C++ interfaces / helpers deal only with type objects (at least, those that I've examined, which is most of them). In fact, only ExtensionClass attempts to deal with the class / type split, and while it's a masterpiece, I think it's a great example of everything to avoid in Py3K. - Gordon From barry at wooz.org Thu Oct 26 16:58:23 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> <39F83818.38EA64AE@prescod.net> Message-ID: <14840.18063.152674.534458@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I agree that the slot stuff is broken but my solution would be PP> to junk it and use the same mechanism for looking up "type PP> methods" and "instance methods". I can think of two ways to PP> make that perform reasonably: one is method caching and the PP> other is by building interface objects where methods are PP> invoked by index -- basically vtables. But if the same PP> mechanism is going to accelerate Python and C types alike then PP> it can't really use C++ vtables because how do you generate a PP> vtable at runtime for a new Python class? (you could also PP> think of it as a COM interface object) Objective-C! :) From effbot at telia.com Thu Oct 26 17:14:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 17:14:28 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid> jim wrote: > Sorry to be such an old fuddy-duddy, but you will > get the same reaction from most commercial software > vendors. Make that nearly ALL vendors. what reaction? are you saying that your own installer can install the Python DLL but not the Tk DLL? From gmcm at hypernet.com Thu Oct 26 17:05:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 11:05:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us> References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 Message-ID: <39F80FDE.6102.52E19102@localhost> James C. Ahlstrom said: > > Yes, very slick. My daughter has an app where you click on > > doors to access parts of the program. Nice design. [Greg Ward] > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I once interviewed with a game designer (sports games - popular ones, too). He spent half an hour slamming MS's UI (his games run on Windows). Then he pulled up his latest (opening to a sports stadium) and said "Now here's a real UI". So I said "Show me how it works". The bozo ended up clicking on random things on the screen until something finally happened. no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs - Gordon From barry at wooz.org Thu Oct 26 17:36:37 2000 From: barry at wooz.org (barry at wooz.org) Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.20357.734136.911927@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: >> Okay, we all know that's a pain, right? Lots of people have >> proposed solutions. I've looked briefly at !?ng's Itpl.py, but >> I think it probably does too much by adding evaluation. KY> Do you think a variant of Itpl that only looked up variable KY> names would solve your problem? I think it would calm my objections, yes. I'll observe that I think there may be a middle ground between my approach and Itpl. I've found a couple of situations where I want a minimal form of evaluation, e.g. I want attributes to be expanded (and methods called), but not a general evaluation facility. So for example, I'd like to be able to say: print _("The name of the mailing list is %(mlist.listname())s") What worries me about a general evaluation framework is that we then have to be really really careful about security and origin of the strings we're using here. Maybe we'd need to adopt something like Perl's taint strings. KY> How about this routine to get the current frame: KY> inspect.currentframe(). It uses the same intentional-exception trick to get at the current frame. It's about 8x faster to do it in C. I'll note that your version raises and catches a string exception, while mine uses an exception instance. I don't see much difference in speed between the two. KY> If there are changes that need to be made before it can be KY> accepted, i'd be happy to make them. Sent under a separate private response... -Barry From gward at mems-exchange.org Thu Oct 26 18:03:09 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 12:03:09 -0400 Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400 References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us> On 24 October 2000, Barry A. Warsaw said: > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. Not sure if I would call that function 'getcaller()' or 'getframe()'; could go either way. In my implementation of this (I guess everyone has one!), I also have a couple of convenience functions: def get_caller_env (level=1): """get_caller_env(level : int = 1) -> (globals : dict, locals : dict) Return the environment of a caller: its dictionaries of global and local variables. 'level' has same meaning as for 'caller()'. """ def get_frame_info (frame): """get_frame_info(frame) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from an execution frame. """ def get_caller_info (level=1): """get_caller_info(level : int = 1) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from some caller's execution frame. 'level' is the same as for 'caller()', i.e. if level is 1 (the default), gets this information about the caller of the function that is calling 'get_caller_info()'. """ These are mainly used by my unit-testing framework (which you'll no doubt remember, Barry) to report where test failures originate. Very handy! Looks like Ping's inspect.py has something like my 'get_frame_info()', only it's called 'getframe()'. Obviously this is the wrong name if Barry's new function gets added as 'sys.getframe()'. How 'bout this: sys.getframe(n) - return stack frame for depth 'n' inspect.getframeinfo(frame) - return (filename, line number, function name, lines-of-code) Although I haven't grokked Ping's module enough to know if that rename really fits his scheme. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From jon+sourceforge at unequivocal.co.uk Thu Oct 26 18:57:01 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 17:57:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com> Message-ID: <20001026175701.A4983@snowy.squish.net> Guido van Rossum wrote: > One thing -- it's perfectly fine to edit Setup after running Make for > the first time. You just have to run Make again. The Makefiles are > designed for this. Mention this too ;-) From fdrake at acm.org Thu Oct 26 19:24:54 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT) Subject: [Python-Dev] Setup changes are checked in Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com> I've checked in the changes to the handling of the Modules/Setup file as we've discussed here. - Setup.in is now Setup.dist - Setup is created by configure - README and other instructions, comments, and documentation has been updated to reflect these changes -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake at acm.org Thu Oct 26 19:30:22 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT) Subject: [Python-Dev] development version of docs online Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Do people want to be notified when the development copy of the documentation is update? There was a comment from someone that they didn't know where the online copy was. I can send the update notice to python-dev instead of just to myself if everyone wants it, or I can send it to some other (appropriate) list. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From trentm at ActiveState.com Thu Oct 26 19:42:30 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 26 Oct 2000 10:42:30 -0700 Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400 References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: <20001026104230.B23283@ActiveState.com> On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote: > > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they Yes, please. Trent -- Trent Mick TrentM at ActiveState.com From jim at interet.com Thu Oct 26 21:34:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:34:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid> Message-ID: <39F8872B.92D69403@interet.com> Fredrik Lundh wrote: > > jim wrote: > > Sorry to be such an old fuddy-duddy, but you will > > get the same reaction from most commercial software > > vendors. Make that nearly ALL vendors. > > what reaction? > > are you saying that your own installer can install the > Python DLL but not the Tk DLL? Not exactly. I am saying I don't want to use the standard Python Windows installer. And I am saying I don't want to install Tk because it is big, complicated, and requires Tcl and its libraries. My installer does install the Python DLL python15.dll, so I guess I could study how to install Tk and duplicate the functionality of the Windows installer, and install Tk too. But why would I want to? JimA From jim at interet.com Thu Oct 26 21:38:40 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:38:40 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us> Message-ID: <39F88840.3F619707@interet.com> Greg Ward wrote: > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I agree up to a point, and my own app doesn't use doors. But kids like this kind of design, have no trouble understanding it, and people wouldn't write this if they didn't think it would sell. I just meant that people have a larger tolerance for non-Microsoft GUI design ideas than I thought up to now. JimA From skip at mojam.com Thu Oct 26 22:10:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? Message-ID: <14840.36793.19348.903534@beluga.mojam.com> Just came across this error while running configure: checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The problem was that /tmp was full - sort of. The system says there's no space: % cat /etc/termcap > /tmp/termcap bash: /tmp/termcap: No space left on device but df disagrees: % df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 153667 88796 56935 61% / Short term workaround is to run configure with TMPDIR set somewhere else. Perhaps this is something to put in a gcc-specific or Unix-specific section of the README file. I didn't see anything, and the message emitted by configure gave no hint at the cause of the problem. I realized what it was because I've been scratching my head about this problem for a couple weeks. If this is deemed useful I'll modify README and check it in. If not, no big deal. (I have no idea why the system thinks /tmp is full... sigh ...) Skip From cgw at fnal.gov Thu Oct 26 22:14:53 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com> References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov> Skip Montanaro writes: > > Just came across this error while running configure: > > checking for gcc... gcc > checking whether the C compiler (gcc ) works... no > configure: error: installation or configuration problem: C compiler cannot create executables. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. Personally, I don't think this is useful. I don't think the Python README is the place to list everything that can go wrong during ./configure. The generic advice is "If something goes wrong during ./configure, read through config.log to see what went wrong" I'm curious what is in your config.log when this error occurs! From nas at arctrix.com Thu Oct 26 15:29:49 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 26 Oct 2000 06:29:49 -0700 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001026062949.A14618@glacier.fnational.com> > The problem was that /tmp was full - sort of. You might try "df -i". You could be out inodes but still have blocks. Neil From guido at python.org Thu Oct 26 23:29:33 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 16:29:33 -0500 Subject: [Python-Dev] Gradual migration PEP In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST." <39F83F7C.2241158F@prescod.net> References: <39F83F7C.2241158F@prescod.net> Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com> Paul, Your deprecation PEP looks good. A few comments: - I think that the one-year period may depend on the feature. Some may require an even longer time. Others less. - I think there will be cases where run-time checks are the only way to detect use of the old feature (e.g. I'm still struggling with how to change the division semantics). But this shouldn't stop it from becoming a PEP. Please arrange for a PEP number with Barry, the PEPmaster. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Fri Oct 27 00:58:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 00:58:41 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700 References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <20001027005841.R12812@xs4all.nl> On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote: > > The problem was that /tmp was full - sort of. > You might try "df -i". You could be out inodes but still have > blocks. Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks, or some other filesystem resource. Not often the case for something like /tmp, but definately possible on some filesystems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Oct 27 01:02:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 01:02:24 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001027010224.S12812@xs4all.nl> On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote: > Short term workaround is to run configure with TMPDIR set somewhere else. > Perhaps this is something to put in a gcc-specific or Unix-specific section > of the README file. I didn't see anything, and the message emitted by > configure gave no hint at the cause of the problem. I realized what it was > because I've been scratching my head about this problem for a couple weeks. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. If you start adding things like that, also consider all the other possibilities of configure being wrong. I hinted at one of them a couple of weeks back, I think. (Somehow, 'last saturday', when I headed for London for the Apachecon, feels like about two months ago :P) It's perfectly possible for configure to be able to run gcc, gcc to be able to create working binaries, but every check for a function or datatype failing because the more 'involved' include files are missing. This is easy to do on Linux, (removing /usr/src/linux, for instance) but not impossible on other systems either. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From greg at cosc.canterbury.ac.nz Fri Oct 27 02:21:26 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001027005841.R12812@xs4all.nl> Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz> Thomas Wouters : > Or failing that, it could be out of 'indirect' or 'doubly-indirect' > blocks, I think they're allocated from the same pool as data blocks. What *can* happen is that you can run out of "large" blocks. The BSD-style filesystem stores files bigger than 8k in blocks made up of 8 contiguous 1k blocks. If the filesystem is nearly full, or contains a large number of small files, you can find that it's impossible to create any more files > 8k, even though there appears to be plenty of free space, because the space is too fragmented. I don't think that's what's happening here, though, since I've only ever seen it happen when the filesystem was about 99% full. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From tim_one at email.msn.com Fri Oct 27 03:13:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 26 Oct 2000 21:13:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F8872B.92D69403@interet.com> Message-ID: [Guido] > are you saying that your own installer can install the > Python DLL but not the Tk DLL? [James Ahlstrom] > Not exactly. I am saying I don't want to use the standard > Python Windows installer. And I am saying I don't want to install > Tk because it is big, complicated, and requires Tcl and its libraries. > > My installer does install the Python DLL python15.dll, so > I guess I could study how to install Tk and duplicate the > functionality of the Windows installer, and install Tk too. > But why would I want to? That's up to you and your customers. What Guido has been telling you is that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is trivial: it merely copies some Tcl/Tk files into the Python installation tree. It no longer runs the Scriptics installer, mucks with the path, changes any envars, copies any files to outside of the Python tree, or even sets anything up in the registry for Tcl/Tk. You may not *want* to install Tcl/Tk, but, if you would like to, there's no longer any basis for fearing it's difficult, obscure, delicate or error-prone. don't-know-about-those-wrt-other-gui-pkgs-ly y'rs - tim From skip at mojam.com Fri Oct 27 05:54:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov> References: <14840.36793.19348.903534@beluga.mojam.com> <14840.37053.829696.379140@buffalo.fnal.gov> Message-ID: <14840.64651.444849.757658@beluga.mojam.com> Charles> The generic advice is "If something goes wrong during Charles> ./configure, read through config.log to see what went wrong" Agreed. Charles> I'm curious what is in your config.log when this error occurs! That's why I was thinking ("hmmm... perhaps a README bit"). It wasn't giving me obvious "no space" messages. I've concluded that it's probably best to forget it anyway. If it's a problem with configure or gcc messages, it's best addressed there. Skip From skip at mojam.com Fri Oct 27 05:57:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com> References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <14840.64780.673428.672300@beluga.mojam.com> Neil> You might try "df -i". You could be out inodes but still have Neil> blocks. Thanks, that indeed seems to be the problem: % df -i /tmp Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 39k 39k 7 100% / I don't believe in all my years of fiddling with Unix systems I've ever run out of inodes with a third of the disk space left. Now to identify the culprit. Skip From mal at lemburg.com Fri Oct 27 12:15:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 27 Oct 2000 12:15:53 +0200 Subject: [Python-Dev] Starship is still down... Message-ID: <39F955D9.279864FD@lemburg.com> It's been over a week since I posted my last gripe about our community server starship being unreachable. Nothing has happened so far... is there any chance on getting the server up and running again ? I am a bit concerned about the lack of support here: starship should be considered a very important part in the Python universe (after all, many Python extension packages and goodies are available from that site). With the frequent downtimes we recently had, I think people will get a wrong picture about the Python community support. Here's a traceroute from Germany to starship: traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets 1 193.158.137.129 (193.158.137.129) 24 ms 23 ms 23 ms 2 193.158.137.130 (193.158.137.130) 24 ms 35 ms 25 ms 3 D-gw13.D.net.DTAG.DE (212.185.10.22) 67 ms 24 ms 35 ms 4 K-gw13.K.net.DTAG.DE (194.25.124.137) 26 ms 25 ms 25 ms 5 F-gw13.F.net.DTAG.DE (194.25.121.101) 32 ms 33 ms 33 ms 6 TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98) 113 ms 127 ms 131 ms 7 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113) 115 ms 117 ms 134 ms 8 mae-east-switch0.maee.above.net (208.184.210.9) 134 ms 114 ms 123 ms 9 core1-mae-east-oc3-1.iad.above.net (209.133.31.225) 122 ms 116 ms 115 ms 10 sjc2-iad-oc48.sjc2.above.net (216.200.127.26) 184 ms 186 ms 185 ms 11 core5-core3-oc48.sjc2.above.net (208.185.156.66) 183 ms 184 ms 186 ms 12 sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37) 299 ms 183 ms !H 188 ms !H 13 * * * 14 * * * ... It looks as if ABOVE.NET is having some serious routing problems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Fri Oct 27 12:43:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 27 Oct 2000 06:43:22 -0400 Subject: [Python-Dev] Starship is still down... In-Reply-To: <39F955D9.279864FD@lemburg.com> Message-ID: [MAL] > It's been over a week since I posted my last gripe about > our community server starship being unreachable. Afraid Manus Head still gets the Most Outraged award for this one. > Nothing has happened so far... is there any chance on getting the server > up and running again ? Works for me, but only very recently. OTOH, my posts to python.org mailing lists started black-holing, so it's not like Python-Dev will actually see this post . Here's a trace from my box (in Virginia); it may take a while for recent routing changes to propagate: 1 tnt32.tco2.da.uu.net [206.115.222.61] 2 GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2] 3 156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50] 4 517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198] 5 294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26] 6 POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25] 7 137.39.52.102 8 beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139] 9 sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42] 10 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139] 11 pacbellpsfoc3.ca.us.prserv.net [165.87.161.5] 12 core3-g2-0.snfc21.pbi.net [209.232.130.78] 13 rback26-fe2-0.snfc21.pbi.net [216.102.187.153] 14 adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65] 15 starship.python.net [63.202.160.91] > I am a bit concerned about the lack of support here: starship > should be considered a very important part in the Python > universe (after all, many Python extension packages and goodies > are available from that site). With the frequent downtimes > we recently had, I think people will get a wrong picture about > the Python community support. They're getting an accurate view of current Starship support. So it goes. Plans for better support *are* in progress, but for reasons that won't become clear until later, you haven't heard anything about them yet. for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs - tim From jim at interet.com Fri Oct 27 14:23:11 2000 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 27 Oct 2000 08:23:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F973AF.80D3BDBE@interet.com> Tim Peters wrote: > That's up to you and your customers. What Guido has been telling you is > that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is > trivial: it merely copies some Tcl/Tk files into the Python installation > tree. It no longer runs the Scriptics installer, mucks with the path, Oh, OK. That is much better. JimA From skip at mojam.com Fri Oct 27 18:15:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT) Subject: [Python-Dev] Starship is still down... In-Reply-To: References: <39F955D9.279864FD@lemburg.com> Message-ID: <14841.43579.261191.986406@beluga.mojam.com> Tim> Here's a trace from my box (in Virginia); ... Tim's trace doesn't show times. Looks to me like Pacbell is having trouble (note the huge leap in response time): ... 13 beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50) 30.387 ms 27.426 ms 28.392 ms 14 beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139) 27.614 ms 27.349 ms 27.250 ms 15 sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42) 71.581 ms 72.535 ms 72.429 ms 16 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139) 71.635 ms 71.420 ms 71.483 ms 17 pacbellpsfoc3.ca.us.prserv.net (165.87.161.5) 71.070 ms 71.606 ms 71.301 ms 18 core4-g2-0.snfc21.pbi.net (209.232.130.77) 70.986 ms 71.129 ms 73.628 ms 19 rback26-fe2-0.snfc21.pbi.net (216.102.187.153) 72.696 ms 77.658 ms 83.046 ms 20 adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65) 3841.343 ms 3705.648 ms 3911.584 ms 21 adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91) 3683.340 ms 3867.550 ms 3653.732 ms Skip From petrilli at amber.org Fri Oct 27 22:15:18 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Fri, 27 Oct 2000 16:15:18 -0400 Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: ; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200 References: <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <20001027161518.B3942@trump.amber.org> Peter Funk [pf at artcom-gmbh.de] wrote: > > It will take years, before MacOS X will find its way onto the desk > of the average Apple Mac user. The Mac s mostly used in the graphics > and printing industry (our cutsomers) where people normally don't > even think about a OS upgrade, if they don't have to. They usually > run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other > so called creative software on the version of the OS they had on > the machine when they bought it. THese machines are usually used > through a period of at least four years. I think this is a bit incorrect. Almost every Mac user that I interact with (including all the users hre at Digital Creations) have OS X running and using it at various levels. Mostly it's waiting for people like Adobe to release Carbon applications. Graphics designers will be the first to move to OS X, not thel ast, as they will ge the most fromt he increased stability and performance. It all depends on your market. The best goal for Mac OS would be to aim at full Carbon compliance, and not write to Cocoa, or to the original MacOS toolkit. This would let you run on all releases after 8.0 I believe (maybe even 7.6). Chris -- | Christopher Petrilli | petrilli at amber.org From guido at python.org Sat Oct 28 03:42:42 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 27 Oct 2000 20:42:42 -0500 Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com> To all Python users and developers: Less than half a year ago, I moved with my team to BeOpen.com, in the hope of finding a new permanent home for Python development. At BeOpen, we've done several good things for Python, such as moving the Python and Jython development process to SourceForge, and the successful release of Python 2.0. Unfortunately, BeOpen.com's original plans for PythonLabs didn't work out as hoped, and we weren't able to reach mutual agreement on workable alternative plans -- despite trying for months. I am proud to have found a new home for my entire team: starting today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself are working for Digital Creations. We will be spending part of our time on core Python development (including Jython and Mailman) and part of our time on Python infrastructure improvements that also benefit Zope. Python will remain Open Source; Digital Creations has no desire to monetize or brand the Python language or specific Python distributions. All future work we do on Python as Digital Creations employees will be owned by a non-profit organization yet to be created. We think of this new organization as the Python Software Foundation. In the meantime (while the PSF is under construction) I will own such copyrights personally. We're excited to be working for Digital Creations: they are one of the oldest companies active in the Python community, one of the companies most committed to Python, and they have a great product! Plus, we know they have deep financial backing. We trust that Digital Creations will provide a stable home for Python for many years. Digital Creations has also offered to take over hosting of the python.org and starship sites. On behalf of the Python community, we're grateful for this support of the two prime community sites for Python, and we expect to be implementing the transitions shortly. These are exciting times for the PythonLabs team -- and also for Python and its community. Mainstream successes for Python are showing up everywhere, and we're proud to be a part of such a smart and friendly community. A great year lies ahead! --Guido van Rossum (home page: http://www.python.org/~guido/) From jim at digicool.com Sat Oct 28 04:45:02 2000 From: jim at digicool.com (Jim Fulton) Date: Fri, 27 Oct 2000 22:45:02 -0400 Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations References: Message-ID: <39FA3DAE.ADB2C8B1@digicool.com> Guido van Rossum wrote: > (snip) > I am proud to have found a new home for my entire team: starting > today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself > are working for Digital Creations. We will be spending part of our > time on core Python development (including Jython and Mailman) and > part of our time on Python infrastructure improvements that also > benefit Zope. Needless to say (but I'll say it anyway), Digital Creations is proud and thrilled that the this team has joined us. These are indeed exciting times! Jim -- Jim Fulton mailto:jim at digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org From martin at loewis.home.cs.tu-berlin.de Sat Oct 28 12:14:00 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:14:00 +0200 Subject: [Python-Dev] getting at the current frame Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> > which actually will look something like this in real code: > > def trade(yours, mine): > print _('if you give me %(yours)s, i will give you %(mine)s') % { > 'yours': yours, > 'mine' : mine, > } > > The string wrapped in _() is what gets translated here. > > Okay, we all know that's a pain, right? What's wrong with def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % vars() Look Ma, no magic! Regards, Martin From effbot at telia.com Sat Oct 28 12:43:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 28 Oct 2000 12:43:05 +0200 Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com> Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid> fred wrote: > At any rate, there has been activity in the source tree; you just > might want to do a CVS update to see what's changed. There have been > a number of bug fixes, a fair number of documentation updates, and > many of the modules in the standard library have been passed through > Tim Peter's reindent.py script (look in Tools/scripts/). now that this has been done, emacs users might want to add something like the following to their local configuration (based on code by jwz, so it should work...) ::: (defun python-mode-untabify () (save-excursion (goto-char (point-min)) (while (re-search-forward "[ \t]+$" nil t) (delete-region (match-beginning 0) (match-end 0))) (goto-char (point-min)) (if (search-forward "\t" nil t) (untabify (1- (point)) (point-max)))) nil) (add-hook 'python-mode-hook '(lambda () (make-local-variable 'write-contents-hooks) (add-hook 'write-contents-hooks 'python-mode-untabify))) From martin at loewis.home.cs.tu-berlin.de Sat Oct 28 12:51:20 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:51:20 +0200 Subject: [Python-Dev] build problems under Solaris Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de> > I don't have access to a Solaris machine, so I can't do anything to > help these users. The patch in 117606 looks right to me: gcc on Solaris (and on any other platform) needs -shared to build shared library; configure currently passes -G. I haven't actually tried the patch, since it is a pain to extract it from the SF bug report page. What happens is that gcc passes -G to the linker, which correctly produces a shared library. However, gcc also links crt1/crti into the library, which causes the reference to main. 117508 looks like a user error to me. On its own, configure would not try to link -ldb, unless it detects the presence of db.h. My guess is that there is a libdb in /usr/local, so a gcc configure finds it, whereas the native compiler doesn't. Later, the linker even finds a -ldb library, but somehow this doesn't have dbopen. So it could be that the BSDDB installation on that system is screwed. Regards, Martin From barry at scottb.demon.co.uk Sat Oct 28 13:14:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:14:45 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <000601c040d0$474ce1d0$060210ac@private> > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. Integrating C++ and Python well is hard in a general library. CXX tries to make objects that look and feel like Python objects. But to do that we have to figure out the details of how python uses objects. You have no docs on the subject so we read the source code. Barry CXX maintainer From barry at scottb.demon.co.uk Sat Oct 28 13:23:50 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:23:50 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F80C30.5448.52D32F94@localhost> Message-ID: <000701c040d1$8beecf00$060210ac@private> [Gordon wrote] > All of the existing C++ interfaces / helpers deal only with type > objects (at least, those that I've examined, which is most of > them). In fact, only ExtensionClass attempts to deal with the > class / type split, and while it's a masterpiece, I think it's a > great example of everything to avoid in Py3K. Py_Cpp support C++ classes you can derived from in Python. Once I get my head around the proxy interface I'll try and add that to CXX. CXX today allows you to create C++ class that you can use from Python, but not derive from. Barry CXX maintainer From moshez at math.huji.ac.il Sun Oct 29 08:59:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST) Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote: > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they > didn't know where the online copy was. I can send the update notice > to python-dev instead of just to myself if everyone wants it, or I can > send it to some other (appropriate) list. I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that means I'm getting it twice. My foot is used to being shot at though) -- Moshe Zadka -- 95855124 http://advogato.org/person/moshez From barry at wooz.org Mon Oct 30 17:14:53 2000 From: barry at wooz.org (barry at wooz.org) Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST) Subject: [Python-Dev] Re: getting at the current frame References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> Message-ID: <14845.40573.917058.905009@anthem.concentric.net> >>>>> "MvL" == Martin v Loewis writes: MvL> What's wrong with MvL> def trade(yours, mine): print _('if you give me MvL> %(yours)s, i will give you %(mine)s') % vars() MvL> Look Ma, no magic! Except that I also want globals() to be included and vars() doesn't include that. I really want: d = globals().copy() d.update(locals()) but I've also noticed that you sometimes want attribute following so you can do things like _('the name of the list is %(mlist.listname)') -Barry From barry at wooz.org Mon Oct 30 18:35:25 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213 References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <14845.45405.867829.722598@anthem.concentric.net> Well, it looks like checkin messages are flowing again. Yay! From mal at lemburg.com Mon Oct 30 18:54:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 30 Oct 2000 18:54:50 +0100 Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <39FDB5EA.B60EA39A@lemburg.com> Jeremy Hylton wrote: > > Update of /cvsroot/python/python/dist/src/Python > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python > > Modified Files: > ceval.c > ... > N.B. The CALL_FUNCTION implementation is getting really hairy; should > review it to see if it can be simplified. How about a complete redesign of the whole call mechanism ?! I have an old patch somewhere which reorganizes the Python calling mechanism into something more sane than what we have in ceval.c now. Should I try to find it for someone to use as basis for the reorg (don't have time for this myself) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at alum.mit.edu Mon Oct 30 15:59:00 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST) Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com> References: <200010301715.JAA32564@slayer.i.sourceforge.net> <39FDB5EA.B60EA39A@lemburg.com> Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net> >>>>> "MAL" == M -A Lemburg writes: MAL> Jeremy Hylton wrote: >> >> Update of /cvsroot/python/python/dist/src/Python In directory >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python >> >> Modified Files: ceval.c ... N.B. The CALL_FUNCTION >> implementation is getting really hairy; should review it to see >> if it can be simplified. MAL> How about a complete redesign of the whole call mechanism ?! MAL> I have an old patch somewhere which reorganizes the Python MAL> calling mechanism into something more sane than what we have in MAL> ceval.c now. MAL> Should I try to find it for someone to use as basis for the MAL> reorg (don't have time for this myself) ? I'd be interested in looking at it. Jeremy From tim_one at email.msn.com Mon Oct 30 20:36:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:36:55 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? Message-ID: C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall test_extcall test test_extcall failed -- Writing: '3', expected: '' 1 test failed: test_extcall C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v test_extcall test_extcall test_extcall () {} (1,) {} (1, 2) {} (1, 2, 3) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3) {'b': 5, 'a': 4} (1, 2, 3, 4, 5) {'b': 7, 'a': 6} (1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8} TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 1 () {} 1 (2,) {} 1 (2, 3) {} 1 (2, 3, 4, 5) {} 0 (1, 2) {} 1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} keyword parameter 'x' redefined in call to g() keyword parameter 'b' redefined in function call keywords must be strings h() got an unexpected keyword argument 'e' * argument must be a sequence ** argument must be a dictionary 3 512 1 3 3 unbound method must be called with instance as first argument unbound method must be called with instance as first argument 1 test OK. From fdrake at acm.org Mon Oct 30 21:38:09 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com> Tim Peters writes: > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall > > test_extcall > test test_extcall failed -- Writing: '3', expected: '' > 1 test failed: test_extcall I get the same thing on Linux. The output appears identical to what Tim got. -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From jeremy at alum.mit.edu Mon Oct 30 17:48:08 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net> This output matches the output file I just checked in under Lib/test/output/test_extcall. Looks like I failed to check in this change. Jeremy From tim_one at email.msn.com Mon Oct 30 20:54:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:54:14 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: [Jeremy] > This output matches the output file I just checked in under > Lib/test/output/test_extcall. Looks like I failed to check in this > change. Thank you -- works on Windows now. It should work on Linux too, if Linux knows what's good for it . From fdrake at acm.org Mon Oct 30 21:56:13 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com> Tim Peters writes: > Thank you -- works on Windows now. It should work on Linux too, if Linux > knows what's good for it . It does. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From guido at python.org Sun Oct 1 07:31:43 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 01 Oct 2000 00:31:43 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> I'm considering to issue a release candidate before the final 2.0 release. I'd like to poll opinions about this (we haven't had a PythonLabs group meeting about this yet). The importance of a release candidate (RC) is twofold: we announce it widely so it (hopefully) gets a lot of testing -- necessary since a lot of things have changed again since beta2; and we impose a checkin stop once the RC is out, with exceptions only allowed by the release manager to fix showstopper bugs found in the RC. This will hopefully avoid a disaster like we had with the buggy last-minute changes in beta2 (for which I take full responsibility). If the idea of a RC sounds okay, I'd like to propose to release it on October 5. The final release would still be on October 10, or perhaps 1-2 days later. Much less than a week between the RC and the final release is not good because it doesn't give testers enough time to try out the RC; much more than a week is bad because the developers get antsy when they can't check in their changes! This means that any current bug reports and patches that aren't in the RC, WON'T BE FIXED in the final release! Think about it. This is a good thing, so we won't be able to screw up the final release at the last moment. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Sun Oct 1 14:06:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 1 Oct 2000 14:06:48 +0200 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500 References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <20001001140648.A12812@xs4all.nl> On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote: > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for some lunch/breakfast ;) I would be in favor if the str() output were only used to display something to a user, but that's not the case. And too many people are under the impression that the 'print' handler is the same as the 'str' handler to make that distinction now, I'm afraid. My main gripe with this change is that it makes str() for container objects unreliable... Strings are a special case, but class-instances are not -- so something like UserString will be displayed without quotes. I don't like the idea of sometimes doing 'str' and sometimes doing 'repr'. I understand what it's trying to solve, but I don't think that's a worse inconsistency than the one this change introduces. It's also easy to explain: 'str(list or dict) is the same as repr(list or dict)'. The new phrase would be something like 'str(list or dict) calls str() on the objects it contains, except for string and unicode objects.'. And even that breaks when you mix in instances that wrap a container. A list containing a UserList containing a set of (unicode-)strings would display the strings without quotes. And you can't see that the second container is a UserList. I also don't think this change should be made between the final beta and 2.0. Jeremy, don't let him ruin your feature freeze! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jim at digicool.com Sun Oct 1 16:32:27 2000 From: jim at digicool.com (Jim Fulton) Date: Sun, 01 Oct 2000 10:32:27 -0400 Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR) Message-ID: <39D74AFB.322E5187@digicool.com> If a select-based (or, presumably, poll-based) server wants to use signals for anything other than shutdown (e.g. closing and reopening log files, rereading configs, etc.), then, on some platforms, a select call can fail with an "interrupted system call" (EINTR) error that should be ignored. The asyncore main loop should check for this error in it's select call and the select module should make this error easier to check for. In Python 1.5.2, the medusa select call can be changed from r,w,e = select.select (r,w,e, timeout) to: while 1: try: r,w,e = select.select (r,w,e, timeout) except select.error, v: if v[0] != EINTR: raise else: break I presume that this works in Python 1.6/2.0, but I haven't tried it yet? This depends on the structure of select.error values and requires that we get EINTR from somewhere. (What should the value be on NT?) I wonder if there should be an InterruptedSystemCall exception somewhere that select raises in this case? At a minimum, code like the above should be added to asyncore. Thoughts? Jim -- Jim Fulton mailto:jim at digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From rushing at nightmare.com Sun Oct 1 21:07:59 2000 From: rushing at nightmare.com (Sam Rushing) Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT) Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR) In-Reply-To: <39D74AFB.322E5187@digicool.com> References: <39D74AFB.322E5187@digicool.com> Message-ID: <14807.35727.423642.721873@seattle.nightmare.com> Jim Fulton writes: > The asyncore main loop should check for this error in it's select > call and the select module should make this error easier to check > for. It might go better into the event_loop function, which I think of as a more user-serviceable part. [for example, the default loop vs. the one in medusa/event_loop.py that supports schedulable events] > I presume that this works in Python 1.6/2.0, but I > haven't tried it yet? > > This depends on the structure of select.error values > and requires that we get EINTR from somewhere. (What > should the value be on NT?) If it's a big problem, I guess we could use a different default event_loop() function for win32 vs. unix. > At a minimum, code like the above should be added to asyncore. > > Thoughts? This has been asked for several times, I agree it'd be nice to have at least a note in the docs.. -Sam From loewis at informatik.hu-berlin.de Sun Oct 1 21:13:41 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> > I'd like to poll opinions about this (we haven't had a PythonLabs > group meeting about this yet). YES! I was hoping somebody would propose such a thing; I was quite concerned that check-in procedures are still that liberate. To report how similar projects operate: In gcc, a CVS release branch is created at some point in time (usually months before the release). When the code is declared frozen, all changes to the release branch have to go through the release manager. After the release, "important" changes to the mainline branch are manually propagated to the release branch for subminor releases. Regards, Martin From dkwolfe at pacbell.net Sun Oct 1 23:23:03 2000 From: dkwolfe at pacbell.net (Dan Wolfe) Date: Sun, 01 Oct 2000 14:23:03 -0700 Subject: [Python-Dev] FW: regarding the Python Developer posting... Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net> >> [commented out code that was causing seg fault in test_sre.py] >you could try adding a Mac OS clause to the recursion limit stuff >in Modules/_sre.c: > >#if !defined(USE_STACKCHECK) >#if defined(...whatever's needed to detect Max OS X...) [....] > >replace "...whatever...", and try larger values than 5000 (or smaller, >if necessary. 10000 is clearly too large for your platform). > >(alternatively, you can increase the stack size. maybe it's very small >by default?) the stack size is quite small by default - 512K. After some testing I was able to figure out that it fails around 440 recursions... probably a bit too small in comparison to the other *nixes.... but then I'll defer to the experts in sre. I was reading the August developer archives on the getrlimit and since that seem to be available, it's probably the right way to implement the stack check on Mac OS X. Sure I can increase the default stack size - just a simple limit -h before running it in the shell... I let it run until about 7K recursions... even then it was only about 11MB and bumping the stack up by 30K or so per recursion... and I still had nearly 100MB free... and places to go. :-) I'm going to write a bug report against Mac OS X and we'll see what happens. In the meantime, you can hard code it to 440 and it will pass the test... I've placed a patch on sourceforge that give the initial support for detecting Mac OS X as part of the make file but I still have to figure out how/where you defined MS_WIN64.... - Dan From barry at scottb.demon.co.uk Mon Oct 2 00:19:21 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 1 Oct 2000 23:19:21 +0100 Subject: [Python-Dev] Patch to avoid conflict with older versions of Python. In-Reply-To: Message-ID: <000b01c02bf5$a5edf070$060210ac@private> I still think that Python needs to fix the problem with the API between the core and the extensions. That way all the version checking would work for Windows and Unix. But since that approach has been rejected I'd take any change to python that reduces support calls. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Mark Hammond > Sent: 29 September 2000 02:36 > To: python-dev at python.org > Subject: [Python-Dev] Patch to avoid conflict with older versions of > Python. > > > Hi all, > I'd like some feedback on a patch assigned to me. It is designed to > prevent Python extensions built for an earlier version of Python from > crashing the new version. > > I haven't actually tested the patch, but I am sure it works as advertised > (who is db31 anyway?). > > My question relates more to the "style" - the patch locates the new .pyd's > address in memory, and parses through the MS PE/COFF format, locating the > import table. If then scans the import table looking for Pythonxx.dll, and > compares any found entries with the current version. > > Quite clever - a definite plus is that is should work for all old and > future versions (of Python - dunno about Windows ;-) - but do we want this > sort of code in Python? Is this sort of hack, however clever, going to > some back and bite us? > > Second related question: if people like it, is this feature something we > can squeeze in for 2.0? > > If there are no objections to any of this, I am happy to test it and check > it in - but am not confident of doing so without some feedback. > > Thanks, > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From mal at lemburg.com Mon Oct 2 09:36:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:36:49 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <39D83B11.C1DE9EE8@lemburg.com> Martin von Loewis wrote: > > > I'd like to poll opinions about this (we haven't had a PythonLabs > > group meeting about this yet). > > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. > > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. +1 I think this is very good approach to the problem which we should consider to apply to Python too. BTW, could the nightly snapshots of the CVS tree that Jeremy installed be made official ? This would be a great way to attract more beta-tester since not everyone is willing to first set CVS on their machine just to download the current Python development version. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Oct 2 09:39:09 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:39:09 +0200 Subject: [Python-Dev] What is --with-next-framework Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> I've been trying to understand how --with-next-framework is supposed to work, and on what systems it is supposed to work - with little success. From what I understand, it will create a python2.0.dylib, and it will pass that to the linker when linking extension modules. Fine. What confuses me is the snippet in Modules/getpath.c, where it somehow assumes that the Python library will live in an unversioned lib directory relative to the location of the Python framework. How is that supposed to work? Is anybody here willing to claim that this code is not entirely broken? Regards, Martin From mal at lemburg.com Mon Oct 2 09:51:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 09:51:37 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> Message-ID: <39D83E89.62F57D79@lemburg.com> Guido van Rossum wrote: > > When we changed floats to behave different on repr() than on str(), we > briefly discussed changes to the container objects as well, but > nothing came of it. > > Currently, str() of a tuple, list or dictionary is the same as repr() > of those objects. This is not very consistent. For example, when we > have a float like 1.1 which can't be represented exactly, str() yields > "1.1" but repr() yields "1.1000000000000001". But if we place the > same number in a list, it doesn't matter which function we use: we > always get "[1.1000000000000001]". > > Below I have included changes to listobject.c, tupleobject.c and > dictobject.c that fix this. The fixes change the print and str() > callbacks for these objects to use PyObject_Str() on the contained > items -- except if the item is a string or Unicode string. I made > these exceptions because I don't like the idea of str(["abc"]) > yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. > And str() of a Unicode object fails when it contains non-ASCII > characters, so that's no good either -- it would break too much code. > > Is it too late to check this in? Another negative consequence would > be that for user-defined or 3rd party extension objects that have > different repr() and str(), like NumPy arrays, it might break some > code -- but I think this is not very likely. -1 I don't think that such a change is really worth breaking code which relies on the current output of repr(list) or str(list). As the test script from Fredrik for the Unicode database showed there are some very subtle implications to changes in str() and repr() -- e.g. in the mentioned case the hash value would change. Also, if I understand the patch correctly, str(list) would be almost the same as '[' + ', '.join(map(str, entries)) + ']' and '[' + ', '.join(map(repr, entries)) + ']' for repr(). While this may seem more transparent, I think it will cause problems in practice: e.g. for large data buffers, str(list) would now return the contents of the buffers rather than just an abstract note about a buffer containing the memory mapped data of file xyz.txt. As consequence, you'd suddenly get a few MBs of output instead of a 100 char string... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Oct 2 09:48:37 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 2 Oct 2000 09:48:37 +0200 Subject: [Python-Dev] Usage of --with- configure options Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> I noticed that Python's configure.in does not follow the autoconf style for using --enable- options. The autoconf documentation says # Some packages require, or can optionally use, other software packages # which are already installed. The user can give `configure' command # line options to specify which such external software to use. The # options have one of these forms: # # --with-PACKAGE[=ARG] # --without-PACKAGE ... # If a software package has optional compile-time features, the user # can give `configure' command line options to specify whether to compile # them. The options have one of these forms: # # --enable-FEATURE[=ARG] # --disable-FEATURE So --with- options should be used for integrating 3rd party libraries, --enable- options for features that that can be independently turned on or off. I'd conclude that the following options are provided incorrectly in Python 2.0: --with-pydebug (should be --enable-pydebug), --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something that should change? Regards, Martin From guido at python.org Mon Oct 2 13:30:45 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:30:45 -0500 Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200." <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com> > I noticed that Python's configure.in does not follow the autoconf > style for using --enable- options. The autoconf documentation says > > # Some packages require, or can optionally use, other software packages > # which are already installed. The user can give `configure' command > # line options to specify which such external software to use. The > # options have one of these forms: > # > # --with-PACKAGE[=ARG] > # --without-PACKAGE > ... > # If a software package has optional compile-time features, the user > # can give `configure' command line options to specify whether to compile > # them. The options have one of these forms: > # > # --enable-FEATURE[=ARG] > # --disable-FEATURE > > So --with- options should be used for integrating 3rd party libraries, > --enable- options for features that that can be independently turned > on or off. > > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? I noticed that too. (Arguably also for --with-thread?) I think it's a forgiveable sin against the autoconf style guide, and not worth the work of fixing it. Either way the autoconf --with- or --enable- syntax is stupid because it doesn't check for spelling errors in the options. The rationale for that is that some folks like to pass in unsupported options to a whole tree of configure scripts. I think that stinks, but what can I do. This would make the fix even more work, because we would have to trap --with*-pydebug and --with*-cycle-gc to give an error message, else developers used to the old syntax would never notice the change. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 13:35:40 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 06:35:40 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200." <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com> > I've been trying to understand how --with-next-framework is supposed > to work, and on what systems it is supposed to work - with little > success. > > From what I understand, it will create a python2.0.dylib, and it will > pass that to the linker when linking extension modules. Fine. > > What confuses me is the snippet in Modules/getpath.c, where it somehow > assumes that the Python library will live in an unversioned lib > directory relative to the location of the Python framework. How is > that supposed to work? Is anybody here willing to claim that this code > is not entirely broken? It's most likely broken. Which suggests that nobody has tried it in a *looooooong* time. I have no idea what the --with-next-framework option does, and I have no idea what a NeXT framework is. Why are we still trying to support NeXT? Isn't it completely obsolete? I propose to rip out --with-next-framework and be done with it. If you feel --with-next-framework is worth having, feel free to propose platform-specific fixes to getpathp.c. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Oct 2 15:22:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT) Subject: [Python-Dev] Usage of --with- configure options In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > I'd conclude that the following options are provided incorrectly in > Python 2.0: --with-pydebug (should be --enable-pydebug), > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something > that should change? Yes, if only to make it more consistent with existing practice. A harder one to change would be --enable-threads, because we've used that for so long already. Perhaps --enable-threads should be added, and use that in the README instead of --with-threads. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fredrik at pythonware.com Mon Oct 2 15:41:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 15:41:21 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com> Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF> guido wrote: > If the idea of a RC sounds okay Sure does. > I'd like to propose to release it on October 5. Hmm. My plan was to to work on the remaining SRE issues on Saturday, leaving Sunday-Tuesday for final "burn-in"... From petrilli at amber.org Mon Oct 2 16:14:23 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 10:14:23 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> Message-ID: <20001002101423.A18958@trump.amber.org> Guido van Rossum [guido at python.org] wrote: > > I've been trying to understand how --with-next-framework is supposed > > to work, and on what systems it is supposed to work - with little > > success. > > > > From what I understand, it will create a python2.0.dylib, and it will > > pass that to the linker when linking extension modules. Fine. > > > > What confuses me is the snippet in Modules/getpath.c, where it somehow > > assumes that the Python library will live in an unversioned lib > > directory relative to the location of the Python framework. How is > > that supposed to work? Is anybody here willing to claim that this code > > is not entirely broken? > > It's most likely broken. Which suggests that nobody has tried it in a > *looooooong* time. I have no idea what the --with-next-framework > option does, and I have no idea what a NeXT framework is. A NeXT Framework is a way of building software on NeXTstep/OpenStep machines, and as far as I can tell, it continues largely unmodified on MacOS X (which is more OpenStep than MacOS at many layers). We just got our development copies of MacOS X here at Digital Creations, so we can take a look, but... as I recall, Jeffrey Shell wasn't able to get Python running without using these options. > Why are we still trying to support NeXT? Isn't it completely > obsolete? I know of a few dozen large organizations still on OpenStep, and with MacOS X I'd say it's far frrom obsolete, if anything it's more likely than ever to be a"strong platform". > I propose to rip out --with-next-framework and be done with it. If > you feel --with-next-framework is worth having, feel free to propose > platform-specific fixes to getpathp.c. I think it should be auto-detected, there's just no reason not to. The uname of a MacOS X box is quite different than a Mac OX 9 box (which has no uname :-). Hopefully we can get a chance to look at this at work this week. Chris -- | Christopher Petrilli | petrilli at amber.org From thomas at xs4all.net Mon Oct 2 19:23:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 2 Oct 2000 19:23:19 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700 References: <200010021553.IAA01251@slayer.i.sourceforge.net> Message-ID: <20001002192319.C12812@xs4all.nl> On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200 > Modified Files: > readline.c > Log Message: > Supporting rl_library_version is more trouble than it's worth -- > readline doesn't have it before readline 2.2 and there's no > compile-time way to find out which readline version is in use. But we can detect whether readline has rl_library_version during runtime, and #ifdef it ;) I think the readline version info is useful enough to warrant the extra #define and #ifdef... I can whip it up tonight, if the autoconf check is desired ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Mon Oct 2 20:54:31 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 13:54:31 -0500 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400." <20001002101423.A18958@trump.amber.org> References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com> [Argument for the continued viability of OpenStep noted.] > I think it should be auto-detected, there's just no reason not to. > The uname of a MacOS X box is quite different than a Mac OX 9 box > (which has no uname :-). Hopefully we can get a chance to look at > this at work this week. Hm... That might not get there in time for the 2.0 Release Candidate, and after that it's an absolute code freeze (with exceptions only for showstopper bugfixes) until 2.0 is released. I guess MacOS X itself is still in beta, so we can afford to require the creation of additional patches to fully support it after 2.0 is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From petrilli at trump.amber.org Mon Oct 2 19:56:03 2000 From: petrilli at trump.amber.org (Christopher Petrilli) Date: Mon, 2 Oct 2000 13:56:03 -0400 Subject: [Python-Dev] What is --with-next-framework In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500 References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com> Message-ID: <20001002135603.C18958@trump.amber.org> Guido van Rossum [guido at python.org] wrote: > [Argument for the continued viability of OpenStep noted.] > > > I think it should be auto-detected, there's just no reason not to. > > The uname of a MacOS X box is quite different than a Mac OX 9 box > > (which has no uname :-). Hopefully we can get a chance to look at > > this at work this week. > > Hm... That might not get there in time for the 2.0 Release Candidate, > and after that it's an absolute code freeze (with exceptions only for > showstopper bugfixes) until 2.0 is released. > > I guess MacOS X itself is still in beta, so we can afford to require > the creation of additional patches to fully support it after 2.0 is > released. MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's a 2.1 planned sometime around there, which I believe there is, then it'd be fine to roll it into that level in my opinion. Chris -- | Christopher Petrilli | petrilli at amber.org From guido at python.org Mon Oct 2 21:15:37 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:15:37 -0500 Subject: [Python-Dev] Changes in semantics to str()? In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200." <20001001140648.A12812@xs4all.nl> References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com> I guess Thomas has settled the fate of my str() patch -- UserString won't be dealt with properly. I hereby withdraw the patch. (I'm not sure what Marc-Andre means by buffer objects whose str() is long but whose repr() is short, but it's probably a similar issue.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 21:19:24 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 14:19:24 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200." <200010011913.VAA01107@pandora.informatik.hu-berlin.de> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com> > YES! I was hoping somebody would propose such a thing; I was quite > concerned that check-in procedures are still that liberate. Good. We will have a release candidate then. > To report how similar projects operate: In gcc, a CVS release branch > is created at some point in time (usually months before the > release). When the code is declared frozen, all changes to the release > branch have to go through the release manager. After the release, > "important" changes to the mainline branch are manually propagated to > the release branch for subminor releases. I am reluctant to use CVS branches (my experience with the branch for 1.6 suggests again that this is not at all smooth). About the timing for the release candidate (RC): I think we need a week +/- two days between the RC and the final release; this is needed to make sure that the RC is actually tried out by enough people and that the bug reports (if any) have been processed. I believe we can refrain from checkin in for a week but not much longer. Fredrik Lundh mentions that he can't get his final batch of SRE patches in before Saturday. So the only realistic timing is to do the RC on Monday (Oct 9) and the final release a week later (Oct 16). Everybody okay with this? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Oct 2 20:35:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 02 Oct 2000 20:35:27 +0200 Subject: [Python-Dev] Changes in semantics to str()? References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com> <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com> Message-ID: <39D8D56F.F279B9E5@lemburg.com> Guido van Rossum wrote: > > I guess Thomas has settled the fate of my str() patch -- UserString > won't be dealt with properly. I hereby withdraw the patch. > > (I'm not sure what Marc-Andre means by buffer objects whose str() is > long but whose repr() is short, but it's probably a similar issue.) > Example for the record: >>> b = buffer('long string') >>> b >>> l = [b] >>> l [] >>> [str(b)] ['long string'] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nas at arctrix.com Mon Oct 2 13:48:59 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 04:48:59 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> Message-ID: <20001002044859.A9639@glacier.fnational.com> On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote: > So the only realistic timing is to do the RC on Monday (Oct 9) > and the final release a week later (Oct 16). > > Everybody okay with this? What is going to be the fate of the GC? There are currently two reported bugs which I have been unable to reproduce. If its going to be disabled for 2.0 then it should be disabled in the beta release. Neil From effbot at telia.com Mon Oct 2 21:11:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 21:11:58 +0200 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument References: <200010021341.GAA26413@bush.i.sourceforge.net> Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > Details: Split gives TypeError when called as a method of compiled > regular expression object with maxsplit as keyword argument. > This error is only in sre, pre is OK. > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > >>> import re > >>> patt = re.compile(' ') > >>> list = patt.split("a b c",50) # OK > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > >>> list = patt.split("a b c",maxsplit=50) # ERROR > Traceback (most recent call last): > File "", line 1, in ? > TypeError: this function takes no keyword arguments > > >>> import pre > >>> patt = pre.compile(' ') > >>> list = patt.split("a b c",maxsplit=50) # OK is this really a bug? should users expect to be able to use keyword arguments anywhere? From guido at python.org Mon Oct 2 22:09:32 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:09:32 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33 In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200." <20001002192319.C12812@xs4all.nl> References: <200010021553.IAA01251@slayer.i.sourceforge.net> <20001002192319.C12812@xs4all.nl> Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com> > But we can detect whether readline has rl_library_version during runtime, > and #ifdef it ;) I think the readline version info is useful enough to > warrant the extra #define and #ifdef... I can whip it up tonight, if the > autoconf check is desired ;P Actually, I'm not sure what difference the readline version makes -- why would you need it? Also, I'm not sure that the configure check is enough -- it's possible that readline lives in a non-standard place where configure can't find it but ppointed to by the Setup file. I think it's just not worth it. Please don't. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Oct 2 22:18:57 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 15:18:57 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200." <003e01c02ca4$a7e2ef20$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com> > http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470 > > > Details: Split gives TypeError when called as a method of compiled > > regular expression object with maxsplit as keyword argument. > > This error is only in sre, pre is OK. > > > > Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 > > >>> import re > > >>> patt = re.compile(' ') > > >>> list = patt.split("a b c",50) # OK > > >>> list = re.split(' ',"a b c",maxsplit=50) # OK > > >>> list = patt.split("a b c",maxsplit=50) # ERROR > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: this function takes no keyword arguments > > > > >>> import pre > > >>> patt = pre.compile(' ') > > >>> list = patt.split("a b c",maxsplit=50) # OK > > is this really a bug? should users expect to be able to use > keyword arguments anywhere? Unclear, but the names were documented, and it worked before (when pattern objects were Python instances) -- so who knows how much code there's lying around that assumes this. Well, we know it's more than zero, because the bug report came from soemone who ran into this. :-) Can we at PythonLabs help by adding keyword arguments to all of the _sre.c functions? I presume it's a pretty straightforward change. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Mon Oct 2 21:35:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 2 Oct 2000 21:35:45 +0200 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid> > Can we at PythonLabs help by adding keyword arguments to all of the > _sre.c functions? I presume it's a pretty straightforward change. if anyone can post (or point me to) an example showing how to use the keyword API, I can take if from there. From guido at python.org Mon Oct 2 23:06:00 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 16:06:00 -0500 Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200." <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com> > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. Grep the Modules directory for PyArg_ParseTupleAndKeywords. It's used in the mmap, parser, pyexpat and sha modules. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Oct 2 22:04:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid> References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com> <014001c02ca8$44f7eb00$766940d5@hagrid> Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if anyone can post (or point me to) an example showing > how to use the keyword API, I can take if from there. This is documented in the Extending & Embedding manual. The parser module (Modules/parsermodule.c) uses this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH at ActiveState.com Tue Oct 3 00:37:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 3 Oct 2000 09:37:13 +1100 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF> Message-ID: > guido wrote: > > If the idea of a RC sounds okay > > Sure does. > > > I'd like to propose to release it on October 5. > > Hmm. My plan was to to work on the remaining SRE issues on > Saturday, leaving Sunday-Tuesday for final "burn-in"... Also FYI, I intend applying the previous-version-crash patch tomorrow (or late today), so those extra few days for /F would also prevent this patch going out _too_ green... Mark. From fdrake at beopen.com Tue Oct 3 02:23:13 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT) Subject: [Python-Dev] Development HTML docs online Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com> I've set things up so I can easily "publish" the Python documentation online without actually building a release. It's not entirely automatic, but I can push it online easily, so you'll be able to see what I'm doing. It can include more than just what's in CVS, but I try not to have too much waiting to checkin at once. Check it out: ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Tue Oct 3 04:36:03 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 02 Oct 2000 21:36:03 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST." <20001002044859.A9639@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com> > What is going to be the fate of the GC? There are currently two > reported bugs which I have been unable to reproduce. If its > going to be disabled for 2.0 then it should be disabled in the > beta release. Good point. I see only the one that's assigned to you (reported by Rob Hooft): http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341 What's the other? Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe that's a clue? Does he also use threads? Is he willing to send his entire program over? (If you don't have time, we may have time at PythonLabs!) Anyway, I'm not yet ready to disable GC by default -- that's sensible but also defeats the purpose... --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at python.net Tue Oct 3 06:08:45 2000 From: gward at python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: <20001003000845.A1812@beelzebub> Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. Greg -- Greg Ward gward at python.net http://starship.python.net/~gward/ And now for something completely different. From fredrik at pythonware.com Tue Oct 3 10:52:37 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 10:52:37 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <200010030832.BAA05615@slayer.i.sourceforge.net> Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF> > Change first line to #!/usr/bin/env python (really just to test check-in). hmm. cgi.py is a CGI script. according to the Python FAQ, CGI scripts should use an explicit path, not /usr/bin/env: "Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter." (since this comes up over and over again, maybe someone should add a comment to the file?) From ping at lfw.org Tue Oct 3 12:15:13 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: On Tue, 3 Oct 2000, Fredrik Lundh wrote: > > Change first line to #!/usr/bin/env python (really just to test check-in). > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > scripts should use an explicit path, not /usr/bin/env: > > "Note -- *don't* do this for CGI scripts. The $PATH variable > for CGI scripts is often very minimal, so you need to use the > actual absolute pathname of the interpreter." The $PATH variable for CGI scripts may be minimal, but minimal as it is, Python should still be on it. Using /usr/bin/python works for half the people and /usr/local/bin/python works for the other half... /usr/bin/env is supposed to work for everyone. If this has already been argued soundly to death, i'm happy to back out the change and add a comment. It was a meaningless change for me anyway. Oh well. Anyway, i'm glad CVS commit *finally* works for me. Sorry for the extra hassle. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From nas at arctrix.com Tue Oct 3 08:41:18 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 2 Oct 2000 23:41:18 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001002234118.A11108@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > What's the other? Some people from Origin Systems have reported a crash. They are using Python in a large application (probably related to the Ultima Online game). I will put the bug report in the database today. They are using a custom version of cPickle that may be causing the problem. It is an instance object which is causing the trouble. My malloc() == NULL patch for classobject.c did not fix things. They still haven't reported back regarding the cPickle fix. > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. > Maybe that's a clue? I don't think _tkinter does anything special (unlike cPickle and new). > Does he also use threads? His interpreter has threads enabled it seems. Maybe I should get him to test without threads, assuming he doesn't require them. > Is he willing to send his entire program over? From bwarsaw at beopen.com Tue Oct 3 15:49:23 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 References: <011801c02d17$48659b10$0900a8c0@SPIFF> Message-ID: <14809.58339.707476.273418@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> The $PATH variable for CGI scripts may be minimal, but minimal KY> as it is, Python should still be on it. Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes $PATH from the environment before calling python with a compiled in absolute path. Which leads me to ask: how often are you calling cgi.py directly anyway? That'll just run the text() function which isn't terribly useful other than to debug your cgi setup. Usually you're calling some other module that imports cgi, and in that case this line won't have any effect. And besides, it's not very safe to call a script directly so I'd recommend a wrapper program anyway. I'd say this one is rather harmless. -Barry From guido at python.org Tue Oct 3 16:58:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 09:58:00 -0500 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54 In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST." References: Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com> > > hmm. cgi.py is a CGI script. according to the Python FAQ, CGI > > scripts should use an explicit path, not /usr/bin/env: > > > > "Note -- *don't* do this for CGI scripts. The $PATH variable > > for CGI scripts is often very minimal, so you need to use the > > actual absolute pathname of the interpreter." > > The $PATH variable for CGI scripts may be minimal, but minimal > as it is, Python should still be on it. Using /usr/bin/python > works for half the people and /usr/local/bin/python works for > the other half... /usr/bin/env is supposed to work for everyone. No. On a typical Unix system (Linux perhaps excluded), /usr/local/bin is not on the default $PATH. > If this has already been argued soundly to death, i'm happy to > back out the change and add a comment. It was a meaningless > change for me anyway. I backed it out for you. It really has been argued to death. Glad CVS works for you! --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Tue Oct 3 17:37:21 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT) Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <20001002234118.A11108@glacier.fnational.com> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001002234118.A11108@glacier.fnational.com> Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: [GvR writes:] >> Anyway, I'm not yet ready to disable GC by default -- that's >> sensible but also defeats the purpose... NS> Okay. I think I've found a possible problem. When I set NS> threshold0 to 1 in the C code, weird things start happening. NS> I'm looking into it. I agree that it isn't too useful to ship the garbage collector, but have it turned off. On the other hand, we're going to get a lot of unhappy users if GC bugs cause inexplicable crashes in large programs. It would be hard to sell Python for important applications, e.g. long-running server processes, if there was a small possibility that the program could crash through no fault of its own. Jeremy From bwarsaw at beopen.com Tue Oct 3 17:39:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in Message-ID: <14809.64935.157146.681813@anthem.concentric.net> I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with the zlib rpm installed, all I need to enable this module is the following line: zlib zlibmodule.c -lz but Setup.in has this suggestion, which I think is too hard for people to figure out what to do: zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz The standard build options will already include the right -I and -L flags for this to Just Work. I suggest we make the common case (Linux?) simple, and let others figure out what the right -I and -L flags are. I submit that even if they /do/ have to handcraft -I and -L, the defaults in Setup.in are pretty meaningless. A worthy change? For 2.0 final? -Barry From guido at python.org Tue Oct 3 19:31:47 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 12:31:47 -0500 Subject: [Python-Dev] Canvas.Canvas.bbox() return value Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com> Hi Fredrik, Re this bug report: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 I can take care of the Canvas issues, but I need your advice on bbox(). He's right that the bbox() method the Canvas class in the Canvas module is different from all other bbox() methods: it returns a tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple (x,y1,x2,y2). Do you think it's worth not breaking existing code here??? --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Tue Oct 3 18:34:51 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c Message-ID: <14810.2731.466997.243906@anthem.concentric.net> I've found a small memory leak in unicodeobject.c, in the way _PyUnicode_Fini() shuts down. Take a loop such as: -------------------- snip snip -------------------- #include "Python.h" int main(int argc, char** argv) { int i; while (1) { Py_Initialize(); Py_Finalize(); } return 0; } -------------------- snip snip -------------------- and you'll find that unicode_empty leaks. This is because, while _PyUnicode_Fini() decrefs unicode_empty, it never actually gets freed. Instead it gets placed on the already freed unicode_freelist! See _PyUnicode_Free() for why. I've come up with the following nasty hack to force unicode_empty to really be freed in _PyUnicode_Fini(). Maybe there's a better way to do this. Note that moving the decref of unicode_empty to above the freeing of unicode_freelist didn't plug the memory leak for me (but I'm quite tired so maybe I missed something! ;} ). Below is the proposed patch. -Barry -------------------- snip snip -------------------- Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -u -r2.64 unicodeobject.c --- unicodeobject.c 2000/09/26 05:46:01 2.64 +++ unicodeobject.c 2000/10/03 16:31:32 @@ -5234,7 +5234,11 @@ PyObject_DEL(v); } unicode_freelist = NULL; - unicode_freelist_size = 0; + /* XXX This is a hack to force the freeing of unicode_empty's memory. + * Otherwise, it'll get placed on the already freed free list. + */ + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; Py_XDECREF(unicode_empty); unicode_empty = NULL; + unicode_freelist_size = 0; } From effbot at telia.com Tue Oct 3 19:08:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 19:08:05 +0200 Subject: [Python-Dev] Canvas.Canvas.bbox() return value References: <200010031731.MAA08827@cj20424-a.reston1.va.home.com> Message-ID: <001801c02d5c$801d0300$766940d5@hagrid> > Hi Fredrik, > > Re this bug report: > > http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 > > I can take care of the Canvas issues, but I need your advice on > bbox(). He's right that the bbox() method the Canvas class in the > Canvas module is different from all other bbox() methods: it returns a > tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple > (x,y1,x2,y2). > > Do you think it's worth not breaking existing code here??? no idea -- I don't think I've ever used that module (!). (I'd deprecate the entire module if I were in charge -- there are better ways to put objects on the canvas) but in case someone's using it, it's probably best to leave things as they are... From thomas at xs4all.net Tue Oct 3 19:07:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 3 Oct 2000 19:07:11 +0200 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400 References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <20001003190711.D12812@xs4all.nl> On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote: > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > A worthy change? For 2.0 final? What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by default, for all modules, if those directories already exist ? Because zlib is not the only module that has this problem. On BSDI and Solaris, the same problem exists for curses, readline and gdbm, at least. If you are installing in a completely separate tree, for whatever reason, either those include/lib directories won't exist, they won't contain anything useful, or they will contain the actual libraries you want to link with, anyway ;-P And if you are installing in a 'standard' tree, like /usr, /usr/local, /usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be there, too. If you don't fall under any of these cases, you'll have to do what you have to do now, figure it out by hand. I don't think changing the zlib line alone is going to matter much; it stops working 'out of the box' for the slightly-less common case of non-linux platforms (and not even all linux platforms ! There is no reason why a distribution would install zlib in /usr.) I would prefer adding a comment that clarifies the -I/-L lines, over removing them altogether, if we aren't including $prefix/include and $exec_prefix/lib by default. I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Oct 3 19:13:39 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5 In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net> References: <200010031651.JAA06853@slayer.i.sourceforge.net> Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net> Thomas, Thanks for taking care of this. One nit on the checkin procedure, pleae reference the SF bug number when you're fixing a bug. Also, report the revision number of the changed file when you close the bug. Thanks, Jeremy From fdrake at beopen.com Tue Oct 3 19:08:06 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT) Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > A worthy change? For 2.0 final? This is good; even better would be the configure magic to make it work automatically, similar to what we have for bsddb. Given the short time frame, your approach is good. There may be other modules that need similar adjustments in Setup.in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Oct 3 19:13:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 19:13:40 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <39DA13C4.B1855D9A@lemburg.com> "Barry A. Warsaw" wrote: > > I've found a small memory leak in unicodeobject.c, in the way > _PyUnicode_Fini() shuts down. Take a loop such as: > > -------------------- snip snip -------------------- > #include "Python.h" > > int main(int argc, char** argv) > { > int i; > > while (1) { > Py_Initialize(); > Py_Finalize(); > } > return 0; > } > -------------------- snip snip -------------------- > > and you'll find that unicode_empty leaks. This is because, while > _PyUnicode_Fini() decrefs unicode_empty, it never actually gets > freed. Instead it gets placed on the already freed unicode_freelist! > See _PyUnicode_Free() for why. > > I've come up with the following nasty hack to force unicode_empty to > really be freed in _PyUnicode_Fini(). Maybe there's a better way to > do this. Note that moving the decref of unicode_empty to above the > freeing of unicode_freelist didn't plug the memory leak for me (but > I'm quite tired so maybe I missed something! ;} ). It would be easier to simply move the Py_DECREF() in front of the cleanup code for the free list. That way, unicode_empty would be placed on the free list, but then immedialtely cleaned up by the following code. Should I check in such a patch ? > Below is the proposed patch. > -Barry > > -------------------- snip snip -------------------- > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 3 20:28:08 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:28:08 -0500 Subject: [Python-Dev] Suggested change for Setup.in In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400." <14809.64935.157146.681813@anthem.concentric.net> References: <14809.64935.157146.681813@anthem.concentric.net> Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com> > I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with > the zlib rpm installed, all I need to enable this module is the > following line: > > zlib zlibmodule.c -lz > > but Setup.in has this suggestion, which I think is too hard for people > to figure out what to do: > > zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz > > The standard build options will already include the right -I and -L > flags for this to Just Work. I suggest we make the common case > (Linux?) simple, and let others figure out what the right -I and -L > flags are. I submit that even if they /do/ have to handcraft -I and > -L, the defaults in Setup.in are pretty meaningless. > > A worthy change? For 2.0 final? Check it in right now. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Tue Oct 3 19:54:44 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 3 Oct 2000 19:54:44 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5 References: <200010031651.JAA06853@slayer.i.sourceforge.net> <14810.5059.445654.876073@bitdiddle.concentric.net> Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid> > Thanks for taking care of this. One nit on the checkin procedure, > pleae reference the SF bug number when you're fixing a bug. Also, > report the revision number of the changed file when you close the bug. do you really need both? the former is easy, the latter is more of a PITA, at least with the CVS setup I'm using here... From guido at python.org Tue Oct 3 20:58:20 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 03 Oct 2000 13:58:20 -0500 Subject: [Python-Dev] Small memory leak in unicodeobject.c In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400." <14810.2731.466997.243906@anthem.concentric.net> References: <14810.2731.466997.243906@anthem.concentric.net> Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com> > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -u -r2.64 unicodeobject.c > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > +++ unicodeobject.c 2000/10/03 16:31:32 > @@ -5234,7 +5234,11 @@ > PyObject_DEL(v); > } > unicode_freelist = NULL; > - unicode_freelist_size = 0; > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > + * Otherwise, it'll get placed on the already freed free list. > + */ > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > Py_XDECREF(unicode_empty); > unicode_empty = NULL; > + unicode_freelist_size = 0; > } Doesn't it make more sense to decref unicode_empty sooner? The loop over the free list won't touch it: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -c -r2.64 unicodeobject.c *** unicodeobject.c 2000/09/26 05:46:01 2.64 --- unicodeobject.c 2000/10/03 17:55:34 *************** *** 5225,5230 **** --- 5225,5232 ---- { PyUnicodeObject *u = unicode_freelist; + Py_XDECREF(unicode_empty); + unicode_empty = NULL; while (u != NULL) { PyUnicodeObject *v = u; u = *(PyUnicodeObject **)u; *************** *** 5235,5240 **** } unicode_freelist = NULL; unicode_freelist_size = 0; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; } --- 5237,5240 ---- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Oct 3 20:02:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 03 Oct 2000 20:02:39 +0200 Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com> Message-ID: <39DA1F3F.9EFA41EB@lemburg.com> Guido van Rossum wrote: > > > Index: unicodeobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > > retrieving revision 2.64 > > diff -u -r2.64 unicodeobject.c > > --- unicodeobject.c 2000/09/26 05:46:01 2.64 > > +++ unicodeobject.c 2000/10/03 16:31:32 > > @@ -5234,7 +5234,11 @@ > > PyObject_DEL(v); > > } > > unicode_freelist = NULL; > > - unicode_freelist_size = 0; > > + /* XXX This is a hack to force the freeing of unicode_empty's memory. > > + * Otherwise, it'll get placed on the already freed free list. > > + */ > > + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; > > Py_XDECREF(unicode_empty); > > unicode_empty = NULL; > > + unicode_freelist_size = 0; > > } > > Doesn't it make more sense to decref unicode_empty sooner? Right. That's the change I proposed to Barry in my last mail. Please check this in. Thanks, Marc-Andre > The loop > over the free list won't touch it: > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.64 > diff -c -r2.64 unicodeobject.c > *** unicodeobject.c 2000/09/26 05:46:01 2.64 > --- unicodeobject.c 2000/10/03 17:55:34 > *************** > *** 5225,5230 **** > --- 5225,5232 ---- > { > PyUnicodeObject *u = unicode_freelist; > > + Py_XDECREF(unicode_empty); > + unicode_empty = NULL; > while (u != NULL) { > PyUnicodeObject *v = u; > u = *(PyUnicodeObject **)u; > *************** > *** 5235,5240 **** > } > unicode_freelist = NULL; > unicode_freelist_size = 0; > - Py_XDECREF(unicode_empty); > - unicode_empty = NULL; > } > --- 5237,5240 ---- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at beopen.com Tue Oct 3 22:35:10 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17150.777092.128211@anthem.concentric.net> >>>>> "M" == M writes: M> It would be easier to simply move the Py_DECREF() in front of M> the cleanup code for the free list. That way, unicode_empty M> would be placed on the free list, but then immedialtely cleaned M> up by the following code. I know that's the obvious fix -- and it was the first thing I tried, but it doesn't work! (I thought I mentioned that in my original message). Verifying after a cvs up still shows unicode_empty leaking (I loop through the Py_Initialize/Py_Finalize loop 10 times): -------------------- snip snip -------------------- 240 bytes 10 chunks allocated at unicodeobject.c, 227 malloc() _PyUnicode_New() unicodeobject.c, 227 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() 30 bytes 10 chunks allocated at unicodeobject.c, 230 malloc() _PyUnicode_New() unicodeobject.c, 230 _PyUnicode_Init() unicodeobject.c, 5217 Py_Initialize() pythonrun.c, 125 main() -------------------- snip snip -------------------- So let me step through the code and figure out what's wrong... -Barry From loewis at informatik.hu-berlin.de Tue Oct 3 22:39:06 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST) Subject: [Python-Dev] Release candidate followed by feature freeze? Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de> > It would be hard to sell Python for important applications, > e.g. long-running server processes, if there was a small possibility > that the program could crash through no fault of its own. There is always a small possibility that the program could crash through no faults of its own - i.e. I don't believe that Python is bug free without gc. I'd agree that bugs in the gc are more serious than other bugs. If it turns out that there are serious bugs in 2.0 (whether in the gc or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they get fixed. Regards, Martin From bwarsaw at beopen.com Tue Oct 3 22:42:25 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT) Subject: [Python-Dev] Small memory leak in unicodeobject.c References: <14810.2731.466997.243906@anthem.concentric.net> <39DA13C4.B1855D9A@lemburg.com> Message-ID: <14810.17585.567814.278594@anthem.concentric.net> Oh the problem is obvious. You have to initialize the local variable `u' /after/ unicode_empty is freed otherwise it doesn't point to the proper start of the free list. I'll check that change in. -Barry From MarkH at ActiveState.com Wed Oct 4 00:58:14 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 09:58:14 +1100 Subject: [Python-Dev] pep42 procedure? Message-ID: Please excuse my ignorance... I am in the process of applying the patch to prevent 1.5/1.6 extensions crashing 2.0 under Windows. Based on the feedback here (ie, "this should be a short term patch"), the various other patches that try to do the same thing, and the belief by some that we should be more like Unix anyway, I believe we should try and capture this entire issue in a more formal manner. The 2 logical places would be as a bug, and in pep42. However, after applying this patch, it doesnt really qualify as a bug! Putting it in pep42 is slightly suspect, as it is not a thought-out feature request yet - however, I believe capturing it there, with links to the relevant patches and discussions would be valuable. So, assuming this sounds reasonable - a bug, or pep42? If pep42, what is the procedure for changing it? I couldnt find it (or any pep) in the CVS repository, and the source-force pages would show me the peps, but not their source. I do remember seeing this mentioned some time ago, but can't locate that mail either... Thanks, Mark. From trentm at ActiveState.com Wed Oct 4 01:08:09 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:08:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows Message-ID: <20001003160809.A18387@ActiveState.com> Fred's checkin: http://www.python.org/pipermail/python-checkins/2000-September/008355.html breaks test_popen2.py on windows. This is because test_popen2.py attempts to refer to popen2's internal '_active' variable, which is now explicitly deleted on Windows platforms. test_popen2.py should be updated for the new popen2 semantics. sorry-no-patch-ly yours, Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Wed Oct 4 01:10:09 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 3 Oct 2000 16:10:09 -0700 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700 References: <20001003160809.A18387@ActiveState.com> Message-ID: <20001003161009.B18387@ActiveState.com> On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote: > > Fred's checkin: > http://www.python.org/pipermail/python-checkins/2000-September/008355.html > breaks test_popen2.py on windows. > > This is because test_popen2.py attempts to refer to popen2's internal > '_active' variable, which is now explicitly deleted on Windows platforms. > > test_popen2.py should be updated for the new popen2 semantics. > Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my email but before my email made it to python-dev!) Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Wed Oct 4 02:54:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT) Subject: [Python-Dev] pep42 procedure? In-Reply-To: References: Message-ID: <14810.32735.229954.547385@beluga.mojam.com> Mark> So, assuming this sounds reasonable - a bug, or pep42? I think neither. This topic seems to have generated a lot of discussion. I think it deserves a bit more elaboration than what you'd find reasonable for pep42. Also, it would be kinda nice to add it to the Python FAQ with a reference to a specific pep for all the gory details of the problem and solution(s). Skip From MarkH at ActiveState.com Wed Oct 4 05:58:25 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 4 Oct 2000 14:58:25 +1100 Subject: [Python-Dev] pep42 procedure? In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: > I think neither. This topic seems to have generated a lot of > discussion. I > think it deserves a bit more elaboration than what you'd find > reasonable for > pep42. Also, it would be kinda nice to add it to the Python FAQ with a > reference to a specific pep for all the gory details of the problem and > solution(s). That would be a great idea, if only we had a PEP author. To be honest, I really dont care too much about this issue, and have been doing my level best to avoid it. But Tim knows that, and delights in assigning related patches to me ;-) I certainly don't care enough to own a pep on it. The way things stand, I have a checkin ready to go, and am unwilling to commit to any sort of pep in the short or medium term. The best I could do is to add links to the 3 or 4 other patches submitted for the same thing, and pep42 seemed ideal. So given this, what should I do - just check it in, and leave it to the collective memory? ;-) Mark. From tim_one at email.msn.com Wed Oct 4 06:58:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 4 Oct 2000 00:58:46 -0400 Subject: [Python-Dev] CIV Message-ID: No, that's not 104, it's a Call for Indentation Volunteers! An item that mistakenly got dropped on the floor before 2.0b1 was to ensure that the standard Python libraries follow the recommended "4-space indents, no hard tabs" guideline. Since 100s of files (especially older ones in oddball directories) are affected, I moved that it into PEP42 rather than risk destabilizing the release after 2.0b1. So it will happen instead soon after 2.0final is released. I looked at existing tools for doing this, and found they all left way too much manual fiddling to bear, too prone to screw up on comment lines (e.g., try running your favorite tool over pindent.py: does the output bear any resemblance to the input?! The Emacs pymode does OK there because pindent comments match its conventions for "indenting comment lines", but nothing else even gets close; OTOH, if 1: # some insane people like # writing comments # like this too and nobody knows what to do about that). Attached is a new tool that tries much harder to get perverse comments right (everything else is easy). Try it and gripe at will. Since I wrote it while on vacation, it's public domain <0.5 wink>. regularly y'rs - tim #! /usr/bin/env python # Released to the public domain, by Tim Peters, 03 October 2000. """reindent [-d][-r][-v] path ... -d Dry run. Analyze, but don't make any changes to, files. -r Recurse. Search for all .py files in subdirectories too. -v Verbose. Print informative msgs; else no output. Change Python (.py) files to use 4-space indents and no hard tab characters. Also trim excess whitespace from ends of lines, and empty lines at the ends of files. Ensure the last line ends with a newline. Pass one or more file and/or directory paths. When a directory path, all .py files within the directory will be examined, and, if the -r option is given, likewise recursively for subdirectories. Overwrites files in place, renaming the originals with a .bak extension. If reindent finds nothing to change, the file is left alone. If reindent does change a file, the changed file is a fixed-point for reindent (i.e., running reindent on the resulting .py file won't change it again). The hard part of reindenting is figuring out what to do with comment lines. So long as the input files get a clean bill of health from tabnanny.py, reindent should do a good job. """ import tokenize import os import sys verbose = 0 recurse = 0 dryrun = 0 def errprint(*args): sep = "" for arg in args: sys.stderr.write(sep + str(arg)) sep = " " sys.stderr.write("\n") def main(): import getopt global verbose, recurse, dryrun try: opts, args = getopt.getopt(sys.argv[1:], "drv") except getopt.error, msg: errprint(msg) return for o, a in opts: if o == '-d': dryrun += 1 elif o == '-r': recurse += 1 elif o == '-v': verbose += 1 if not args: errprint("Usage:", __doc__) return for arg in args: check(arg) def check(file): if os.path.isdir(file) and not os.path.islink(file): if verbose: print "listing directory", file names = os.listdir(file) for name in names: fullname = os.path.join(file, name) if ((recurse and os.path.isdir(fullname) and not os.path.islink(fullname)) or name.lower().endswith(".py")): check(fullname) return if verbose: print "checking", file, "...", try: f = open(file) except IOError, msg: errprint("%s: I/O Error: %s" % (file, str(msg))) return r = Reindenter(f) f.close() if r.run(): if verbose: print "changed." if dryrun: print "But this is a dry run, so leaving it alone." if not dryrun: bak = file + ".bak" if os.path.exists(bak): os.remove(bak) os.rename(file, bak) if verbose: print "renamed", file, "to", bak f = open(file, "w") r.write(f) f.close() if verbose: print "wrote new", file else: if verbose: print "unchanged." class Reindenter: def __init__(self, f): self.find_stmt = 1 # next token begins a fresh stmt? self.level = 0 # current indent level # Raw file lines. self.raw = f.readlines() # File lines, rstripped & tab-expanded. Dummy at start is so # that we can use tokenize's 1-based line numbering easily. # Note that a line is all-blank iff it's "\n". self.lines = [line.rstrip().expandtabs() + "\n" for line in self.raw] self.lines.insert(0, None) self.index = 1 # index into self.lines of next line # List of (lineno, indentlevel) pairs, one for each stmt and # comment line. indentlevel is -1 for comment lines, as a # signal that tokenize doesn't know what to do about them; # indeed, they're our headache! self.stats = [] def run(self): tokenize.tokenize(self.getline, self.tokeneater) # Remove trailing empty lines. lines = self.lines while lines and lines[-1] == "\n": lines.pop() # Sentinel. stats = self.stats stats.append((len(lines), 0)) # Map count of leading spaces to # we want. have2want = {} # Program after transformation. after = self.after = [] for i in range(len(stats)-1): thisstmt, thislevel = stats[i] nextstmt = stats[i+1][0] have = getlspace(lines[thisstmt]) want = thislevel * 4 if want < 0: # A comment line. if have: # An indented comment line. If we saw the same # indentation before, reuse what it most recently # mapped to. want = have2want.get(have, -1) if want < 0: # Then it probably belongs to the next real stmt. for j in xrange(i+1, len(stats)-1): jline, jlevel = stats[j] if jlevel >= 0: if have == getlspace(lines[jline]): want = jlevel * 4 break if want < 0: # Maybe it's a hanging # comment like this one, # in which case we should shift it like its base # line got shifted. for j in xrange(i-1, -1, -1): jline, jlevel = stats[j] if jlevel >= 0: want = have + getlspace(after[jline-1]) - \ getlspace(lines[jline]) break if want < 0: # Still no luck -- leave it alone. want = have else: want = 0 assert want >= 0 have2want[have] = want diff = want - have if diff == 0 or have == 0: after.extend(lines[thisstmt:nextstmt]) else: for line in lines[thisstmt:nextstmt]: if diff > 0: if line == "\n": after.append(line) else: after.append(" " * diff + line) else: remove = min(getlspace(line), -diff) after.append(line[remove:]) return self.raw != self.after def write(self, f): f.writelines(self.after) # Line-getter for tokenize. def getline(self): if self.index >= len(self.lines): line = "" else: line = self.lines[self.index] self.index += 1 return line # Line-eater for tokenize. def tokeneater(self, type, token, (sline, scol), end, line, INDENT=tokenize.INDENT, DEDENT=tokenize.DEDENT, NEWLINE=tokenize.NEWLINE, COMMENT=tokenize.COMMENT, NL=tokenize.NL): if type == NEWLINE: # A program statement, or ENDMARKER, will eventually follow, # after some (possibly empty) run of tokens of the form # (NL | COMMENT)* (INDENT | DEDENT+)? self.find_stmt = 1 elif type == INDENT: self.find_stmt = 1 self.level += 1 elif type == DEDENT: self.find_stmt = 1 self.level -= 1 elif type == COMMENT: if self.find_stmt: self.stats.append((sline, -1)) # but we're still looking for a new stmt, so leave # find_stmt alone elif type == NL: pass elif self.find_stmt: # This is the first "real token" following a NEWLINE, so it # must be the first token of the next program statement, or an # ENDMARKER. self.find_stmt = 0 if line: # not endmarker self.stats.append((sline, self.level)) # Count number of leading blanks. def getlspace(line): i, n = 0, len(line) while i < n and line[i] == " ": i += 1 return i if __name__ == '__main__': main() From bwarsaw at beopen.com Wed Oct 4 08:06:14 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT) Subject: [Python-Dev] pep42 procedure? References: Message-ID: <14810.51414.59852.855231@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> I couldnt find it (or any pep) in the CVS repository, and the MH> source-force pages would show me the peps, but not their MH> source. The PEPs are located in the nondist directory, under nondist/peps! -Barry From bwarsaw at beopen.com Wed Oct 4 08:07:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com Message-ID: <14810.51466.486982.938180@anthem.concentric.net> An embedded message was scrubbed... From: aahz at panix.com Subject: htmllib.HTMLescape() Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT) Size: 1672 URL: From thomas at xs4all.net Wed Oct 4 08:16:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 08:16:58 +0200 Subject: [Python-Dev] pep42 procedure? In-Reply-To: ; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100 References: <14810.32735.229954.547385@beluga.mojam.com> Message-ID: <20001004081658.E12812@xs4all.nl> On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote: [ Mark wants to apply a patch that prevents crashes on windows when loading extentions linked with old Python DLLs, but doesn't know where to document it: PEP 42 or the bug report(s) ] [ Skip proposes a separate PEP ] [ Mark doesn't have time to write a PEP ] > So given this, what should I do - just check it in, and leave it to the > collective memory? ;-) PEP 42 is the meaning of life PEP, meaning that it's everything that needs to be done before python-dev can rest in pieces. I don't think that a solved issue is in its place there, even if it had such a section. A PEP on its own would probably be the best spot, because even if it's a 'temporary' solution now, we or someone else might need the info later. And a PEP doesn't have to be that hard to write ;) And besides, you don't have to be the person to write the PEP, someone else can. And if noone suitable volunteers, perhaps a checkin-message giving 'full' documentation, the necessary sourcecode comments and a reference to both in the bugreport message will suffice... But I'm willing to PEPify whatever docs or comments you write on this issue, Mark. I will need some guidance on what exactly is the issue, but I'm sure I'll get that from one of you Windows lovers ! :-) And no, I don't think Python should be more like UNIX. Windows, yes, but it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides, that would only alienate the Windows users with Uni(x)fobia. Unix-unix-unix-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Wed Oct 4 13:02:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT) Subject: [Python-Dev] Installing python in /usr/bin Message-ID: The cgi.py discussion brought my attention to this comment from Guido: > No, no, no! The /usr/bin/env form *fails* on most platforms (except > Linux) because Python is not installed in any of the default "bin" > directories -- /usr/local/bin is the standard install place and that's > not in the default path. So the natural question to ask is -- why not install Python in /usr/bin like everyone else? Perhaps a while ago Python wasn't popular enough to belong in /usr/bin and decided to modestly stay out of the way in /usr/local/bin instead? But by now, i think it's quite qualified to take its seat in /usr/bin along with all the other standard Unix binaries like /usr/bin/vi, /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default binary directory. Your thoughts? -- ?!ng From thomas at xs4all.net Wed Oct 4 13:35:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 4 Oct 2000 13:35:28 +0200 Subject: [Python-Dev] Installing python in /usr/bin In-Reply-To: ; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700 References: Message-ID: <20001004133528.G12812@xs4all.nl> On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote: > So the natural question to ask is -- why not install Python in /usr/bin > like everyone else? > Perhaps a while ago Python wasn't popular enough to belong in /usr/bin > and decided to modestly stay out of the way in /usr/local/bin instead? The only reason is the hysterical one: it's always been that way. Traditionally, /usr/local/bin was the place for user-installed binaries. This sets them apart from the the vendor-supplied binaries (commonly in /bin and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and /usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.) > But by now, i think it's quite qualified to take its seat in /usr/bin > along with all the other standard Unix binaries like /usr/bin/vi, > /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default > binary directory. Perl only resides in /usr/bin if the vendor (or distribution-maker, in the case of the Free OSes) put it there. The default for Perl is /usr/local as well. In fact, almost all source packages default to /usr/local; I have yet to see a package that uses autoconf and does not have /usr/local as the default prefix, for instance. I think the best solution is just for every OS to put /usr/local/bin in their path, and not pretend they delivered the Definitive Collection of Useful Programs. Installing Python in /usr can do more damage than good -- think of all the people that are used to have it installed in /usr/local, don't specify a prefix because they 'know' it's /usr/local by default, and end up filling up their minimal /usr partition with Python ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward at python.net Tue Oct 3 06:08:45 2000 From: gward at python.net (Greg Ward) Date: Tue, 3 Oct 2000 00:08:45 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 1.0 Message-ID: Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. Greg -- Greg Ward gward at python.net http://starship.python.net/~gward/ And now for something completely different. From bwarsaw at beopen.com Wed Oct 4 15:44:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT) Subject: [Python-Dev] Installing python in /usr/bin References: <20001004133528.G12812@xs4all.nl> Message-ID: <14811.13384.137080.196973@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> The only reason is the hysterical one: it's always been that TW> way. Traditionally, /usr/local/bin was the place for TW> user-installed binaries. Yes exactly. And in fact on my RH6.1 system, I have Python in both /usr/bin and /usr/local/bin. RedHat sticks its rpms in /usr/bin, and right now, 1.5.2 resides there. My dev copy gets installed from source into /usr/local/bin, and that's the current CVS snapshot. This is as it should be and all is right in the world. The rule is -- and ought to be -- that the default install location in a build-from-source distro is /usr/local. rpms or other package installs can install where ever is appropriate for that platform (e.g. if someone were to build a Solaris pkg distro, it probably ought to install to /opt by default). if-it-ain't-broke...-ly y'rs, -Barry From nas at arctrix.com Wed Oct 4 11:46:36 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 02:46:36 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700 References: <200010041622.JAA17363@slayer.i.sourceforge.net> Message-ID: <20001004024636.A13475@glacier.fnational.com> On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules > > Modified Files: > cPickle.c > Log Message: > - Fix a GC bug caused by PyDict_New() failing. > > > Index: cPickle.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v > retrieving revision 2.52 > retrieving revision 2.53 > diff -C2 -r2.52 -r2.53 > *** cPickle.c 2000/09/07 14:35:37 2.52 > --- cPickle.c 2000/10/04 16:22:26 2.53 > *************** > *** 2876,2880 **** > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! Py_DECREF(inst); > goto err; > } > --- 2876,2881 ---- > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! inst = (PyInstanceObject *) PyObject_AS_GC(inst); > ! PyObject_DEL(inst); > goto err; > } I aways seem to think harder when reviewing a commit message than a diff. :( I just realized that this commit subtly modifies cPickle's behavior. Before the change instances __del__ methods would be called if allocating __dict__ failed. After the change they are not. I think the new behavior is better but the question is will it break existing code? I think probably not. BTW, pickle seems to follow the new behavior. Neil From esr at snark.thyrsus.com Wed Oct 4 19:17:39 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 13:17:39 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010041717.NAA03509@snark.thyrsus.com> In the course of maintaining fetchmail, I've developed effective techniques for integrating RPM and lsm generation into the release machinery of a package. I'm willing to do this for Python; it will involve adding a makefile production and a couple of scripts to the distribution. The benefit would be that we could generate correct RPMs automatically and ship them with each release. I think RPM is a sufficiently important distribution format to justify this effort. Comments? -- Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 From effbot at telia.com Wed Oct 4 19:25:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 19:25:37 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid> eric wrote: > In the course of maintaining fetchmail, I've developed effective > techniques for integrating RPM and lsm generation into the release machinery > of a package. I'm willing to do this for Python; it will involve > adding a makefile production and a couple of scripts to the > distribution. > > The benefit would be that we could generate correct RPMs automatically > and ship them with each release. I think RPM is a sufficiently > important distribution format to justify this effort. Comments? isn't this a distutils thing? see: ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html (lazy programmers just press the "deploy" button, of course ;-) From akuchlin at mems-exchange.org Wed Oct 4 20:02:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 4 Oct 2000 14:02:19 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: >isn't this a distutils thing? see: >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html >(lazy programmers just press the "deploy" button, of course ;-) It's not immediately obvious that the Distutils 1.0, which after all mostly aims to support installing Python modules, can be applied to installing Python itself, what with all the libraries and scripts and such that Python needs. It certainly is something to aim for, and I intend to work on this some more after 2.0, but the attempt might run into missing Distutil features. Whether it's worth adding rules for RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or -0, just 0 -- a Nirvana-like state of utter unconcern.) --amk From gward at mems-exchange.org Wed Oct 4 20:13:01 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:13:01 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us> On 04 October 2000, Fredrik Lundh said: > isn't this a distutils thing? see: > > ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html But the Distutils brag line is: The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. If that first sentence were instead The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python. then you'd have a point. What a difference one little word can make... Greg From gward at mems-exchange.org Wed Oct 4 20:16:20 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 4 Oct 2000 14:16:20 -0400 Subject: [Python-Dev] Adding a section to PEP 0042 Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us> I need to add an entry to PEP 0042 about the lack of cross-compilation support, because that's a bug report that was assigned to me, and needs to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems to me that I should just add a section on "Build/Installation" to the PEP -- anyone disagree? This might also be a good place to gather other gripes about Python's build/installation machinery... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From effbot at telia.com Wed Oct 4 20:53:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 20:53:48 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us> Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid> greg wrote: > If that first sentence were instead > > The Python Distribution Utilities, or Distutils for short, are a > collection of modules that aid in the development, distribution, and > installation of Python. > > then you'd have a point. > > What a difference one little word can make... so why not fix it? cannot be too hard to remove one little word, can it? ;-) From loewis at informatik.hu-berlin.de Wed Oct 4 22:31:23 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> > Someone just pointed out on c.l.py that we need an HTMLescape() > function that takes a string and converts special characters to > entities. I'm not on python-dev, so could you please forward this > and find out whether I need to run a PEP? Doesn't xml.sax.saxutils.escape do what you want (together with htmlentitydefs)? I was going to say that this is quite a small change to warrant a PEP - but there are two obvious approaches (working from scratch, or working on top of xml.sax.saxutils.escape - perhaps modifying and relocating that function), so *some* design probably needs to be recorded in a PEP. Regards, Martin From trentm at ActiveState.com Wed Oct 4 23:17:37 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 4 Oct 2000 14:17:37 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails Message-ID: <20001004141737.A16659@ActiveState.com> I did not follow the discussion a while back regarding the implementation and use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results in this test: test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) in test_sre.py failing on Win64. This is because PyOS_CheckStack seem to *never* fail on Win64. Three possibilites: (1) I don't understand the PyOS_CheckStack code or I am misintepreting the problem. (2) The semantics of _alloca() has changed for Win64 such that a stack overflow exception is no longer thrown if space cannot be allocated. NOTE: I changed the number of pointers allocated in PyOS_CheckStack from 2048 to over 1 *Tera*byte and it *still* did not fail. (3) I am stoopid. In any case, I would like to *not* define USE_STACKCHECK on Win64 for the time being (and for 2.0, unless a Win64 angel comes to me in the next couple of days). Does anybody have a problem with me checking this in? *** Include\pythonrun.h~ Wed Oct 04 14:18:00 2000 --- Include\pythonrun.h Wed Oct 04 13:17:17 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif Thanks, Trent -- Trent Mick TrentM at ActiveState.com From effbot at telia.com Wed Oct 4 23:34:50 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 23:34:50 +0200 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails References: <20001004141737.A16659@ActiveState.com> Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid> trent wrote: > I did not follow the discussion a while back regarding the implementation and > use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK) > instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results > in this test: > test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError) > in test_sre.py failing on Win64. note that the test assumes that 50000 iterations would be enough to hit the stack limit. maybe Win64 has a *huge* stack? what does this little program do: import sre sre.match(r'(x)*', 50000*'x').span() if it prints (0, 50000), all is well, and the *test* should be disabled (or modified) on Win64... From jeremy at beopen.com Wed Oct 4 23:35:26 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com> References: <200010041717.NAA03509@snark.thyrsus.com> Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> In the course of maintaining fetchmail, I've developed ESR> effective techniques for integrating RPM and lsm generation ESR> into the release machinery of a package. I'm willing to do ESR> this for Python; it will involve adding a makefile production ESR> and a couple of scripts to the distribution. ESR> The benefit would be that we could generate correct RPMs ESR> automatically and ship them with each release. I think RPM is ESR> a sufficiently important distribution format to justify this ESR> effort. Comments? We are now distributing RPMs for RH 6 with Python and have plans to support other distributions we have access to, namely those available on the SF compile farm. This page has the RPMs: http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html Can you compare this approach to using a hand-crafted .spec file for the RPMs? It took a little while to figure out how to generate the .spec, but now that it has been created it does not seem hard to maintain. I imagine, without knowing any details of what you propose, that this is primarily beneficial for people who do not know how to build RPMs. Jeremy From effbot at telia.com Wed Oct 4 23:43:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 4 Oct 2000 23:43:41 +0200 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails References: <20001004141737.A16659@ActiveState.com> Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid> trent wrote: > This is because PyOS_CheckStack seem to *never* fail on Win64. Three > possibilites: > (1) I don't understand the PyOS_CheckStack code or I am misintepreting the > problem. > (2) The semantics of _alloca() has changed for Win64 such that a stack > overflow exception is no longer thrown if space cannot be allocated. > NOTE: I changed the number of pointers allocated in PyOS_CheckStack > from 2048 to over 1 *Tera*byte and it *still* did not fail. me again: didn't read the note carefully enough, so I didn't quite figure out what you said... ::: what happens if you run this program (on my win95 box, it counts up to 8, and stops). #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ::: if it goes on and on and on, check the assembler output from this program. (maybe the win64 compiler is smarter than I -- if it realizes that I don't actually use the return value from _alloca, it may of course remove the entire thing...) From esr at thyrsus.com Wed Oct 4 23:56:38 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 17:56:38 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> Message-ID: <20001004175638.A4423@thyrsus.com> Jeremy Hylton : > We are now distributing RPMs for RH 6 with Python and have plans to > support other distributions we have access to, namely those available > on the SF compile farm. > > This page has the RPMs: > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > Can you compare this approach to using a hand-crafted .spec file for > the RPMs? It took a little while to figure out how to generate the > .spec, but now that it has been created it does not seem hard to > maintain. > > I imagine, without knowing any details of what you propose, that this > is primarily beneficial for people who do not know how to build RPMs. Actually, the point of my approach is *not* to hand-craft the spec file. What I normally do is write a specfile generator script in shell, which takes the release version as an argument. Most of the point of the generator script is so the file list part of the specfile never has to be handhacked. So, for example, a specfile generator script for Python would know that for each library file foo.py in the Python X.Y release tree, it needs to generate a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is added to the library it will automatically ripple through to the RPM. Then I embed something like this in the Makefile: # Make RPMs. You need to be root to make this work RPMROOT=/usr/src/redhat RPM = rpm RPMFLAGS = -ba rpm: dist cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES; $(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir) cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir) Hey presto! Instant RPMs. I use this approach for several of my projects. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From nas at arctrix.com Wed Oct 4 18:12:04 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 09:12:04 -0700 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> Message-ID: <20001004091204.A787@glacier.fnational.com> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > Jeremy Hylton : > > Can you compare this approach to using a hand-crafted .spec file for > > the RPMs? It took a little while to figure out how to generate the > > .spec, but now that it has been created it does not seem hard to > > maintain. > Actually, the point of my approach is *not* to hand-craft the spec file. Okay, but we already have the spec file. Why is your approach better? Is your script that generates the the spec easier to maintain then the spec file itself? Is it just as flexible? If so then Red Hat screwed up designing RPM. I can see the utility of such as script but I don't see how it helps in this situation. Neil From esr at thyrsus.com Thu Oct 5 04:23:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 4 Oct 2000 22:23:18 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700 References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com> Message-ID: <20001004222318.E4742@thyrsus.com> Neil Schemenauer : > On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote: > > Jeremy Hylton : > > > Can you compare this approach to using a hand-crafted .spec file for > > > the RPMs? It took a little while to figure out how to generate the > > > .spec, but now that it has been created it does not seem hard to > > > maintain. > > Actually, the point of my approach is *not* to hand-craft the spec file. > > Okay, but we already have the spec file. Why is your approach > better? Is your script that generates the the spec easier to > maintain then the spec file itself? Is it just as flexible? If > so then Red Hat screwed up designing RPM. I can see the utility > of such as script but I don't see how it helps in this situation. The main thing a specfile generator can accomplish is to automate the generation of the file list so that (for example) when we add a new library module the specfile doesn't have to be hand-edited. -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 From nas at arctrix.com Wed Oct 4 23:43:50 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 14:43:50 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> Message-ID: <20001004144350.A434@glacier.fnational.com> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > that's a clue? Rob was kind enough to send me some code to trigger the bug. The winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's program seems to work fine. I think Pmw uses lots of tuples. Looking closely at the code I see that _PyTuple_Resize is almost certainly buggy. I think something is wrong with PyTuple_New as well. I'll have to come up with a patch later as it is much to late now for me to fully understand such hairy code. :( Neil From pf at artcom-gmbh.de Thu Oct 5 07:55:19 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000 3:40:33 pm" Message-ID: Hi, Barry Warsaw : > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669 > > Added Files: > pep-0004.txt > Log Message: > Added PEP 4, Deprecation of Standard Modules, Martin von Loewis > > > ***** Error reading new file: (2, 'No such file or directory') Whenever Barry adds a new file to the CVS, its initial content is invisible on the checkins mailing list due to the error message above. However if for example fdrake adds a new file (for example the support.py recently added to the doc subtree) then this doesn't happen. Is there anybody out there able to fix this for future checkins-mails? Regards, Peter From fdrake at beopen.com Thu Oct 5 08:23:10 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) In-Reply-To: References: <200010042240.PAA14714@slayer.i.sourceforge.net> Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Peter Funk writes: > Whenever Barry adds a new file to the CVS, its initial content > is invisible on the checkins mailing list due to the error message > above. However if for example fdrake adds a new file (for example the > support.py recently added to the doc subtree) then this doesn't happen. > Is there anybody out there able to fix this for future checkins-mails? Wow! I had noticed the bolluxed messages, but hadn't tied it to Barry! But I just checked the added files for this month and spot-checked the ones from last month, and Barry's all exhibit this problem, and no one else's do. I wonder if something is wrong with his SourceForge account? Barry, check your group memberships, please! If nothing obvious is wrong, submit a support request, because this is definately annoying. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Oct 5 09:09:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:20 -0400 Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows In-Reply-To: <20001003161009.B18387@ActiveState.com> Message-ID: [Trent Mick, pointing out that test_popen2 was busted on Windows] > Geez, you are fast Tim! (for others: he patched test_popen.py > after I sent my email but before my email made it to python-dev!) I hate to be honest, but I actually pointed out the test_popen2 failure on Python-Dev last week. However, I was On Vacation(tm) then, so thought merely mentioning it would shame someone else into fixing it. At this point, I'll happily settle for that somebody else eventually *noticed* it! our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs - tim From tim_one at email.msn.com Thu Oct 5 09:09:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 5 Oct 2000 03:09:17 -0400 Subject: [Python-Dev] pep42 procedure? In-Reply-To: Message-ID: [Mark Hammond] > That would be a great idea, if only we had a PEP author. To be honest, > I really dont care too much about this issue, and have been doing my > level best to avoid it. But Tim knows that, and delights in assigning > related patches to me ;-) I certainly don't care enough to own a pep > on it. ... I assign them to you because there's barely a line of Windows startup code you didn't write, and you gave Windows the notion of naming the main DLL differently across (some) different releases thus creating the possibility for the problem these patches are trying to solve . That's not to say it's "your problem", but is to say you've thought more about "stuff like this" than anyone else, and have very particular ideas about how you want "stuff like this" done: you're the best qualified. That said, the subject of the PEP shouldn't be competing hacks to worm around Windows-specific startup problems, it should be an actual design for binary compatibility across iterations of the C API, or at least a reliable way for extensions to *know* they're not getting a version of the Python core they can use. we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs - tim From martin at loewis.home.cs.tu-berlin.de Thu Oct 5 09:44:52 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 5 Oct 2000 09:44:52 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> > The main thing a specfile generator can accomplish is to automate > the generation of the file list so that (for example) when we add a > new library module the specfile doesn't have to be hand-edited. That sounds similar to the rationale for having automatically generated dependency files for make, e.g. by gcc -MM. Many projects use this as a convenience, and it kind-of works. However, I still like it better to have dependencies explicitly recorded in the Makefiles. That requires more discipline, but is easier to understand, and the behaviour is more reproducable. So given the option of using an existing hand-written spec file, and having some magic generate one for me, I'd always use the hand-written one. The magic is only good if there is no hand-written one. Regards, Martin From fredrik at pythonware.com Thu Oct 5 09:50:37 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 09:50:37 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> neil wrote: > On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote: > > Hooft's problem makes heavy use of Tkinter and Pmw, it seems. Maybe > > that's a clue? > > Rob was kind enough to send me some code to trigger the bug. The > winner is ... tupleobject.c! When MAXSAVESIZE is zero Rob's > program seems to work fine. I think Pmw uses lots of tuples. The new version of Tkinter contains a _flatten function written in C, which uses PyTuple_Resize extensively. To check if Rob's program works better without it, you can comment out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or so, iirc). From larsga at garshol.priv.no Thu Oct 5 10:36:33 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 05 Oct 2000 10:36:33 +0200 Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: * Martin von Loewis | | Doesn't xml.sax.saxutils.escape do what you want (together with | htmlentitydefs)? I was going to say that this is quite a small | change to warrant a PEP - but there are two obvious approaches | (working from scratch, or working on top of xml.sax.saxutils.escape | - perhaps modifying and relocating that function), so *some* design | probably needs to be recorded in a PEP. It would probably help, but now that Python has Unicode support there should be some way to convert string data to a legacy encoding and represent all characters not available in that encoding using numeric character references. This would be very useful for both XML and HTML. The difficulty, I assume, lies in figuring out which encodings support what characters. --Lars M. From nas at arctrix.com Thu Oct 5 07:59:38 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Wed, 4 Oct 2000 22:59:38 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> Message-ID: <20001004225938.A802@glacier.fnational.com> On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote: > The new version of Tkinter contains a _flatten function written in C, > which uses PyTuple_Resize extensively. > > To check if Rob's program works better without it, you can comment > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > so, iirc). That fixes the crash as well. Neil From bwarsaw at beopen.com Thu Oct 5 15:33:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1) References: <200010042240.PAA14714@slayer.i.sourceforge.net> <14812.7758.940994.732616@cj42289-a.reston1.va.home.com> Message-ID: <14812.33601.730022.889777@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Wow! I had noticed the bolluxed messages, but hadn't tied Fred> it to Barry! But I just checked the added files for this Fred> month and spot-checked the ones from last month, and Barry's Fred> all exhibit this problem, and no one else's do. I wonder if Fred> something is wrong with his SourceForge account? Barry, Fred> check your group memberships, please! If nothing obvious is Fred> wrong, submit a support request, because this is definately Fred> annoying. I don't understand why this is happening, esp. just for me! My primary group is users and I'm definitely in the python group as well. Why would it be a permission problem anyway, since that's not what the error message is saying? Better log messages in syncmail would help diagnose this, but I haven't got the time right now to hack on that. -Barry From pf at artcom-gmbh.de Thu Oct 5 15:54:58 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST) Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000 9:33:53 am" Message-ID: Hi, Barry A. Warsaw: > > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Wow! I had noticed the bolluxed messages, but hadn't tied > Fred> it to Barry! But I just checked the added files for this > Fred> month and spot-checked the ones from last month, and Barry's > Fred> all exhibit this problem, and no one else's do. I wonder if > Fred> something is wrong with his SourceForge account? Barry, > Fred> check your group memberships, please! If nothing obvious is > Fred> wrong, submit a support request, because this is definately > Fred> annoying. > > I don't understand why this is happening, esp. just for me! My > primary group is users and I'm definitely in the python group as > well. Why would it be a permission problem anyway, since that's not > what the error message is saying? > > Better log messages in syncmail would help diagnose this, but I > haven't got the time right now to hack on that. Just speculating: it has something todo with the current directory where the cvs commit command is executed in or it depends on the difference that the PEPs are under nondist and Freds files were under dist. Possible ugly workaround for Barry: for new files first commit an empty file and then the real file just a moment later. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From jeremy at beopen.com Thu Oct 5 16:42:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT) Subject: [Python-Dev] Release candidate schedule Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net> There are still a number of open bugs that need to be addressed before we can issue a release candidate. We plan to issue the release candidate on Monday and the final release a week later. According to the Sourceforge bug report -- http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1 -- the following people still have open bugs: akuchlin (3) bwarsaw (3) dcjim (2) effbot (5) fdrake (4) gvanrossum (12) gward (1) jackjansen (1) jhylton (8) lemburg (2) mhammond (5) nascheme (3) tim_one (5) I don't expect that every bug will be closed before 2.0 final, but there are some open bugs about test failures and build problems with 2.0 beta releases. We should address these if at all possible. Please review your open bugs and make sure you aren't forgetting about something. If you have bugs that will not be fixed for 2.0, make sure they have a fairly low priority. If you have bugs you will not be able to address, assign them to me. Jeremy From effbot at telia.com Thu Oct 5 16:53:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 16:53:48 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002501c02edc$1302b040$766940d5@hagrid> what's the current release schedule, btw? is the repository frozen, or do we still have a chance to fix the GC tuple problem and SRE's "nothing to repeat" bug? From effbot at telia.com Thu Oct 5 16:51:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 16:51:25 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid> > > To check if Rob's program works better without it, you can comment > > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or > > so, iirc). > > That fixes the crash as well. in other words, _PyTuple_Resize needs some work... (or does _flatten do something wrong? it starts by creating a tuple, and if it needs more space, it doubles the size one or more times, and ends by calling Resize again to set the final size...) ::: btw, the start of Resize looks a bit strange: should that DECREF really be there? should least be an XDECREF, or am I missing something? if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { *pv = 0; Py_DECREF(v); /* really? what if v is NULL? */ PyErr_BadInternalCall(); return -1; } From mal at lemburg.com Thu Oct 5 17:00:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 05 Oct 2000 17:00:12 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> Message-ID: <39DC977C.89D14AB1@lemburg.com> Andrew Kuchling wrote: > > On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote: > >isn't this a distutils thing? see: > >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html > >(lazy programmers just press the "deploy" button, of course ;-) > > It's not immediately obvious that the Distutils 1.0, which after all > mostly aims to support installing Python modules, can be applied to > installing Python itself, what with all the libraries and scripts and > such that Python needs. It certainly is something to aim for, and I > intend to work on this some more after 2.0, but the attempt might run > into missing Distutil features. Whether it's worth adding rules for > RPM in the meantime is up to the Pythoneers; I'm 0 on it. (Not +0 or > -0, just 0 -- a Nirvana-like state of utter unconcern.) distutils is not useful for installing Python (it needs Python to start with), but it does a pretty good job at finding the needed files and can generate RPMs which can be used without distutils or Python. It even allows adding handcrafted sections to the resulting RPM. If anybody plans to help in this direction, I'd suggest to add those efforts to the build_rpm command in distutils (and the build_deb command for that matter). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Thu Oct 5 17:24:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 5 Oct 2000 11:24:32 -0400 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200 References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com> Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us> On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote: >distutils is not useful for installing Python (it needs Python >to start with), ... Note that the Distutils doesn't need many C-based modules: _sre, posix, and string are about it. So those modules could be automatically compiled into the Python binary (perhaps being moved from Modules/ into Python/ to signify their new importance) and the resulting binary should have enough marbles to run a setup.py script that would build everything else in Modules/. The downside is that you could no longer compile those 3 modules as dynamically loadable, but the upside is that the setup.py could be smarter about detecting which libraries are available on the system, and compiling everything which can be. This would, one hopes, make Setup file hacking a thing of the past... --amk From tismer at appliedbiometrics.com Thu Oct 5 16:33:54 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Thu, 05 Oct 2000 17:33:54 +0300 Subject: [Python-Dev] Stackless Python Mailing List Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com> Hi Pythoneers (without or not without Stack (yet:)) there have been a couple of interviews, and some articles on Stackless Python are published or in preparation. I recognize an increasing number of individual emails concerning Stackless Python. This lets me take the opportunity to start a mailing list on Stackless Python, an overdue task. The goal of this list is two-fold: On the one hand, people should have a forum to discuss their use of SLP, its further development, concurrency in general, and more. The other reason is to increase the support for SLP, with the final goal to get it merged into Standard Python. There are a couple of ways to help me with that, see http://starShip.python.net/mailman/listinfo/stackless Everybody who is interested in Stackless Python and all the related topics may feel invited to join this discussion group. cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : 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 From nas at arctrix.com Thu Oct 5 10:40:28 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 5 Oct 2000 01:40:28 -0700 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200 References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> Message-ID: <20001005014028.A1055@glacier.fnational.com> On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote: > in other words, _PyTuple_Resize needs some work... Yup. I've attached a patch which I believe fixes some GC bugs in addition to making it simpler. > btw, the start of Resize looks a bit strange: should that > DECREF really be there? should least be an XDECREF, or > am I missing something? > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > *pv = 0; > Py_DECREF(v); /* really? what if v is NULL? */ > PyErr_BadInternalCall(); > return -1; > } I think your right. Here's a fun little program: from _tkinter import _flatten import random # don't ask me why for x in xrange(10000): print x t = _flatten([(0,)*x]*x) It gives: 0 1 2 3 4 5 Segmentation fault on the two Linux machines I've tested it on. It also crashes with GC disabled. Neil *** Objects/tupleobject.c Thu Oct 5 11:31:30 2000 --- tupleobject.c Thu Oct 5 10:47:44 2000 *************** *** 500,531 **** } else #endif { ! #ifdef WITH_CYCLE_GC ! PyGC_Head *g = PyObject_AS_GC((PyObject *)v); ! PyObject_GC_Fini((PyObject *)v); ! g = (PyGC_Head *) ! PyObject_REALLOC((char *)g, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! if (g == NULL) { ! sv = NULL; ! } else { ! sv = (PyTupleObject *)PyObject_FROM_GC(g); ! } ! #else sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); ! #endif ! *pv = (PyObject *) sv; if (sv == NULL) { ! PyObject_GC_Init((PyObject *)v); ! v = (PyTupleObject *) PyObject_AS_GC(v); PyObject_DEL(v); PyErr_NoMemory(); return -1; } } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) --- 500,519 ---- } else #endif { ! PyObject_GC_Fini(v); ! v = (PyObject *) PyObject_AS_GC(v); sv = (PyTupleObject *) ! PyObject_REALLOC((char *)v, sizeof(PyTupleObject) ! + PyGC_HEAD_SIZE ! + newsize * sizeof(PyObject *)); if (sv == NULL) { ! *pv = NULL; PyObject_DEL(v); PyErr_NoMemory(); return -1; } + sv = (PyTupleObject *) PyObject_FROM_GC(sv); + *pv = (PyObject *) sv; } _Py_NewReference((PyObject *)sv); for (i = sv->ob_size; i < newsize; i++) From guido at python.org Thu Oct 5 20:22:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:22:49 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400." <14810.51466.486982.938180@anthem.concentric.net> References: <14810.51466.486982.938180@anthem.concentric.net> Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> [Aahz] > Someone just pointed out on c.l.py that we need an HTMLescape() function > that takes a string and converts special characters to entities. I'm > not on python-dev, so could you please forward this and find out whether > I need to run a PEP? Has someone pointed out yet that this is done by cgi.escape()? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:24:20 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:24:20 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53 In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST." <20001004024636.A13475@glacier.fnational.com> References: <200010041622.JAA17363@slayer.i.sourceforge.net> <20001004024636.A13475@glacier.fnational.com> Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com> > I aways seem to think harder when reviewing a commit message than > a diff. :( I just realized that this commit subtly modifies > cPickle's behavior. Before the change instances __del__ methods > would be called if allocating __dict__ failed. After the change > they are not. I think the new behavior is better but the > question is will it break existing code? I think probably not. This is goodness. Don't worry about breaking code -- it probably *fixes* code. Most __del__ methods don't know what to do when the instance variables haven't been defined yet! > BTW, pickle seems to follow the new behavior. Even better. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:29:27 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:29:27 -0500 Subject: [Python-Dev] Adding a section to PEP 0042 In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400." <20001004141620.A31293@ludwig.cnri.reston.va.us> References: <20001004141620.A31293@ludwig.cnri.reston.va.us> Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com> > I need to add an entry to PEP 0042 about the lack of cross-compilation > support, because that's a bug report that was assigned to me, and needs > to be marked "Closed/Feature Request/Later" and put in PEP 0042. Seems > to me that I should just add a section on "Build/Installation" to the > PEP -- anyone disagree? This might also be a good place to gather > other gripes about Python's build/installation machinery... +1 (I think the "Library" section is growing too big and may be split in "Lib" and "Modules" sections.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:33:47 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:33:47 -0500 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200." <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Whatever the outcome of this discussion, this is too late for 2.0. But I tend to side with Jeremy and Martin -- "explicit is better". I do want Jeremy to check his RPM generation scripts in, so they can be improved in a truly open source project. (Maybe in Tools/rpm?) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 5 20:43:30 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 13:43:30 -0500 Subject: [Python-Dev] Release candidate followed by feature freeze? In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200." <002501c02edc$1302b040$766940d5@hagrid> References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002501c02edc$1302b040$766940d5@hagrid> Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com> > what's the current release schedule, btw? Let me give that a shot... - Feature Freeze Now. I.e. it's too late for anything even vaguely resembling a feature -- even if it's been discussed to death. - Bugfix Checkin Freeze Saturday (Oct 7) Starting Saturday, all checkins must be coordinated with the releasemeister (still Jeremy). - Release Candidate Monday (Oct 9) - Final Release Monday week (Oct 16) Between the Release Candidate and the Final Release, all checkins must fix bugs and must be approved by the releasemeister. > is the repository frozen, or do we still have a chance to fix > the GC tuple problem and SRE's "nothing to repeat" bug? Simple bugfixes are okay till Saturday. Bugfixes that are complex and may break other stuff should be discussed with the releasemeister, possibly cc'ing python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Thu Oct 5 20:05:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 5 Oct 2000 20:05:54 +0200 Subject: [Python-Dev] Release candidate followed by feature freeze? References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com> Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid> neil wrote: > Yup. I've attached a patch which I believe fixes some GC bugs in > addition to making it simpler. don't have the slightest idea how the GC stuff works, but it sure looks right: just go ahead and check it in... > > btw, the start of Resize looks a bit strange: should that > > DECREF really be there? should least be an XDECREF, or > > am I missing something? > > > > if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { > > *pv = 0; > > Py_DECREF(v); /* <- really? what if v is NULL? */ > > PyErr_BadInternalCall(); > > return -1; > > } > > I think your right. Here's a fun little program: > > from _tkinter import _flatten > import random # don't ask me why > for x in xrange(10000): > print x > t = _flatten([(0,)*x]*x) > > It gives: > > 0 > 1 > 2 > 3 > 4 > 5 > Segmentation fault guido? From jim at digicool.com Thu Oct 5 20:10:42 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 05 Oct 2000 14:10:42 -0400 Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR) References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com> Message-ID: <39DCC422.90E4D0D5@digicool.com> Sam Rushing wrote: > > Jim Fulton writes: > > The asyncore main loop should check for this error in it's select > > call and the select module should make this error easier to check > > for. > > It might go better into the event_loop function, which I think of as a > more user-serviceable part. [for example, the default loop vs. the > one in medusa/event_loop.py that supports schedulable events] Don't you think anyone using select on Unix would want this? This isn't really an application-specific thing is it? > > I presume that this works in Python 1.6/2.0, but I > > haven't tried it yet? > > > > This depends on the structure of select.error values > > and requires that we get EINTR from somewhere. (What > > should the value be on NT?) > > If it's a big problem, I guess we could use a different default > event_loop() function for win32 vs. unix. Or we could put this in the poll function and reraise the error on NT, as my change does. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From aahz at panix.com Thu Oct 5 21:52:47 2000 From: aahz at panix.com (aahz at panix.com) Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM Message-ID: <200010051952.PAA05883@panix6.panix.com> > [Aahz] >> Someone just pointed out on c.l.py that we need an HTMLescape() function >> that takes a string and converts special characters to entities. I'm >> not on python-dev, so could you please forward this and find out whether >> I need to run a PEP? > > Has someone pointed out yet that this is done by cgi.escape()? Yeah, I missed that earlier. But after thinking some more, there are a fair number of browser-like bits of software that fail to render many of the special characters correctly (e.g. trademark). This is frequently due to character set issues; entities almost always render correctly, though. Therefore a general translation routine is probably handy. cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape ought to be expanded to handle all characters or a new routine should be added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I have zero familiarity with XML and am waiting for 2.0final. Perhaps this should be taken off-line? -- --- Aahz (Copyright 2000 by aahz at pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 There's a difference between a person who gets shit zie doesn't deserve and a person who gets more shit than zie deserves. --Aahz From skip at mojam.com Thu Oct 5 21:54:56 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net> References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <14812.56464.380651.537610@beluga.mojam.com> Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty Barry> string always returns true. This closes SF bug #115392. There was a big thread recently on the tramp mailing list (similar to efs for remote file editing in Emacs, but uses ssh/scp instead) about trying to find a portable way to test for the existence of a file. After trying all sorts of stuff, the final result was pretty ugly, as I recall. -- Skip Montanaro (skip at mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From guido at python.org Thu Oct 5 23:07:29 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 05 Oct 2000 16:07:29 -0500 Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST." <200010051952.PAA05883@panix6.panix.com> References: <200010051952.PAA05883@panix6.panix.com> Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com> > Yeah, I missed that earlier. But after thinking some more, there are a > fair number of browser-like bits of software that fail to render many of > the special characters correctly (e.g. trademark). This is frequently > due to character set issues; entities almost always render correctly, > though. Therefore a general translation routine is probably handy. But character set issues also make it impossible to provide such a translation routine: the current party line is that the encoding of 8-bit strings is unknown and that only ASCII can be assumed. > cgi.escape() only handles "&", "<", ">". I'm not sure whether cgi.escape > ought to be expanded to handle all characters or a new routine should be > added. Martin van Loewis suggested xml.sax.saxutils.escape(), but I > have zero familiarity with XML and am waiting for 2.0final. Perhaps > this should be taken off-line? xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read the source (Lib/xml/sax/saxutils.py). It allows you to specify additional things to be replaced by entities by passing in a dictionary mapping chars (or strings) to entities. If you know that you are dealing with Latin-1, you could use the table in htmlentitydefs.py to construct a table. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Thu Oct 5 22:13:34 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT) Subject: [Python-Dev] forwarded message from aahz@panix.com In-Reply-To: <200010051952.PAA05883@panix6.panix.com> References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> <200010051952.PAA05883@panix6.panix.com> Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net> >>>>> "AM" == aahz writes: >> [Aahz] >>> Someone just pointed out on c.l.py that we need an HTMLescape() >>> function that takes a string and converts special characters to >>> entities. I'm not on python-dev, so could you please forward >>> this and find out whether I need to run a PEP? >> >> Has someone pointed out yet that this is done by cgi.escape()? AM> Yeah, I missed that earlier. But after thinking some more, AM> there are a fair number of browser-like bits of software that AM> fail to render many of the special characters correctly AM> (e.g. trademark). This is frequently due to character set AM> issues; entities almost always render correctly, though. AM> Therefore a general translation routine is probably handy. AM> cgi.escape() only handles "&", "<", ">". I'm not sure whether AM> cgi.escape ought to be expanded to handle all characters or a AM> new routine should be added. Martin van Loewis suggested AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML AM> and am waiting for 2.0final. Perhaps this should be taken AM> off-line? Perhaps we should take it to python-list -- or maybe we should form a web-sig and work on it there. There are definitely some tricky issues to work out. I attempted to work out some of the same issues for internationalization support in Mailman's pipermail archives. The escape function in cgi should stay minimal, because it deals with the only truly essential characters. If the browser interprets an HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are going to be rendered properly. You can add an explicit meta tag to the HTML page and the server will return the charset in the headers. This seems quite a bit simpler than trying to escape all characters > chr(127), except if you have to deal with old browsers that don't support the charset specified by the HTTP header. Jeremy From thomas at xs4all.net Thu Oct 5 23:40:22 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 5 Oct 2000 23:40:22 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167 In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700 References: <200010051845.LAA16072@slayer.i.sourceforge.net> Message-ID: <20001005234022.I12812@xs4all.nl> On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007 > Modified Files: > configure configure.in > Log Message: > Change all occurances of > > test -d "$directory" > to > test ! -z "directory" -a -d "directory" > Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string > always returns true. This closes SF bug #115392. > --- 3103,3110 ---- > USE_THREAD_MODULE="#" > else > ! if test ! -z $with_threads -a -d $with_threads > then LDFLAGS="$LDFLAGS -L$with_threads" > fi > ! if test ! -z $withval -a -d $withval > then LDFLAGS="$LDFLAGS -L$withval" > fi Is this really going to work ? I always see 'portable' shell code do something like if [ "X${spam}" != "X" ] ... instead of 'test -z', eventhough even BSDI test has -z. (The portable code I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is minimal, compared to modern day equivalents.) My /bin/sh-knowledge is decidedly less impressive than my Python knowledge, but I thought something like if test ! -z $withval -a -d $withval where $withval is empty, would be parsed as if test ! -z -a -d which would be, uhm, wrong ? But like I said, I don't really know what I'm talking about here, there could be another perfectly valid reason for BSDI to use the roundabout way, instead of using -z. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Fri Oct 6 00:12:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> Whatever the outcome of this discussion, this is too late for GvR> 2.0. But I tend to side with Jeremy and Martin -- "explicit is GvR> better". I do want Jeremy to check his RPM generation scripts GvR> in, so they can be improved in a truly open source project. GvR> (Maybe in Tools/rpm?) I don't actually use a script to generate the RPM. I wrote a .spec file by hand and use it to generate the RPMs using the rpm command. I could check in the spec file, which I would end up changing every time we do a release -- to update the version number, change the Setup.in patch, etc. I should probably also include the patch file along with the .spec file. I also wrote a smal distutils setup script for 2.0b2, which I should check in somewhere. Not sure where... BTW, I've attached the spec file below. You can get it from the .src.rpm on pythonlabs.com, but that's pretty inconvenient if you're merely curious. Jeremy %define name BeOpen-Python %define version 2.0b2 %define release 1 %define __prefix /usr/local Summary: An interpreted, interactive, object-oriented programming language. Name: %{name} Version: %{version} Release: %{release} Copyright: Modified CNRI Open Source License Group: Development/Languages Source: %{name}-%{version}.tar.bz2 Source1: html-%{version}.tar.bz2 Patch0: %{name}-%{version}-Setup.patch BuildRoot: /var/tmp/%{name}-%{version}-root Prefix: %{__prefix} URL: http://www.pythonlabs.com/ Vendor: BeOpen PythonLabs Packager: Jeremy Hylton %description Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes. Python combines remarkable power with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C or C++. It is also usable as an extension language for applications that need a programmable interface. Finally, Python is portable: it runs on many brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the Mac. %changelog * Thu Oct 5 2000 Jeremy Hylton - added bin/python2.0 to files list (suggested by Martin v. L?wis) * Tue Sep 26 2000 Jeremy Hylton - updated for release 1 of 2.0b2 - use .bz2 version of Python source * Tue Sep 12 2000 Jeremy Hylton - Version 2 of 2.0b1 - Make the package relocatable. Thanks to Suchandra Thapa. - Exclude Tkinter from main RPM. If it is in a separate RPM, it is easier to track Tk releases. %prep %setup -n Python-%{version} %patch0 %setup -D -T -a 1 -n Python-%{version} # This command drops the HTML files in the top-level build directory. # That's not perfect, but it will do for now. %build ./configure make %install [ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{__prefix} make prefix=$RPM_BUILD_ROOT%{__prefix} install %clean rm -fr $RPM_BUILD_ROOT %files %defattr(-, root, root) %{__prefix}/bin/python %{__prefix}/bin/python2.0 %{__prefix}/man/man1/python.1 %doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Porting %doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS %doc index.html modindex.html api dist doc ext inst lib mac ref tut icons %dir %{__prefix}/include/python2.0 %{__prefix}/include/python2.0/*.h %dir %{__prefix}/lib/python2.0/ %{__prefix}/lib/python2.0/*.py* %{__prefix}/lib/python2.0/pdb.doc %{__prefix}/lib/python2.0/profile.doc %dir %{__prefix}/lib/python2.0/config %{__prefix}/lib/python2.0/config/Makefile %{__prefix}/lib/python2.0/config/Makefile.pre.in %{__prefix}/lib/python2.0/config/Setup %{__prefix}/lib/python2.0/config/Setup.config %{__prefix}/lib/python2.0/config/Setup.local %{__prefix}/lib/python2.0/config/config.c %{__prefix}/lib/python2.0/config/config.c.in %{__prefix}/lib/python2.0/config/install-sh %{__prefix}/lib/python2.0/config/libpython2.0.a %{__prefix}/lib/python2.0/config/makesetup %{__prefix}/lib/python2.0/config/python.o %dir %{__prefix}/lib/python2.0/curses %{__prefix}/lib/python2.0/curses/*.py* %dir %{__prefix}/lib/python2.0/distutils %{__prefix}/lib/python2.0/distutils/*.py* %{__prefix}/lib/python2.0/distutils/README %dir %{__prefix}/lib/python2.0/distutils/command %{__prefix}/lib/python2.0/distutils/command/*.py* %{__prefix}/lib/python2.0/distutils/command/command_template %dir %{__prefix}/lib/python2.0/encodings %{__prefix}/lib/python2.0/encodings/*.py* %dir %{__prefix}/lib/python2.0/lib-dynload %dir %{__prefix}/lib/python2.0/lib-tk %{__prefix}/lib/python2.0/lib-tk/*.py* %{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so %{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so %{__prefix}/lib/python2.0/lib-dynload/_localemodule.so %{__prefix}/lib/python2.0/lib-dynload/arraymodule.so %{__prefix}/lib/python2.0/lib-dynload/binascii.so %{__prefix}/lib/python2.0/lib-dynload/cPickle.so %{__prefix}/lib/python2.0/lib-dynload/cStringIO.so %{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so %{__prefix}/lib/python2.0/lib-dynload/errnomodule.so %{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so %{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so %{__prefix}/lib/python2.0/lib-dynload/grpmodule.so %{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so %{__prefix}/lib/python2.0/lib-dynload/mathmodule.so %{__prefix}/lib/python2.0/lib-dynload/md5module.so %{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so %{__prefix}/lib/python2.0/lib-dynload/newmodule.so %{__prefix}/lib/python2.0/lib-dynload/operator.so %{__prefix}/lib/python2.0/lib-dynload/parsermodule.so %{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so %{__prefix}/lib/python2.0/lib-dynload/pyexpat.so %{__prefix}/lib/python2.0/lib-dynload/readline.so %{__prefix}/lib/python2.0/lib-dynload/resource.so %{__prefix}/lib/python2.0/lib-dynload/rotormodule.so %{__prefix}/lib/python2.0/lib-dynload/selectmodule.so %{__prefix}/lib/python2.0/lib-dynload/shamodule.so %{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so %{__prefix}/lib/python2.0/lib-dynload/stropmodule.so %{__prefix}/lib/python2.0/lib-dynload/structmodule.so %{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so %{__prefix}/lib/python2.0/lib-dynload/termios.so %{__prefix}/lib/python2.0/lib-dynload/timemodule.so %{__prefix}/lib/python2.0/lib-dynload/ucnhash.so %{__prefix}/lib/python2.0/lib-dynload/unicodedata.so %{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so %dir %{__prefix}/lib/python2.0/lib-old %{__prefix}/lib/python2.0/lib-old/*.py* %dir %{__prefix}/lib/python2.0/plat-linux2 %{__prefix}/lib/python2.0/plat-linux2/*.py* %{__prefix}/lib/python2.0/plat-linux2/regen %dir %{__prefix}/lib/python2.0/site-packages %{__prefix}/lib/python2.0/site-packages/README %dir %{__prefix}/lib/python2.0/test %{__prefix}/lib/python2.0/test/*.py* %{__prefix}/lib/python2.0/test/README %{__prefix}/lib/python2.0/test/audiotest.au %{__prefix}/lib/python2.0/test/greyrgb.uue %{__prefix}/lib/python2.0/test/test.xml %{__prefix}/lib/python2.0/test/testimg.uue %{__prefix}/lib/python2.0/test/testimgr.uue %{__prefix}/lib/python2.0/test/testrgb.uue %dir %{__prefix}/lib/python2.0/test/output %{__prefix}/lib/python2.0/test/output/test_* %dir %{__prefix}/lib/python2.0/xml %{__prefix}/lib/python2.0/xml/*.py* %dir %{__prefix}/lib/python2.0/xml/dom %{__prefix}/lib/python2.0/xml/dom/*.py* %dir %{__prefix}/lib/python2.0/xml/sax %{__prefix}/lib/python2.0/xml/sax/*.py* From fdrake at beopen.com Fri Oct 6 02:14:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> I just got this message from the gcc-announce list. We've seen bug reports related to GCC 2.96 (which may or may not be the problem). We need to be aware that these releases are out there and can be a problem. I've noticed that the version of GCC shipped with Mandrake 7.1 is "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much confidence either. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: Gerald Pfeifer Subject: GCC 2.96 Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST) Size: 3308 URL: From thomas at xs4all.net Fri Oct 6 02:29:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 6 Oct 2000 02:29:11 +0200 Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400 References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> Message-ID: <20001006022910.J12812@xs4all.nl> On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote: > I just got this message from the gcc-announce list. We've seen bug > reports related to GCC 2.96 (which may or may not be the problem). We > need to be aware that these releases are out there and can be a > problem. > I've noticed that the version of GCC shipped with Mandrake 7.1 is > "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much > confidence either. ;( The 'unstable' branch of Debian currently ships with: gcc version 2.95.2 20000220 (Debian GNU/Linux) and it seems to be working fine. I did notice a problem, but it was related to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have caught that one, but I found it on my machine before he checked in that fix ;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h include file: /* Number of bits in a word of type ong int'. */ #if LONG_MAX == 2147483647 # define LONG_BIT 32 #else /* Safe assumption. */ # define LONG_BIT 64 #endif where LONG_MAX was not defined (yet). I fixed it 'manually' for more than just Python by adding #ifndef LONG_MAX #define LONG_MAX 2147483647 #endif above it. I had to laugh, though, when I saw that assuming longs had 64 bits is considered 'a safe assumption'. I guess most people use 64 bit machines nowadays ? :-) I'm not complaining about this, though. Woody (Debian's current unstable tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm also wondering where to send my bugreport, but I think I'll read some documentation before I do that, first ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Fri Oct 6 03:37:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT) Subject: [Python-Dev] forwarded message from Gerald Pfeifer In-Reply-To: <20001006022910.J12812@xs4all.nl> References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com> <20001006022910.J12812@xs4all.nl> Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > The 'unstable' branch of Debian currently ships with: > gcc version 2.95.2 20000220 (Debian GNU/Linux) > > and it seems to be working fine. I did notice a problem, but it was related I understand this to be the latest "stable" version of GCC, and it appearantly it has been accepted as such for a while now. > above it. I had to laugh, though, when I saw that assuming longs had 64 bits > is considered 'a safe assumption'. I guess most people use 64 bit machines > nowadays ? :-) Hey, my machine is 4294967296 bits! Forget those ancient 64 bit machines! ;-) > I'm not complaining about this, though. Woody (Debian's current unstable > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm I'm less concerned about people who know they're deliberatly putting themselves on the bleeding edge than the people that pick up the latest version of some Linux distribution and find they have a buggy compiler because the distribution builders weren't as careful as perhaps they should have been. Putting together a professional grade Linux distro is still a very hard thing. There's no such thing as enough testing here! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From MarkH at ActiveState.com Fri Oct 6 05:52:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Fri, 6 Oct 2000 14:52:13 +1100 Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c In-Reply-To: Message-ID: [Me, responding to Jeremy's request I look for potential buffer exploits on Windows...] > I will be happy to look into this. And was :-) If anyone has time over the next day or 2, any holes I either missed, or added(!) in http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547 0 would be appreciated! Thanks, Mark. From thomas.heller at ion-tof.com Fri Oct 6 09:20:56 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Fri, 6 Oct 2000 09:20:56 +0200 Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> > I don't actually use a script to generate the RPM. I wrote a .spec > file by hand and use it to generate the RPMs using the rpm command. > I could check in the spec file, which I would end up changing every > time we do a release -- to update the version number, change the > Setup.in patch, etc. I should probably also include the patch file > along with the .spec file. > > I also wrote a smal distutils setup script for 2.0b2, which I should > check in somewhere. Not sure where... > Could you post this script? Thomas From loewis at informatik.hu-berlin.de Thu Oct 5 21:49:26 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST) Subject: [Python-Dev] PEP 4: Deprecation of standard modules Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de> I just finished a first draft of a PEP on deprecating (and eventually removing) modules from the standard Python library; it is available from http://python.sourceforge.net/peps/pep-0004.html If you have comments or suggestions on the proposed procedures, or the wording of the text, please send me a message. According to the PEP procedures (PEP 1), this is the preferred way of progressing this PEP (rather than discussing it on these lists), at least initially. Regards, Martin From loewis at informatik.hu-berlin.de Fri Oct 6 14:39:05 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de> > The difficulty, I assume, lies in figuring out which encodings > support what characters. It's not that difficult to write a set of new codecs; with the module below, I can do >>> import xmlenc >>> u'\u0416'.encode('latin-1-xml') 'Ж' >>> unicode('XɅY','latin-1-xml') u'X\u0245Y' The difficulty is that the algorithm is not very efficient if there are many unsupported characters in a string. Regards, Martin # Module implementing a set of new encodings of the form -xml # Copyright Martin v. Löwis # It currently supports hex character references only import codecs class CodecWrapper: def __init__(self,encoder,decoder): self.encoder = encoder self.decoder = decoder def encode(self,input,errors='strict'): try: return self.encoder(input,"strict") except ValueError: l = len(input) if l==1: return "&#x%x;" % ord(input), 1 s1,l1 = self.encode(input[:l/2]) s2,l2 = self.encode(input[l/2:]) return s1+s2,l1+l2 def decode(self,input,errors='strict'): input = str(input) # might be buffer object pos = input.find("&#x") if pos == -1: return self.decoder(input,errors) r1,l1 = self.decode(input[:pos],errors) end = input.find(";",pos) try: if end==-1: raise ValueError # goto failure code below val = int(input[pos+3:end],16) r2,l2 = self.decode(input[end+1:],errors) return r1+unichr(val)+r2,l1+end-pos+l2 except ValueError: # how to deal with errors in decode? r2,l2 = self.decode(input[pos+2:],errors) return r1+"&#x"+r2,l1+3+l2 def mkreader(self): r = codecs.StreamReader() r.decode = self.decode r.encode = self.encode return r def mkwriter(self): r = codecs.StreamWriter() r.decode = self.decode r.encode = self.encode return r def search_function(encoding): if not encoding.endswith("-xml"): return None enc,dec,reader,writer = codecs.lookup(encoding[:-4]) c = CodecWrapper(enc,dec) return c.encode,c.decode,c.mkreader,c.mkwriter codecs.register(search_function) From jeremy at beopen.com Fri Oct 6 16:54:03 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT) Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook> References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> <200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net> <003d01c02f65$fb409550$4500a8c0@thomasnotebook> Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net> Here is the setup script I used to build the Tk RPMs. The name and version part is a mess and I would welcome suggestions on how to fix it. The problem is that Tkinter gets built against a particular version of Python and a particular version of Tcl/Tk. I want the name of the RPM to indiciate both versions, but didn't seem an obvious way to accomplish it. Thus, I put the Python version number in the name and the Tcl/Tk version number in the version. Otherwise, I think this is pretty straightforward distutils stuff (although the documentation was out of date last I checked). I've attached three files. I wrote setup.py and setup.cfg. Distutils created MANIFEST. Jeremy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MANIFEST URL: From jeremy at beopen.com Fri Oct 6 21:11:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net> I just fixed a number of major bugs in the undocumented linuxaudiodev module. I ended up spending about an hour reading the excellent Open Sound System (OSS) Programmer's Guide to figure out what the module was trying to do and why it wasn't working on my Linux box. After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python. I propose we develop a Python module for Python 2.1 and call it osslib. There is nothing at all that is Linux-specific about the interface being used. The OSS guide mentions a plethora of platforms that it supports. In the interim, I have fixed some of the most egregious problems. I would appreciate it if Linux users could try out the fixes and the new test case. On my machine it still sounds awful, but at least the sound can be heard. Jeremy From akuchlin at mems-exchange.org Fri Oct 6 21:17:39 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 6 Oct 2000 15:17:39 -0400 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400 References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >After reading the module and the OSS guide, it is clear to me that we >need a complete re-write. The module itself is just a wrapper around >a bunch of read, write, and ioctl calls. It could all be implemented >in pure Python. So, is there any point in releasing linuxaudiodev at all, then, if it needs a complete rewrite? --amk From DavidA at ActiveState.com Fri Oct 6 21:39:21 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: > I propose we develop a Python module for Python 2.1 and call it > osslib. There is nothing at all that is Linux-specific about the > interface being used. The OSS guide mentions a plethora of platforms > that it supports. Have you evaluated http://net.indra.com/~tim/ossmodule/ ? From jeremy at beopen.com Fri Oct 6 21:47:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <20001006151739.A31189@kronos.cnri.reston.va.us> Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote: >> After reading the module and the OSS guide, it is clear to me >> that we need a complete re-write. The module itself is just a >> wrapper around a bunch of read, write, and ioctl calls. It could >> all be implemented in pure Python. AMK> So, is there any point in releasing linuxaudiodev at all, then, AMK> if it needs a complete rewrite? I would be include to chuck it, except that it also shipped with 1.6. I would hestitate to deprecate it so far into the release process. jeremy From jeremy at beopen.com Fri Oct 6 21:47:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net> I had no idea it existed. Jeremy From jeremy at beopen.com Fri Oct 6 21:54:35 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net> >>>>> "DA" == David Ascher writes: DA> Have you evaluated http://net.indra.com/~tim/ossmodule/ Okay. I took a quick look. It's really old (July 1997). It looks like a more reasonable wrapping than linuxaudiodev, although I would want to review it more carefully against the OSS programmer's guide. I would prefer a pure Python solution, because the code would be shorter and easier to read and maintain. It may be, however, that the ossmodule is still up-to-date; if so, it may be easier to use it than to rewrite it. Jeremy From ping at lfw.org Fri Oct 6 23:13:39 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > After reading the module and the OSS guide, it is clear to me that we > need a complete re-write. The module itself is just a wrapper around > a bunch of read, write, and ioctl calls. It could all be implemented > in pure Python. True. I think your osslib is a good idea. I wanted to take on this sort of project myself a few weeks ago but never had the time to really get started. From playing with the test script, i think all we care about having in C is audioop (and that's just for ulaw conversion). I would like to fix audioop so we can expect it to be present as a standard module; then we can have a module written in Python that provides uniform sound support for all platforms. > On my machine it still sounds awful, but at least the > sound can be heard. It should not sound awful. If it sounds too loud and scratchy, then maybe you need to use audioop to convert from Sun .au (ulaw) to raw samples first. This was the case with the Spanish inquisition clip. -- ?!ng From jeremy at beopen.com Sat Oct 7 00:28:57 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: References: <14814.9199.422989.273484@bitdiddle.concentric.net> Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: >> On my machine it still sounds awful, but at least the sound can >> be heard. KPY> It should not sound awful. If it sounds too loud and scratchy, KPY> then maybe you need to use audioop to convert from Sun .au KPY> (ulaw) to raw samples first. This was the case with the KPY> Spanish inquisition clip. I don't think I know how to do that. I tried using sox to convert audiotest.au to audiotest.raw and it sounded just as bad on my machine. Perhaps I have my machine configured incorrectly, although CDs and Real Audio sound fine. Have you tried the new code, BTW? Does the test work on your machine? Jeremy From tim_one at email.msn.com Sat Oct 7 00:28:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 6 Oct 2000 18:28:53 -0400 Subject: [Python-Dev] test_StringIO broken Message-ID: test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' 1 test failed: test_StringIO This on Win98SE, broke sometime late this afternoon (EDT). Working elsewhere? From jeremy at beopen.com Sat Oct 7 00:59:41 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: References: Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net> The test was changed in a number of ways, but whoever checked it in didn't actually run the regression test! Also, the last messsage I see printed is: Failed to catch ValueError writing to closed StringIO. This ain't a case of forgetting to generate new output. This is just plain wrong. Jeremy From thomas at xs4all.net Sat Oct 7 00:56:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:56:08 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: ; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400 References: Message-ID: <20001007005608.K12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote: > test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg' > 1 test failed: test_StringIO > This on Win98SE, broke sometime late this afternoon (EDT). Working > elsewhere? No. Fails the same way on my Linux box. And the problem is probably that the test was updated (two tests were uncommented) but the output file wasn't updated. Jim Fulton did the checkin, so he looks like the right person to fix it (and manually check that the generated output file is *correct*, of course ! ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Sat Oct 7 01:01:37 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net> Message-ID: > Okay. I took a quick look. It's really old (July 1997). It looks > like a more reasonable wrapping than linuxaudiodev, although I would > want to review it more carefully against the OSS programmer's guide. > > I would prefer a pure Python solution, because the code would be > shorter and easier to read and maintain. It may be, however, that the > ossmodule is still up-to-date; if so, it may be easier to use it than > to rewrite it. Absolutely. I just remember some announcement about it. I suspect that what I remember is not that old, so it may make sense to do a little more digging than I did in the archives... --david From thomas at xs4all.net Sat Oct 7 00:58:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 7 Oct 2000 00:58:19 +0200 Subject: [Python-Dev] test_StringIO broken In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400 References: <14814.22877.882280.651958@bitdiddle.concentric.net> Message-ID: <20001007005819.L12812@xs4all.nl> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: > Also, the last messsage I see printed is: > Failed to catch ValueError writing to closed StringIO. > This ain't a case of forgetting to generate new output. This is just > plain wrong. Hm, are you sure you re-built your modules before doing that ? The output looks okay on my linux box, in any case. The last message is 'Caught expected ValueError writing to closed StringIO: I/O operation on closed file', for me. If you recompiled cStringIO, something odd is going on ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sat Oct 7 01:06:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT) Subject: [Python-Dev] test_StringIO broken In-Reply-To: <20001007005819.L12812@xs4all.nl> References: <14814.22877.882280.651958@bitdiddle.concentric.net> <20001007005819.L12812@xs4all.nl> Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote: >> Also, the last messsage I see printed is: Failed to catch >> ValueError writing to closed StringIO. >> This ain't a case of forgetting to generate new output. This is >> just plain wrong. TW> Hm, are you sure you re-built your modules before doing that ? This is probably what went wrong for me. Jeremy From guido at python.org Sat Oct 7 15:51:12 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 08:51:12 -0500 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST." <200010062309.QAA32052@slayer.i.sourceforge.net> References: <200010062309.QAA32052@slayer.i.sourceforge.net> Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> > Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE). The > parsing functions in support of auto-indent weren't expecting Unicode > strings, but text.get() can now return them (although it remains muddy as > to exactly when or why that can happen). Fixed that with a Big Hammer. I apologize, I should have explained when text.get() returns Unicode: Any string returned from Tcl/Tk that contains a byte with the 8th bit set is translated from UTF-8 into Unicode, unless the translation fails (in which case the original raw 8-bit string is returned as a fallback). This *should* be correct because Tcl/Tk always uses UTF-8 internally. (Even though it is "lenient" when receiving strings -- if a sequence of characters has no valid Unicode representation, it appears to falls back to Latin-1; I don't know the details of this algorithm.) --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Sat Oct 7 20:43:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 7 Oct 2000 14:43:55 -0400 Subject: [Python-Dev] Tcl and Unicode In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com> Message-ID: >> Fix for next iteration of SF bug 115690 (Unicode headaches in >> IDLE). ... [Guido] > I apologize, I should have explained when text.get() returns Unicode: > > Any string returned from Tcl/Tk that contains a byte with the 8th bit > set is translated from UTF-8 into Unicode, unless the translation > fails (in which case the original raw 8-bit string is returned as a > fallback). Except that's *why* it was muddy : in the specific case that popped up in the bug, text.get() appeared to return a Unicode string of length 1 containing only a newline. No high-bit byte appeared to be involved. However, that was an illusion I didn't unmask until later. All is clear now. > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > (Even though it is "lenient" when receiving strings -- if a sequence > of characters has no valid Unicode representation, it appears to falls > back to Latin-1; I don't know the details of this algorithm.) Dunno, but wouldn't be surprised if they had a notion of default encoding, and that it simply appears to be Latin-1 to us because American Windows uses a superset of Latin-1. If BeOpen would like to buy me a version of Chinese Windows, happy to lend it to you . as-american-as-they-come-ly y'rs - tim From guido at python.org Sun Oct 8 03:41:11 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 07 Oct 2000 20:41:11 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400." <14814.21033.195290.728159@bitdiddle.concentric.net> References: <14814.9199.422989.273484@bitdiddle.concentric.net> <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com> I think I fixed the linuxaudio test -- see if it sounds reasonable now! The crux of the matter seemed to be that the last, optional argument to setparameters(), meaning "emulate the format if the sound card doesn't support it", is not supported right. It suppresses the error message, and the ioctl to set the format succeeds, but the emulation doesn't work (at least not on my system, or on Jeremy's). So I've used a subterfuge: assuming most sound cards support signed 16-bit native-endian format, I convert the data to that format, and use the appropriate format code: AFMT_S16_LE for little-endian machines, AFMT_S16_BE for big-endian machines. I've only tested little-endian. I use the new sys.byteorder variable to determine the endianness. I use the audioop module to do the conversion. Much simpler than sox! (Oh feeling of nostalgia... I wrote several of the file format handlers for sox, and fixed lots of bugs in it too... I even started the audio file formats FAQ, now maintained by Chris Bagwell, who also took over sox...) Downside: test_linuxaudiodev will now be skipped if you don't have the audioop enabled in your Setup file. But that's fixed easily. By the way -- the checkin freeze for the release candidate should go in just about now... --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Sun Oct 8 12:32:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 06:32:36 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: Blast from the past! [/F] > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) [Tim] > How about instead enhancing existing (?Ppattern) notation, to > set a new match object attribute to name if & when pattern matches? > Then arbitrary info associated with a named pattern can be gotten at > via dicts via the pattern name, & the whole mess should be more > readable. [/F Sent: Sunday, July 02, 2000 6:35 PM] > I just added "lastindex" and "lastgroup" attributes to the match object. > > "lastindex" is the integer index of the last matched capturing group, > "lastgroup" the corresponding name (or None, if the group didn't have > a name). both attributes are None if no group were matched. Reviewing this before 2.0 has been on my todo list for 3+ months, and finally got to it. Good show! I converted some of my by-hand scanners to use lastgroup, and like it a whole lot. I know you understand why this is Good, so here's a simple example of an "after" tokenizer for those who don't (this one happens to tokenize REXX-like PARSE stmts): import re _token = re.compile(r""" (?P \s+) | (?P [a-zA-Z_]\w*) | (?P \.) | (?P \d+) | (?P [-+=()]) | (?P " [^"\\\n]* (?: \\. [^"\\\n]*)* " | ' [^'\\\n]* (?: \\. [^'\\\n]*)* ' ) """, re.VERBOSE).match del re (T_SPACE, T_VAR, T_DONTCARE, T_NUMBER, T_PUNC, T_STRING, T_EOF, ) = range(7) # For debug output. _enum2name = ["T_SPACE", "T_VAR", "T_DONTCARE", "T_NUMBER", "T_PUNC", "T_STRING", "T_EOF", ] _group2action = { "space": (T_SPACE, None), "var": (T_VAR, None), "dontcare": (T_DONTCARE, None), "number": (T_NUMBER, int), "punc": (T_PUNC, None), "string": (T_STRING, eval), } def tokenize(s, tokeneater): i, n = 0, len(s) while i < n: m = _token(s, i) if not m: raise ParseError(s, i) group = m.lastgroup enum, action = _group2action[group] val = m.group(group) if action is not None: val = action(val) tokeneater(enum, val) i = m.end() tokeneater(T_EOF, None) The tokenize function here used to be a mass of if/elif stmts trying to figure out which group had matched. Now it's all table-driven: easier to write, reuse & maintain, and quicker to boot. +1. the-aged-may-be-slow-but-they-never-forget-ly y'rs - tim From effbot at telia.com Sun Oct 8 13:04:50 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 8 Oct 2000 13:04:50 +0200 Subject: [Python-Dev] Tcl and Unicode References: Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid> guido: > > This *should* be correct because Tcl/Tk always uses UTF-8 internally. > > (Even though it is "lenient" when receiving strings -- if a sequence > > of characters has no valid Unicode representation, it appears to falls > > back to Latin-1; I don't know the details of this algorithm.) Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but their 8-bit strings use UTF-8. When converting from external 8-bit strings to unicode, they convert valid UTF-8 sequences to unicode characters just like Python, but "a lead-byte not followed by enough trail-bytes represents itself." (in other words, it's cast from an unsigned char to an unsigned short). And the chance that any reasonable Latin-1 string would contain a UTF-8 lead bytes followed by the right number of UTF-8 trail bytes is close to zero... (in case anyone wonders, Python's codec thinks that "close to zero" isn't good enough, so it raises an exception instead) tim: > Dunno, but wouldn't be surprised if they had a notion of default encoding, > and that it simply appears to be Latin-1 to us because American Windows uses > a superset of Latin-1. They have a system encoding, but it's not used here -- it's just that Latin-1 is a subset of Unicode... From thomas at xs4all.net Sun Oct 8 13:14:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 8 Oct 2000 13:14:33 +0200 Subject: [Python-Dev] Release candidate Message-ID: <20001008131433.M12812@xs4all.nl> Is there any chance we can get the 'release candidate' released on the SF File Module thingy as well ? Mailman uses this for the betas, for instance, and I think it would attract that bit more attention to it. I believe the 'release' gets listed on various SF pages that way. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry at scottb.demon.co.uk Sun Oct 8 16:36:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 8 Oct 2000 15:36:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000401c03135$2ebd4ec0$060210ac@private> Tim, Two requests: 1. Can you ship the .PDB files for the debug images so devo's do not need to build the python sources to debug extensions. And Yes I know the .ZIP will be huge. If you want a compromise only include the .PDB for python20_d.dll. 2. Place the files into libs, pyd etc dirs. I had to extract the groups into the right places which is a bit tedious and error prone. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Tim Peters > Sent: 27 September 2000 23:40 > To: PythonDev; Python list > Subject: [Python-Dev] Python 2.0b2 note for Windows developers > > > Since most Python users on Windows don't have any use for them, I trimmed > the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe > and .dll files. If you want them, they're available in a separate zip > archive; read the Windows Users notes at > > http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html > > for info and a download link. If you don't already know *why* you might > want them, trust me: you don't want them . > > they-don't-even-make-good-paperweights-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From ping at lfw.org Sun Oct 8 20:19:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT) Subject: [Python-Dev] linuxaudiodev module In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net> Message-ID: On Fri, 6 Oct 2000, Jeremy Hylton wrote: > > Have you tried the new code, BTW? Does the test work on your machine? Works okay (i updated after Guido's last edit). Sounds fine to me. But it bugs me that some of the descriptions say "audio" and others say "format". This seems arbitrary -- is there a reason? Excerpt of Modules/linuxaudiodev.c: { 8, ??????AFMT_MU_LAW, "Logarithmic mu-law audio" }, { 8, ??????AFMT_A_LAW, "Logarithmic A-law audio" }, { 8,???????AFMT_U8, "Standard unsigned 8-bit audio" }, { 8, ??????AFMT_S8, "Standard signed 8-bit audio" }, { 16, ??????AFMT_U16_BE, "Big-endian 16-bit unsigned format" }, { 16, ??????AFMT_U16_LE, "Little-endian 16-bit unsigned format" }, { 16, ??????AFMT_S16_BE, "Big-endian 16-bit signed format" }, { 16, ??????AFMT_S16_LE, "Little-endian 16-bit signed format" }, If you don't mind, i'd prefer something like: { 8, ??????AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" }, { 8, ??????AFMT_A_LAW, "logarithmic A-law 8-bit audio" }, { 8,???????AFMT_U8, "linear unsigned 8-bit audio" }, { 8, ??????AFMT_S8, "linear signed 8-bit audio" }, { 16, ??????AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" }, { 16, ??????AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" }, { 16, ??????AFMT_S16_BE, "linear signed 16-bit big-endian audio" }, { 16, ??????AFMT_S16_LE, "linear signed 16-bit little-endian audio" }, The above conforms to: "audio" where ::= "logarithmic" ("mu-law" | "A-law") | "linear" ("unsigned" | "signed") ::= "8-bit" | "16-bit" ("big-endian" | "little-endian") -- ?!ng "Simple, yet complex." -- Lenore Snell From tim_one at email.msn.com Sun Oct 8 21:28:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 8 Oct 2000 15:28:55 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private> Message-ID: [Barry] > Two requests: > > 1. Can you ship the .PDB files for the debug images so devo's > do not need to build the python sources to debug extensions. > And Yes I know the .ZIP will be huge. If you want a > compromise only include the .PDB for python20_d.dll. Sure! Most .pdb files are highly compressible, and the zip size hit isn't anything to worry about. > 2. Place the files into libs, pyd etc dirs. I had to extract > the groups into the right places which is a bit tedious > and error prone. No. If you want a directory structure that doesn't match the actual build directory structure, I can't read your mind, and have no reason to believe that the specific artificial structure you have in mind is of use to anyone but you. Don't be so helpless : write a tiny Python script to move the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python themselves and just want to avoid jumping thru all the snaky hoops needed to compile the 3rd-party subprojects (from _tkinter to zlib). alphabetically y'rs - tim From guido at python.org Sun Oct 8 22:52:54 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 08 Oct 2000 15:52:54 -0500 Subject: [Python-Dev] linuxaudiodev module In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST." References: Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com> > But it bugs me that some of the descriptions say "audio" and others say > "format". This seems arbitrary -- is there a reason? Okay, you're right. (But there are sooooo many other things wrong with the code still... E.g. the bogus reference to "ctl". :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Mon Oct 9 08:04:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 08 Oct 2000 23:04:55 -0700 Subject: [Python-Dev] A standard lexer? References: Message-ID: <39E16007.5F1DDF9A@prescod.net> Tim Peters wrote: > > ... > > Reviewing this before 2.0 has been on my todo list for 3+ months, and > finally got to it. Good show! I converted some of my by-hand scanners to > use lastgroup, and like it a whole lot. I know you understand why this is > Good, so here's a simple example of an "after" tokenizer for those who don't > (this one happens to tokenize REXX-like PARSE stmts): Is there a standard technique for taking a regexp like this and applying it to data fed in a little at a time? Other than buffering the data forever? That's something else I would like in a "standard Python lexer", if that's the goal. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido at beopen.com Thu Oct 5 15:16:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 5 Oct 2000 09:16:14 -0400 Subject: [Python-Dev] htmllib.HTMLescape() References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com> Note that cgi.escape() does this too. --Guido ----- Original Message ----- From: "Martin von Loewis" To: Cc: Sent: Wednesday, October 04, 2000 4:31 PM Subject: [Python-Dev] htmllib.HTMLescape() > > Someone just pointed out on c.l.py that we need an HTMLescape() > > function that takes a string and converts special characters to > > entities. I'm not on python-dev, so could you please forward this > > and find out whether I need to run a PEP? > > Doesn't xml.sax.saxutils.escape do what you want (together with > htmlentitydefs)? I was going to say that this is quite a small change > to warrant a PEP - but there are two obvious approaches (working from > scratch, or working on top of xml.sax.saxutils.escape - perhaps > modifying and relocating that function), so *some* design probably > needs to be recorded in a PEP. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From loewis at informatik.hu-berlin.de Mon Oct 9 16:01:10 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST) Subject: [Python-Dev] htmllib.HTMLescape() In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com> (guido@beopen.com) References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com> Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de> > Note that cgi.escape() does this too. Indeed. That justifies a PEP that proposes to concentrate the functionality in one place, deprecating the other places. One approach would be to enhance the codec facilites, so that "string".encode("iso-entities") becomes possible - but that is already in the middle of discussing the PEP. Regards, Martin From jeremy at beopen.com Mon Oct 9 16:35:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36 In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net> References: <200010091418.HAA08765@slayer.i.sourceforge.net> Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net> Thanks. I didn't get to it on Friday. Jeremy From trentm at ActiveState.com Tue Oct 10 00:56:00 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 9 Oct 2000 15:56:00 -0700 Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200 References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid> Message-ID: <20001009155600.A27929@ActiveState.com> [Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py fail on the overflow checks] [Fredrik gives me a simple test C program to test PyOS_CHeckStack independently (The test program is included at the bottom of this email.)] SOrry I took so long to reply to this but I spent a little bit of time playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated. Here is what I found: - The simple test program shows that PyOS_CheckStack will fire as intended on both Win32 and Win64 with either Visual C's default optimization OR no optimization. - The simple test program will *not* fire as intended with the '-O2' optimization which Python *does* use for pythonrun.c (where PyOS_CheckStack lives). So, likely the '-O2' optimization will optimize-away the _alloca() call. Fine. But why then does it *not* get optimized away when pythonrun.c is compiled? Does the context around other code in the same file affect that optimization? - When I apply this patch to _sre.c on *Win32* (basically the same test as the test file that Fredrik gave me to try) the "callme(0)" call *never* returns -- infinite loop. Note that this happens on the Release *and* Debug builds so nothing is being optimized away. *************** *** 560,565 **** --- 560,569 ---- } #endif + + + void callme(int i); + LOCAL(int) SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level) { *************** *** 578,583 **** --- 582,588 ---- TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level)); #if defined(USE_STACKCHECK) + callme(0); if (level % 10 == 0 && PyOS_CheckStack()) return SRE_ERROR_RECURSION_LIMIT; #endif *************** *** 2337,2340 **** --- 2342,2357 ---- Py_InitModule("_" MODULE, _functions); } + void callme(int i) + { + char buf[100000]; + if (PyOS_CheckStack()) + return; + printf("%d\n", i); + memset(buf, 0, sizeof buf); + callme(i+1); + } + + + #endif /* !defined(SRE_RECURSIVE) */ - I am not smart enough and/or (you decide :) do not have the inclination to figure this out (i.e. start looking at assembly code) just so _sre can use stack checking instead of the existing RECURSION_LIMIT framework (albeit the limited general usefullness of this) on Win64 so that test_sre.py can pass. Would it be alright for me to apply: *** python/dist/src/Include/pythonrun.h Sat Sep 16 09:31:31 2000 --- python/dist/src/Include/pythonrun.h Sun Oct 8 10:20:02 2000 *************** *** 88,94 **** to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif --- 88,94 ---- to a 8k margin. */ #define PYOS_STACK_MARGIN 2048 ! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER) /* Enable stack checking under Microsoft C */ #define USE_STACKCHECK #endif to disable stack checking on Win64 until Win64 become more mainstream and others can bang away at this? The important thing, I would think, is getting the test suite passing for Python 2.0. ------- test file mentioned above -------------------------------- #include #include int __inline PyOS_CheckStack() { __try { _alloca(100000); return 0; } __except (EXCEPTION_EXECUTE_HANDLER) { /* just ignore all errors */ } return 1; } void callme(int i) { char buf[100000]; if (PyOS_CheckStack()) return; printf("%d\n", i); memset(buf, 0, sizeof buf); callme(i+1); } int main() { callme(0); } ----------------------------------------------------- -- Trent Mick TrentM at ActiveState.com From jeremy at beopen.com Tue Oct 10 02:26:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT) Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net> I have placed pre-release copies of the 2.0 release candidate 1 source tarballs at ftp://python.beopen.com/pub/python/2.0c1/. We reserve the right two change these without notice prior to the official release :-). Jeremy From nas at arctrix.com Mon Oct 9 21:06:08 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Mon, 9 Oct 2000 12:06:08 -0700 Subject: [Python-Dev] test_import failing Message-ID: <20001009120608.A13588@glacier.fnational.com> I assume the CVS sources are basicly the same as 2.0c1. Anyhow, test_import is failing on my Debian machine. The script is creating "@test.py" and then trying to import it. "." is not in sys.path for some reason. Neil From jeremy at beopen.com Tue Oct 10 04:17:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net> I assume that you are running the test some way other than using "make test." It seems that make test executes python this way -- PYTHONPATH= ./python -- which causes the current directory to be added to the path. If you run python without having the current directory on your path test_import file fail. Unless you are having a different problem, this isn't important enough to fix in 2.0c1, although it seems good to fix for 2.0 final. Jeremy PS We have left GC turned on by default in 2.0c1 and plan to do the same for 2.0 final. From fdrake at beopen.com Tue Oct 10 04:09:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT) Subject: [Python-Dev] test_import failing In-Reply-To: <20001009120608.A13588@glacier.fnational.com> References: <20001009120608.A13588@glacier.fnational.com> Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > test_import is failing on my Debian machine. The script is > creating "@test.py" and then trying to import it. "." is not in > sys.path for some reason. Jeremy & I finally figured this out. "make test" runs python with PYTHONPATH set to '' (an empty string). This is decidedly different from running with PYTHONPATH unset (I consider this a bug that should be fixed in 2.1). The empty string is interpreted as the current directory (as expected), so running "make test" adds the current directory to sys.path, but running the regression test (test_import or regrtest) as a script does not. We decided not to fix this now, since it's too late to be sure it's the right change, and adjusting the test case also means a very late change. So whoever runs the tests is responsible for making sure the current directory is on sys.path. (*Really* bogus!) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Oct 10 04:20:11 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT) Subject: [Python-Dev] Re: test_import failing In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Unless you are having a different problem, this isn't important enough > to fix in 2.0c1, although it seems good to fix for 2.0 final. And it's questionable how many bugs are hiding here as well. I count two: - test_import.py assumes the current directory is on the path; this is just plain fragile, and should explicitly pick the directory off of test_support.TESTFN, and add it to sys.path for the duration of the test (which does indeed fix this bug) - Modules/getpath.c interprets an empty definition of $PYTHONPATH as adding '' to sys.path, where I assert it should not add anything to sys.path. Everywhere else I've recall seeing an environment variable used as a data source, the test is done like this: char *cp = getenv("VARIABLE"); if (cp != NULL && cp[0] != '\0') { ... } (with some spelling variations). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Tue Oct 10 08:52:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT) Subject: [Python-Dev] Python 2.0 release candidate 1 Message-ID: <200010100652.XAA74600@python.beopen.com> Python 2.0c1 is released. The BeOpen PythonLabs and our cast of SourceForge volunteers have fixed many bugs since the beta releases last month. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There's a tarball, a Windows installer, RedHat RPMs, online documentation, and a long list of fixed bugs. The final release of Python 2.0 will be next week. We would appreciate feedback on the release candidate in order to fix any remaining bugs before the final release. Confirmation of build and test success on less common platforms is also helpful.n All major reported bugs have been fixed in the release candidate. We do not plan to make any changes between now and the final release, except to fix bugs reported in the next week. We encourage potential users of Python 2.0 to try the release candidate with their programs and report any remaining bugs. To report a new bug, use the SourceForge bug tracker http://sourceforge.net/bugs/?func=addbug&group_id=5470 Python 2.0 has many new features, including the following: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0, please see the article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: http://starship.python.net/crew/amk/python/writing/new-python/ -- Jeremy Hylton From tismer at appliedbiometrics.com Tue Oct 10 12:33:36 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Tue, 10 Oct 2000 13:33:36 +0300 Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9 Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com> ANNOUNCING: Stackless Python 1.2 A Python Implementation That Does Not Use The C Stack * plus the real toy * Continuation Module 0.9 Continuations as First Class Objects with support for MicroThreads What is it? A plugin-replacement for core Python. It should run any program which runs under Python 1.5.2 . But it does not need space on the C stack. For further info, see the new site at http://www.stackless.com You might also want to join the mailing list at http://starship.python.net/mailman/listinfo/stackless Major changes in this release: Extra reference counting reduces continuation frame creation Better exception handling avoids cycles. Next to come: - A port to Python 2.0 will be the first thing to do. - Long-term project is a complete redesign and rewrite for inclusion with Python 2.1 ciao - Christian Tismer / Mission Impossible 5oftware Team

    Stackless Python 1.2 + Continuations 0.9 - a version of Python 1.5.2 that does not need space on the C stack, first-class callable continuation objects for Python, and Microthread-support. (10-Oct-2000)

    -- http://www.python.org/mailman/listinfo/python-list From guido at python.org Tue Oct 10 15:04:39 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:04:39 -0500 Subject: [Python-Dev] test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400." <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com> > Neil Schemenauer writes: > > I assume the CVS sources are basicly the same as 2.0c1. Anyhow, > > test_import is failing on my Debian machine. The script is > > creating "@test.py" and then trying to import it. "." is not in > > sys.path for some reason. > > Jeremy & I finally figured this out. "make test" runs python with > PYTHONPATH set to '' (an empty string). This is decidedly different > from running with PYTHONPATH unset (I consider this a bug that should > be fixed in 2.1). > The empty string is interpreted as the current directory (as > expected), so running "make test" adds the current directory to > sys.path, but running the regression test (test_import or regrtest) as > a script does not. > We decided not to fix this now, since it's too late to be sure it's > the right change, and adjusting the test case also means a very late > change. So whoever runs the tests is responsible for making sure the > current directory is on sys.path. (*Really* bogus!) Proper fix, which I will check in momentarily: put import sys sys.path.insert(0, os.curdir) in front of test_import.py; and add del sys.path[0] to the end. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 10 15:06:54 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 08:06:54 -0500 Subject: [Python-Dev] Re: test_import failing In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400." <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net> <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com> > And it's questionable how many bugs are hiding here as well. I > count two: > > - test_import.py assumes the current directory is on the path; this > is just plain fragile, and should explicitly pick the directory > off of test_support.TESTFN, and add it to sys.path for the > duration of the test (which does indeed fix this bug) I'll fix this. > - Modules/getpath.c interprets an empty definition of $PYTHONPATH as > adding '' to sys.path, where I assert it should not add anything > to sys.path. Everywhere else I've recall seeing an environment > variable used as a data source, the test is done like this: > > char *cp = getenv("VARIABLE"); > if (cp != NULL && cp[0] != '\0') { > ... > } > > (with some spelling variations). Agreed, but please *don't fix this in 2.0!* Who knows how many other hidden bugs (in 3rd party code) this will trigger... OK to fix it after 2.0final is released. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Oct 10 14:58:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 14:58:09 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 Message-ID: <39E31261.166F1601@lemburg.com> I've just had a glance at the releas candidate 1. The file LICENSE has grown somewhat, but not as much as I feared... looking at the contents I find the following as only reference to the CNRI license (which holds all the surprises we talked about in the early beta stages): """ CNRI OPEN SOURCE LICENSE AGREEMENT ---------------------------------- Python 1.6 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6 may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1012. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1012. """ Such a note is nice and short, but not legally binding and confusing since it is not clear whether the "handle" for the document will always return the same license text or if it will return a license text at all. It would be more appropriate to include the original CNRI license text, IMHO. Or is there some hidden motivation behind using the handle ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller at ion-tof.com Tue Oct 10 15:06:05 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:06:05 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> There has been some confusion about distutils, especially the bdist_wininst command. I hope I can clarify these things with this post. 1. The current Distutils version 1.0, which is also included in the Python 2.0 release candidate is perfectly usable apart from one bug: You should create windows installers (by running 'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst') ONLY with an external zip utility (info-zip would do). Using the zipfile module results in corrupted installations (all files are created with zero length). Details about the cause for this can be found in the patch I posted to SF. 2. I submitted a patch to SF http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 which corrects this bug. Normally I would have checked this code in immediately, because it is in _my_ code, and that's what my checkin rights are for ;-). I did not because I did not want to interfere with the release process of python 2.0 rc 1. 3. How does bdist_wininst work? bdist_wininst creates a self-extracting zipfile from two components: a stub program (wininst.exe) plus a zip-file containing the code to be distributed. Because I did not liked wininst.exe as binary file checked in into CVS, the actual bytes of this exe are included base64-encoded in the bdist_wininst.py module as string. I'm not sure whether this is a wise design or not, but that is a different topic. The downside of this design is that when the source to wininst.exe changes, it must be recompiled, and bdist_wininst.py must be regenerated. The context-diffs for bdist_wininst.py are so very large. 4. To understand the patch, you should know the following: Distutils is a separate toplevel module in the repository on sourceforge. Parts of this repository are symbolically linked somewhere into the python tree. Thus, this patch must be applied to the distutils _module_ in the repository. Distutils directory structure is as follows: distutils dd distutils command doc dist inst examples sample1 sample2 sample3 misc test text Relevant part of python directory structure: python dist src Lib distutils command The source code for wininst.exe is in CVS in the distutils/misc directory. The patch I posted to SF does not include the compiled wininst.exe, neither does it include the (regenerated) bdist_wininst.py module. 5. If nobody objects, I will check in the changes I made tomorrow, recompile the exe, regenerate the bdist_wininst.py, and everything should be fine again. Greg will then hopefully, when he is back, increase the distutils version number to 1.0.1 (or whatever) and this version will then be delivered with python 2.0 final. Sorry for the confusion. Cheers, Thomas From guido at python.org Tue Oct 10 16:36:57 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:36:57 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200." <39E31261.166F1601@lemburg.com> References: <39E31261.166F1601@lemburg.com> Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com> > I've just had a glance at the releas candidate 1. The file LICENSE > has grown somewhat, but not as much as I feared... Since when? It hasn't changed since it was first released, for 2.0b1. > looking > at the contents I find the following as only reference to the > CNRI license (which holds all the surprises we talked about in > the early beta stages): > > """ > CNRI OPEN SOURCE LICENSE AGREEMENT > ---------------------------------- > > Python 1.6 is made available subject to the terms and conditions in > CNRI's License Agreement. This Agreement together with Python 1.6 may > be located on the Internet using the following unique, persistent > identifier (known as a handle): 1895.22/1012. This Agreement may also > be obtained from a proxy server on the Internet using the following > URL: http://hdl.handle.net/1895.22/1012. > """ > > Such a note is nice and short, but not legally binding and > confusing since it is not clear whether the "handle" for the > document will always return the same license text or if it > will return a license text at all. Why do you say it's not legally binding? The CNRI license explicitly allows you to use this exact text instead of including the whole CNRI license. > It would be more appropriate to include the original CNRI license > text, IMHO. Or is there some hidden motivation behind using the > handle ? I was just trying to save space. ActivePython does the same thing as far as I remember. BTW, I haven't heard from CNRI in two weeks, but the last thing I heard from them was that their lawyers had talked to Stallman's lawyer and that they were optimistic about a successful resolution. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 10 16:41:50 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 09:41:50 -0500 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200." <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Thomas, thanks for the explanation. I agree that you can check in the changes yourself as you proposed. There's one issue I still don't understand (not having the time to read the full distutils docs): how does a typical Windows developer decide whether to use an external zip utility or the zipfile module? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller at ion-tof.com Tue Oct 10 15:58:32 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 10 Oct 2000 15:58:32 +0200 Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> <200010101441.JAA13276@cj20424-a.reston1.va.home.com> Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook> > Thomas, thanks for the explanation. I agree that you can check in the > changes yourself as you proposed. > > There's one issue I still don't understand (not having the time to > read the full distutils docs): how does a typical Windows developer > decide whether to use an external zip utility or the zipfile module? I'm afraid it is not documented. Distutils first tries to spawn an external zip program, then tries the zipfile module, if nothing is found, a warning is issued. So, the windows developer currently _must_ install zip.exe somewhere in the path. (As often, the default is wrong, because a zip utility is not included in windows). Thomas From mal at lemburg.com Tue Oct 10 16:03:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 16:03:14 +0200 Subject: [Python-Dev] LICENSE file in Python 2.0c1 References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> Message-ID: <39E321A2.2BD99E35@lemburg.com> Guido van Rossum wrote: > > > I've just had a glance at the releas candidate 1. The file LICENSE > > has grown somewhat, but not as much as I feared... > > Since when? It hasn't changed since it was first released, for 2.0b1. Since the old 1.5.2 LICENSE file. > > looking > > at the contents I find the following as only reference to the > > CNRI license (which holds all the surprises we talked about in > > the early beta stages): > > > > """ > > CNRI OPEN SOURCE LICENSE AGREEMENT > > ---------------------------------- > > > > Python 1.6 is made available subject to the terms and conditions in > > CNRI's License Agreement. This Agreement together with Python 1.6 may > > be located on the Internet using the following unique, persistent > > identifier (known as a handle): 1895.22/1012. This Agreement may also > > be obtained from a proxy server on the Internet using the following > > URL: http://hdl.handle.net/1895.22/1012. > > """ > > > > Such a note is nice and short, but not legally binding and > > confusing since it is not clear whether the "handle" for the > > document will always return the same license text or if it > > will return a license text at all. > > Why do you say it's not legally binding? The CNRI license explicitly > allows you to use this exact text instead of including the whole CNRI > license. Sure, but not including the verbatim text will produce an unpleasent feeling of not being sure about the completeness of the license text. In a law suit the above construct would certainly not hold, since URLs only describe the location of information and don't hold any information about the validity or origin of it. The situation would be a little better if CNRI had provided a PGP signature or fingerprint of the license, since this is (in some countries) a legally accepted way of determining those two criteria. Just a side note: the URL given for the license results in a redirect to a different URL - http://www.handle.net/python_licenses/python1.6_9-5-00.html (note the date !): this doesn't really give the impression of persistent unchangeable information. Not that there's much to fear about... but why add any extra areas of uncertainty ? > > It would be more appropriate to include the original CNRI license > > text, IMHO. Or is there some hidden motivation behind using the > > handle ? > > I was just trying to save space. ActivePython does the same thing as > far as I remember. Space?... the download is 3.9 Megs ;-) > BTW, I haven't heard from CNRI in two weeks, but the last thing I > heard from them was that their lawyers had talked to Stallman's lawyer > and that they were optimistic about a successful resolution. Great ! This would be really good news indeed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From just at letterror.com Tue Oct 10 17:47:00 2000 From: just at letterror.com (Just van Rossum) Date: Tue, 10 Oct 2000 16:47:00 +0100 Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9 In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com> Message-ID: In response to the new release of Stackless Python (see http://www.stackless.com/), here's a new stackless binary for MacPython 1.5.2: http://starship.python.net/~just/MacStacklessPython.sit.hqx (The archive contains a replacement for the PythonCore shared library) Just From guido at python.org Tue Oct 10 17:50:07 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 10:50:07 -0500 Subject: [Python-Dev] LICENSE file in Python 2.0c1 In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200." <39E321A2.2BD99E35@lemburg.com> References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com> <39E321A2.2BD99E35@lemburg.com> Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com> > > > Such a note is nice and short, but not legally binding and > > > confusing since it is not clear whether the "handle" for the > > > document will always return the same license text or if it > > > will return a license text at all. > > > > Why do you say it's not legally binding? The CNRI license explicitly > > allows you to use this exact text instead of including the whole CNRI > > license. > > Sure, but not including the verbatim text will produce an > unpleasent feeling of not being sure about the completeness > of the license text. > > > > In a law suit the above construct would > certainly not hold, since URLs only describe the location of > information and don't hold any information about the validity > or origin of it. The situation would be a little better if CNRI > had provided a PGP signature or fingerprint of the license, > since this is (in some countries) a legally accepted way of > determining those two criteria. > > Just a side note: the URL given for the license results in a > redirect to a different URL - > http://www.handle.net/python_licenses/python1.6_9-5-00.html > (note the date !): this doesn't really give the impression of > persistent unchangeable information. > > Funny... I agree that's not very confidence-inspiring. CNRI always advertises handles as better than URLs for long-term persistent documents, but it's clear that they didn't think of this! Or maybe (warning: fake conspiracy theory ahead :-) they intend to change the license terms after the fact... > Not that there's much to fear about... but why add any extra areas > of uncertainty ? Agreed. I'll add the full text back in. > > I was just trying to save space. ActivePython does the same thing as > > far as I remember. > > Space?... the download is 3.9 Megs ;-) I meant less text for the reader to wade through. But you've convinced me already. --Guido van Rossum (home page: http://www.python.org/~guido/) From bjorn at roguewave.com Tue Oct 10 20:35:15 2000 From: bjorn at roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 12:35:15 -0600 Subject: [Python-Dev] Re: Python 2.0 release candidate 1 References: <200010100652.XAA74600@python.beopen.com> Message-ID: <39E36163.33291FAB@roguewave.com> Are there any instructions on how to build this for Win64/itanium anywhere? -- bjorn Jeremy Hylton wrote: > > Python 2.0c1 is released. The BeOpen PythonLabs and our cast of > SourceForge volunteers have fixed many bugs since the beta releases > last month. Please pick up the new release at > > http://www.pythonlabs.com/products/python2.0/ > > There's a tarball, a Windows installer, RedHat RPMs, online > documentation, and a long list of fixed bugs. > > The final release of Python 2.0 will be next week. We would > appreciate feedback on the release candidate in order to fix any > remaining bugs before the final release. Confirmation of build and > test success on less common platforms is also helpful.n > > All major reported bugs have been fixed in the release candidate. We > do not plan to make any changes between now and the final release, > except to fix bugs reported in the next week. We encourage potential > users of Python 2.0 to try the release candidate with their programs > and report any remaining bugs. > > To report a new bug, use the SourceForge bug tracker > http://sourceforge.net/bugs/?func=addbug&group_id=5470 > > Python 2.0 has many new features, including the following: > > - Augmented assignment, e.g. x += 1 > - List comprehensions, e.g. [x**2 for x in range(10)] > - Extended import statement, e.g. import Module as Name > - Extended print statement, e.g. print >> file, "Hello" > - Collection of cyclical garbage > > For a fuller discussion of the changes in Python 2.0, please see the > article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke: > http://starship.python.net/crew/amk/python/writing/new-python/ > > -- Jeremy Hylton > > -- > http://www.python.org/mailman/listinfo/python-list From trentm at ActiveState.com Tue Oct 10 21:51:55 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 12:51:55 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> Message-ID: <20001010125155.B3221@ActiveState.com> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > Are there any instructions on how to build this for Win64/itanium > anywhere? > Um... not really. I did/am doing the Win64 port but I have not really given the information required to build it, which, I agree, kind of sucks. I have not done so because: - the Python build system on Windows uses DevStudio project files - AFAIK there is no DevStudio yet for Win64 (if there were, building Python would be trivial, just setup a new configuration in DevStudio) - I am currently using a cross-compiler for Win64 provided by Intel (as part of a contract that ActiveState has to port Python to Win64 and other OSes for the IA-64 platform). I don't know if there is a publicly available compiler for Win64 (I haven't looked). - My method for building for Win64 involves: (1) exporting Win32 build makefile from the Python *.dsp files from within DevStudio. (2) running a hack script of my own to convert those to makefile to ones that will build for Win64 (these makefiles are extremely specific to my system, i.e. it is a hack) (3) run those makefiles I *could* checkin this hack script of mine and provide some documentation in Python's standard readme, if the other python-dev'ers would be ammenable to this. [Note: my files would be isolated to one directory, say PCbuild/win64.] As I said, I have not done this because I expected to just wait until DevStudio for Win64 came on the scene and then the build system for it would fit in smoothly to the current .dsp's. I would rather not become a separate provider of the Win64 build scripts because I don't want to support them outside of Python's mechanisms (i.e. through SourceForge). In other words, I'll check them into the Python core if others think that that is okay, otherwise I am afraid the answer is "please wait until DevStudio for Win64 comes along". Trent -- Trent Mick TrentM at ActiveState.com From bjorn at roguewave.com Tue Oct 10 22:24:00 2000 From: bjorn at roguewave.com (Bjorn Pettersen) Date: Tue, 10 Oct 2000 14:24:00 -0600 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> Message-ID: <39E37AE0.C7380FFD@roguewave.com> To answer some of your questions: - there is no win64 devstudio (and I haven't found a way of getting the current devstudio to use the new compiler) - Intel does have a native compiler for win64 (don't use it, see below). - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the Microsoft compiler. It works MUCH better. It's also binary compatible with the Intel ecl compiler, and they didn't have any problems with us switching. My main interest is in having a python version that runs on the itanium box with socket support (they included socket support in sdk2 didn't they?) I.e. no need to provide a build mechanism for my needs if you can refer me to an executable ;-) -- bjorn Trent Mick wrote: > > On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote: > > Are there any instructions on how to build this for Win64/itanium > > anywhere? > > > > Um... not really. I did/am doing the Win64 port but I have not really given > the information required to build it, which, I agree, kind of sucks. I have > not done so because: > > - the Python build system on Windows uses DevStudio project files > - AFAIK there is no DevStudio yet for Win64 (if there were, building Python > would be trivial, just setup a new configuration in DevStudio) > - I am currently using a cross-compiler for Win64 provided by Intel (as > part of a contract that ActiveState has to port Python to Win64 and other > OSes for the IA-64 platform). I don't know if there is a publicly > available compiler for Win64 (I haven't looked). > - My method for building for Win64 involves: > (1) exporting Win32 build makefile from the Python *.dsp files from > within DevStudio. > (2) running a hack script of my own to convert those to makefile to ones > that will build for Win64 (these makefiles are extremely specific to > my system, i.e. it is a hack) > (3) run those makefiles > > I *could* checkin this hack script of mine and provide some documentation in > Python's standard readme, if the other python-dev'ers would be ammenable to > this. [Note: my files would be isolated to one directory, say PCbuild/win64.] > As I said, I have not done this because I expected to just wait until > DevStudio for Win64 came on the scene and then the build system for it would > fit in smoothly to the current .dsp's. > > I would rather not become a separate provider of the Win64 build scripts > because I don't want to support them outside of Python's mechanisms (i.e. > through SourceForge). In other words, I'll check them into the Python core > if others think that that is okay, otherwise I am afraid the answer is > "please wait until DevStudio for Win64 comes along". > > Trent > > -- > Trent Mick > TrentM at ActiveState.com From trentm at ActiveState.com Tue Oct 10 22:20:42 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:20:42 -0700 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think Message-ID: <20001010132042.B22561@ActiveState.com> test_poll.py currently fails on Monterey (64-bit AIX) because of a difference in the system poll() function as compared to Linux. On Linux (and as required by the Signle Unix Specification: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()" a bogus file descriptor you get a POLLNVAL return value in the 'revents' field of the structure sent to poll(). This is tested like so in test_poll.py: # returns NVAL for invalid file descriptor FD = 42 try: os.close(FD) except OSError: pass p = select.poll() p.register(FD) r = p.poll() assert r[0] == (FD, select.POLLNVAL) Monterey decided to return -1 instead. [Aside: However, 'revents's type is "short" so the Python interface to poll() (using PyInt_FromLong) actually interprets that as -32768 instead.] Questions: 1. Can anybody offer an opinion if this is Python's or Monterey's problem? 2. Can anybody tell me where I can browse the POSIX spec to see if this breaks POSIX compliance as well? 3. Could someone (Vladimir?) run this test program on a normal AIX box and tell me what the output is (does the return value == POLLNVAL?)? ---------------------------------------------------------------------- #include #include #define NFDS 1 int main(void) { struct pollfd ufds[NFDS]; int pollResult; printf("hello\n"); /* poll for any event on a bogus file descriptor */ ufds[0].fd = 42; ufds[0].events = POLLIN | POLLPRI | POLLOUT; pollResult = poll(ufds, NFDS, -1); if (pollResult != 1) { printf("*** poll result was %d, I expected 1.\n", pollResult); } printf("ufds[0].revents = %hd\n", ufds[0].revents); printf("POLLNVAL = %ld\n", POLLNVAL); return 0; } ---------------------------------------------------------------------- Thanks, Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Tue Oct 10 22:30:03 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 10 Oct 2000 13:30:03 -0700 Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1) In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600 References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com> Message-ID: <20001010133003.C22561@ActiveState.com> On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote: > - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the > Microsoft compiler. It works MUCH better. It's also binary compatible > with the Intel ecl compiler, and they didn't have any problems with us > switching. Yes, I knew that that was there. I remember either some earlier problem with it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for me well enough, I just haven't tried the one in Win64/. > My main interest is in having a python version that runs on the itanium > box with socket support (they included socket support in sdk2 didn't > they?) I.e. no need to provide a build mechanism for my needs if you can > refer me to an executable ;-) Well, Python's test_socket runs on my Win64 box so yes, socket support is there. As far as referring you to an exe, I would rather not go down that distribution road in preference to checking in my build scripts. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Tue Oct 10 22:37:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:37:30 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 Message-ID: <39E37E0A.90176759@lemburg.com> FYI, Here's what gcc -Wall gives on Linux: ceval.c: In function `eval_code2': ceval.c:345: warning: `v' might be used uninitialized in this function ceval.c:346: warning: `w' might be used uninitialized in this function ceval.c:347: warning: `u' might be used uninitialized in this function ceval.c:348: warning: `t' might be used uninitialized in this function errors.c: In function `PyErr_Format': errors.c:409: warning: value computed is not used errors.c:415: warning: value computed is not used -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Oct 10 22:45:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 10 Oct 2000 22:45:00 +0200 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? Message-ID: <39E37FCC.9925555A@lemburg.com> It was mentioned early in the beta phase that cycle GC would be enabled only during the beta cycle and disabled in the final. Is this still true ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Tue Oct 10 22:47:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:47:06 -0400 Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think In-Reply-To: <20001010132042.B22561@ActiveState.com> Message-ID: [Trent Mick] > test_poll.py currently fails on Monterey (64-bit AIX) because of > a difference in the system poll() function as compared to Linux. > > On Linux (and as required by the Signle Unix Specification: > http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if > you "poll()" a bogus file descriptor you get a POLLNVAL return value in > the 'revents' field of the structure sent to poll(). > ... > Monterey decided to return -1 instead. [Aside: However, 'revents's type is > "short" so the Python interface to poll() (using PyInt_FromLong) actually > interprets that as -32768 instead.] > > Questions: > 1. Can anybody offer an opinion if this is Python's or Monterey's > problem? Both. "Another day, another incompatible flavor of Unix(tm)." In the early days, Guido actually hoped he could get away without a massive hack like autoconf . > 2. Can anybody tell me where I can browse the POSIX spec to see if this > breaks POSIX compliance as well? Nowhere: ISO/ANSI stds are generally never available online. They get the bulk of their money from selling standards. http://webstore.ansi.org/ is a good place to buy. There are about 20 POSIX-related stds documents; the C API spec is US$245.00. You may get a cheaper answer on comp.unix.aix, of course. may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs - tim From tim_one at email.msn.com Tue Oct 10 22:58:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 16:58:54 -0400 Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ? In-Reply-To: <39E37FCC.9925555A@lemburg.com> Message-ID: [M.-A. Lemburg] > It was mentioned early in the beta phase that cycle GC would be > enabled only during the beta cycle and disabled in the final. > > Is this still true ? No, and it probably never was : the intent of enabling gc during the betas was to determine *whether* to enable it for the final release. The beta experience with gc was very good: a few subtle problems were uncovered, and Neil fixed them quickly. It should probably get a ton of performance testing that never happened, but then so should have all of 2.0 -- no particular reason to pick on gc alone for that. full-cycle-ahead-ly y'rs - tim From fdrake at beopen.com Tue Oct 10 23:13:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <39E37E0A.90176759@lemburg.com> References: <39E37E0A.90176759@lemburg.com> Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function These would be a real tedium to fix, and I'm not convinced the loss of clarity is worth it. From looking at the code in the DUP_TOPX code, I'm led to think that the compiler just isn't smart enough (it should figure out that oparg won't change before the second case statement, and figure it out more carefully. I'll bet *that* would remove these warnings and still right in all cases. > errors.c: In function `PyErr_Format': > errors.c:409: warning: value computed is not used > errors.c:415: warning: value computed is not used Fixed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Wed Oct 11 01:16:42 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:16:42 -0500 Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available! Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> We're experiencing a serious problem with the pythonlabs.com website. Unfortunately the site is down with no estimated time for when it will be back up. Our bestest brains are working on the problem! In the mean time, the Python 2.0c1 source tree can be downloaded from this address: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz The Windows installer is here: http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe And the 2.0c1 documentation is still here (on-line browseable and downloadable): http://www.python.org/doc/2.0c1/ If the outage lasts for more than a day, we'll find another place to hold the full distribution. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Oct 11 00:47:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 10 Oct 2000 18:47:19 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: [MAL] > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function [Fred] > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. I'll take this one. It looks easy to fix, and to my eye doing *everything* needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own blocks) would be much clearer than the current distributed trickiness (faster, too -- the code now is branching more than computing). > From looking at the code in the DUP_TOPX code, I'm led to think that > the compiler just isn't smart enough (it should figure out that oparg > won't change before the second case statement, and figure it out more > carefully. I'll bet *that* would remove these warnings and still right > in all cases. I agree, except that it wasn't trivial for *me* to decide the compiler was being stupid. Code that's obviously correct is better than code that's not obviously wrong. >> errors.c: In function `PyErr_Format': >> errors.c:409: warning: value computed is not used >> errors.c:415: warning: value computed is not used Thanks! > Fixed. Thanks! From thomas at xs4all.net Wed Oct 11 00:49:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 00:49:37 +0200 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400 References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <20001011004937.Q12812@xs4all.nl> On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote: > M.-A. Lemburg writes: > > ceval.c: In function `eval_code2': > > ceval.c:345: warning: `v' might be used uninitialized in this function > > ceval.c:346: warning: `w' might be used uninitialized in this function > > ceval.c:347: warning: `u' might be used uninitialized in this function > > ceval.c:348: warning: `t' might be used uninitialized in this function > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. From looking at the code in the DUP_TOPX > code, I'm led to think that the compiler just isn't smart enough (it > should figure out that oparg won't change before the second case > statement, and figure it out more carefully. I'll bet *that* would > remove these warnings and still right in all cases. Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall sometime before, and I didn't get those warnings then. Probably depends on the version of gcc. As a colleague of mine would say, "insert clue" (into gcc, that is ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Wed Oct 11 01:57:38 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 10 Oct 2000 18:57:38 -0500 Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available! In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST." <200010102316.SAA20071@cj20424-a.reston1.va.home.com> References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com> I wrote: > We're experiencing a serious problem with the pythonlabs.com website. > Unfortunately the site is down with no estimated time for when it will > be back up. Our bestest brains are working on the problem! With the help of Digital Creations' bestest brain, Jim Fulton, the site is back up in record time. We'll try not to break it again, Jim! And thanks to Digital Creations for helping us out on such a short notice. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Wed Oct 11 02:57:11 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <20001011004937.Q12812@xs4all.nl> References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> <20001011004937.Q12812@xs4all.nl> Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall > sometime before, and I didn't get those warnings then. Probably depends on > the version of gcc. As a colleague of mine would say, "insert clue" (into > gcc, that is ;) This is very reasonable. I don't think we'll give you too many demerits for this. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Wed Oct 11 06:40:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 00:40:41 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: We need a glibc expert! Anyone qualify? [Huaiyu Zhu] > ... > This is very likely to be a 2.0 bug. Or a 1.5.2 bug. I have to keep saying this stuff is a platform-dependent crap shoot, because it is (I too prefer that Python underflow silently by default, though). > Just to make sure, I have used freshly downloaded source code of > both 1.5.2 and 2.0b2, then > ./configure > make > ./python > > from math import * > exp(-746) > > I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2. > > The file mathmodule.c has quite some differences between the two versions, > mostly related to the ANSIfication. I'm not sure where the problem is. It's not in mathmodule.c. > I haven't tried the 2.0c1 yet, as the site is not available. Can > other Unix users confirm this behavior? I went over to Guido's and forced him to try it. He sees the same behavior: after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries, 1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises OverflowError. But there is no code in Python that accounts for the difference. Running it under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets errno to ERANGE (34) under 2.0. Since the platform exp was the only conceivable cause for this difference, it's not surprising that the debugger confirmed that the platform exp is in fact the cause. So the remaining question is why the same exp from the same library has different errno behavior depending on which version of Python it's called from. *That* one we couldn't answer, after a fruitless time digging thru the Byzantine glibc source code trying to reverse engineer it. Their exp *can* display different error behavior at runtime depending on several obscure things, but they're too obscure to relate back clearly to anything Python is doing. The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what the glibc exp author believes POSIX mandates, and is one of their exp's possible runtime behaviors, and your own little C program (which you posted earlier) suggests that's the default behavior under gcc + glibc. So presumably 1.5.2 config was such as to inhibit the default behavior. However, nobody changed this on purpose, so it smells like an unintended side effect of some other (currently unknown) config change. I don't know what to do next. I can't pursue it myself, and you've seen from the lack of replies to your posts that I'm the only who'll even listen to you . Guido suggests that one big change in 2.0 is that we're including a lot more std headers than we used to. It could well be that one of those #defines some God-forsaken preprocessor symbol one of whose five meanings (documented or not) is "use POSIX-conformant libm error reporting", but which someone #include'd in 2.0 to make (who knows?) sockets work right on some other flavor of Unix. Don't know. Unix config is a mess, and so is glibc. Best hope now is for someone intimately familiar with glibc internals to jump in and own this. staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs - tim From huaiyu_zhu at yahoo.com Wed Oct 11 10:12:37 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim Peters] > We need a glibc expert! Anyone qualify? If there is none here, maybe someone cares to ask in some gcc or gnu news groups? > The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what > the glibc exp author believes POSIX mandates, and is one of their exp's > possible runtime behaviors, and your own little C program (which you posted > earlier) suggests that's the default behavior under gcc + glibc. So > presumably 1.5.2 config was such as to inhibit the default behavior. > However, nobody changed this on purpose, so it smells like an unintended > side effect of some other (currently unknown) config change. So can we set a flag to explicitly discount ERANGE? There are only 19 lines in the source code that contain ERANGE, and 8 lines containing math_error. All the latter are in Modules/{c,}mathmodule.c. Could we just add an ifdef IEEE754 on these 8 lines? This would go a long way to aleviate this problem before we find a perfect solution, if there is one. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. I'm not interested in where this comes from - the only thing that matters is that it worked in 1.5.2 and breaks in 2.0. Whether the 1.5.2 behavior was intended or not, it's not a bug. The 2.0 behavior is a bug. If Posix conflicts with IEEE floating point arithmetic, then confirming to Posix in this regard is a bug. I would suggest the next thing to do is to introduce an IEEE754 flag and let those who do not like it to voice their opinions. Since this is the same behavior as 1.5.2 I doubt any running code would be broken by this. Huaiyu From thomas at xs4all.net Wed Oct 11 10:26:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:26:14 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400 References: Message-ID: <20001011102614.R12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote: > We need a glibc expert! Anyone qualify? No, at least not me ;) > So the remaining question is why the same exp from the same library has > different errno behavior depending on which version of Python it's called > from. *That* one we couldn't answer, after a fruitless time digging thru > the Byzantine glibc source code trying to reverse engineer it. Their exp > *can* display different error behavior at runtime depending on several > obscure things, but they're too obscure to relate back clearly to anything > Python is doing. Well, I've seen & heard about compilers doing slightly different things depending on ANSI or K&R style C, so perhaps the presence of ANSI C definitions triggered this. I sincerely doubt it, though, but you never know, and it's fairly easy to test. > I don't know what to do next. I can't pursue it myself, and you've seen > from the lack of replies to your posts that I'm the only who'll even listen > to you . Guido suggests that one big change in 2.0 is that we're > including a lot more std headers than we used to. It could well be that one > of those #defines some God-forsaken preprocessor symbol one of whose five > meanings (documented or not) is "use POSIX-conformant libm error reporting", > but which someone #include'd in 2.0 to make (who knows?) sockets work right > on some other flavor of Unix. Don't know. Unix config is a mess, and so is > glibc. Best hope now is for someone intimately familiar with glibc > internals to jump in and own this. Actually, there was some activity to define the right combination of _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not sure what the end result was. If any #define changes the behaviour of glibc, these would definately be it ! A simple test might be to compile 1.5.2 with the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, and do some of the above tests. Computers-suck-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Oct 11 10:31:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 10:31:49 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700 References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <20001011103148.S12812@xs4all.nl> On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote: > default: > fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg); Hm, this fprintf is stray debugging code, added because I wasn't sure that a SystemError wouldn't crash the interpreter, given that the stack is utterly fu*d up at this point and we don't know what the compiler thinks is the stack size or block size here. (The snippet doesn't show it, but it also raises a SystemError.) Is it okay if I remove/comment this fprintf() before 2.0 final ? (At least it didn't say "awoogah, stray debugging code detected, this machine will self-destruct in 10 seconds" :-) Another-day-another-demerit-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Wed Oct 11 11:52:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 05:52:59 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > So can we set a flag to explicitly discount ERANGE? There are > only 19 lines in the source code that contain ERANGE, and 8 lines > containing math_error. > All the latter are in Modules/{c,}mathmodule.c. Could we just > add an ifdef IEEE754 on these 8 lines? This would go a long way to > aleviate this problem before we find a perfect solution, if there > is one. That would stop the exception on exp() underflow, which is what you're concerned about. It would also stop exceptions on exp() overflow, and on underflow and overflow for all other math functions too. I doubt Guido will ever let Python ignore overflow by default, #ifdef'ed or not. A semantic change that jarring certainly won't happen for 2.0 (which is just a week away). > ... > I'm not interested in where this comes from - the only thing that > matters is that it worked in 1.5.2 and breaks in 2.0. The behavior of underflowing exp() is hardly the only thing that matters, although it's becoming clear it may be the only thing you care about <0.9 wink>. I would like to change that too for 2.0, but give a thought to the other consequences. If some change to the Python config screwed up exp(-1000) for you, what else is going wrong? You're not going to get an answer to that until we know exactly "where this comes from". > Whether the 1.5.2 behavior was> intended or not, it's not a bug. The > 2.0 behavior is a bug. If Posix conflicts with IEEE floating point > arithmetic, then confirming to Posix in this regard is a bug. POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno, as is POSIX on 754 issues. It was Python's decision (not POSIX's) to raise an exception when errno gets set. Python wasn't designed to support 754, and makes no claim to support any part of it, so conformance to 754 may be presented as a feature request, but trying to beat Python over the head with it won't work: there's no bug here, in the strong sense that no documented (or even intended!) behavior has changed. What happened is that one platform accident got changed to a different platform accident. You certainly get sympathy for that, but not enough to buy radical last-minute changes. > I would suggest the next thing to do is to introduce an IEEE754 > flag and let those who do not like it to voice their opinions. Nothing like that will happen without a PEP first. I would like to see *serious* 754 support myself, but that depends too on many platform experts contributing real work (if everyone ran WinTel, I could do it myself ). > Since this is the same behavior as 1.5.2 I doubt any running code would be > broken by this. Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and current code certainly relies on detecting overflows in math functions. It would also break code on platforms that were setting errno to ERANGE all along on underflow (as POSIX appears to require, and ANSI C doesn't appear to forbid; I don't know of such a platform for sure offhand, but to judge from their manpages, HPUX looks like one). In no case can you expect to see overflow ignored in 2.0. I want to know where this comes from, so we have *some* handle on what other surprises may be lurking. If no progress is made on determining the true cause over the next few days, I'll hack mathmodule.c to ignore ERANGE in the specific case the result returned is a zero (which would "fix" your exp underflow problem without stopping overflow detection). Since this will break code on any platform where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a long discussion w/ Guido first. I *believe* that much is actually sellable for 2.0, because it moves Python in a direction I know he likes regardless of whether he ever becomes a 754 True Believer. like-herding-cats-indeed-ly y'rs - tim From tim_one at email.msn.com Wed Oct 11 12:02:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 06:02:05 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011103148.S12812@xs4all.nl> Message-ID: > > default: > > fprintf(stderr, "Invalid argument > to DUP_TOPX: %d!\n", oparg); [Thomas Wouters] > Hm, this fprintf is stray debugging code, added because I wasn't > sure that a SystemError wouldn't crash the interpreter, given that the > stack is utterly fu*d up at this point and we don't know what the > compiler thinks is the stack size or block size here. (The snippet > doesn't show it, but it also raises a SystemError.) Is it okay if I > remove/comment this fprintf() before 2.0 final ? Suggest replacing it with: assert(!"Invalid argument to DUP_TOPX"); Then there's no cost in release mode, but we have a useful check in debug mode. ("assert(!string)" is a handy C debugging idiom more people should know about! It's semantically the same as assert(0) (i.e. will fail if ever reached), but unlike using a comment, using a string gets a useful msg displayed if it ever does fail). > (At least it didn't say "awoogah, stray debugging code detected, this > machine will self-destruct in 10 seconds" :-) Beats "Unto the root this day a brother is born" . > Another-day-another-demerit-ly y'rs, That's a funny thing about working on Python: collect 5 demerits and you can exchange them for 1 brownie point! If you're not leaving crap behind, you're not eating enough Python code. continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs - tim From guido at python.org Wed Oct 11 16:39:06 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:39:06 -0500 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400." References: Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com> Incidentally, math.exp(800) returns inf in 1.5, and raises OverflowError in 2.0. So at least it's consistent. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:38:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT) Subject: [Python-Dev] OS Dependant Bugs Message-ID: Many of the sourceforge bugs are platform dependant. Unfortunately, it is impossible, from the main bugs page, to see which are platform dependant, and which platform the occur on. I suggest that, until SF supports it properly, each bug report we enter will have an optional [Platform] in front, if it seems to be platform dependant. Any opinions? Anyone thinks submitting an SF request to add this field is foolish? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at python.org Wed Oct 11 16:41:47 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:41:47 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400." References: Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> > Suggest replacing it with: > > assert(!"Invalid argument to DUP_TOPX"); Actually, I would recommend Py_FatalError("Invalid argument to DUP_TOPX") It's not quite the same since it also triggers in release mode. If, as Thomas says, this should never happen and can only be caused by garbled bytecode, a fatal error is proper rather than a SystemError. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:41:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > Py_FatalError("Invalid argument to DUP_TOPX") > > It's not quite the same since it also triggers in release mode. If, > as Thomas says, this should never happen and can only be caused by > garbled bytecode, a fatal error is proper rather than a SystemError. Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception. Unless I misunderstand the discussion completely. jumping-to-discussions-in-the-middle-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake at beopen.com Wed Oct 11 15:42:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net> References: <200010110704.AAA12861@slayer.i.sourceforge.net> Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com> Tim Peters writes: > Update of /cvsroot/python/python/dist/src/Python > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg, > by making the DUP_TOPX code utterly straightforward. This also gets rid > of all normal-case internal DUP_TOPX if/branches, and allows replacing one > POP() with TOP() in each case, so is a good idea regardless. Tim, There's still one left: gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c -o ceval.o ../../Python/ceval.c ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:346: warning: `w' might be used uninitialized in this function Cruising through this code, it looks like the problem might be in the PRINT_NEWLINE case: case PRINT_NEWLINE: if (stream == NULL || stream == Py_None) { w = PySys_GetObject("stdout"); if (w == NULL) PyErr_SetString(PyExc_RuntimeError, "lost sys.stdout"); } if (w != NULL) { /* If PRINT_NEWLINE is the opcode, w might not be initialized * here (I think), since I don't see it initialize before the * switch. Since we can't initialize it to NULL with the case * (doing so would break the PRINT_NEWLINE_TO case), it would * have to be initialized before the main loop is entered. */ err = PyFile_WriteString("\n", w); if (err == 0) PyFile_SoftSpace(w, 0); } Py_XDECREF(stream); stream = NULL; break; Ok.... yep, initializing that seems to work. I'll check in the fix for this one after I've run the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Wed Oct 11 16:54:14 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:14 -0500 Subject: [Python-Dev] OS Dependant Bugs In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300." References: Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com> > Many of the sourceforge bugs are platform dependant. Unfortunately, it is > impossible, from the main bugs page, to see which are platform dependant, > and which platform the occur on. > > I suggest that, until SF supports it properly, each bug report we enter > will have an optional [Platform] in front, if it seems to be platform > dependant. > > Any opinions? Anyone thinks submitting an SF request to add this field > is foolish? I think it's sufficient (actually better) if the platform name is mentioned in the summary. Note that you can edit the summary of existing bug reports. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 11 16:54:54 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 09:54:54 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300." References: Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> > Can't user Python code, fiddling around with bytecode, produce garbled > bytecode? In that case, it seems even better to raise an exception. Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing. --Guido van Rossum (home page: http://www.python.org/~guido/) From moshez at math.huji.ac.il Wed Oct 11 14:56:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 11 Oct 2000, Guido van Rossum wrote: > > Can't user Python code, fiddling around with bytecode, produce garbled > > bytecode? In that case, it seems even better to raise an exception. > > Yes, they can produce garbled bytecode, and if that is detected, it's > not safe to proceed. So a fatal error is the right thing. The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From akuchlin at mems-exchange.org Wed Oct 11 15:56:50 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 09:56:50 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: >Actually, there was some activity to define the right combination of >_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not >sure what the end result was. If any #define changes the behaviour of glibc, >these would definately be it ! A simple test might be to compile 1.5.2 with That seems the likely cause. Another faint possibility might be threading, since 2.0 automatically uses threads but 1.5.2 needs to have them enabled. (Perhaps Tim remembered this and supplied --with-thread to the 1.5.2 configure script.) --amk From guido at python.org Wed Oct 11 17:03:00 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:03:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300." References: Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > bytecode? In that case, it seems even better to raise an exception. > > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > restricted execution much more difficult. Well, something to think about > for 2.1... Huh? In restricted execution you shouldn't be allowed to mess with bytecode! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 11 17:25:32 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 10:25:32 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400." <20001011095650.A17931@kronos.cnri.reston.va.us> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Bingo! 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the 1.5.2 link line makes is raise OverflowError too. Adding it to the 2.0 link line makes it return 0.0 for exp(-1000) and inf for exp(1000). Next question: what changed in the configure script, and why? --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Wed Oct 11 16:24:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:24:37 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200 References: <20001011102614.R12812@xs4all.nl> Message-ID: <20001011162436.T12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote: [ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ] > Actually, there was some activity to define the right combination of > _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not > sure what the end result was. If any #define changes the behaviour of glibc, > these would definately be it ! A simple test might be to compile 1.5.2 with > the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in > 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can > reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here, > and do some of the above tests. Well, that was no success. I do see the difference between 1.5.2 and 2.0, but *damned* if I can figure out where it comes from. It doesn't seem to be any of the properly placed defines, and it doesn't seem to be the changes in mathmodule itself. Not autoconf, either. What I did: old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0 new tree (current CVS): math.exp(-1000) raises OverflowError (No difference between threads enabled and disabled.) Use new config.h in old tree: math.exp(-1000) returned 0.0 Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0 Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000) raises OverflowError Copy new mathmodule.c to old tree (adding an 'include math.h' because the old Python.h isn't doing that): math.exp(-1000) returns 0.0 Copy config.h and Python.h from new tree to old one (removing the include of unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h to make it compile): math.exp(-1000) returns 0.0 So, as far as I can tell, it's not related to any code in mathmodule.c itself, nor any defines in config.h or Python.h. mymath.h isn't used either, as far as I can tell it only contains stuff for broken math stuff on obscure platforms. Sounds like time for that glibc expert right about now ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Wed Oct 11 16:32:23 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 11 Oct 2000 10:32:23 -0400 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: >1.5.2 links with -lieee while 2.0 doesn't. >Next question: what changed in the configure script, and why? The patch from revisions 1.138 to 1.139 of configure.in is: 853c1139,1142 < AC_CHECK_LIB(ieee, __fpu_control) --- > AC_CHECK_FUNC(__fpu_control, > [], > [AC_CHECK_LIB(ieee, __fpu_control) > ]) The check-in comment is "Only link with -lieee when it's necessary". If it only checks for -lieee when the __fpu_control function is defined, perhaps the function disappeared in glibc 2.1. --amk From thomas at xs4all.net Wed Oct 11 16:32:45 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 16:32:45 +0200 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500 References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> Message-ID: <20001011163244.U12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote: > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). Ack, that's the one thing I didn't check: link libraries ;-P > Next question: what changed in the configure script, and why? Well, that's easy. Old configure.in: # Linux requires this for correct f.p. operations AC_CHECK_LIB(ieee, __fpu_control) New configure.in: # Linux requires this for correct f.p. operations AC_CHECK_FUNC(__fpu_control, [], [AC_CHECK_LIB(ieee, __fpu_control) ]) I remember the patch that did this, on SF. It was titled "don't link with -lieee if it isn't necessary" or something. Not sure what it would break, but mayhaps declaring -lieee necessary on glibc systems is the right fix ? (For the non-autoconf readers among us: the first snippet writes a test program to see if the function '__fpu_control' exists when linking with -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second snippet writes a test program to see if the function '__fpu_control' exists with the current collection of $LIBS. If it doesn't, it tries it again with -lieee, and adds -lieee to $LIBS if it finds it then.) Pesonally, I think the patch should just be reversed... The comment above the check certainly could be read as 'Linux requires -lieee for correct f.p. operations', and perhaps that's how it was meant. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Oct 11 18:31:48 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com> Message-ID: <14820.38388.827883.710489@beluga.mojam.com> Tim> I'll take this one. It looks easy to fix ... Seems to me like a patch that ought to wait until after 2.0final. It's definitely not a show-stopping bug... Skip From thomas at xs4all.net Wed Oct 11 20:04:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 11 Oct 2000 20:04:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500 References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> Message-ID: <20001011200431.V12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote: > > > > Can't user Python code, fiddling around with bytecode, produce garbled > > > > bytecode? In that case, it seems even better to raise an exception. > > > Yes, they can produce garbled bytecode, and if that is detected, it's > > > not safe to proceed. So a fatal error is the right thing. > > The problem with letting Python code cause fatal errors is that it makes > > restricted execution much more difficult. Well, something to think about > > for 2.1... > Huh? In restricted execution you shouldn't be allowed to mess with > bytecode! Well, I can see what Moshe means. You get a code object passed in, say, an untrusted pickle or some such. You want to execute it, but you don't want it to ruin your life. Causing the entire program to quit could be considered 'ruining'. On the other hand, if you can hand-tweak bytecode streams in that degree, you can f** up a lot more. On the one foot, though, most of the calls to Py_FatalError (as far as I can see) deal with initialization failures, or structures to which tweaked bytecode would not have access. On the other foot, it's probably possible to tweak bytecode to *get* access to those structures, or at least structures that don't like being dereferenced or DECREF'd. And there's probably more to consider, but I haven't got any public appendages left, and there might be children listening ;) All in all, Guido's probably right... If something like this happens, you don't want to continue. If the argument to DUP_TOPX is something other than what compile.c generates (between 1 and 5, inclusive, that is) something strange is going on internally. Better to quit now than delete c:\command.com by 'accident'. If people can do this to code being run in restricted environments, they can probably do worse things, too! Now I just need an OK from Jeremy, as the maitre d', and I'll check it in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at python.org Wed Oct 11 23:19:28 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 16:19:28 -0500 Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200." <20001011163244.U12812@xs4all.nl> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Thanks for digging deeper into this. > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct f.p. > operations', and perhaps that's how it was meant. No, the configure patch is right. Tim will check in a change that treats ERANGE with a return value of 0.0 as underflow (returning 0.0, not raising OverflowError). --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Oct 11 23:02:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:02:16 -0400 Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: [Tim] > I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy > to fix ... [Skip Montanaro] > Seems to me like a patch that ought to wait until after 2.0final. It's > definitely not a show-stopping bug... Would have been a more interesting argument had you posted this before the patch was checked in . But wngs are non-negotiable with me anyway. This example turned out to be a good one for showing why: the bogus wngs covered up a legitimate "uninitialized vrbl" complaint (see Fred's later discovery and following checkin). I've simply got zero tolerance for wngs or for failures in the std test suite. My view is warped by prior experience, though: the last 6 years, I worked on projects where the compilers were fiddled to treat warnings as fatal errors. So while this may have looked like a harmless batch of wngs to you, as far as I was concerned Python couldn't even be compiled anymore <0.7 wink>. extremism-in-defense-of-simple-best-practice-may-or-may-not-be- vice-but-it's-sure-effective-over-the-long-term-ly y'rs - tim From skip at mojam.com Wed Oct 11 23:07:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT) Subject: [Python-Dev] -Wall output for the Python 2.0c1 In-Reply-To: References: <14820.38388.827883.710489@beluga.mojam.com> Message-ID: <14820.54942.114086.773609@beluga.mojam.com> Tim> [Tim] >> I'll take this one [wngs putatively due to DUP_TOPX]. It looks easy >> to fix ... Tim> [Skip Montanaro] >> Seems to me like a patch that ought to wait until after 2.0final. >> It's definitely not a show-stopping bug... Tim> Would have been a more interesting argument had you posted this Tim> before the patch was checked in . Agreed, but I posted as soon as I saw it. Can't help it if I can't keep up with all the flurry of activity. Tim> So while this may have looked like a harmless batch of wngs to you, Tim> as far as I was concerned Python couldn't even be compiled anymore Tim> <0.7 wink>. I accept your explanation. ;-) S From jack at oratrix.nl Wed Oct 11 23:10:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 11 Oct 2000 23:10:36 +0200 Subject: [Python-Dev] test_StringIO failing on the Mac Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl> I have one remaining problem (at least, as far as I'm aware:-) with 2.0c1 on the Mac: test_StringIO fails. The reason is that the test_StringIO output file was generated on Unix, and hence it uses the unix form of string.letters (a-zA-Z), whereas the Mac version of string.letters has far more values. As this isn't what the test is about in the first place, shall I fix the test? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tim_one at email.msn.com Wed Oct 11 23:14:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 17:14:17 -0400 Subject: [Python-Dev] test_StringIO failing on the Mac In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl> Message-ID: [Jack Jansen] > I have one remaining problem (at least, as far as I'm aware:-) with > 2.0c1 on the Mac: test_StringIO fails. > > The reason is that the test_StringIO output file was generated on > Unix, and hence it uses the unix form of string.letters (a-zA-Z), > whereas the Mac version of string.letters has far more values. > > As this isn't what the test is about in the first place, shall I fix > the test? +1 from me on making the test portable. From jeremy at beopen.com Thu Oct 12 01:06:56 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208 In-Reply-To: <20001011200431.V12812@xs4all.nl> References: <200010111503.KAA03123@cj20424-a.reston1.va.home.com> <20001011200431.V12812@xs4all.nl> Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net> >>>>> "TW" == Thomas Wouters writes: [Moshe:] >> > The problem with letting Python code cause fatal errors is that >> > it makes restricted execution much more difficult. Well, >> > something to think about for 2.1... [Guido:] >> Huh? In restricted execution you shouldn't be allowed to mess >> with bytecode! TW> Well, I can see what Moshe means. You get a code object passed TW> in, say, an untrusted pickle or some such. You want to execute TW> it, but you don't want it to ruin your life. Causing the entire TW> program to quit could be considered 'ruining'. On the other TW> hand, if you can hand-tweak bytecode streams in that degree, you TW> can f** up a lot more. Damn straight! If you're using restricted execution mode and accepting bytecode objects that weren't produced by a trusted Python compiler, you're nuts. I am not aware of any effort made to protect the Python VM from attack via malicious bytecode. TW> Now I just need an OK from Jeremy, as the maitre d', and I'll TW> check it in. Your table is ready. A checkin message will be accepted as gratuity. Jeremy From jeremy at beopen.com Thu Oct 12 01:12:15 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT) Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com> References: <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com> <20001011163244.U12812@xs4all.nl> <200010112119.QAA03651@cj20424-a.reston1.va.home.com> Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net> I checked in the patch that removed the -lieee link in some cases. I don't remember the details off the top of my head, but I can go digging in the SF patch logs if it's important. As I recall, someone reported problems on a platform (HPUX?) where link with ieee caused problems. I didn't have access to the platform in question. So I applied the patch on a Linux box and ran the regression test; it reported no errors, so I assumed the patch fixed some other platform and did mine no harm. At the moment, I would assume that the patch still helps some other platform but might not be right on Linux. On the other hand, it sounds like Tim has a patch that will cause Linux to do the right thing. It's hard to say much about what should or should not happen since neither the language reference nor the regression tests specifies much about what should happen with fp. Jeremy From thomas at xs4all.net Thu Oct 12 01:15:21 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 01:15:21 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15 In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700 References: <200010112144.OAA20776@slayer.i.sourceforge.net> Message-ID: <20001012011521.X12812@xs4all.nl> On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717 > > Modified Files: > dlmodule.c > Log Message: > > Remove one more gcc -Wall warning. To note, if gcc didn't inherit at least *some* of C's original philosophy of 'the programmer always knows what [s]he is doing', gcc would yell bloody murder at this code. The 'func' function pointer is used to point to symbols loaded from arbitrary shared objects, and the dlmodule has no way of knowing howmany arguments the function expects, or even if it isn't more than 10 (which would result in the function grabbing garbage off the stack, on most architectures, I think.) While on the ANSIfication spree, I ran screaming and hid under my bed after reading this code ;) Is anyone using the dlmodule anymore ? Is it really useful ? Is this *really* how loading and calling arbitrary shared objects should be done ? :P > { > PyObject *name; > ! long (*func)(long, long, long, long, long, > ! long, long, long, long, long); > long alist[10]; > long res; Idle-and-post-2.0-talk-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu at yahoo.com Thu Oct 12 01:33:08 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: On the issue of whether Python should ignore over/underflow on IEEE-enabled platforms: [Tim Peters] > That would stop the exception on exp() underflow, which is what you're > concerned about. It would also stop exceptions on exp() overflow, and on > underflow and overflow for all other math functions too. I doubt Guido will > ever let Python ignore overflow by default, #ifdef'ed or not. A semantic > change that jarring certainly won't happen for 2.0 (which is just a week > away). It can be argued that on IEEE enabled systems the proper thing to do for overflow is simply return Inf. Raising exception is WRONG. See below. [Guido van Rossum] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. That is not consistent at all. Suppose I'm plotting the curve f(x) where x include some singular points of f. In the first case the plot works with some portion of the curve clipped. In the second case it bombs. [Tim Peters] > Nothing like that will happen without a PEP first. I would like to see > *serious* 754 support myself, but that depends too on many platform experts > contributing real work (if everyone ran WinTel, I could do it myself > ). [Guido van Rossum] > Bingo! > > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). If using ieee is as simple as setting such a flag, there is no reason at all not to use it. Here are some more examples: Suppose you have done hours of computation on a problem. Just as you are about to get the result, you get an exception. Why? Because the residual error is too close to zero. Suppose you want to plot the curve of Gausian distribution. Oops, it fails. Because beyond a certain region the value is near zero. With these kinds of problems, vectorized numerical calculation becomes nearly impossible. How do you work in such an environment? You have to wrap every calculation in a try/except structure, and whenever there is an exception, you have to revert to elementwise operations. In practice this simply means Python would not be suitable for numerical work at all. What about the other way round? No problem. It is easy to write functions like isNaN, isInf, etc. With these one can raise exceptions in any place one want. It is even possible to raise exceptions if a matrix is singular to a certain precision, etc. The key point to observe here is that most numerical work involve more than one element. Some of them may be out of mahcine bounds but the whole thing could still be quite meaningful. Vice versa it is also quite possible that all elements are within bounds while the whole thing is meaningless. The language should never take over or subvert decisions based on numerical analysis. [Tim Peters] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. As Guido observed ERANGE is not generated with ieee, even for overflow. So it is the same behavior as 1.5.2. Besides, no correct numerical code should depend on exceptions like this unless the machine is incapable of handling Inf and NaN. Even in the cases where you do want to detect overflow, it is still wrong to use exceptions. Here's an example: x*log(x) approaches 0 as x approaches 0. If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want. But exception is the wrong tool to hangle this, because if x is an array, some of its element may be zero but other's may not. The right way to do it is something like def entropy(probability): p = max(probability, 1e-323) return p*log(p) [Tim Peters] > In no case can you expect to see overflow ignored in 2.0. You are proposing a dramatic change from the behavior of 1.5.2. This looks like to me to need a PEP and a big debate. It would break a LOT of numerical computations. [Thomas Wouters] > I remember the patch that did this, on SF. It was titled "don't link with > -lieee if it isn't necessary" or something. Not sure what it would break, > but mayhaps declaring -lieee necessary on glibc systems is the right fix ? > > (For the non-autoconf readers among us: the first snippet writes a test > program to see if the function '__fpu_control' exists when linking with > -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second > snippet writes a test program to see if the function '__fpu_control' > exists with the current collection of $LIBS. If it doesn't, it tries it > again with -lieee, > > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct > f.p. operations', and perhaps that's how it was meant. The patch as described seems to be based on flawed thinking. The numbers Inf and NaN are always necessary. The -lieee could only be unnecessary if the behavior is the same as IEEE. Obviously it isn't. So I second Thomas's suggestion. [Tim Peters] > If no progress is made on determining the true cause over the next few days, > I'll hack mathmodule.c to ignore ERANGE in the specific case the result > returned is a zero (which would "fix" your exp underflow problem without > stopping overflow detection). Since this will break code on any platform > where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a > long discussion w/ Guido first. I *believe* that much is actually sellable > for 2.0, because it moves Python in a direction I know he likes regardless > of whether he ever becomes a 754 True Believer. [Guido van Rossum] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). What is the reason to do this? It looks like intetionally subverting ieee even when it is available. I thought Tim meant that only logistical problems prevent using ieee. If you do choose this route, please please please ignore ERANGE entirely, whether return value is zero or not. The only possible way that ERANGE could be useful at all is if it could be set independently for each element of an array, and if it behave as a warning instead of an exception, ie. the calculation would continue if it is not caught. Well, then, Inf and NaN serve this purpose perfectly. It is very reasonable to set errno in glibc for this; it is completely unreasonable to raise an exception in Python, because exceptions cannot be set to individual elements and they cannot be ignored. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From pauldubois at home.com Thu Oct 12 02:04:51 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 17:04:51 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: I don't have time to follow in detail this thread about changed behavior between versions. These observations are based on working with hundreds of code authors. I offer them as is. a. Nobody runs a serious numeric calculation without setting underflow-to-zero, in the hardware. You can't even afford the cost of software checks. Unfortunately there is no portable way to do that that I know of. b. Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going. From guido at python.org Thu Oct 12 03:45:30 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 20:45:30 -0500 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST." References: Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> > I don't have time to follow in detail this thread about changed behavior > between versions. These observations are based on working with hundreds of > code authors. I offer them as is. > > a. Nobody runs a serious numeric calculation without setting > underflow-to-zero, in the hardware. You can't even afford the cost of > software checks. Unfortunately there is no portable way to do that that I > know of. > > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > stop, not put a zero and keep going. Thanks, Paul! This behavior has always been what I wanted Python to do (even though it's not always what Python did, depending on the platform) and also what Tim's proposed patch will implement for the specific case of math.exp() (and other math functions that may underflow or overflow), on most reasonable platforms. There are still lots of places where the platform gives Python no choice of creating NaN and Inf, and because there's no platform-independent way to test for these, they are hard to avoid in some cases; but eventually, Tim will find a way to root them out. And for people like Huaiyu, who want to see Inf, there will (eventually) be a way to select this as a run-time option; and ditto for whoever might want underflow to raise an exception. --Guido van Rossum (home page: http://www.python.org/~guido/) From huaiyu_zhu at yahoo.com Thu Oct 12 04:22:54 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> Message-ID: [Paul Dubois] > > > > a. Nobody runs a serious numeric calculation without setting > > underflow-to-zero, in the hardware. You can't even afford the cost of > > software checks. Unfortunately there is no portable way to do that that I > > know of. Amen. > > > > b. Some people use Inf but most people want the code to STOP so they can > > find out where the INFS started. Otherwise, two hours later you have big > > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > > stop, not put a zero and keep going. $ /usr/bin/python Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from math import * >>> exp(777) inf >>> exp(-777) 0.0 >>> sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error This was sane behavior. Are we saying that Python 2.0 has invented something better than IEEE 754? [Guido van Rossum] > Thanks, Paul! This behavior has always been what I wanted Python to > do (even though it's not always what Python did, depending on the > platform) and also what Tim's proposed patch will implement for the > specific case of math.exp() (and other math functions that may > underflow or overflow), on most reasonable platforms. Guido, with due respect to your decisions on Python issues, I simply have to fight this one. It is one thing to accomodate for naive users, but it is another to dumb down every one else. Case 1. Someone writes a flawed numerical routine. Two hours later he finds his array filled with Inf and NaN. Case 2. Someone writes a perfect numerical routine. Two hours later he gets an exception, because the error is near zero. Solution for case 1. Use better algorithm. Use better error control. Raise exceptions when error is too large. These are proper solutions. They are easy and efficient to implement. They are needed anyway - If something's wrong, you want to raise exceptions far earlier than Inf, certainly before you get arrays filled with elements like 1e300. Solution for case 2. Almost impossible. The division between under- and over-flow is artificial. What about 1/x or similar functions? The only way to work on such a platform is to abandon vectorized computation. > There are still lots of places where the platform gives Python no > choice of creating NaN and Inf, and because there's no > platform-independent way to test for these, they are hard to avoid in > some cases; but eventually, Tim will find a way to root them out. And > for people like Huaiyu, who want to see Inf, there will (eventually) > be a way to select this as a run-time option; and ditto for whoever > might want underflow to raise an exception. I can understand that exceptions are the only available choices if IEEE is not available. But is there a compelling reason that Python should behave "better" than IEEE when it's in fact available? If the reason is to protect naive users, I can think of several responses: 1. For people doing one-off interactive work, returning Inf is in fact more informative. 2. For users iterative numerical computations, they need to be educated about error control. Otherwise they won't get corrent results anyway. 3. For really serious work, we could provide good numerical modules so that they don't need to write themselves. To make this happen fast the fewer debacles like this one the better. Case in point: Someone asked for regession modules two weeks ago. I was trying to convert my old matlab programs, which only took a few hours. But I wasted a week of (spare) time fighting for some mysterious "overflow". Turns out that a Guassian is near zero when it's far from center, and Python does not like it. In practice, Inf may be generated more often as a proper value than by mistake. This is not an issue about whether someone "prefers" Inf or exception. It is about whether there is a choice to do proper computation. Returning Inf does not prevent someone to raise exception. Raising exception automatically prevents perfect algorithms to work properly. As Kevin has volunteered to help with IEEE implementation and made a plan, is there a strong reason to drop IEEE for Linux in 2.0? If there is insufficient time to carry out his plan, wouldn't it be prudent to keep things as they were in 1.5.2? Huaiyu From tim_one at email.msn.com Thu Oct 12 04:44:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 22:44:20 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim From sdm7g at virginia.edu Thu Oct 12 05:23:32 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: First: I haven't followed this thread from the beginning -- only the last ten or so posts. Second: One reason I didn't follow it from the start is that I'm not doing any heavy numerical stuff in Python. I've been using Lisp for that, and use Python more for string/symbolic or GUI hacking. But, if I was going to do the sort of numerical stuff I now do in Lisp in Python, I would agree with Huaiya Zhu. I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points in the vector -- they are independent of the bad points. In my case, it's not that these are lengthy calculations. It's that they are interactive and tied to immediate graphical representations. If there are strange zero's or infinities in the result, there is (or should be) a way to backtrack and investigate. ( That's why people want interactive and graphical regression analysis and modeling tools! ) The idea that your calculation should blow up and you should check it and resubmit your job sounds just so ancient-20th-century- Fortran-JCL-and-punched-cards-technology! ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 06:18:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 00:18:19 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <20001011234038.A2322@better.net> Message-ID: [William Park] > On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. I didn't write that. Paul Dubois did. > Hmm... I don't like this. It should stop or return complex. Paul said it should stop. You said it should stop (or return complex). So what is it that you don't like ? 754 mandates that sqrt(x) for x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently doesn't like. [actually Tim] > I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* > have silently returned a NaN (not a zero) without setting errno if it > was *self*-consistent -- anyone care to check that under -lieee?: > > import math > math.sqrt(-1) > > NaN or ValueError? 2.0 should raise ValueError regardless of > what 1.5.2 did here.). [back to William] > It returns 'OverflowError: math range error' in 1.5.2, Ah, that's hilarious ! It's tempting to believe that glibc is violating the IEEE std despite the -lieee flag in this case, but I don't believe that's true: it's almost certainly the case that glibc is actually returning a NaN, *not* setting errno at all, and this other check in Python's mathmodule.c: #define CHECK(x) if (errno != 0) ; \ else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \ else errno = ERANGE is setting errno to ERANGE purely due to an accident of the way gcc happens to compile code for comparing NaN to Inf and -Inf. > and 'ValueError: math domain error' in 2.0. Which is the correct exception, so is another reason for Python to avoid -lieee in 2.0. will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out- what-happens-by-accident-now-ly y'rs - tim From tim_one at email.msn.com Thu Oct 12 08:16:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 02:16:23 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > $ /usr/bin/python > Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux-i386 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from math import * > >>> exp(777) > inf > >>> exp(-777) > 0.0 > >>> sqrt(-1) > Traceback (innermost last): > File "", line 1, in ? > OverflowError: math range error > > This was sane behavior. Are we saying that Python 2.0 has invented > something better than IEEE 754? 754 allows users to choose the behaviors they want. Any *fixed* policy is not 754. So long as we have to fix a single policy, yes, I believe Guido (& know I) would say that raising OverflowError on exp(777), and silently returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not* OverflowError, as shown above), is indeed better than the 754 default behaviors. And 2.0 will do all three of those (& I just checked in the code to make that happen). About the sqrt example above, that's neither 754 behavior nor sane behavior: default 754 behavior on sqrt(-1) is to return a NaN and keep on going. I'm pretty sure that's what glibc linked w/ -lieee actually does, too (if it doesn't, glibc -lieee is violating 754). That 1.5.2 raised an OverflowError instead is insane, and appears purely due to an accident of how gcc compiles code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was fooled by this into setting errno to ERANGE itself). Python should raise a ValueError there instead (corresponding to libm setting errno to EDOM -- this is a domain error, not a range error) -- which it does now under CVS Python. 754-doesn't-work-unless-you've-got-all-of-it-ly y'rs - tim From thomas at xs4all.net Thu Oct 12 10:11:57 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 10:11:57 +0200 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400 References: Message-ID: <20001012101157.Y12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. > Nobody has proposed changing anything about libm domain (as opposed to > range) errors (although Huaiyu probably should if he's serious about his > flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on > 1.5.2, but it *should* have silently returned a NaN (not a zero) without > setting errno if it was *self*-consistent -- anyone care to check that > under -lieee?: > import math > math.sqrt(-1) >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do: >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error Consistency-conschmistency-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Thu Oct 12 17:58:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT) Subject: [Python-Dev] (no subject) Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net> Cc xml-sig at python.org Subject: test_minidom non-failure failure? X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: jeremy at beopen.com Comments: Hyperbole mail buttons accepted, v04.18. SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7 J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0 cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4 dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4 dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0 ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3 aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ== From jeremy at beopen.com Thu Oct 12 18:11:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net> Sorry about the previous message; a mail munger somewhere between my display and python.org choked on a very long line... I am getting an occasional, hard-to-reproduce error in test_minidom. When I run the test, it displays about a thousand lines of garbage, but the test suite does not report test_minidom as failed or skipped. The output I see during the test run is this: test_minidom garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': , 'childNodes': None, 'attributes': None, 'parentNode': None, 'data': u'Obsolete but implemented...', 'previousSibling': None}, , {'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a [... many hundreds of lines omitted] At the end of the test, I get a pretty normal result: 95 tests OK. 13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl test_imgfile test_largefile test_nis test_sunaudiodev test_timing test_winreg test_winsound So two questions: Why is test_minidom producing all this output? And why is it only happening intermittently? Why does regrtest.py think that test_minidom is working correctly when it produces all this output? Jeremy From nas at arctrix.com Thu Oct 12 11:31:34 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 02:31:34 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <20001012023134.A18254@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > I am getting an occasional, hard-to-reproduce error in test_minidom. > When I run the test, it displays about a thousand lines of garbage, > but the test suite does not report test_minidom as failed or skipped. > > The output I see during the test run is this: > > test_minidom > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': This is most likely the garbage collector. regrtest.py contains the following code: if findleaks: gc.collect() if gc.garbage: print "garbage:", repr(gc.garbage) found_garbage.extend(gc.garbage) del gc.garbage[:] findleaks is true if the -l option is specified (TESTOPS in the makefile includes it). Something is producing cyclic garbage. Neil From guido at python.org Thu Oct 12 19:39:40 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 12:39:40 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST." <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com> > On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote: > > I am getting an occasional, hard-to-reproduce error in test_minidom. > > When I run the test, it displays about a thousand lines of garbage, > > but the test suite does not report test_minidom as failed or skipped. > > > > The output I see during the test run is this: > > > > test_minidom > > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling': [Neil] > This is most likely the garbage collector. regrtest.py contains > the following code: > > if findleaks: > gc.collect() > if gc.garbage: > print "garbage:", repr(gc.garbage) > found_garbage.extend(gc.garbage) > del gc.garbage[:] > > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. Of course something is producing cyclic garbage! The DOM tree is full of parent and child links. Does this output mean that the GC works correctly? Or does it mean that there is a reason why this garbage cannot be disposed of? In the latter case, could that be because there are __del__ methods? --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Thu Oct 12 18:55:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012023134.A18254@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > This is most likely the garbage collector. regrtest.py contains > the following code: ... > findleaks is true if the -l option is specified (TESTOPS in the > makefile includes it). Something is producing cyclic garbage. This is definately the problem. Lars, Paul: This looks like a problem in the unlink() method of the DOM. Could you please check that the unlink() method is updated to handle the latest version of the other changes? Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Oct 12 18:59:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is test_minidom producing all this output? And why is it only > happening intermittently? It isn't. See Neil's excellent explanation. > Why does regrtest.py think that test_minidom is working correctly when > it produces all this output? The test is passing just fine, and is complete before the test for garbage is performed. The unlink() method on DOM objects is the culprit; it is updating the Node.allnodes dictionary correctly, but not the Node instances. I've already asked Paul & Lars to fix this; it should work just fine with or without GC once they've seen the report. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Thu Oct 12 12:24:48 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 03:24:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> Message-ID: <20001012032448.A18407@glacier.fnational.com> On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote: > Of course something is producing cyclic garbage! > > The DOM tree is full of parent and child links. > > Does this output mean that the GC works correctly? Or does it > mean that there is a reason why this garbage cannot be disposed > of? In the latter case, could that be because there are > __del__ methods? The -l option tries to find any cyclic garbage produced by the tests. I don't think that that option should be enabled default. The output means that the GC is working and is finding stuff that would not be freed by reference counting alone. I can't tell if the GC would free this garbage. The -l option sets the DEBUG_SAVEALL option which causes all garbage found to end up in gc.garbage, not just garbage the can't be cleaned up. I don't have pyexpat installed here so I can't test it. If you want to find out if test_minidom is creating garbage the collector can't free you should comment out the: gc.set_debug(gc.DEBUG_SAVEALL) line in regrtest.py and run: regrtest.py -l test_minidom If that does what I think it does and you still get the "garbage: " line then the test is creating evil things. :) Neil From hinsen at dirac.cnrs-orleans.fr Thu Oct 12 19:24:18 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Thu, 12 Oct 2000 19:24:18 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: (sdm7g@virginia.edu) References: Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr> > The idea that your calculation should blow up and you should > check it and resubmit your job sounds just so ancient-20th-century- > Fortran-JCL-and-punched-cards-technology! Long-running jobs are still with us, even there's neither Fortran nor JCL in them. And for these applications, stopping is better than going on with nonsense values. On the other hand, as you point out, exceptions for math errors are a bit of a pain for interactive work. So how about making this a run-time option? I'd choose exceptions by default and Infs and Nans by specifying a command-line option, but there are certainly others who would prefer it the other way round. What matters most to me is that the choice is possible somehow. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From sdm7g at virginia.edu Thu Oct 12 20:25:44 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr> Message-ID: On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote: > > The idea that your calculation should blow up and you should > > check it and resubmit your job sounds just so ancient-20th-century- > > Fortran-JCL-and-punched-cards-technology! > > Long-running jobs are still with us, even there's neither Fortran nor > JCL in them. And for these applications, stopping is better than going > on with nonsense values. On the other hand, as you point out, exceptions > for math errors are a bit of a pain for interactive work. > > So how about making this a run-time option? I'd choose exceptions by > default and Infs and Nans by specifying a command-line option, but > there are certainly others who would prefer it the other way round. > What matters most to me is that the choice is possible somehow. > I agree entirely! Maybe I was being a bit too glib, but I didn't mean to imply that wanting it to halt or throw an exception on errors is wrongheaded. I just wanted to make sure the counter-case to what Paul was saying also got heard: Yes-- underflows or infinities where they aren't expected are usually a sign that something is very wrong somewhere. But in the case where the vector holds independent observations or data points, then usually what it means is that there's something wrong with *that* data point -- miscallibrated or mislabeled -- but no reason not to complete the calculations for all of the other points. Scaling or doing projections for interactive graphics is another case where bad points are often better than throwing an exception. ( And it's a pain to have to remember to lambda wrap all the function calls with some sort of guard when you'ld be happy to get NaNs. ) I also mostly agree with Tim, except that I'm not sure that bad or incomplete ieee support is always better than none at all. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From thomas at xs4all.net Thu Oct 12 21:14:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 21:14:37 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700 References: <200010121711.KAA00584@slayer.i.sourceforge.net> Message-ID: <20001012211436.Z12812@xs4all.nl> On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote: [ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ] > There is one known warning at this time, caught by the -Wstrict-prototypes > option. In Modules/main.c, the declaration of getopt() without parameters > gets a complaint (rightly) that it is not a proper prototype. The lack of > a complete prototype information should be corrected when the right > portability conditions have been identified. I already looked at this before, and the problem is that the prototype for getopt is not portable (because of quirks in the ANSI C standard regarding 'compatible' pointer types.) Some systems define it as 'const char **' (or 'char const **'), some perhaps as 'char **', and some as 'char * const *'. 'const char **' and 'char const **' are the same, but 'char * const *' is something else, and so is 'char **'. 'char * const *' and 'char **' are equivalent types, meaning that conforming compilers should be able to intermix them without problems, but 'const char **' is a different type, and ANSI C either demands or strongly suggests a warning. (Why exactly it's a different type is mostly a choice of language, though I'm sure there are people who would defend the choice. What it means it that you can't mix two layers of indirection with qualifiers like 'const' or 'volatile', without paying close attention to assignment and prototypes :P) As a result, no matter what prototype we think up, we're always screwing either the one type of platform or the other. And not with a warning; the conflicting prototype would generate an error, nto a warning. The only solution I can think of is adding the proper prototype to the pyport.h header file, inside a proper #ifdef. For generated code it doesn't really matter which of the prototypes is used, but if the system headers do provide a prototype, and it doesn't match in indirect-constness, compilation will fail. (In other words, even on the platforms that are missing it, close attention should be paid to the manual pages, trying to guess what the prototype is going to look like if that particular system would ever grow a prototype in a system header. From what I read in the getopt(3) manpage on my linux box the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) Does anyone have a system where the prototype to getopt() is not defined in header files ? My Solaris 2.x testbox has that problem, but the box in question is one huge mess, and I doubt it has anything to do with Solaris in particular. I only use it to reproduce reported bugs, not report any myself ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Thu Oct 12 22:10:50 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012032448.A18407@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> The -l option tries to find any cyclic garbage produced by the NS> tests. I don't think that that option should be enabled NS> default. The output means that the GC is working and is finding NS> stuff that would not be freed by reference counting alone. NS> I can't tell if the GC would free this garbage. The -l option NS> sets the DEBUG_SAVEALL option which causes all garbage found to NS> end up in gc.garbage, not just garbage the can't be cleaned up. NS> I don't have pyexpat installed here so I can't test it. If you NS> want to find out if test_minidom is creating garbage the NS> collector can't free you should comment out the: NS> gc.set_debug(gc.DEBUG_SAVEALL) NS> line in regrtest.py and run: NS> regrtest.py -l test_minidom NS> If that does what I think it does and you still get the NS> "garbage: " line then the test is creating evil things. :) The test is not creating evil things. I commented out the DEBUG_SAVEALL line and got no error report. The question, then, is what to do about the -l option. I assume we should remove the -l option from the Makefile, so that "make test" doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in some way so that it still reports on tests that create evil things? Jeremy From nas at arctrix.com Thu Oct 12 15:20:10 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:20:10 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <20001012062010.A19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote: > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? This is a policy decision. Is it okay for the test suite to create garbage that is not collectable by reference counting? If yes, what about garbage that is not collectable by the (current) GC? Neil From guido at python.org Thu Oct 12 23:21:39 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:21:39 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400." <14822.6858.920988.167252@bitdiddle.concentric.net> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com> > The question, then, is what to do about the -l option. I assume we > should remove the -l option from the Makefile, so that "make test" > doesn't turn on DEBUG_SAVEALL. This seems to make sense, yes. Since the "leaked" objects that are found will be released by the GC code, I see no point in reporting these during the regression test. This can only confuse people (like it did Jeremy :-). > Or do we need to change regrtest in > some way so that it still reports on tests that create evil things? Any form of evilness that can be detected without *too* much effort is worth it... I have no idea what kind of evil we're looking for here or how to detect is, so I can't answer yes or no. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Thu Oct 12 22:18:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT) Subject: [Python-Dev] New development documentation up... Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com> I don't normally post when I've updated the development copy of the documentation, but there are a couple of big additions there now. Martin von L?wis contributed substantial SAX2 documentation, which I've now integrated. Thanks, Martin! Chris Barker is working on new documentation for the Macintosh manual; I've only just started to look at it, but there's definately a *lot* of new material. That's not checked into CVS yet, but will be once I've had more time to go over it. Thanks, Chris! ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Thu Oct 12 15:28:04 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:28:04 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> Message-ID: <20001012062804.B19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote: > Any form of evilness that can be detected without *too* much effort is > worth it... I have no idea what kind of evil we're looking for here > or how to detect is, so I can't answer yes or no. That would be reference cycles with finalizers (ie. instances with __del__ methods). The current garbage collector does not free such structures but instead appends them to gc.garbage. Sorry for not being clear. In any case, regrtest should probably print a more clueful message when objects are found in gc.garbage. That would go a long way in clearing up the confusion. I'll see about a patch. Neil From guido at python.org Thu Oct 12 23:26:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 16:26:49 -0500 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST." <20001012062010.A19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com> > This is a policy decision. Is it okay for the test suite to > create garbage that is not collectable by reference counting? I don't see why that should be forbidden. After all some of the code we test has such leaks -- we haven't declared those absolute bugs. > If yes, what about garbage that is not collectable by the (current) > GC? Can you give an example of how such garbage can be created? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Thu Oct 12 22:38:29 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012062804.B19026@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com> <20001012062804.B19026@glacier.fnational.com> Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> In any case, regrtest should probably print a more clueful NS> message when objects are found in gc.garbage. That would go a NS> long way in clearing up the confusion. I'll see about a patch. I think there is some value to issueing reports when a test creates trash that can't be cleaned up by the GC, but it doesn't make sense to report this by default. If "make test" reports an error, it should mean that something has gone wrong with the user's build and the interpreter is broken. That's not the case here. The build was fine; it's just the test that is iffy. I think we should turn of the -l option by default *and* patch it so that the output is more useful. I would suggest printing a count of the objects, perhaps organized by type/class name. Something like this: Test created 6 uncollectable objects 4 foo.Bar instances 2 foo.Baz instances Jeremy From tim_one at email.msn.com Thu Oct 12 22:33:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 16:33:41 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages . Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas , asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great . all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). From nas at arctrix.com Thu Oct 12 15:43:09 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 06:43:09 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> Message-ID: <20001012064309.C19026@glacier.fnational.com> On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote: > > This is a policy decision. Is it okay for the test suite to > > create garbage that is not collectable by reference counting? > > I don't see why that should be forbidden. After all some of the code > we test has such leaks -- we haven't declared those absolute bugs. Again, "-l" should probably not be a default. I don't know who added it to TESTOPTS but it wasn't me. > Can you give an example of how such garbage can be created? Look at test_gc. Here is an example: class Foo: def __del__(self): pass foo = Foo() foo.foo = foo del foo Theoretically this structure could be collected without problem but the GC is too simple minded to realize that there is only one finalizer involved. Here's a better example: foo = Foo() bar = Foo() foo.bar = bar bar.foo = foo del foo, bar The GC cannot safely break this cycle so it punts and adds the instance objects involved to gc.garbage and forgets about it. Neil From tim_one at email.msn.com Thu Oct 12 23:38:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 17:38:13 -0400 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: <20001012211436.Z12812@xs4all.nl> Message-ID: [Thomas Wouters, on getopt] > ... > From what I read in the getopt(3) manpage on my linux box the > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) I bet it's actually talking about Interpretation 150 to POSIX.2, here (while you can't read the std online, you can read the complaints online!): http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. html Doesn't have anything to do with the prototype, alas. > Does anyone have a system where the prototype to getopt() is not > defined in header files ? My Solaris 2.x testbox has that problem, but > the box in question is one huge mess, and I doubt it has anything to do > with Solaris in particular. ... Sure: Windows doesn't have a getopt; getopt isn't std C (not even in C99). Assorted derived stds demand that a getopt protoptype appear in stdlib.h, and others that it appear in unistd.h. I have a different suggestion: screw it. getopt keeps creating problems on GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU getopt shuffles all the "option strings" to the front, making a mess of, e.g., python myprog.py -v The Python source tree already has its own getopt implementation (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we like, and have Python use that instead on all systems. Every second we've spent tracking down problems with platform-supplied getopts has been a waste of time. they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- ly y'rs - tim From jack at oratrix.nl Fri Oct 13 00:03:57 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 13 Oct 2000 00:03:57 +0200 Subject: [Python-Dev] MacPython 2.0c1 available Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl> MacPython 2.0c1 is available, both as binary installer and in source form. You can find it through http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive please let me know whether it works, and, in the unlikely event it doesn't:-) what the problems are. Thanks, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From guido at python.org Fri Oct 13 01:07:28 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 12 Oct 2000 18:07:28 -0500 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400." References: Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com> > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of, > e.g., > > python myprog.py -v > > The Python source tree already has its own getopt implementation > (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get > rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we > like, and have Python use that instead on all systems. Every second we've > spent tracking down problems with platform-supplied getopts has been a waste > of time. Excellent. After 2.0. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Fri Oct 13 00:18:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 00:18:01 +0200 Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other] In-Reply-To: ; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400 References: <20001012211436.Z12812@xs4all.nl> Message-ID: <20001013001801.A12812@xs4all.nl> On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote: > [Thomas Wouters, on getopt] > > ... > > From what I read in the getopt(3) manpage on my linux box the > > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) > > I bet it's actually talking about Interpretation 150 to POSIX.2, here (while > you can't read the std online, you can read the complaints online!): > http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150. > html > Doesn't have anything to do with the prototype, alas. Ah, that sounds about right. Nifty link, too. I thought it had something to do with the prototype because of this comment: CONFORMING TO getopt(): POSIX.2, provided the environment variable POSIXLY_CORRECT is set. Otherwise, the elements of argv aren't really const, because we permute them. We pretend they're const in the prototype to be compatible with other systems. > I have a different suggestion: screw it. getopt keeps creating problems on > GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU > getopt shuffles all the "option strings" to the front, making a mess of [ a lot of things ] Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when necessary. Funny, I've seen that file a number of times, and read it, and read the getopt autoconf test as well, but somehow I never connected it with the loose prototype in main.c. I'm +1 on doing what you suggested, then. Wonder why it hasn't been done yet, though... we have no use for a system-wide getopt, except for a slightly smaller binary on systems that do have a 'good' system getopt. We can't use enhancements made to system getopt or anything, anyway. > they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- > ly y'rs - tim what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules- ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From m.favas at per.dem.csiro.au Fri Oct 13 02:47:25 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 13 Oct 2000 08:47:25 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au> Just a little unreality check - the whole world is not (yet) Linux - or even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour of 2.0 - OverflowError: math range error. Thus, on these platform, the proposed fixes _will_ change behaviour. But that's cool - I like Tim's proposed, um, steps to "rationalizing" fp behaviour, and will do what I can to help in the future. -- Email - m.favas at per.dem.csiro.au CSIRO Exploration & Mining From tim_one at email.msn.com Fri Oct 13 07:15:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:15:13 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au> Message-ID: [Mark Favas] > Just a little unreality check - the whole world is not (yet) Linux - or > even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on > Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour > of 2.0 - OverflowError: math range error. This is unfortunate. Guido never intended for Python to raise exceptions on underflow (and especially not *Over*flowError(!)), but he apparently didn't run on any platforms where this happened (I never have!), and AFAIK nobody ever mentioned this before. > Thus, on these platform, the proposed fixes _will_ change behaviour. See "unfortunate" above <0.5 wink>. > But that's cool - I like Tim's proposed, um, steps to "rationalizing" > fp behaviour, and will do what I can to help in the future. Want to fund a crack group of 754 experts for a year? Didn't think so. Constructive complaints will help a lot. So will beta testing. For example, I'm very keen to know whether the current CVS version of Python (2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or Tru64 Unix boxes. Running the (current CVS) std test suite will tell you: test_libm will pass or fail accordingly. If it's still busted on one of your systems, we've only got about a day to fix it (2.0 final is shipping early next week, and we have to let the codebase settle down for a couple days before building the final release). but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not- losing-much-sleep-over-it-ly y'rs - tim From tim_one at email.msn.com Fri Oct 13 07:18:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 01:18:52 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim hallucinated ...] > ... I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. Sorry for contradicting myself within a single sentence: I couldn't care less what happens in 2.0c1 anymore. Like I clearly said at the start, "current CVS version" is the question. From bwarsaw at beopen.com Fri Oct 13 07:33:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> Message-ID: <14822.40645.656159.493390@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> Again, "-l" should probably not be a default. I don't know NS> who added it to TESTOPTS but it wasn't me. I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I think (but don't really remember) that LEAK_DEBUG had different semantics than it does now. No matter. This was useful when gc was spankin' new and only semi-tested. It's probably fine to turn off -l in "make test" by default for the 2.0 release. -Barry From tim_one at email.msn.com Fri Oct 13 10:01:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 04:01:16 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Tim] > ... > We cannot consider this to be a bug since Python has had no *intended* > behavior whatsoever wrt 754 gimmicks. We can and do consider gripes > about these accidents to be feature requests. [Huaiyu Zhu] > Yes it varies widely in Python. But isn't that precisely because Python > does not support IEEE? Yes, but that's darned near tautological <0.5 wink>. > If Python does not actively undermine IEEE on platforms that have it, > would it still vary widely across these platforms? Yes. Your own -lieee example showed that math.sqrt(-1) computes not only a non-754 result, but a senseless result, on your platform under 1.5.2. If I show you a platform, how are you going to decide whether it "has" IEEE? 754 is a very involved std, and it's still rare to find a platform C that supports it correctly. On platform C's that do support it correctly, I know of none that do so without requiring platform-specific tricks. Python has *nothing* portable it can rely on, and its mass of utterly non-754-aware code building on haphazard C implementations adds up to the random x-platform crap we have today. ... [T] > The patch to stop setting -lieee was contributed by a Python user who > claimed it fixed bugs on *their* platform. That's "the reason". > We don't want to screw them either. [H] > Q: What bug? Which platform? Maybe there is another way that has less > impact on others? How to find out? I didn't check it in, and you can search the CVS archives as easily as I can (I'm not inclined to, since I don't think it can affect the outcome of this). Jeremy Hylton may, or may not, remember more about it (IIRC, he said he checked it in). > ... > If there is a way to fix the bug on that other platform while still keep > -lieee on Linux, would that be acceptable? No: Guido *wants* overflow to raise OverflowError by default, and *wants* sqrt(-1.0) to raise ValueError by default. Python's x-platform fp numerics today are an utter mess, and the best we can do for 2.0 is to make them as consistent as we have time to make them, despite that we know it will break some of your code (but you can still link with -lieee if you feel you must), and that Mark Favas has confirmed it will break code under both his Solaris and Tru64 Unix systems (but for a reason opposite of yours: he's been getting OverflowError on underflow since 1.5.2, and we're taking that away from him, and he'll have *no* way to go back). At this point we favor forcing consistency over maintaining platform accidents, no matter how attached people have gotten to them; else we'll be stuck with them forever. [oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/] > Interesting! I've glanced through some of Prof Kahan's writings. He is an entertaining writer, although his rhetoric is often more extreme than either of ours . > It appears that he favors raising flags that can be checked optionally, and > he is against mandatary raising exceptions. Have you read the 754 std? He's in favor of the 754 std. [quotes snipped, except for my favorite, which I've paraphrased many times over the years on c.l.py] > ... > They are called "Exceptions" because to any policy for handling them, > imposed in advance upon all programmers by the computer system, some > programmers will have good reason to take exception. > ... > From these quotes and others I understand that he wants f.p. exceptions to > be merely messanges, not errors that force programmers to take extra > actions, unless the programmer choose to. So what aspect of Java did he > think is deficient? It is the "Trap" style exception that mandate a users > action. His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5 main gripes about Java in bullet points at the top of page 3. The paper runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink>, reducing it to a bogus claim about Java that Kahan didn't make (Java has neither "Trap" nor "Flag" style fp exception signaling). > He told "A cautionary Tale of the Ariane 5", Which has nothing to do with Java -- the software in question was written in Ada, which (unlike Java) has "Trap" style. Why he put it in a paper about Java is a bit of a mystery; I write it off to rhetorical excess. > the European rocket that mulfunctioned after lift off. It turned out > that a piece of software produced an unimportant exception that is > not caught by a handler and caused debugging data to be dumped to a > critical memory location. This would have been avoided if the exception > merely raised a flag and returned a NaN, and the program continued. Actually, that was impossible to do, and he didn't suggest that. What he wrote is Had overflow merely obeyed the IEEE 754 default policy, the recalibration software would have raised a flag and delivered an invalid result both to be ignored by the motor guidance programs, and the Ariane 5 would have pursued its intended trajectory. Note that he didn't say NaN. He couldn't, because this was overflow in a conversion from Float to Integer. Despite his cheery optimism here, 754 is approximately useless in this case, since there is no generally accepted "invalid result" in integer formats (and 754 doesn't define one either -- the result of overflow in converting floats to ints is ill-defined in 754; 754 doesn't even require that it set the overflow flag). > So do we want every Python program to bomb whenever there is a floating > point value outside bound and is not trapped by try/except? By default, yes, Guido does, but for overflow, not underflow. If you read the following section of Kahan's paper, you should have noticed that he is *just* as critical of just returning Infs and NaNs (which is all Java does, and which is the accidental Python behavior you're arguing we keep in glibc) as he is of just trapping! His conclusion: "Without Traps nor Flags, Java? s floating-point is Dangerous": Without flags, detecting rare creations of Inf and NaN before they disappear requires programmed tests and branches that, besides duplicating tests already performed by the hardware, slow down the program and impel a programmer to make decisions prematurely in many cases. Worse, a plethora of tests and branches undermines a program?s modularity, clarity and concurrency. I agree with him there wholeheartedly: without the 754-mandated flags, *and* without raising exceptions, the subset of 754 remaining sucks. >> ironically, 754 is hardest to sell to those who could benefit from >> it the most. > So far the only concern from number-crunchers voiced here is that it might > allow sqrt(-1)==0, which is not the case. Gimme a break! In the very msg Paul Dubois said that, he also said "Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened.". I'm starting to drop my assumption of good faith on your part: what you remember and how you paraphrase (whether it's Paul or Kahan) is extremely selective, beyond normal bounds of zeal-inspired distortion. > I was a fortran programmer before. I switched to using IEEE ten years > ago as soon as it was available on the machine I was using. So there > are different opinions. Certainly, and good 754 support will cater to most of them. I don't believe your opinion (or mine, for that matter) reflects anything even close to the majority view here, though. As I said in my reply to Paul, my observations (based on 15 years on the vendor side of the fp biz) matched his exactly (based on his experience with hundreds of numeric code authors): a vast majority still want divide-by-0, invalid operation, and overflow to raise an exception the vast majority of the time. > ... > Obviously we agree on the benefit of having a choice. But we > have different perspective on what choice means. Your want a choice > to force user to take explicit action, I want a choice to ignore these > events. No. I want exactly the choices 754 lays out: user-settable sticky flags and user-maskable exceptions. We're not getting that for 2.0. And we're *never* getting it if 2.0 doesn't do *something* to start disabusing people of the notion that their historical numeric platform accidents in Python will be faithfully preserved forever more. > The ideal solution might be to have a sys.fp_exception class. Each > exception would set a flag like fp_exception.overflow so that user can > check them. There could also be a variable like fp_exception.force_trap, > which when set, could make each f.p. exception to produce a Python > exception. This would confirm to IEEE 754 and give both of us a choice > we want. Kinda, except that each of the 5 754-defined traps must be individually maskable. 754 spells out what's needed. A PEP will be required to spell out the Python- and C-level APIs. I've corresponded (just -- no time now) a little with Kevin Jacobs about that offline. > Now that we are in feature freeze for 2.0, we can't get both choices. > Can we adopt the one that does not break behaviors on previous official > release, even if that's only by accident? Not as far as Guido or I are concerned, no. You can link with -lieee yourself if you must, although I can't recommend perpetuating the x-platform confusion here. We want to say that, e.g., math.exp works substantially the same way on *all* platforms under 2.0, not repeat the same decade-old "umm, don't know, and no way to guess -- try it on your platform and see what it does" yet again. I don't expect 2.0 will actually achieve that on all platforms, but it should on the primary ones. > ... > So now I know why people reported that NaN and Inf were broken on HPUX > and Windows and some others. If Python had simply ignored the flags ... Then we would have broken 754 subsets in slightly subtler ways, and still wildly varying across platforms. > ... > Could you please point a URL to "presubstitution"? In the paragraphs I > quoted the only mention of presubstitute is with NaNs and Inf, etc. Sorry, I don't save URLs, and don't recall whether this was in a paper or on David Hough's "Numeric Interest" mailing list in the early 90's. A Google search on "presubstitution Kahan" turns up 4 promising-looking hits I'll leave you to pursue. The basic idea is that the programmer gets to specify, via library calls (whatever), which particular fp value each 754 exceptional case returns. So, e.g., if it made sense for some part of the app, the programmer could say they wanted +- pi returned instead +- Inf, if and whenever overflow happened. Then set it back to +- Inf (or anything else they needed) later. This would be best if supported in HW directly, of course. > ... > You are not confirming to 754 until you allow all the exceptions to go > through with well defined values as default. I know that, but don't care. As I said, enabling overflow + invalid + div0 by default is the only scheme that can be *sold*. If you can find two NumPy users in favor of disabling them all by default, I'll be mildly astonished. 754 did itself enormous harm by insisting on that trivial point (it's trivial because, with proper support, anyone can change the defaults to anything they like with one line of code): I worked in the supercomputer biz at the time 754 was adopted, and for a decade after, and the "non stop" defaults were *universally* opposed by customers. Scared the hell out of language stds committees too, which goes a lot farther than the 754 folks would like to admit toward explaining why language committees stayed away from 754 bindings in droves. C99 is 15 years(!) after the fact. > Raising Python exceptions on some of them does not confirm to 754, as > the default IEEE 754 behavior on f.p. exception is not a Python exception, > but just a raised flag. See above. > Before that happens, what is the motive to make IEEE less usable for those > who have it (pretty much every one nowadays), even if just by accident? I think I've repeated the reasons to death already, and you've repeated to death that you'll never agree. So no more from me on that. > ... > But just to clarify some wordings you quoted in another post: I meant that > sqrt(-1)==0 is insane, whether silent or not. I agree. > Raising an exception is sane, Not according to 754's default rules, which you wanted me to take as sacred just a few paragraphs ago . > although OverflowError is not so reasonable. I'd say it's insane. > Raising a ValueError is reasonable. I expect we'll have to make InvalidOperationError a subclass of ValueError for that reason, when 754 support materializes. > But just returning NaN without a fuss is even better. You're going to find that's a very lonely position. > My favorite is returning 1j, as MatPy does. Then you should use cmath.sqrt instead of math.sqrt. Even $3 business calculators have a sqrt key these days, and you do not want to be on the other end of email when trying to explain to a businessperson why their crappy std deviation program returned a complex number <0.1 wink>. > if-it-ain't-broke-don't-fix-it-ly y'rs it-it-weren't-broke-we-wouldn't-ly y'rs - tim From fgranger at altern.org Fri Oct 13 12:08:23 2000 From: fgranger at altern.org (Francois Granger) Date: Fri, 13 Oct 2000 12:08:23 +0200 Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl> Message-ID: on 13/10/00 0:03, Jack Jansen at jack at oratrix.nl wrote: > MacPython 2.0c1 is available, both as binary installer and in source > form. You can find it through > http://www.cwi.nl/~jac/macpython.html. This one works better. http://www.cwi.nl/~jack/macpython.html -- Fran?ois Granger fgranger at altern.org From nas at arctrix.com Fri Oct 13 08:37:17 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 12 Oct 2000 23:37:17 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400 References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> Message-ID: <20001012233717.A20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote: > I think (but don't really remember) that LEAK_DEBUG had > different semantics than it does now. Nope. LEAK_DEBUG prints to stderr information about all garbage the GC finds, even stuff the GC can free. The thinking was that GC would be an option and people would want to find applications that leak when only using reference counting. > No matter. This was useful when gc was spankin' new and only > semi-tested. It's probably fine to turn off -l in "make test" by > default for the 2.0 release. I've left -l enabled for now. Detecting tests that create uncollectable garbage is probably a good thing. It doesn't cost much and the message should be fairly clear now. Neil From fdrake at beopen.com Fri Oct 13 15:34:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001012233717.A20054@glacier.fnational.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I've left -l enabled for now. Detecting tests that create > uncollectable garbage is probably a good thing. It doesn't cost > much and the message should be fairly clear now. Perhaps one thing that could be done is to reduce the volume of the output; perhaps just list the first 1K or 2K of the repr? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nas at arctrix.com Fri Oct 13 09:09:48 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 00:09:48 -0700 Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400 References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> Message-ID: <20001013000948.C20054@glacier.fnational.com> On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote: > Perhaps one thing that could be done is to reduce the volume of the > output; perhaps just list the first 1K or 2K of the repr? It just prints the number of object found now. Neil From fdrake at beopen.com Fri Oct 13 16:06:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT) Subject: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <20001013000948.C20054@glacier.fnational.com> References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com> <20001013000948.C20054@glacier.fnational.com> Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > It just prints the number of object found now. Ok, I must have missed the checkin that changed that. This is fine in my book as well. Thanks for staying on top of this work! I think you've really done a great job with the GC effort. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Fri Oct 13 17:18:23 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach I tried sending a message with the output of ./configure and make attached, but it was over the 40K limit. If anybody wants to see these, email me. From nas at arctrix.com Fri Oct 13 10:28:49 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Fri, 13 Oct 2000 01:28:49 -0700 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013012849.C20168@glacier.fnational.com> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Unresolved: > __pthread_mutex_init [...] What is the LIBS variable set to in Modules/Makefile? It looks your missing something like "-lpthread". Neil From cgw at fnal.gov Fri Oct 13 17:35:52 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013012849.C20168@glacier.fnational.com> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013012849.C20168@glacier.fnational.com> Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov> Neil Schemenauer writes: > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > > Unresolved: > > __pthread_mutex_init > [...] > > What is the LIBS variable set to in Modules/Makefile? It looks > your missing something like "-lpthread". Hehehe. I might be kinda thick sometimes, but I think I would have caught that. Here's a little more of the "make" output: cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. From thomas at xs4all.net Fri Oct 13 18:34:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 18:34:36 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> Message-ID: <20001013183436.B12812@xs4all.nl> On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote: > Sorry, I don't have time to investigate this fully right now. Maybe > this weekend. For now this is just a heads-up. Hopefully, something > is just misconfigured on this system. > The machine in question is running OSF1 V4.0 878 alpha That's a former DEC alpha, right ? Perhaps running configure with '--with-dec-threads' will solve the problem ? I'm not sure if that will work alone, so you might need '--with-dec-threads --with-threads=no' to disable 'normal' thread-checking. You can also try this by hand; after running configure, edit Modules/Makefile.pre, and change LDLAST= into LDLAST= -threads (not -lthreads, just -threads) That seems to be the only difference --with-dec-threads uses. I looked at this before, but don't have an alpha or anything else that needs --with-dec-threads, so I couldn't detect this automatically. I do think it should be done automatically, though. Perhaps I can figure it if you can send me, for instance, config.log and the output of configure, and find the time to run a few tests later. > I can only build Python from current CVS sources on OSF/1 if I specify > --without-thread. If I don't specify this I get the following errors > at link time: > Unresolved: > __pthread_mutex_init > I tried sending a message with the output of ./configure and make > attached, but it was over the 40K limit. If anybody wants to see > these, email me. If the above doesn't fix it, I can take a look at the output of configure and config.log. No need to see the output of make just yet. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From cgw at fnal.gov Fri Oct 13 20:31:34 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013183436.B12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov> Thomas Wouters writes: > > That's a former DEC alpha, right ? Perhaps running configure with > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > alone, so you might need '--with-dec-threads --with-threads=no' to disable > 'normal' thread-checking. Thank you, that indeed solves the problem. Sorry for the noise. It would be nice if configure were smart enough to figure this out! From cgw at fnal.gov Fri Oct 13 20:38:26 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <200010131453.JAA23050@buffalo.fnal.gov> Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov> Tim Peters wrote: > I'm very keen to know whether the current CVS version of Python > (2.0c1) still raises OverflowError for math.exp(-746) on your > Solaris and/or Tru64 Unix boxes. I just repeated this test, on the following 4 platforms: 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 2) OSF1 V4.0 878 alpha DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) 3) IRIX64 6.5 07151432 IP27 MIPSpro Compilers: Version 7.2.1 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 gcc version 2.95.2 19991024 (release) On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) raises an exception, and test_math.py completes successfully. Testing-ly (not to be confused with testily) yr's, cgw From tim_one at email.msn.com Fri Oct 13 20:56:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 14:56:43 -0400 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: [Charles G Waldman] > I just repeated this test, on the following 4 platforms: > > 1) SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise > cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2 > > 2) OSF1 V4.0 878 alpha > DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) > > 3) IRIX64 6.5 07151432 IP27 > MIPSpro Compilers: Version 7.2.1 > > 4) Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686 > gcc version 2.95.2 19991024 (release) > > On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1) > raises an exception, and test_math.py completes successfully. Excellent! Note that test_math.py was augmented to verify that: 1. exp(-huge) returns 0 without exception. 2. exp(+huge) raises OverflowError. 3. sqrt(-1) raises ValueError. None of those were reliable across platforms before, and I'm afraid there's strong reason to suspect one or more still won't work right under Mandrake Linux when Python is compiled with -O (this based on the output of a C program someone posted to c.l.py yesterday). But it's a world better than it used to be. > Testing-ly (not to be confused with testily) yr's, You bet -- everyone leave testily to me on this one. I'm bitter enough about floating-point in stinking C for everyone combined <0.9 wink>. From thomas at xs4all.net Fri Oct 13 21:19:38 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 13 Oct 2000 21:19:38 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> Message-ID: <20001013211938.C12812@xs4all.nl> On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > > > That's a former DEC alpha, right ? Perhaps running configure with > > '--with-dec-threads' will solve the problem ? I'm not sure if that will work > > alone, so you might need '--with-dec-threads --with-threads=no' to disable > > 'normal' thread-checking. > Thank you, that indeed solves the problem. Sorry for the noise. No problem. When I went over the README file a few weeks back, and sent Guido an update, this particular issue was one of the biggest problems for me: the old README, which assumed threads were not default, was quite adamant about using --with-dec-threads for OSF/1 and its incarnations. Unfortunately, it doesn't say why :) And the configure script only says that it's necessary to get threadsafe libraries. > It would be nice if configure were smart enough to figure this out! Configure is as smart as we make it. configure is made by autoconf, which is moderately intelligent, and we just have to add the extra geniality to configure.in. If the only check we need is 'does this system call itself OSF1', we can easily add that. See the attached patch (configure.in version only. Let me know if you need a patched configure as well, I don't know if OSF systems come with autoconf. It's pretty large, though, and you don't need to generate configure on the same system as you run it on. Just apply the configure.in patch, type 'autoconf', and copy the resulting configure script to your OSF1 machine.) The question is, is this enough ? Will this detect all the OSF platforms that need '-threads', and will it only add it to those platforms ? It wouldn't be particularly nice of configure if it insisted on adding '-threads' on platforms that don't need it, or worse, break because of it. For instance, the patch uses 'OSF*', which might be too generic... but 'OSF1' might be too restrictive :-) A better fix would probably be to write a test program that explicitly uses threads & the -threads arguments, but that could fail for a large number of reasons, which doesn't mean -threads isn't needed :P (Configure is really amusing like that. For instance, if your compile system is broken, like when you unpacked a new linux kernel source tree in /usr/src/linux, but forgot to type 'make symlinks', configure will assume the worst (every check is negative, after all.) If you're lucky, it will complain because you miss an essential feature... If you're unlucky, it finishes cleanly, writes the config.cache file, your compile fails, you figure out the problem, and you keep compiling using the wrong autoconf 'settings'. And re-configuring doesn't fix it, because the config.cache file is just fine ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.172 diff -c -r1.172 configure.in *** configure.in 2000/10/12 17:11:38 1.172 --- configure.in 2000/10/13 19:15:11 *************** *** 805,810 **** --- 805,819 ---- LIBS="$LIBS -lthread" LIBOBJS="$LIBOBJS thread.o" USE_THREAD_MODULE=""]) + + if test "$USE_THREAD_MODULE" != "#" + then + # If the above checks didn't disable threads, (at least) OSF1 + # needs this '-threads' argument during linking. + case $ac_sys_system in + OSF*) LDLAST=-threads;; + esac + fi fi # Check for GC support From skip at mojam.com Fri Oct 13 21:39:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: <14823.22178.605732.455689@buffalo.fnal.gov> Message-ID: <14823.25854.786347.542654@beluga.mojam.com> Tim> None of those were reliable across platforms before, and I'm afraid Tim> there's strong reason to suspect one or more still won't work right Tim> under Mandrake Linux when Python is compiled with -O (this based on Tim> the output of a C program someone posted to c.l.py yesterday). But Tim> it's a world better than it used to be. After executing cvs update -d . ./configure make clean make OPT=-O3 I get the following output from regrtest.py regarding test_math: % ./python Lib/test/regrtest.py test_math test_math 1 test OK. This is on a Mandrake 7.1 system. Here are the bits I think are relevant to identify my environment: % cat /etc/issue.net Linux Mandrake release 7.1 (helium) Kernel 2.2.16-9mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -q -a | egrep glibc glibc-devel-2.1.3-15mdk compat-glibc-5.3-2.0.7.6mdk glibc-2.1.3-15mdk If you have a C test program you'd like me to try, shoot it over. I'll be glad to run it and shoot back the results. Skip From fdrake at beopen.com Fri Oct 13 21:41:46 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: The test passes for me as well on Mandrake 7.1. Here's the environment info: % ./python -tt ../Lib/test/regrtest.py test_math test_math 1 test OK. % cat /etc/issue.net Welcome to %h Linux Mandrake release 7.1 (helium) Kernel 2.2.15-4mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -qa | egrep glibc nedit-5.1.1-1.glibc glibc-profile-2.1.3-5mdk glibc-2.1.3-5mdk compat-glibc-5.3-2.0.7.6mdk glibc-devel-2.1.3-5mdk > If you have a C test program you'd like me to try, shoot it over. I'll be > glad to run it and shoot back the results. Same here... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Fri Oct 13 21:52:44 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov> Skip Montanaro writes: > This is on a Mandrake 7.1 system. Here are the bits I think are relevant to > identify my environment: > % gcc -v > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs > gcc version 2.95.3 19991030 (prerelease) AFAIK, this version of GCC was never "blessed" by the GCC maintainers and should not be being used for any production work. I think Mandrake did a bad thing by shipping this version. Not quite as bad as what RedHat did by shipping the completely not-for-general-use gcc-2.96, but nonetheless still a bad thing. When will distribution builders learn that having a higher version number is not necessarily a good thing? Why do they keep second-guessing the good advice of the GCC Steering Committee? Sigh... In any case, I don't think we should put effort into chasing down bugs that are caused by bogus C compilers. Any reports coming in from RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. From fdrake at beopen.com Fri Oct 13 21:58:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT) Subject: [Python-Dev] gcc versions (was:RE: Possible bug (was Re: some other junk, ...)) In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov> References: <14823.22178.605732.455689@buffalo.fnal.gov> <14823.25854.786347.542654@beluga.mojam.com> <14823.26636.59174.832572@buffalo.fnal.gov> Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com> Charles G Waldman writes: > AFAIK, this version of GCC was never "blessed" by the GCC maintainers > and should not be being used for any production work. I think > Mandrake did a bad thing by shipping this version. Not quite as bad I agree. > In any case, I don't think we should put effort into chasing down bugs > that are caused by bogus C compilers. Any reports coming in from > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light. I think Skip & I were showing that there isn't a bug for Mandrake 7.1. I don't know what version of GCC shipped with Mandrake 7.0, which may have been the version Tim received the report for (I recall he said "Mandrake 7", which isn't specific). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From larsga at garshol.priv.no Fri Oct 13 22:08:05 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 13 Oct 2000 22:08:05 +0200 Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com> Message-ID: * Fred L. Drake, Jr. | | This looks like a problem in the unlink() method of the DOM. Could | you please check that the unlink() method is updated to handle the | latest version of the other changes? It seems that the current unlink() does not remove sibling cycles. Patch #101897 adds a line to set sibling references to None, which seems to make regrtest.py -l happy. --Lars M. From prescod at prescod.net Fri Oct 13 22:12:38 2000 From: prescod at prescod.net (Paul) Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT) Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2) In-Reply-To: Message-ID: Right, I just checked in the fix to that. Paul Prescod On 13 Oct 2000, Lars Marius Garshol wrote: > > * Fred L. Drake, Jr. > | > | This looks like a problem in the unlink() method of the DOM. Could > | you please check that the unlink() method is updated to handle the > | latest version of the other changes? > > It seems that the current unlink() does not remove sibling cycles. > Patch #101897 adds a line to set sibling references to None, which > seems to make regrtest.py -l happy. > > --Lars M. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From tim_one at email.msn.com Fri Oct 13 22:23:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 13 Oct 2000 16:23:31 -0400 Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com> Message-ID: The original source of my concern was this c.l.py post from David Cooke: http://www.deja.com/getdoc.xp?AN=680840594 He ran a little C program that Huaiyu Zhu had posted earlier in the thread. According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ... without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt *never* set errno, regardless of input. In which case what Python does with the platform NaN result from math.sqrt(-1.) is an accident (and probably ends up setting errno to ERANGE itself by mistake), and an overflowing exp would let the platform +Inf result pass thru silently. So, if David's report is correct, and best I understand it you were all using 7.1 too with at least some level of optimization, it's A Mystery why CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would probably fail; its new math.exp(+huge) test would almost certainly fail). I'm anal enough about this stuff that I'd try to figure out why if I had a Mandrake system, but in the cosmic scheme of things I doubt it's important enough for anyone else to burn time on. From jeremy at beopen.com Sat Oct 14 01:05:02 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT) Subject: [Python-Dev] build problems large and small on FreeBSD Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net> I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE FreeBSD). There are a number of compiler warnings, all having to do with redefinitions, plus some linker warnings and a test failure. I don't have time to investigate further, but thought I'd let people know in case someone else has time to take a look. test_math failed -- overflowing exp() didn't trigger OverflowError Python 2.0c1 (#2, Oct 13 2000, 15:50:26) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.exp(1200) Inf The warnings from the linker seem harmless enough. I don't know why it is complaining about setkey and des_setkey. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() The compiler-time warnings look like they are caused by a configure problem. If so, I don't know how to fix it :-). gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c In file included from /usr/include/unistd.h:42, from ../../Python/thread.c:28: /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined ../config.h:136: warning: this is the location of the previous definition In file included from ../../Python/thread.c:118: ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined /usr/include/pthread.h:158: warning: this is the location of the previous definition ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined /usr/include/pthread.h:157: warning: this is the location of the previous definition ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined /usr/include/pthread.h:156: warning: this is the location of the previous definition Jeremy From jeremy at beopen.com Sat Oct 14 01:11:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT) Subject: [Python-Dev] warnings --with-pydebug Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net> If you configure using '--with-pydebug' you get a lot of compile-time warnings. ../../Python/ceval.c: In function `eval_code2': ../../Python/ceval.c:672: warning: value computed is not used ../../Python/ceval.c:675: warning: value computed is not used ../../Python/ceval.c:678: warning: value computed is not used ../../Python/ceval.c:680: warning: value computed is not used ../../Python/ceval.c:681: warning: value computed is not used [etc.] I assume these are caused by the definition of Py_INCREF #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) Is there some way to change this macro so that the warnings are silenced? Jeremy From thomas at xs4all.net Sat Oct 14 01:28:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:28:19 +0200 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400 References: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <20001014012819.D12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote: > The warnings from the linker seem harmless enough. I don't know why > it is complaining about setkey and des_setkey. That's probably due to 'crypt()' being used, or some other library call that Python uses indirectly. If you want crypt(), you need to install a seperate DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all crypt purposes by default, because of the US Counter-Espionage Protection Plan or something :) If you don't want to install those, don't enable the crypt module. There are a couple of pure python crypt() implementations around, by the way, which always use pure DES crypt(). > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. This one is weirdish. I don't see any gets() call in Python, so I have to assume it's in some library or header file Python includes. A good candidate would be readline, which has appalled me before :) but who knows :P I'm inclined to think it isn't a library that comes with FreeBSD by default, since they are usually pretty picky about such things. (especially if it generates a linker warning each time it's used!) > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Yes, I've seen this before. Debian-unstable (I think ?) complains about tmpnam() and tempnam() as well. The manpages just say 'don't use this function, use mkstemp(3)'. It doesn't mention a reason, but it's probably because the files/directories created by these functions are predictable, which means you shouldn't use them for security-by-obscurity. The mktemp() warning doesn't come from Python, looks like. Probably another library that is included. If you really care about which it is, you'll have to comment them out one by one (I'd suggest starting with the oldest and least FreeBSDish one, i.e. readline :) but I don't think it's going to really matter. Python does use 'tempnam' and 'tmpnam', but only in the posixmodule, to provide Python versions. I'm not sure if we can just change these functions to use mkstemp (or tempfile, see below) internally, without breaking code, though I expect it'll be alright. What's more, these functions are new since 1.5.2. And also, I just noticed a bug/typo in the tempnam docstring. The one funny bit, though, is that these three functions point to mkstemp(), and the mkstemp() manpage reads this: Don't use this function, use tmpfile(3) instead. It's better defined and more portable. "When does the hurting stop ?" > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. And this falls in the 'it wasn't us' category again. > The compiler-time warnings look like they are caused by a configure > problem. If so, I don't know how to fix it :-). > gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c > In file included from /usr/include/unistd.h:42, > from ../../Python/thread.c:28: > /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined > ../config.h:136: warning: this is the location of the previous definition Hm, yes. This looks like an unfortunate clash between a Python internal #define and a FreeBSD libc internal #define. I'm not sure if this is really the case, maybe the Python one serves exactly the same purpose as the FreeBSD one, but in that case, configure shouldn't redefine it. We can either rename the #define in Python, as it's only used to determine which thread functionality is available, or adjust the configure tests to see if it is #defined and not redefine it if so. (Or rather, to be sure that it defines the right thing, configure would have to test for posix threads, check the #define (if any), and if they don't match up, scream its head off. So perhaps renaming is the smarter thing.) On the other hand, the fact that you only got a warning, and not an error, means that Python isn't defining it to a different value than FreeBSD did, so it's not really a problem. It might be a problem if Python #defines it, but FreeBSD does not, but FreeBSD does have code that checks that #define, and starts doing weird things... > In file included from ../../Python/thread.c:118: > ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined > /usr/include/pthread.h:158: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined > /usr/include/pthread.h:157: warning: this is the location of the previous definition > ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined > /usr/include/pthread.h:156: warning: this is the location of the previous definition Not sure about these, because I don't know enough about the various types of posix thread standards, and almost-posix thread almost-standards. I'm not sure if those names are reserved in any way, but they are apparently clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code that does the defines like Python does, too. A simple '#undef' or '#ifndef' would suffice, here, I think, but I'm not sure. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sat Oct 14 01:33:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 01:33:59 +0200 Subject: [Python-Dev] warnings --with-pydebug In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400 References: <14823.38542.908547.275077@bitdiddle.concentric.net> Message-ID: <20001014013359.E12812@xs4all.nl> On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote: > If you configure using '--with-pydebug' you get a lot of compile-time > warnings. > ../../Python/ceval.c: In function `eval_code2': > ../../Python/ceval.c:672: warning: value computed is not used > ../../Python/ceval.c:675: warning: value computed is not used > ../../Python/ceval.c:678: warning: value computed is not used > ../../Python/ceval.c:680: warning: value computed is not used > ../../Python/ceval.c:681: warning: value computed is not used > [etc.] > I assume these are caused by the definition of Py_INCREF > #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++) > Is there some way to change this macro so that the warnings are > silenced? Yes, prefix it with '(void)': #define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++) However, that means that the 'return value' of Py_INCREF() must never be used anywhere. (If it does, it'll generate an error.) The return value of Py_INCREF() is not terribly useful, though. Both in debug and in normal mode, it expands to the refcount of the object *before* it was INCREF'd. I still consider this kind of warning (I've seen it before, always with macros that do several things by using the otherwise fairly useless tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements have sideeffects, and it's obvious we want to throw away the first result, so why worry about the second ? But at least it isn't screwing up floating-point operations, and nobody's perfect :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From huaiyu_zhu at yahoo.com Sat Oct 14 02:25:49 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT) Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: Tim, Thank you for the explanations. We actually agree more than it appears: - Full IEEE 754 support in Python is good, which should allow the user to decide when to use raised flags and when to use Python exceptions. - If the user default can be changed with one line of code, it does not matter if Python default use exceptions, even if that's not strict compliance in words. The "factory default" might as well set for the benefit of newbies. - Without IEEE 754 support, or with just partial support, f.p. computation is a mess. Following are some contentious issues: I am not so sure that even with 754, there would still be a great variety. I see you giving one example: sqrt(-1) in 1.5.2. But wasn't that caused by extra Python checking? I say this because errno==0 in C. Maybe I'm missing something. Or, do you mean that glibc itself is deficient, because it should have set the flag? My worry concerns the decision to unify 2.0 f.p. behavior in a specific way before full IEEE 754 support. I understand that you say this does not count as a changed behavior because the previous one is accidental. But I don't see the particular fixed subset chosen as any better than any other. I agree that I do have a choice of using -lieee, though. It is interesting to know that someone actually relies on OverflowError to detect underflow. But why not let them continue that as well, given that all of these would be available in the future anyway? > At this point we favor forcing consistency over maintaining platform > accidents, no matter how attached people have gotten to them; else we'll > be stuck with them forever. I do not understand. Once there is full IEEE 754, everyone would have a choice, which pretty much includes all the things people are doing now. Before that happens, why consistency accross platform is deemed more important than consistency accross releases? My naive thinking is that people port more from 1.5.2 to 2.0 than from one platform to another, isn't it? :-) Following does not have much new to say, just some clarification. You are right to emphasise that Kahan does not favor any subset of IEEE 754: > > They are called "Exceptions" because to any policy for handling them, > > imposed in advance upon all programmers by the computer system, some > > programmers will have good reason to take exception. Yes. And that's what's happening. :-) > His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5 > main gripes about Java in bullet points at the top of page 3. The paper > runs on to 80 pages. You somehow managed to miss 79.89 of them <0.4 wink>, > reducing it to a bogus claim about Java that Kahan didn't make (Java has > neither "Trap" nor "Flag" style fp exception signaling). Thank you for correcting me on this one. I did "glance over" all the pages. I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and got Exception in thread "main" java.lang.ArithmeticException: / by zero But now I see that 1/0.0 is Infinity. So is Math.exp(777). And so on. So that teaches me to test, test, test, ... > > He told "A cautionary Tale of the Ariane 5", > > Which has nothing to do with Java -- the software in question was written in > Ada, which (unlike Java) has "Trap" style. Why he put it in a paper about > Java is a bit of a mystery; I write it off to rhetorical excess. You are right it does not apply to Java. I guess he meant that as a warning that changing to the other side might be equally bad. > > So do we want every Python program to bomb whenever there is a floating > > point value outside bound and is not trapped by try/except? > > By default, yes, Guido does, but for overflow, not underflow. That's the harsh reality I have to live with, I suppose. <0.9wink> > If you read > the following section of Kahan's paper, you should have noticed that he is > *just* as critical of just returning Infs and NaNs (which is all Java does, > and which is the accidental Python behavior you're arguing we keep in glibc) > as he is of just trapping! His conclusion: "Without Traps nor Flags, Java? > s floating-point is Dangerous": > > Without flags, detecting rare creations of Inf and NaN before they > disappear requires programmed tests and branches that, besides > duplicating tests already performed by the hardware, slow down the > program and impel a programmer to make decisions prematurely in many > cases. Worse, a plethora of tests and branches undermines a program?s > modularity, clarity and concurrency. > > I agree with him there wholeheartedly: without the 754-mandated flags, > *and* without raising exceptions, the subset of 754 remaining sucks. That is true, but all these problems apply to "without raising flags", whether with or without "raising exceptions". Silent overflow forces programmers to do extra checking if they need to find them. Mandatory exception forces programmer to do extra checking if they don't want them to stop the program. Which is more common? It depends on programming style. In my programs, intentional NaN is far more than NaN by mistake. As to whether it is dangerous, I would say that if an overflow is really an error, good programming style requires that it be detected much earlier than the actual overflow. I agree this cannot be expected of everyone, though. > >> ironically, 754 is hardest to sell to those who could benefit from > >> it the most. > > > So far the only concern from number-crunchers voiced here is that it might > > allow sqrt(-1)==0, which is not the case. > > Gimme a break! In the very msg Paul Dubois said that, he also said "Some > people use Inf but most people want the code to STOP so they can find out > where the INFS started. Otherwise, two hours later you have big arrays of > Infs and no idea how it happened.". I'm starting to drop my assumption of > good faith on your part: what you remember and how you paraphrase (whether > it's Paul or Kahan) is extremely selective, beyond normal bounds of > zeal-inspired distortion. Well, I was talking about whether anyone has shown a concern to oppose 754. I was not talking about whether exception is prefered to flags. See the line I was replying to? Actually, thinking about it, Paul was not talking about concerns over 754, either. So there appears zero resistence to 754 from number crunchers here. > > Obviously we agree on the benefit of having a choice. But we > > have different perspective on what choice means. Your want a choice > > to force user to take explicit action, I want a choice to ignore these > > events. > > No. I want exactly the choices 754 lays out: user-settable sticky flags > and user-maskable exceptions. We're not getting that for 2.0. And we're > *never* getting it if 2.0 doesn't do *something* to start disabusing people > of the notion that their historical numeric platform accidents in Python > will be faithfully preserved forever more. Let me make it clear that we agree on all essential points about full 754 support. The difference only exists in the period before that. Since both the 1.5.2 accidental behaviors and the one you want to unify to are just subsets of the full support, it does not appear to me that disabling several of them is a prerequisite for the full support. > Kinda, except that each of the 5 754-defined traps must be individually > maskable. 754 spells out what's needed. A PEP will be required to spell > out the Python- and C-level APIs. I've corresponded (just -- no time now) a > little with Kevin Jacobs about that offline. Great! If the true IEEE 754 support could come soon, all my gripe is moot. So I'll stop disturbing you on the good work. :-) OK, I see that you want consistency above anything else before that good day comes. Well, consistency is good. Whether the price is too high is a subjective judgement. So I'll just use the -lieee hack for myself, then. [On presubstitution] Ok, I found it. It looks good. [On whether 754 default uses flags or exceptions] I agree with you: the system default matters very little as long as users can set their own defaults easily. > I expect we'll have to make InvalidOperationError a subclass of ValueError > for that reason, when 754 support materializes. That'll be handy. > > My favorite is returning 1j, as MatPy does. > > Then you should use cmath.sqrt instead of math.sqrt. Thanks. Huaiyu From skip at mojam.com Sat Oct 14 02:29:06 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT) Subject: [Python-Dev] Simple xml.sax example? Message-ID: <14823.43218.337621.157021@beluga.mojam.com> Is there a simple example available that demonstrates how to use elements of the new xml.sax package? I'd prefer something that doesn't require me to install anything other than what comes with the Python 2.0 distribution? Thanks, Skip From cbarker at jps.net Sat Oct 14 03:22:28 2000 From: cbarker at jps.net (Chris Barker) Date: Fri, 13 Oct 2000 18:22:28 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) References: Message-ID: <39E7B554.29A168E3@jps.net> Incomplete vs. non-at-all IEEE 754 support is a non argument. If you have full IEEE support (which it seems everyone here thinks would be good, but difficult), it is clear what you have. If not, you are not consistent with a standard, and therefor making up your own. That being the case, it's a matter of what we want the Python standard to be. I, for one think that NaN and Inf are fantastic!!! I think the best argument for them here is that it is almost impossible to do a lot of array based calculations without them, and you can't do serious number crunching in Python without array based calculations. I've come to Python from MATLAB for numerics, and I really appreciated MATLAB's way of handling all this. I don't think MATLAB has true 754 support, as I don't think you can change the behaviour, but you do get a consistent result across platforms (including non-iee machines like the Cray?---I have no idea). I have not yet heard a decent response to the question of what to do when a single value in a large array is bad, and causes an exception. This really does render Python essentially useless for Numerics for me. I suspect all those number crunchers that want an exception rather than an Inf are NOT using array-oriented languages. My goal is to dump MATLAB for Python, but this may prevent me from doing that. Does anyone know what other array-oriented languages use? I know what MATLAB does: >> exp(-777) ans = 0 >> exp(777) ans = Inf >> sqrt(-1) ans = 0 + 1.0000i Hey! I like that! Python is dynamic, why can't we just get the actual answer to sqrt(-1), without using cmath, that always returns a complex ? sorry, other subjet, not meant to be raised at the moment. >> 54/0 Warning: Divide by zero. ans = Inf Here we get a warning, but also a result that won't crash the computation. >> a = 0/0 Warning: Divide by zero. a = NaN >> b = a b = NaN >> a == b ans = 0 So comparing two NaNs yields a false, as it should, and though Python won't do it now, it could. One thing that a numerical routine should NEVER do is give an incorrect answer. No answer is often bad, but an incorrect one is much worse. NaN == NaN must return false. Does anyone know what FORTRAN 90 specifies (if anything)? What other array-oriented languages are there? I think what MATLAB does is what Tim is calling "bad *and* incomplete 754 support" Incomplete is surely true, "bad" is clearly a matter of opinion. It seems we have a variety of users of numerics in Python, that I break into three broad catagories: Casual users: mostly doing non-numeric stuff, with the occasional calculation: This group could use any non-cryptic handling of over/underflow, it just doesn't matter. Mid-level number crunchers: This is the group I put myself in. We crunch a lot of numbers, really like the array semantics (and speed) of NumPy, and are doing things like graphing functions, statistical calculations, etc. We have probably only taken one of two (at most) numerical analysis courses, and many don't know what the heck IEE 754 is. (The one Numerical Analysis course I did take, happened to be with Kahan, which is why I know what it is) For this group, the incomplete IEEE support is probably the best way to go. We're more likely to be annoyed by our whole computation stopping because of one bad data point, than we are to be pissed off that it didn't stop when it started to compute garbage. Hard Core Number crunchers: These are the folks that do things like write optimised routines for particular architectures, adn teach numerical analysis courses. These folks want either FULL IEEE, or plain old "classic" overflow and underflow errors, that they can handle themselves. Do these folks really use Python as other than a glue language? Are they really doing massive number crunching in Python itself, rather than in C (or whatever) extensions? If so, I'd be surprised is they didn't find Huaiyu's argument compelling when doing array based calculations. Tim pointed out that Python was not designed with 754 in mind, so for 2.0, what he is doing is probably our best bet, but it seems to not be the best ultimate solution, I hope using NaN and Inf will be considered for future versions, even if it is incomplete 754 compliance. Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible without custom re-compiling your own interpreter? If so, is there any chance that it will come any time soon (2.1 ?) , so we don't have to have this discussion at all? Thanks for all of your work on this, Python just keeps getting better!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cgw at fnal.gov Sat Oct 14 04:44:42 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov> Chris Barker writes: > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? You have to import the sqrt function from somewhere. Either you import it from math or from cmath, depending on which flavor you need. Anybody sophisticated enough to know what complex numbers are, and sophisticated enough to want to get complex values as a result of a calculation, should be sophisticated enough to be able to type "cmath". From larsga at garshol.priv.no Sat Oct 14 12:19:20 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 14 Oct 2000 12:19:20 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com> References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: * Skip Montanaro | | Is there a simple example available that demonstrates how to use | elements of the new xml.sax package? Here are a couple from an internal seminar I recently gave on this. I could make the slides available as well, if there is interest. --Lars M. --- elem_count.py import sys from xml.sax import make_parser, handler class FancyCounter(handler.ContentHandler): def __init__(self): self._elems = 0 self._attrs = 0 self._elem_types = {} self._attr_types = {} def startElement(self, name, attrs): self._elems = self._elems + 1 self._attrs = self._attrs + len(attrs) self._elem_types[name] = self._elem_types.get(name, 0) + 1 for name in attrs.keys(): self._attr_types[name] = self._attr_types.get(name, 0) + 1 def endDocument(self): print "There were", self._elems, "elements." print "There were", self._attrs, "attributes." print "---ELEMENT TYPES" for pair in self._elem_types.items(): print "%20s %d" % pair print "---ATTRIBUTE TYPES" for pair in self._attr_types.items(): print "%20s %d" % pair parser = make_parser() parser.setContentHandler(FancyCounter()) parser.parse(sys.argv[1]) --- roundtrip.py """ A simple demo that reads in an XML document and spits out an equivalent, but not necessarily identical, document. """ import sys, string from xml.sax import saxutils, handler, make_parser # --- The ContentHandler class ContentGenerator(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out # ContentHandler methods def startDocument(self): self._out.write('\n') def startElement(self, name, attrs): self._out.write('<' + name) for (name, value) in attrs.items(): self._out.write(' %s="%s"' % (name, saxutils.escape(value))) self._out.write('>') def endElement(self, name): self._out.write('' % name) def characters(self, content): self._out.write(saxutils.escape(content)) def ignorableWhitespace(self, content): self._out.write(content) def processingInstruction(self, target, data): self._out.write('' % (target, data)) # --- The main program parser = make_parser() parser.setContentHandler(ContentGenerator()) parser.parse(sys.argv[1]) --- rss2html.py import sys from xml.sax import make_parser, handler # --- Templates top = \ """ %s

    %s

    """ bottom = \ """
Converted to HTML by sax_rss2html.py.
""" # --- The ContentHandler class RSSHandler(handler.ContentHandler): def __init__(self, out = sys.stdout): handler.ContentHandler.__init__(self) self._out = out self._text = "" self._parent = None self._list_started = 0 self._title = None self._link = None self._descr = "" # ContentHandler methods def startElement(self, name, attrs): if name == "channel" or name == "image" or name == "item": self._parent = name self._text = "" def endElement(self, name): if self._parent == "channel": if name == "title": self._out.write(top % (self._text, self._text)) elif name == "description": self._out.write("

%s

\n" % self._text) elif self._parent == "item": if name == "title": self._title = self._text elif name == "link": self._link = self._text elif name == "description": self._descr = self._text elif name == "item": if not self._list_started: self._out.write("
    \n") self._list_started = 1 self._out.write('
  • %s %s\n' % (self._link, self._title, self._descr)) self._title = None self._link = None self._descr = "" if name == "rss": self._out.write(bottom) def characters(self, content): self._text = self._text + content # --- Main program parser = make_parser() parser.setContentHandler(RSSHandler()) parser.parse(sys.argv[1]) From thomas at xs4all.net Sat Oct 14 13:05:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:05:41 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> Message-ID: <20001014130541.F12812@xs4all.nl> On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote: > On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote: [ DEC threads (OSF1) are not automatically detected, causing a compilation failure on such systems ] > > It would be nice if configure were smart enough to figure this out! > ... we can easily add that. See the attached patch ... Charles, if you get a chance to test this patch before monday, please do. I think it's important to try and get the thread compiling right, now that threads are on by default. This is going to create a lot of confusion with OSF-users that don't read the README all the way through! If you can't test it, perhaps we can apply it before 2.0 none the less. I personally think there are more systems calling themselves OSF1 that do need the -threads argument than there are that don't need it (if any) and the patch only adds -threads if threads are really enabled. (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be conservative.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Oct 14 13:35:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 14 Oct 2000 13:35:29 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Thomas Wouters wrote: > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > in the case stmt, to be conservative.) are there really any others? (that "1" is part of the original name, it's not a version number) From thomas at xs4all.net Sat Oct 14 13:28:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 13:28:20 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid> Message-ID: <20001014132820.Y12776@xs4all.nl> On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote: > Thomas Wouters wrote: > > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)' > > in the case stmt, to be conservative.) > are there really any others? Don't know. That's why I asked it :) > (that "1" is part of the original name, it's not a version number) Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1) in others: case $ac_sys_system in OSF1) CC=cc without_gcc=;; versus if test -z "$LDSHARED" then case $ac_sys_system/$ac_sys_release in [..] OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";; [..] I guess the OSF*) action is specific enough (most likely to lead to errors on systems that call themselves, say, OSFORME) that we don't really have to worry about it right now. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sat Oct 14 14:32:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT) Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: References: <14823.43218.337621.157021@beluga.mojam.com> Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Lars Marius Garshol writes: > Here are a couple from an internal seminar I recently gave on this. I > could make the slides available as well, if there is interest. Could we include this in Demos/xml/ ? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cgw at fnal.gov Sat Oct 14 15:08:30 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <20001014130541.F12812@xs4all.nl> References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov> Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > think it's important to try and get the thread compiling right, now that > threads are on by default. OK, I just tried it and it worked for me. (I only tested it on one OSF/1 system, but I suppose that's better than nothing). Thanks for patching this, I think you are right that it will save a lot of confusion (at least for that handful of people running this OS!) From m.favas at per.dem.csiro.au Sat Oct 14 15:11:11 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sat, 14 Oct 2000 21:11:11 +0800 Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au> [Huaiyu Zhu, replying to Tim...] >It is interesting to know that someone actually relies on >OverflowError to detect underflow. But why not let them continue that >as well, given that all of these would be available in the future >anyway? I think I'm the someone referred to - but I _don't_ rely on this at all. I was reporting that, on my platforms, the behaviour of exp(-666) did _not_ change between 1.5.2 and 2.0, both of which raised an OverflowError (for underflow). I prefer Tim's change so that exp(-huge) will produce 0, and that exp(huge) produces an OverflowError, even though this changes the behaviour when moving from 1.5.2 to 2.x... [Huaiyu Zhu again] >Before that happens, why consistency accross platform is deemed more >important than consistency accross releases? My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it? :-) In spite of the smiley, I'd have to say (politely) "Rubbish!". One of the many attractions of Python to me _is_ cross-platform consistency - more so than up-version consistency. In my previous life as a computational chemist I spent a lot of effort in writing code that was portable - indeed, we developed a pre-processor language (which spat out FORTRAN) to try to more easily handle OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first came up against IEEE stuff in the early 80's, and I agree with Tim - as a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I was used to my code stopping when I divided by zero - it usually indicated a coding or algorithmic error. When (if) Python supports access to masking/unmasking 754 exceptions, that'll be good - in the meantime, from my POV, the steps taken by Tim/Guido are in the right direction. -- Mark Favas - m.favas at per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA From thomas at xs4all.net Sat Oct 14 19:12:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 14 Oct 2000 19:12:34 +0200 Subject: [Python-Dev] can't build with threads on OSF/1 In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500 References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov> Message-ID: <20001014191234.G12812@xs4all.nl> On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote: > Thomas Wouters writes: > > Charles, if you get a chance to test this patch before monday, please do. I > > think it's important to try and get the thread compiling right, now that > > threads are on by default. > OK, I just tried it and it worked for me. (I only tested it on one > OSF/1 system, but I suppose that's better than nothing). Yeah, I already tested it on the ther platforms I have. Not really necessary, since the patch is really tiny and can only really be a problem on platforms that have a 'system name' that matches 'OSF*' but don't need '-threads'. Thanx for testing that it works, though. Jeremy, are you OK on checking this autoconf change in ? Is it in time for 2.0-final ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sun Oct 15 00:11:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sat, 14 Oct 2000 18:11:30 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56 In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net> Message-ID: Greg, Do you intend these most recent changes to be included in 2.0 final on Monday? Just giving you a heads up in case you didn't realize what the release schedule is. The only changes we should be making are critical bugs fixes for mainline code (non-demo, tools, etc.). Also, there is some code in the top-level of the CVS repository that hasn't been put in the previous source tarballs; at least the C code for the Windows installer, but maybe other things as well. Can you recommend how to include this in the source distribution for the final release? We'd like to include *all* the source code for distutils. Jeremy From barry at scottb.demon.co.uk Sun Oct 15 01:28:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 15 Oct 2000 00:28:45 +0100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: Message-ID: <000001c03636$7f5b5600$060210ac@private> > -----Original Message----- > From: Tim Peters [mailto:tim_one at email.msn.com] > Sent: 08 October 2000 20:29 > To: Barry Scott; PythonDev; Python list > Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers > > > [Barry] > > Two requests: > > > > 1. Can you ship the .PDB files for the debug images so devo's > > do not need to build the python sources to debug extensions. > > And Yes I know the .ZIP will be huge. If you want a > > compromise only include the .PDB for python20_d.dll. > > Sure! Most .pdb files are highly compressible, and the zip size hit isn't > anything to worry about. Thanks > > > 2. Place the files into libs, pyd etc dirs. I had to extract > > the groups into the right places which is a bit tedious > > and error prone. > > No. If you want a directory structure that doesn't match the actual build > directory structure, I can't read your mind, and have no reason to believe > that the specific artificial structure you have in mind is of use to anyone The structure I refer to is the one used by the Python Windows installer. > but you. Don't be so helpless : write a tiny Python script to move I comment not because I'm lazy but because it seemed that every developer would need to reorganise the files. > the files where you want them after unpacking. What I upload will be an > exact image of the build directory structure. Most feedback I've gotten is > that people want exactly that, because they *want* to compile Python I'd not thought of that. MY assumption was that I build the release windows code against the files installed by the python windows installer. And that the debug settings would logically point into the same structure. > themselves and just want to avoid jumping thru all the snaky hoops needed to > compile the 3rd-party subprojects (from _tkinter to zlib). > > alphabetically y'rs - tim Barry From MarkH at ActiveState.com Sun Oct 15 01:53:03 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Sun, 15 Oct 2000 10:53:03 +1100 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry] > I'd not thought of that. My either. I must admit mild surprise at that. If people want the debug files in the same tree as the build tree, it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries? My experience with people wanting debug binaries is that they either don't want to, or can not build. When people need debug binaries, they go one of 2 routes - try and find pre-built debugs, or build them themselves. I can't see when people ever do both. For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different. Just-FWIW ly, Mark. From nick at nickbower.com Sun Oct 15 07:09:26 2000 From: nick at nickbower.com (Nick Bower) Date: Sun, 15 Oct 2000 05:09:26 GMT Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <20001015.5092600@cricket.> > Does anyone know what other array-oriented languages use? I know what > MATLAB does: I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's Space Science Ceter is split down the middle between this and MatLab, but python/numpy is definitely on the increase). As you can see from results below, like MatLab over/under-flows in IDL are reported but do not stop execution. This is the best (only) possible scenario for an interactive arrays and visualization environment. IDL> print, exp(-777) 0.00000 % Program caused arithmetic error: Floating underflow IDL> print, exp(777) Inf % Program caused arithmetic error: Floating overflow IDL> print, sqrt(-1) -NaN % Program caused arithmetic error: Floating illegal operand IDL> print, 54/0 54 % Program caused arithmetic error: Integer divide by 0 From martin at loewis.home.cs.tu-berlin.de Sun Oct 15 17:57:18 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 15 Oct 2000 17:57:18 +0200 Subject: [Python-Dev] Mandrake vs glibc Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de> > So, if David's report is correct, and best I understand it you were > all using 7.1 too with at least some level of optimization, it's A > Mystery why CVS test_math.py succeeds on that system (its new > math.sqrt(-1) test would probably fail; its new math.exp(+huge) test > would almost certainly fail). I'm anal enough about this stuff that > I'd try to figure out why if I had a Mandrake system, but in the > cosmic scheme of things I doubt it's important enough for anyone > else to burn time on. Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I get Python 2.0 (#104, Oct 15 2000, 15:47:19) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> math.exp(800) inf >>> math.exp(-800) 0.0 It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That is implemented as _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_; in this version of glibc, which in turn changes the behaviour of double __exp(double x) /* wrapper exp */ { double z; z = __ieee754_exp(x); if(_LIB_VERSION == _IEEE_) return z; if(__finite(x)) { if(x>o_threshold) return __kernel_standard(x,x,6); /* exp overflow */ else if(x > Can you recommend how to include this in the source distribution for > the final release? Even though I was not asked, I still answer :-) I think having the source code for the installer is essential, just so that people won't get frightened by the potential for a Trojan Horse in front of the gates (or, rather, the windows?-) I'd put the installer (i.e. all of distutils/misc except for get_metadata.py) into Tools/wininst. (I'd actually preferred to see the wininst sources in distutils in a different directory as well). In case you need some descripting text as well, here's my proposal. In Tools/README, maybe it would be wininst Sources for Windows installer of distutils.command.bdist_wininst. For Tools/wininst/README, see the text below. One complication is that invoking bdist_wininst as a program will regenerate the module, but it expects the installer binary in ../../misc/wininst.exe; I'm not sure whether it is worth the effort to change that for the Python distribution. Regards, Martin THE WINDOWS INSTALLER ===================== The distutils support the command bdist_wininst, which will produce a windows auto-installing executable using the information in the setup function. The executable consists of a user interface program, concatenated with a zip archive of the distributed files. This directory contains the sources of the user interface program. The bdist_wininst command itself does not need the sources, instead, it has an embedded copy of the installer binary file. If the installer program is modified, bdist_wininst.py must be updated by invoking it as a program (i.e. "python bdist_wininst.py") Building the installer ---------------------- To build the installer, you need a copy of Microsoft Visual C++ version 6; the project file is wininst.dsp. You may also use the executable compressor UPX, which is available from http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is not strictly required - it just reduces the size of the installation program itself. Using the bdist_wininst command ------------------------------- To create an binary distribution of your package for Windows, simply invoke "python setup.py bdist_wininst" in your package directory. If your package does not contain C modules, you may invoke this command on any system; if it does contain C modules, bdist_wininst will need the C compiler used to build Python (typically MSVC++). It will not need MSVC++ or UPX to build the setup program. To build the ZIP file contained in the installer, bdist_wininst will first try an external zip program (zip.exe) that understands the -rq option, such as Info-ZIP (http://www.info-zip.org/pub/infozip/Zip.html). If no such program is found, it will next try the zipfile module, which is available if Python was build with zlib support. From larsga at garshol.priv.no Sun Oct 15 19:52:16 2000 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: 15 Oct 2000 19:52:16 +0200 Subject: [Python-Dev] Simple xml.sax example? In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> References: <14823.43218.337621.157021@beluga.mojam.com> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com> Message-ID: * Lars Marius Garshol | | Here are a couple from an internal seminar I recently gave on this. | I could make the slides available as well, if there is interest. * Fred L. Drake, Jr. | | Could we include this in Demos/xml/ ? Sure. Do whatever you like with them. --Lars M. From hinsen at cnrs-orleans.fr Sun Oct 15 21:04:27 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun, 15 Oct 2000 21:04:27 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13 Oct 2000 18:22:28 -0700) References: <39E7B554.29A168E3@jps.net> Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr> > I've come to Python from MATLAB for numerics, and I really appreciated > MATLAB's way of handling all this. I don't think MATLAB has true 754 MATLAB is fine for simple interactive data processing, and its behaviour is adapted to this task. I don't think anyone would use MATLAB for developing complex algorithms, its programming language isn't strong enough for that. Python is, so complex algorithms have to be considered as well. And for that kind of application, continuing a calculation with Infs and NaNs is a debugging nightmare. > I have not yet heard a decent response to the question of what to do > when a single value in a large array is bad, and causes an exception. I'd like to have at least the option of raising an exception in that case. Note that this is not what NumPy does today. > >> sqrt(-1) > ans = > 0 + 1.0000i > > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? For the same reason that makes 2/3 return zero instead of a float division result. Like C or Fortran, Python treats integers, floats, and complex numbers as different data types. And the return type of a function should depend only on the types, but not the values, of its parameters (for consistency, not because of any implementational limitation). So sqrt(a) for a of type float can either always return a float (math, Numeric) and crash for negative arguments, or always return a complex (cmath). The "right" solution, in my opinion, would be to have a single "number" type of which integers, float, and complex numbers are simply different internal representations. But such a change cannot be introduced without breaking a lot of code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tim_one at email.msn.com Sun Oct 15 21:22:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 15:22:09 -0400 Subject: [Python-Dev] Python 2.0b2 note for Windows developers In-Reply-To: <000001c03636$7f5b5600$060210ac@private> Message-ID: [Tim] > the files where you want them after unpacking. What I upload > will be an exact image of the build directory structure. Most > feedback I've gotten is that people want exactly that, > because they *want* to compile Python [Barry Scott] > I'd not thought of that. [Mark Hammond] > My either. I must admit mild surprise at that. Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree. > If people want the debug files in the same tree as the build tree, Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count. > it seems all they are trying to do is avoid the initial huge build. If > they intend compiling, why are they asking for the binaries? The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours. > My experience with people wanting debug binaries is that they either don't > want to, or can not build. If they can't build, it's hard to take their claim to be developing extension modules seriously . > ... > For the last year or so, I have been making Debug builds of win32all > available to registered users. This has always been made available in > the "install" structure - quite a bit different than the source/build > structure. I've never been asked for anything different. Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over-ly y'rs - tim From tim_one at email.msn.com Sun Oct 15 22:35:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 16:35:27 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr> Message-ID: [cbarker at jps.net] >> I've come to Python from MATLAB for numerics, and I really appreciated >> MATLAB's way of handling all this. I don't think MATLAB has true 754 ... [Konrad Hinsen] > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. A non-constructive (because futile) speculation: the first time I saw what 754 was intending to do, my immediate reaction was "hmm -- the exponent field is too narrow!". With a max (double) val in the ballpark of 1e300, you get an infinity as soon as you square something as small as 1e150, and once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and Inf/Inf). The dynamic range for 754 singles is much smaller still. There's no doubt about Cray arithmetic being hard to live with, but while Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's exponent field (vs. 11 for 754). As a result, overflows were generally a non-issue on Cray boxes, and *nobody* complained (in my decade there) about Cray HW raising a fatal exception if one occurred. In return, you got only 48 bits of precision (vs. 53 for 754). But, for most physical problems, how accurate are the inputs? 10 bits on a good day, 20 bits on a great day? Crays worked despite their sloppy numerics because, for most problems to which they were applied, they carried more than twice the precision *and* dynamic range than the final results needed. >> I have not yet heard a decent response to the question of what to do >> when a single value in a large array is bad, and causes an exception. I'd usually trace back and try to figure out how it got "bad" to begin with ... > I'd like to have at least the option of raising an exception in that > case. Note that this is not what NumPy does today. Does NumPy use the fpectl module? I suppose not. LLNL contribued that code, but we hear very little feedback on it. It arranges to (in platform-dependent ways) convert the 754 overflow, divide-by-0 and invalid-operation signals into Python exceptions. In core Python, this is accomplished at the extraordinary expense of doing a setjmp before, and a function call + double->int conversion after, every single fp operation. A chief problem is that SIGFPE is the only handle C gives us on fp "errors", and the C std does not allow returning from a SIGFPE handler (the result of trying to is undefined, and indeed varies wildly across platforms); so if you want to regain control, you have to longjmp out of the handler. The NumPy implementation could use the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros to brackete entire array operations, though, and so pay for the setjmp etc only once per array op. This is difficult stuff, but doable. >> >> sqrt(-1) >> ans = >> 0 + 1.0000i >> >> Hey! I like that! Python is dynamic, why can't we just get the actual >> answer to sqrt(-1), without using cmath, that always returns a complex ? > For the same reason that makes 2/3 return zero instead of a float > division result. Like C or Fortran, Python treats integers, floats, > and complex numbers as different data types. You know I'm in general agreement with you on this one, but I have to draw a distinction here: Guido thinks that 2/3 returning 0 was a design mistake, but not that math.sqrt(-1) raising an exception is a mistake. Most Python users won't know what to do with a complex number, so it's "an error" to them. I would like to view this in P3K (if not earlier) as being akin to 754 exceptions: some people are delighted to have 1e300**2 return +Inf, while others want to see OverflowError instead, and still others want to see +Inf *and* have a sticky flag set saying "an overflow occurred". We could treat f(x) (for f == sqrt and everything else) the same way wrt to a new ComplexResultFromNonComplexInputsError: define "non-stop" complex results, let the user choose whether to do nonstop or raise an exception, and a supply a sticky flag saying whether or not any complex results were generated from non-complex inputs. > ... > The "right" solution, in my opinion, would be to have a single > "number" type of which integers, float, and complex numbers are simply > different internal representations. But such a change cannot be > introduced without breaking a lot of code. The current distinction between ints and longs (unbounded ints) should also get swallowed by this. A way to get from here to there is especially irksome at the C API level, since, e.g., many C API functions pass Python ints as C longs directly. A smaller number pass Python floats as C doubles directly. it's-wonderful-that-p3k-will-solve-everything-ly y'rs - tim From MarkH at ActiveState.com Mon Oct 16 01:49:19 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 10:49:19 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. Message-ID: I just struck this, and wonder if it is intentional: * Adding 2 buffer objects together yields a string. Fair enough. * Adding a buffer and a string yields a type error! Eeek. This yields the following strange behaviour: >>> a=buffer('a') >>> a+a 'aa' >>> a+a+a Traceback (innermost last): File "", line 1, in ? TypeError: cannot add type "buffer" to string >>> That doesnt seem correct to me? Mark. From rob at hooft.net Mon Oct 16 07:39:13 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18 In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net> References: <200010091242.FAA02671@slayer.i.sourceforge.net> Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl> Just checking my E-mail coming back from holidays, I see: diff -C2 -r1.17 -r1.18 *** calendar.py 2000/08/30 14:01:28 1.17 --- calendar.py 2000/10/09 12:42:04 1.18 *************** *** 55,60 **** def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2 and no funny (non-leap century) years.""" ! return (y2+3)/4 - (y1+3)/4 def weekday(year, month, day): --- 55,62 ---- def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2.""" ! y1 -= 1 ! y2 -= 1 ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) def weekday(year, month, day): I am worried about the use of "-=" here. The code basically says: "if the arguments are mutable numeric types, I'd like to modify them in place". In c.l.py it has been stressed multiple times that "-=" is not the same as "= -". I think this is clearly a place where "= -" is preferable over "-=". Even though you might think people will always call this with python integers, you can never be sure enough. Rob -- ===== rob at hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From pf at artcom-gmbh.de Mon Oct 16 09:23:11 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST) Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext) In-Reply-To: Message-ID: Hi Ulf, Ulf Betlehem: [...] > ok, I compiled 2.0c1 and tried gettext. Now, there seems to be > a bug in the "normalize and expand" code that can prevent > gettext from finding an existing .mo file. The normalization > is done using a dictionary and therefore the languages get > reordered (as dict keys do). Later when selecting language the > function returns None if 'C' happens to come before the > required languages. I've included a patch to fix this. Your patch looks good to me. Thanks for taking the time to test and contributing the patch. I've submitted your bug report and your patch to sourceforge. See: https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470 https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 Regards, Peter P.S.: Cc to python-dev -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal at lemburg.com Mon Oct 16 09:50:22 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 09:50:22 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAB33E.35B72EA4@lemburg.com> Mark Hammond wrote: > > I just struck this, and wonder if it is intentional: > > * Adding 2 buffer objects together yields a string. Fair enough. > * Adding a buffer and a string yields a type error! Eeek. This just seems plain wrong. Adding two buffers should yield a new buffer -- in the long run, buffers should replace strings wrt to holding binary data. If not even buffers themselves implement this idea, I don't see any perspective for ever getting there... > This yields the following strange behaviour: > > >>> a=buffer('a') > >>> a+a > 'aa' > >>> a+a+a > Traceback (innermost last): > File "", line 1, in ? > TypeError: cannot add type "buffer" to string > >>> > > That doesnt seem correct to me? Neither to me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller at ion-tof.com Mon Oct 16 11:14:49 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Mon, 16 Oct 2000 11:14:49 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> IMHO, the whole buffer interface is weird. - Only the Buffer_FromObject() function is exposed to the python level (as buffer()), the other functions are missing. This means that one could only use the buffer interface in extension modules. Was this intentional? - No way a python class can expose the buffer interface - There is a bug in the buffer interface (which prevented recently that I could use buffer objects at all, I had to implement my own) PyObject *base = PyBuffer_New(100); PyObject *buffer = PyBuffer_FromObject(base, 0, 100); Py_DECREF(base); After this code is executed, buffer points to deallocated memory (because buffer does not hold a reference to base anymore). (Guido classified this as a wish, but at least it contradicts the documentation) Thomas From MarkH at ActiveState.com Mon Oct 16 11:38:26 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 16 Oct 2000 20:38:26 +1100 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook> Message-ID: > IMHO, the whole buffer interface is weird. I'm not sure that weird is the correct term for your points (it is for my spelling, though :-) > - Only the Buffer_FromObject() function is exposed to the ... > - No way a python class can expose the buffer interface These are simply oversights, I would suggest. Nothing in the design prevents this. > - There is a bug in the buffer interface (which > prevented recently that I could use buffer objects > at all, I had to implement my own) This looks like quite a simple bug. bufferobject.c, line 77: /* if the base object is another buffer, then "deref" it */ if ( PyBuffer_Check(base) ) base = ((PyBufferObject *)base)->b_base; if the condition was changed to: if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base) Then I think this one would be solved? A more serious design flaw is the one Fredrik pointed out quite some time ago. If you have (eg.) an "array" object and query for its buffer, life is good. If the array then resizes itself, your pointer is now dangling. The simplest solution to this is probably to simply define the lifetimes of these pointers as very very short ;-) Mark. From mal at lemburg.com Mon Oct 16 12:14:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 12:14:46 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: Message-ID: <39EAD516.7EA34C20@lemburg.com> Mark Hammond wrote: > [Problems with the buffer interface] > If you have (eg.) an "array" object and query for its buffer, life is > good. If the array then resizes itself, your pointer is now dangling. The > simplest solution to this is probably to simply define the lifetimes of > these pointers as very very short ;-) ...or disable the buffer interface for mutable types altogether ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Oct 16 15:01:26 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 06:01:26 -0700 Subject: [Python-Dev] Wierd buffer "add" behaviour. In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200 References: <39EAB33E.35B72EA4@lemburg.com> Message-ID: <20001016060126.X347@lyra.org> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > Mark Hammond wrote: >... > > This yields the following strange behaviour: > > > > >>> a=buffer('a') > > >>> a+a > > 'aa' > > >>> a+a+a > > Traceback (innermost last): > > File "", line 1, in ? > > TypeError: cannot add type "buffer" to string > > >>> > > > > That doesnt seem correct to me? > > Neither to me. It is caused by the non-commutative aspect of Python types. You end up with a string, and that type doesn't know how to add a buffer to itself. Ideally, it might be nice to allow a string to append any object that exports the buffer-interface. But when somebody goes and writes "abc"+my_array ... hoo boy, will we hear complaints. The alternative is to allow the buffer to resolve the type conflict and do the appending within the buffer code. Of course, the choice of returning a string (from buf+buf) rather than a buffer was arguably the wrong choice. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Mon Oct 16 16:30:44 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 09:30:44 -0500 Subject: [Python-Dev] mutable integers In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200." <14826.38017.352907.716552@temoleh.chem.uu.nl> References: <200010091242.FAA02671@slayer.i.sourceforge.net> <14826.38017.352907.716552@temoleh.chem.uu.nl> Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com> Rob W. W. Hooft: > Just checking my E-mail coming back from holidays, I see: [...] > def leapdays(y1, y2): > """Return number of leap years in range [y1, y2). > ! Assume y1 <= y2.""" > ! y1 -= 1 > ! y2 -= 1 > ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) > > I am worried about the use of "-=" here. The code basically says: "if the > arguments are mutable numeric types, I'd like to modify them in place". In > c.l.py it has been stressed multiple times that "-=" is not the same as > "= -". I think this is clearly a place where "= -" is preferable over > "-=". Even though you might think people will always call this with > python integers, you can never be sure enough. Hmm... Your fear sounds a little paranoid for this particular case, but I can't say that I totally disagree in general. This is definitely something to keep in mind when writing polymorphic functions for which a NumPy array might be an acceptable input argument. I don't think it's worth checking in a patch in this case. --Guido van Rossum (home page: http://www.python.org/~guido/) From hinsen at cnrs-orleans.fr Mon Oct 16 17:52:43 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 16 Oct 2000 17:52:43 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr> > > I'd like to have at least the option of raising an exception in that > > case. Note that this is not what NumPy does today. > > Does NumPy use the fpectl module? I suppose not. LLNL contribued that No. Perhaps it should, but it doesn't make sense unless fpectl works on a large number of platforms. I confess I have never looked at it. I want my code to be portable, so I don't even consider using packages that aren't. > > For the same reason that makes 2/3 return zero instead of a float > > division result. Like C or Fortran, Python treats integers, floats, > > and complex numbers as different data types. > > You know I'm in general agreement with you on this one, but I have to draw a > distinction here: Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Well, that would be a good occasion to learn about complex numbers! I remember having learned about generalized inverses by using APL in high school (in a very similar way: I was amazed that it could invert non-square matrices), and that turned out to be very useful knowledge later on. Perhaps that's a topic for the EDU-SIG... Anyway, I don't care what math.sqrt(-1) does, but I would definitely prefer Numeric.sqrt(-1) to return a complex result. And I think that someone who uses NumPy has probably heard about complex numbers. > I would like to view this in P3K (if not earlier) as being akin to > 754 exceptions: some people are delighted to have 1e300**2 return +Inf, > while others want to see OverflowError instead, and still others want to see > +Inf *and* have a sticky flag set saying "an overflow occurred". We could > treat f(x) (for f == sqrt and everything else) the same way wrt to a new > ComplexResultFromNonComplexInputsError: define "non-stop" complex results, > let the user choose whether to do nonstop or raise an exception, and a > supply a sticky flag saying whether or not any complex results were > generated from non-complex inputs. There is, however, one difference: in properly debugged production code, there should be no overflow situations, so it doesn't matter much how they are treated. Complex number can (do!) occur in production code, but there could also be production code relying on exceptions for sqrt(-1) (e.g. for input error checking). Therefore a program using several libraries might be impossible to run with either setting. Since this concerns only the math module, I'd prefer to keep separate module versions for the two cases, which can be used in parallel. > > The "right" solution, in my opinion, would be to have a single > > "number" type of which integers, float, and complex numbers are simply > > different internal representations. But such a change cannot be > > introduced without breaking a lot of code. > > The current distinction between ints and longs (unbounded ints) should also > get swallowed by this. A way to get from here to there is especially > irksome at the C API level, since, e.g., many C API functions pass Python > ints as C longs directly. A smaller number pass Python floats as C doubles > directly. I don't see the problem in that direction, it's rather C API functions that *return* numbers in C data types that would be difficult to adapt. But then, why should be C API not be allowed in P3K? it's-wonderful-that-anything-may-be-changed-in-p3k'ly Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From guido at python.org Mon Oct 16 20:08:07 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:08:07 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST." <20001016060126.X347@lyra.org> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> The buffer interface is one of the most misunderstood parts of Python. I believe that if it were PEPped today, it would have a hard time getting accepted in its current form. There are also two different parts that are commonly referred by this name: the "buffer API", which is a C-only API, and the "buffer object", which has both a C API and a Python API. Both were largely proposed, implemented and extended by others, and I have to admit that I'm still uneasy with defending them, especially the buffer object. Both are extremely implementation-dependent (in JPython, neither makes much sense). The Buffer API -------------- The C-only buffer API was originally intended to allow efficient binary I/O from and (in some cases) to large objects that have a relatively well-understood underlying memory representation. Examples of such objects include strings, array module arrays, memory-mapped files, NumPy arrays, and PIL objects. It was created with the desire to avoid an expensive memory-copy operation when reading or writing large arrays. For example, if you have an array object containing several millions of double precision floating point numbers, and you want to dump it to a file, you might prefer to do the I/O directly from the array's memory buffer rather than first copying it to a string. (You lose portability of the data, but that's often not a problem the user cares about in these cases.) An alternative solution for this particular problem was consdered: object types in need of this kind of efficient I/O could define their own I/O methods, thereby allowing them to hide their internal representation. This was implemented in some cases (e.g. the array module has read() and write() methods) but rejected, because a simple-minded implementation of this approach would not work with "file-like" objects (e.g. StringIO files). It was deemed important that file-like objects would not place restrictions on the kind of objects that could interact with them (compared to real file objects). A possible solution would have been to require that each object implementing its own read and write methods should support both efficient I/O to/from "real" file objects and fall-back I/O to/from "file-like" objects. The fall-back I/O would have to convert the object's data to a string object which would then be passed to the write() method of the file-like object. This approach was rejected because it would make it impossible to implement an alternative file object that would be as efficient as the real file object, since large object I/O would be using the inefficient fallback interface. To address these issues, we decided to define an interface that would let I/O operations ask the objects where their data bytes are in memory, so that the I/O can go directly to/from the memory allocated by the object. This is the classic buffer API. It has a read-only and a writable variant -- the writable variant is for mutable objects that will allow I/O directly into them. Because we expected that some objects might have an internal representation distributed over a (small) number of separately allocated pieces of memory, we also added the getsegcount() API. All objects that I know support the buffer API return a segment count of 1, and most places that use the buffer API give up if the segment count is larger; so this may be considered as an unnecessary generalization (and source of complexity). The buffer API has found significant use in a way that wasn't originally intended: as a sort of informal common base class for string-like objects in situations where a char[] or char* type must be passed (in a read-only fashion) to C code. This is in fact the most common use of the buffer API now, and appears to be the reason why the segment count must typically be 1. In connection with this, the buffer API has grown a distinction between character and binary buffers (on the read-only end only). This may have been a mistake; it was intended to help with Unicode but it ended up not being used. The Buffer Object ----------------- The buffer object has a much less clear reason for its existence. When Greg Stein first proposed it, he wrote: The intent of this type is to expose a string-like interface from an object that supports the buffer interface (without making a copy). In addition, it is intended to support slices of the target object. My eventual goal here is to tweak the file object to support memory mapping and the buffer interface. The buffer object can then return slices of the file without making a new copy. Next step: change marshal.c, ceval.c, and compile.c to support a buffer for the co_code attribute. Net result is that copies of code streams don't need to be copied onto the heap, but can be left in an mmap'd file or a frozen file. I'm hoping there will be some perf gains (time and memory). Even without some of the co_code work, enabling mmap'd files and buffers onto them should be very useful. I can probably rattle off a good number of other uses for the buffer type. I don't think that any of these benefits have been realized yet, and altogether I think that the buffer object causes a lot of confusion. The buffer *API* doesn't guarantee enough about the lifetime of the pointers for the buffer *object* to be able to safely preserve those pointers, even if the buffer object holds on to the base object. (The C-level buffer API informally guarantees that the data remains valid only until you do anything to the base object; this is usually fine as long as you don't release the global interpreter lock.) The buffer object's approach to implementing the various sequence operations is strange: sometimes it behaves like a string, sometimes it doesn't. E.g. a slice returns a new string object unless it happens to address the whole buffer, in which case it returns a reference to the existing buffer object. It would seem more logical that a subslice would return a new buffer object. Concatenation and repetition of buffer objects are likewise implemented inconsistently; it would have been more consistent with the intended purpose if these weren't supported at all (i.e. if none of the buffer object operations would allocate new memory except for buffer object headers). I would have concluded that the buffer object is entirely useless, if it weren't for some very light use that is being made of it by the Unicode machinery. I can't quite tell whether that was done just because it was convenient, or whether that shows there is a real need. What Now? --------- I'm not convinced that we need the buffer object at all. For example, the mmap module defines a sequence object so doesn't seem to need the buffer object to help it support slices. Regarding the buffer API, it's clearly useful, although I'm not convinced that it needs the multiple segment count option or the char vs. binary buffer distinction, given that we're not using this for Unicode objects as we originally planned. I also feel that it would be helpful if there was an explicit way to lock and unlock the data, so that a file object can release the global interpreter lock while it is doing the I/O. But that's not a high priority (and there are no *actual* problems caused by the lack of such an API -- just *theoretical*). For Python 3000, I think I'd like to rethink this whole mess. Perhaps byte buffers and character strings should be different beasts, and maybe character strings could have Unicode and 8-bit subclasses (and maybe other subclasses that explicitly know about their encoding). And maybe we'd have a real file base class. And so on. What to do in the short run? I'm still for severely simplifing the buffer object (ripping out the unused operations) and deprecating it. --Guido van Rossum (home page: http://www.python.org/~guido/) From cbarker at jps.net Mon Oct 16 19:38:11 2000 From: cbarker at jps.net (Chris Barker) Date: Mon, 16 Oct 2000 10:38:11 -0700 Subject: [Python-Dev] Re: numpy, overflow, inf, ieee, and rich comparison References: Message-ID: <39EB3D03.A00C78B6@jps.net> > >> I have not yet heard a decent response to the question of what to do > >> when a single value in a large array is bad, and causes an exception. > > I'd usually trace back and try to figure out how it got "bad" to begin with And from Konrad Hinsen >I'd like to have at least the option of raising an exception in that >case. Note that this is not what NumPy does today. Exactly. This was Huaiyu's point. The problem is that for your code to be usable for folks other than yourself, you'd have to have a lot of checks in there, and essentially revert to elementwise code, which would kill you. With the addition of the occasional "isnan" and something like Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of A are NaNs) you could set up your code to raise an exception in the middle of computation. If, on the other hand the Code definiately raises an exception, than you are stuck with a lot of elementwise coding. > over/under-flows in IDL are reported but do > not stop execution. This is the best (only) possible scenario for an > interactive arrays and visualization environment. Exactly!!! ("the best (only) possible scenario" part) > IDL> print, 54/0 > 54 > % Program caused arithmetic error: Integer divide by 0 This, however, is wierd!! 54/0 == 54 ??? I'd much rather see a NaN or Inf here! > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. People do some pretty complex algorith develpment with MATLAB. I'm also no so sure about "continuing a calculation with Infs and NaNs is a debugging nightmare" I'm don't think it's any more of a nighmare than having your calculation on an entire array stop because of one Inf. It's just a different trade off. Sprinkle a few "isnan"'s in there and and you can get the behaviour you want, while not forcing it on all calculations. Of course, the best option is to have it switchable, but that may prove to be very difficult. Are people doing the kind of numeric programming with "complex algorithms" using Python that Konrad refers to? More importantly, how many people? > Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Guido's philosophy is clearly that Python defaults should be geared to "Most Python users". I agree, and as I wrote in an earlier post, the only users for whom the "exception raising only" option is best are the users Konrad refers to as writing "complex algorithms". I would argue that those users are few, and the group most able to deal with a less-that-optimum system. Maybe we can have true 754 compliance in Py3k, and we can all be happy!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From effbot at telia.com Mon Oct 16 19:47:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 16 Oct 2000 19:47:55 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid> guido wrote: > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. agreed. (does this mean that we're in post-2.0 mode? ;-) From mal at lemburg.com Mon Oct 16 19:42:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 19:42:15 +0200 Subject: [Python-Dev] Wierd buffer "add" behaviour. References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> Message-ID: <39EB3DF7.459A1BC1@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote: > > Mark Hammond wrote: > >... > > > This yields the following strange behaviour: > > > > > > >>> a=buffer('a') > > > >>> a+a > > > 'aa' > > > >>> a+a+a > > > Traceback (innermost last): > > > File "", line 1, in ? > > > TypeError: cannot add type "buffer" to string > > > >>> > > > > > > That doesnt seem correct to me? > > > > Neither to me. > > It is caused by the non-commutative aspect of Python types. You end up with > a string, and that type doesn't know how to add a buffer to itself. The problem is that buffer() objects coerce to strings in the first place... they should return new buffer objects instead of strings -- then we wouldn't have the above problems. > ... > Of course, the choice of returning a string (from buf+buf) rather than a > buffer was arguably the wrong choice. Right :-/ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Mon Oct 16 20:51:51 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 13:51:51 -0500 Subject: [Python-Dev] The buffer interface In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200." <00f601c03799$39f2c7b0$3c6340d5@hagrid> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com> > guido wrote: > > What to do in the short run? I'm still for severely simplifing the > > buffer object (ripping out the unused operations) and deprecating it. > > agreed. > > (does this mean that we're in post-2.0 mode? ;-) Yes :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Oct 16 20:03:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 16 Oct 2000 20:03:15 +0200 Subject: [Python-Dev] The buffer interface References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <39EB42E3.B76F37EB@lemburg.com> Guido van Rossum wrote: > ... > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. I used the buffer object since I thought that buffer() objects were to replace strings as container for binary data. The buffer object wraps a memory buffer into a Python object for the purpose of decoding it into Unicode. 8-bit string objects would have worked just as well... > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. It would be nice to have an object for "copy by reference" rather than "malloc + copy". This would be useful for strings (e.g. to access substrings of a large string), Unicode and binary data. The buffer object almost does this... it would only have to stick to always returning buffer objects in coercion, slicing etc. I also think that the name "buffer" is misleading, since it really means "reference" in the context published by the Python interface (the C API also has a way of defining new malloc areas and referencing them through the buffer interface, but that is not published in Python). The other missing data type in Python is one for binary data. Currently, string objects are in common use for this kind of data. The problems with this are obvious: in some contexts strings are expected to contain text data in other binary data. When the two meet there's great confusion. I'd suggest either making arrays the Python standard type for holding binary data, or creating a completely new type (this should then be called something like "buffer"). > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. True. > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). How about adding a generic low-level lock type for these kind of tasks. The interpreter could be made aware of these types to allow a much more fine-grained lock mechanism, e.g. to check for acquired locks of certain objects only. > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. Great... but 3000 is a long way ahead :-( > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. Since it isn't all that known anyway, how about streamlining the buffer object implementations of the various protocols and removing the distinction between "s" and "t" ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jcollins at endtech.com Mon Oct 16 22:22:22 2000 From: jcollins at endtech.com (Jeff Collins) Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: All this just when I was getting accustomed to the thought of using buffer objects in the Palm Python port... I need buffer objects for many the same reasons as Greg Stein originally proposed, as you quoted below. The on the Palm, the datamanager heap (used for permanent database storage and limited by the physical memory size) already stores the compiled python module. Directly referencing the data of objects like bytecodes and strings would greatly reduce the dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM or greater) requirements. Buffer objects seem like a natural choice. A record in a Palm database is just chunk of contiguous memory. Representing this chunk as a buffer object would allow the direct referencing it and any of it's slices. So, the co_code of code objects could be unmarshalled with a reference to permanent storage. Further, with the appropriate modifications, string objects (char *ob_sval?) could access this memory as well, though this additional optimization is probably only appropriate for small platforms. I think that buffer object is fairly important. They provide a mechanism for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), something that no other python object does, AFIAK. Perhaps clarifying the interface (such as the slice operator returning a buffer, as suggested below) and providing more hooks from Python for creating buffers (via newmodule, say) would be helpful. On Mon, 16 Oct 2000, Guido van Rossum wrote: > The buffer interface is one of the most misunderstood parts of > Python. I believe that if it were PEPped today, it would have a hard > time getting accepted in its current form. > > There are also two different parts that are commonly referred by this > name: the "buffer API", which is a C-only API, and the "buffer > object", which has both a C API and a Python API. > > Both were largely proposed, implemented and extended by others, and I > have to admit that I'm still uneasy with defending them, especially > the buffer object. Both are extremely implementation-dependent (in > JPython, neither makes much sense). > > The Buffer API > -------------- > > The C-only buffer API was originally intended to allow efficient > binary I/O from and (in some cases) to large objects that have a > relatively well-understood underlying memory representation. Examples > of such objects include strings, array module arrays, memory-mapped > files, NumPy arrays, and PIL objects. > > It was created with the desire to avoid an expensive memory-copy > operation when reading or writing large arrays. For example, if you > have an array object containing several millions of double precision > floating point numbers, and you want to dump it to a file, you might > prefer to do the I/O directly from the array's memory buffer rather > than first copying it to a string. (You lose portability of the data, > but that's often not a problem the user cares about in these cases.) > > An alternative solution for this particular problem was consdered: > object types in need of this kind of efficient I/O could define their > own I/O methods, thereby allowing them to hide their internal > representation. This was implemented in some cases (e.g. the array > module has read() and write() methods) but rejected, because a > simple-minded implementation of this approach would not work with > "file-like" objects (e.g. StringIO files). It was deemed important > that file-like objects would not place restrictions on the kind of > objects that could interact with them (compared to real file objects). > > A possible solution would have been to require that each object > implementing its own read and write methods should support both > efficient I/O to/from "real" file objects and fall-back I/O to/from > "file-like" objects. The fall-back I/O would have to convert the > object's data to a string object which would then be passed to the > write() method of the file-like object. This approach was rejected > because it would make it impossible to implement an alternative file > object that would be as efficient as the real file object, since large > object I/O would be using the inefficient fallback interface. > > To address these issues, we decided to define an interface that would > let I/O operations ask the objects where their data bytes are in > memory, so that the I/O can go directly to/from the memory allocated > by the object. This is the classic buffer API. It has a read-only > and a writable variant -- the writable variant is for mutable objects > that will allow I/O directly into them. Because we expected that some > objects might have an internal representation distributed over a > (small) number of separately allocated pieces of memory, we also added > the getsegcount() API. All objects that I know support the buffer API > return a segment count of 1, and most places that use the buffer API > give up if the segment count is larger; so this may be considered as > an unnecessary generalization (and source of complexity). > > The buffer API has found significant use in a way that wasn't > originally intended: as a sort of informal common base class for > string-like objects in situations where a char[] or char* type must be > passed (in a read-only fashion) to C code. This is in fact the most > common use of the buffer API now, and appears to be the reason why the > segment count must typically be 1. > > In connection with this, the buffer API has grown a distinction > between character and binary buffers (on the read-only end only). > This may have been a mistake; it was intended to help with Unicode but > it ended up not being used. > > The Buffer Object > ----------------- > > The buffer object has a much less clear reason for its existence. > When Greg Stein first proposed it, he wrote: > > The intent of this type is to expose a string-like interface from > an object that supports the buffer interface (without making a > copy). In addition, it is intended to support slices of the target > object. > > My eventual goal here is to tweak the file object to support > memory mapping and the buffer interface. The buffer object can > then return slices of the file without making a new copy. Next > step: change marshal.c, ceval.c, and compile.c to support a buffer > for the co_code attribute. Net result is that copies of code > streams don't need to be copied onto the heap, but can be left in > an mmap'd file or a frozen file. I'm hoping there will be some > perf gains (time and memory). > > Even without some of the co_code work, enabling mmap'd files and > buffers onto them should be very useful. I can probably rattle off > a good number of other uses for the buffer type. > > I don't think that any of these benefits have been realized yet, and > altogether I think that the buffer object causes a lot of confusion. > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. (The > C-level buffer API informally guarantees that the data remains valid > only until you do anything to the base object; this is usually fine as > long as you don't release the global interpreter lock.) > > The buffer object's approach to implementing the various sequence > operations is strange: sometimes it behaves like a string, sometimes > it doesn't. E.g. a slice returns a new string object unless it > happens to address the whole buffer, in which case it returns a > reference to the existing buffer object. It would seem more logical > that a subslice would return a new buffer object. Concatenation and > repetition of buffer objects are likewise implemented inconsistently; > it would have been more consistent with the intended purpose if these > weren't supported at all (i.e. if none of the buffer object operations > would allocate new memory except for buffer object headers). > > I would have concluded that the buffer object is entirely useless, if > it weren't for some very light use that is being made of it by the > Unicode machinery. I can't quite tell whether that was done just > because it was convenient, or whether that shows there is a real > need. > > What Now? > --------- > > I'm not convinced that we need the buffer object at all. For example, > the mmap module defines a sequence object so doesn't seem to need the > buffer object to help it support slices. > > Regarding the buffer API, it's clearly useful, although I'm not > convinced that it needs the multiple segment count option or the char > vs. binary buffer distinction, given that we're not using this for > Unicode objects as we originally planned. > > I also feel that it would be helpful if there was an explicit way to > lock and unlock the data, so that a file object can release the global > interpreter lock while it is doing the I/O. But that's not a high > priority (and there are no *actual* problems caused by the lack of > such an API -- just *theoretical*). > > For Python 3000, I think I'd like to rethink this whole mess. Perhaps > byte buffers and character strings should be different beasts, and > maybe character strings could have Unicode and 8-bit subclasses (and > maybe other subclasses that explicitly know about their encoding). > And maybe we'd have a real file base class. And so on. > > What to do in the short run? I'm still for severely simplifing the > buffer object (ripping out the unused operations) and deprecating it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > -- Jeffery D. Collins Sr. Software Developer Endeavors Technology, Inc. From akuchlin at cnri.reston.va.us Mon Oct 16 21:35:13 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Mon, 16 Oct 2000 15:35:13 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500 References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us> On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote: >> (does this mean that we're in post-2.0 mode? ;-) >Yes :-) Then this is a good time to ask what strategy will be followed post-2.0. Do you want a moratorium on massive checkins for a time while 2.0 shakes out, re-opening the tree for larger changes in a few months? Or will you try to live with a CVS branch for 2.0 and re-open the tree immediately? --amk From fdrake at beopen.com Mon Oct 16 21:37:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT) Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com> Andrew M. Kuchling writes: > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? I think a maintenance branch for 2.0.1 (or whatever) should be created as part of the release process in case we need a quick release for critical bug fixes. The tree should be re-opened after the release via a message to python-dev after the release is published. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Mon Oct 16 22:46:22 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 15:46:22 -0500 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400." <20001016153513.A14693@amarok.cnri.reston.va.us> References: <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com> <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com> > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out, re-opening the tree for larger changes in a few > months? Or will you try to live with a CVS branch for 2.0 and re-open > the tree immediately? If we need to issue a patch release, we'll use a branch. That seems the only reasonable approach. The tree will be open for checkins as soon as 2.0 is released (tonight is looking good!), but I hope the people exercise some restraint and discuss their plans for significant checkins on the python-dev list first. A lot of things should probably be discussed in the form of PEPs too! --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Mon Oct 16 21:47:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 16 Oct 2000 15:47:05 -0400 Subject: [Python-Dev] Post-2.0 strategy In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > Then this is a good time to ask what strategy will be followed > post-2.0. Do you want a moratorium on massive checkins for a time > while 2.0 shakes out ... It's not a great time to ask, as we're still balls-to-the-wall *building* the release and doing last-second checkins (things like NEWS, not code). So there's an absolute ban on any checkins until further notice (on Python-Dev), excepting for those explicitly approved by Jeremy. After that, I agree with Fred that we should make a 2.0.1 branch simultaneous with the release. From jeremy at beopen.com Tue Oct 17 00:11:49 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT) Subject: [Python-Dev] Python 2.1 Release Schedule (tentative) Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net> FYI: In anticpation of the Python 2.0 final release this evening, we just created a new PEP describing the release schedule for Python 2.1. Jeremy PEP: 226 Title: Python 2.1 Release Schedule Version: $Revision: 1.1 $ Author: Jeremy Hylton Status: Incomplete Type: Informational Created: 16-Oct-2000 Python-Version: 2.1 Post-History: Abstract This document describes the post Python 2.0 development and release schedule. According to this schedule, Python 2.1 will be released in mid-March of 2001. The schedule primarily concerns itself with PEP-size items. Small bug fixes and changes will occur up until the first beta release. Tentative Release Schedule 16-Oct-2000: Python 2.0 final release These dates represent goals, not commitments. 16-Dec-2000: 2.1 PEPs ready for review 01-Feb-2001: First 2.1 beta release 16-Mar-2001: 2.1 final release Guidelines for making changes for Python 2.1 The guidelines and schedule will be revised based on discussion in the python-dev at python.org mailing list. The PEP system was instituted late in the Python 2.0 development cycle and many changes did not follow the process described in PEP 1. The development process for 2.1, however, will follow the PEP process as documented. The first eight weeks following 2.0 final will be the design and review phase. By the end of this period, any PEP that is proposed for 2.1 should be ready for review. This means that the PEP is written and discussion has occurred on the python-dev at python.org and python-list at python.org mailing lists. The next six weeks will be spent reviewing the PEPs and implementing and testing the accepted PEPs. When this period stops, we will end consideration of any incomplete PEPs. Near the end of this period, there will be a feature freeze where any small features not worthy of a PEP will not be accepted. Before the final release, we will have six weeks of beta testing and a release candidate or two. Bug fix releases before 2.1 We may have to issue Python 2.0.1 for critical bug fixes. If we need to issue a bug fix release, we will use a CVS branch. General guidelines for submitting patches and making changes Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SourceForge (SF) Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, must include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you should write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database (if you have access to the bug database). It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it must be fixed within 24 hours or it will be backed out. All contributed C code must be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code must follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From greg at cosc.canterbury.ac.nz Tue Oct 17 01:09:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT) Subject: [Python-Dev] The buffer interface In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz> Guido: > The buffer *API* doesn't guarantee enough about the lifetime of the > pointers for the buffer *object* to be able to safely preserve those > pointers, even if the buffer object holds on to the base object. This seems like a fatal flaw to me, which should have prevented the buffer object in its present form from ever having been implemented. I suggest that this problem MUST be fixed, or the buffer object removed entirely. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From gstein at lyra.org Tue Oct 17 03:57:09 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 16 Oct 2000 18:57:09 -0700 Subject: [Python-Dev] The buffer interface In-Reply-To: ; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700 References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> Message-ID: <20001016185709.J25097@lyra.org> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: >... > I think that buffer object is fairly important. They provide a mechanism > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > something that no other python object does, AFIAK. Perhaps clarifying the > interface (such as the slice operator returning a buffer, as suggested > below) and providing more hooks from Python for creating buffers (via > newmodule, say) would be helpful. There have been quite a few C extensions (and embedding Python!) where the buffer objects have been used in this fashion. For example, if you have a string argument that you wish to pass into Python, then you can avoid a copy by wrapping a Buffer Object around it and passing that. Many of the issues with the buffer object can be solved with simple changes. For example, the "mutable object" thing is easily dealt with by having the object not record the pointer, but just fetch it every time that it wants to do an operation. [ and if we extend the buffer API, we could potentially optimize the behavior to avoid the ptr refetch on each operation ] I don't recall the motivation for returning strings. I believe it was based on an attempt to make the buffer look as much like a string as possible (and slices and concats return strings). That was a poor choice :-) ... so, again, some basic changes to return slices and concats as buffer objects would make sense. Extending the buffer() builtin to create writeable buffer objects has been a reasonably common request. What seems to happen instead is that people developing C extensions (which desire buffer objects as their params) just add a new function to the extension to create buffer objects. Re: the buffer API: At the time the "s"/"t" codes were introduced (before 1.5.2 was released), we had a very different concept of how Unicode objects would be implemented. At that time, Unicode objects had no 8-bit representation (just 16-bit chars), so the difference was important. I'm not clued in enough on the ramifications of torching the difference in the API, but it would be a nice simplification. Buffers vs arrays: this is a harder question. Which is the "recommended binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. Arrays maintain their own memory. I believe the two models are needed, so I'd initially offer that both buffers and arrays need to be maintained. However, given that... what is the purpose of the array if a buffer can *also* maintain its own memory? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Tue Oct 17 05:35:02 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com> I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Oct 17 06:53:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT) Subject: [Python-Dev] CVS repository open for business Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com> The Python CVS repository is now open for further development. If critical patches are needed to the 2.0 release, they should be developed against the branch tagged "release20-maint", and should be posted at SourceForge and discussed here on python-dev before checking them into the branch. Thanks to all the Python developers for your hard work and contributions! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Oct 17 10:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 17 Oct 2000 10:16:56 +0200 Subject: [Python-Dev] The buffer interface References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <20001016185709.J25097@lyra.org> Message-ID: <39EC0AF8.5FA79E97@lemburg.com> Greg Stein wrote: > > On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote: > >... > > I think that buffer object is fairly important. They provide a mechanism > > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory), > > something that no other python object does, AFIAK. Perhaps clarifying the > > interface (such as the slice operator returning a buffer, as suggested > > below) and providing more hooks from Python for creating buffers (via > > newmodule, say) would be helpful. > > There have been quite a few C extensions (and embedding Python!) where the > buffer objects have been used in this fashion. For example, if you have a > string argument that you wish to pass into Python, then you can avoid a copy > by wrapping a Buffer Object around it and passing that. Perhaps we ought to flesh out the current uses of buffer objects and then decide how to proceed ?! IMHO, the problem with buffer objects (apart from the sometimes strange protocol behaviour) is that there too many "features" built into it. Simplification and possibly diversification is needed: instead of trying to achieve every possible C hack with buffer objects we should try to come up with a reasonably small set of types which allow only very basic tasks, e.g. 1. wrapping C memory areas with the possibility of accessing the raw bytes in a read-only way (this should be buffer()), 2. providing a non-copying object reference type (I'd call this reference()) and 3. maintaining a writeable C memory buffer (arrays provide this feature). The buffer object currently tries to do all three. > Many of the issues with the buffer object can be solved with simple changes. > For example, the "mutable object" thing is easily dealt with by having the > object not record the pointer, but just fetch it every time that it wants to > do an operation. > [ and if we extend the buffer API, we could potentially optimize the > behavior to avoid the ptr refetch on each operation ] Please don't extend the buffer API: the whole design is flawed since it undermines data encapsulation in very dangerous ways. If at all, we should consider a new API at abstract API level which doesn't return raw C pointers, but real Python objects (e.g. type 2 reference objects). > I don't recall the motivation for returning strings. I believe it was based > on an attempt to make the buffer look as much like a string as possible (and > slices and concats return strings). That was a poor choice :-) ... so, > again, some basic changes to return slices and concats as buffer objects > would make sense. +1. > Extending the buffer() builtin to create writeable buffer objects has been a > reasonably common request. What seems to happen instead is that people > developing C extensions (which desire buffer objects as their params) just > add a new function to the extension to create buffer objects. Please don't. Instead either suggest to use arrays or come up with some new type with the sole purpose of providing read-write access to a chunk of bytes. > Re: the buffer API: At the time the "s"/"t" codes were introduced (before > 1.5.2 was released), we had a very different concept of how Unicode objects > would be implemented. At that time, Unicode objects had no 8-bit > representation (just 16-bit chars), so the difference was important. I'm not > clued in enough on the ramifications of torching the difference in the API, > but it would be a nice simplification. Well, think of it this way: Unicode was the first object to actually try to make a difference between "s" and "t" -- and failed badly. In the end, we reverted the decision to make any difference and now special case Unicode objects in the getargs.c parser (so that "s" and "t" work virtually the same for Unicode). +1 on the idea of removing the difference altogether in 2.1. If anyone needs to a special representation of an object, the object should provide a clearly defined C API for this instead. E.g. Unicode has lots of APIs to encode Unicode into quite a few new repesentations. > Buffers vs arrays: this is a harder question. Which is the "recommended > binary type [for series of bytes]" ? Buffers can refer to arbitrary memory. > Arrays maintain their own memory. I believe the two models are needed, so > I'd initially offer that both buffers and arrays need to be maintained. > However, given that... what is the purpose of the array if a buffer can > *also* maintain its own memory? Right and that's the problem: buffers shouldn't be able to own memory. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From barry at scottb.demon.co.uk Tue Oct 17 10:40:52 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 17 Oct 2000 09:40:52 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net> Message-ID: <001201c03815$f54c4960$060210ac@private> The FreeBSD ports collection had to be updated to support importing C++ extensions with Python 1.5.2. (You get things like cout not defined when importing). Are the nessesary compile/link changes in 2.0? BArry From gstein at lyra.org Tue Oct 17 12:48:27 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 17 Oct 2000 03:48:27 -0700 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: ; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200 References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <20001017034827.F26804@lyra.org> [ moving from xml-sig to python-dev ] Reality check time... On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote: > [maintaining a pythonforge.org would take time and ressources] > > Yes. But I understand a commercial company (BeOpen) has taken over python > development. I think it is the kind of free services they could give > back to the python community. If VA Linux is already offering the service, then how does the community benefit from BeOpen offering the same thing? More importantly: how is BeOpen going to benefit from it? How do they get a business return on that investment? That *will* come into play, you know. Somebody has to pay for those sysadmins and hardware and connectivity. > > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-) > > > > I'd personally hope that python.org becomes accessible in that > > way. You could probably have all of the current content there, and > > then also have python.org/projects/pyxml; python.org/users/someone; > > xml.python.org (and whatever other gimmicks they offer). The last I heard, the intent was to move python.org from CNRI to a machine at VA Linux. The content would then become available for the community to work on; possibly through SourceForge facilities. > > One advantage of taking things off SF is that responsiveness of that > > system was really bad. That seems to have improved recently; > > My concern is not about responsiveness as much as distribution (as in > Internet is a distributed system). SourceForge is a great service. Good. > Now are we to host every single open source project on SourceForge ? If we > do so, the day SourceForge closes or changes its policy, or whatever, > every single open source project will be halted or maybe discontinued. There is no way that SF is ever going to close and take all of those projects with it. VA Linux would be see their business instantly vaporized. As ESR is fond to point out: VA Linux has built their business on trust from the community. *ANY* failure to meet that trust will kill their biz. > The people at SourceForge know their job: they provide a good service and > the tools (code+doc) to implement that same service at other places. > > Why wouldn't a community as big an active as python's put up ressources in > common to offer such a useful service, but dedicated to python > development ? There use to be a python.starship.net, maintained by > volunteers, that is now hosted by BeOpen. Why not take the next step ? python.starship.net has historically been a disaster area. Poorly maintained or (even worse) maintained by a whole bunch of people. Have you ever seen what happens when you give 20 people root access? Then there was the time that a drive crashed. The machine was *gone* for months. Oh, and the network connectivity loss. A month offline, maybe? The community is way to busy to run a service. Sorry. That is why I like SF so much. They are ready and willing to run a service and to fund that operation. And to all appearances, they are running it very well (and continually upgrading it!). > > if anybody is to host a similar server, they need to be aware that it > > is probably hard to compete with SF in terms of provided services. For > > example, I trust that SF has a reasonable backup strategy - they They do. It is somewhere on their site. They have a complete backup strategy. In fact, a while back, they lost a drive and restored most of it from backup. I forget if there was any actual material lost. > > simply can't risk a desaster. Anybody hosting a server for just a few > > projects would not get the same sort of trust from me. > > That's why I think we shouldn't look for someone able to host a server for > a few projects but for some company(ies) able to put up the ressources for > "python projects" and volunteers that help them. Idealistic, but it won't happen. starship.net is my case in point. > That would also make it easier for people to look for python ressources: > code in development would be at something.python.org and 3rd party > software at www.vex.net/parnassus. But I would agree that's a weak > argument as long as www.python.org continues to be well-maintained with > no broken links and stays the central hub for python information. When python.org moves, then it will be maintained much better. I don't recall the status of that, but I presume that Guido is still pushing to see it happen. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at python.org Tue Oct 17 05:35:02 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 16 Oct 2000 22:35:02 -0500 Subject: [Python-Dev] Python 2.0 final release is out! Message-ID: I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 17 16:06:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 09:06:00 -0500 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100." <001201c03815$f54c4960$060210ac@private> References: <001201c03815$f54c4960$060210ac@private> Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> > The FreeBSD ports collection had to be updated to support > importing C++ extensions with Python 1.5.2. (You get things > like cout not defined when importing). > > Are the nessesary compile/link changes in 2.0? Tell you what: I have no idea. :-( I believe there were some changes to the Makefile and/or config file to support C++, but I don't know if this works on FreeBSD. I'm not a big C++ user myself, so I rarely try this... Can you try it? If it doesn't work out of the box, let's sit down together and figure out a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Oct 17 15:59:46 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> [Moved to python-dev, since the shift has begun.] Nicolas Chauvat writes: > I'm sure several people from PythonLabs are on this list. What is their > opinion ? I rather like letting the SourceForge crew take care of running the service. Running a website that needs constant updates is no trivial matter, and SourceForge is *much* more complex than that! I have a great deal of respect for the hard work that I know goes into running SourceForge, and would rather see that effort bolstered by volunteers & contributions (docs, code, whatever) by people who are able, than to see the efforts splintered. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Nicolas.Chauvat at logilab.fr Tue Oct 17 16:07:36 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com> Message-ID: > I have a great deal of respect for the hard work that I know goes > into running SourceForge, and would rather see that effort bolstered > by volunteers & contributions (docs, code, whatever) by people who are > able, than to see the efforts splintered. Hum, maybe I did not explain myself correctly and I don't want a misunderstanding: I never meant "let's create a SourceForge-like tool, SourceForge is bad", but only "why not host a python specific service using the SourceForge code and tools", as www.bioinformatics.org does for projects related to bio-ingeneering. -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From guido at python.org Tue Oct 17 17:26:31 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 17 Oct 2000 10:26:31 -0500 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200." References: Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> > Hum, maybe I did not explain myself correctly and I don't want a > misunderstanding: I never meant "let's create a SourceForge-like tool, > SourceForge is bad", but only "why not host a python specific service > using the SourceForge code and tools", as www.bioinformatics.org does for > projects related to bio-ingeneering. Why not indeed? Why spend time running a service that SourceForge is already providing, and very well at that? This has come up occasionally at BeOpen but the only argument for it that was ever brought up (by the marketing folks, of course :-) was the hope that it would help sell banner ads -- not that there would be an advantage for the community. What would be the advantage for the community or running our own? What's wrong with using SourceForge? I say, if it ain't broke don't fix it. (And then again, there may be a very good reason to run our own, and maybe I just don't see it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Tue Oct 17 17:11:11 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 17 Oct 2000 17:11:11 +0200 Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500 References: <200010171526.KAA09461@cj20424-a.reston1.va.home.com> Message-ID: <20001017171111.K12812@xs4all.nl> On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote: > > Hum, maybe I did not explain myself correctly and I don't want a > > misunderstanding: I never meant "let's create a SourceForge-like tool, > > SourceForge is bad", but only "why not host a python specific service > > using the SourceForge code and tools", as www.bioinformatics.org does for > > projects related to bio-ingeneering. > What would be the advantage for the community or running our own? > What's wrong with using SourceForge? I say, if it ain't broke don't > fix it. (And then again, there may be a very good reason to run our > own, and maybe I just don't see it. :-) There is no advantage that I know of. I know a lot about keeping machines and websites up and running (that's what I do for a living(*), after all) and I can tell you you need a big (or very dedicated) sysadmin staff to be able to offer anything as reliable as SourceForge. So the website & CVS tree itself could be run on a low-end machine. Say a PII-300 with 128 MB RAM. You need at least two, preferably three machines, regardless of performance, to be able to offer 'reliable' services. Preferably load-balanced by something like a smart switch (we use Alteon Layer-4 ethernet switches for that task, and you can do cool things with them. They're also pretty expensive.) And you need a way to back it up. A tape library or DAT streamer of some kind. Preferably a separate machine to do the actual backups. Live or fast-cycled backups can also be a lifesaver, which either requires another machine or two with speedy disks, or storing your data on something dedicated like a NetApp Filer. (Very cool machine, a dedicated NFS and CIFS (SMB) fileserver with excellent live backups, 'snapshots', as many as you want/need. Only costs you diskspace. Oh, and this quality comes at a price, too, of course.) And then there's the reliable network access, reliable system room (with reliable and preferably redundant power), and the 24/7 warning system that wakes up stand-by sysadmins to fix problems. And for the specialized hardware and software, you need a few people who know how to handle them. You need several people anyway, to cover all bases even in the face of illness, vacations and the famous bus accidents. We have a crew of 12 now, with a few new additions, and even then we run into trouble with vacations. I dare say we offer more reliable services than SourceForge does, but we also cost more :-) In short, the only advantage to not using SourceForge is that you can do things SourceForge can't or won't. Run software SourceForge won't, for instance. However, I would strongly suggest making such software 'non-essential', keeping most of the stuff on SourceForge, spend lots less money on the technical setup, and suffer a bit when the service is down. *) Where living is defined as 'making enough money to stay breathing and work on Python', and 'work on Python' has higher importance, of course :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Tue Oct 17 18:47:34 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 12:47:34 -0400 Subject: [Python-Dev] Publicity for 2.0 release? Message-ID: Is BeOpen doing any publicity for the release of 2.0? For example, issuing a press release and sending it to lots of different publications, such as DDJ, Web Development, Windows programming magazines, whatever that XML magazine is called, etc.? (Hmm... www.beopen.com hasn't been updated to mention the new release -- nor even 2.0c1.) --amk From pf at artcom-gmbh.de Tue Oct 17 19:21:19 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST) Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm" Message-ID: Andrew Kuchling: > Is BeOpen doing any publicity for the release of 2.0? For example, > issuing a press release and sending it to lots of different > publications, such as DDJ, Web Development, Windows programming magazines, > whatever that XML magazine is called, etc.? > > (Hmm... www.beopen.com hasn't been updated to mention the new release > -- nor even 2.0c1.) Really bad marketing! ;-) But not as bad as it could have been: Other places hopping into my mind were: http://slashdot.org/ (already done, see below) http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) http://www.newsforge.com/ (didn't see Python mentioned there yet) and not to forget http://www.python.org/ (already done) quoting from slashdot: """Python 2.0 Released Posted by timothy on 5:34 Tuesday 17 October 2000 from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept. atallah writes: "It would appear that the long awaited Python 2.0 was finally released today. The front page of the Web site has the announcement." According to that announcement, Python 2.0 will receive minor-version updates around every 6 months, even as work begins on the shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list includes "full XML support and several forms of new syntax," as well as the BeOpen label. ( Read More... | 164 comments ) """ Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From akuchlin at mems-exchange.org Tue Oct 17 19:33:22 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 17 Oct 2000 13:33:22 -0400 Subject: [Python-Dev] Publicity for 2.0 release? In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200 References: Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us> On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote: > http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits) By Jeremy, actually. I'm not sure why it lists my name instead -- Freshmeat bug? --amk From hinsen at cnrs-orleans.fr Tue Oct 17 22:27:10 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:10 +0200 Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16 Oct 2000 10:38:11 -0700) References: <39EB3D03.A00C78B6@jps.net> Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr> > Are people doing the kind of numeric programming with "complex > algorithms" using Python that Konrad refers to? More importantly, how > many people? At least one: me. > > Guido thinks that 2/3 returning 0 was a design mistake, > > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > > users won't know what to do with a complex number, so it's "an error" to > > them. > > Guido's philosophy is clearly that Python defaults should be geared to > "Most Python users". I agree, and as I wrote in an earlier post, the It's difficult to say what "most Python users" want; it's not a static community. I'd say the basic principle is "no bad surprises". 2/3 == 0 is a bad surprise for anyone who knows elementary math but is not familiar with certain programming languages, especially since the program goes on silently with a "wrong" intermediate result. > Maybe we can have true 754 compliance in Py3k, and we can all be happy!! Py3k forever! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Nicolas.Chauvat at logilab.fr Wed Oct 18 10:35:02 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST) Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de> Message-ID: On Tue, 17 Oct 2000, Martin v. Loewis wrote: [about my suggestion concerning a SourceForge dedicated to python] That was only a suggestion, not a demand as someone stated. I would love to set up a pythonforge myself if I had the resources, unfortunately I don't... maybe in a few months? Time will tell. For now I'll just go back to hacking and keep quiet. Cheers, :) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From barry at scottb.demon.co.uk Wed Oct 18 11:57:04 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 18 Oct 2000 10:57:04 +0100 Subject: [Python-Dev] build problems large and small on FreeBSD In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com> Message-ID: <001401c038e9$c4cabbd0$060210ac@private> O.k. will do, hopefully this weekend. BArry > -----Original Message----- > From: guido at cj20424-a.reston1.va.home.com > [mailto:guido at cj20424-a.reston1.va.home.com]On Behalf Of Guido van > Rossum > Sent: 17 October 2000 15:06 > To: Barry Scott > Cc: jeremy at beopen.com; python-dev at python.org > Subject: Re: [Python-Dev] build problems large and small on FreeBSD > > > > The FreeBSD ports collection had to be updated to support > > importing C++ extensions with Python 1.5.2. (You get things > > like cout not defined when importing). > > > > Are the nessesary compile/link changes in 2.0? > > Tell you what: I have no idea. :-( > > I believe there were some changes to the Makefile and/or config file > to support C++, but I don't know if this works on FreeBSD. I'm not a > big C++ user myself, so I rarely try this... > > Can you try it? If it doesn't work out of the box, let's sit down > together and figure out a fix. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > From mal at lemburg.com Wed Oct 18 18:03:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 18 Oct 2000 18:03:16 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? Message-ID: <39EDC9C4.7D61454@lemburg.com> Before starting to work on postponed patches and checking them in: is the current CVS tree ready for new checkins (tags applied, etc.) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Wed Oct 18 18:29:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <39EDC9C4.7D61454@lemburg.com> References: <39EDC9C4.7D61454@lemburg.com> Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Before starting to work on postponed patches and checking them > in: is the current CVS tree ready for new checkins (tags applied, > etc.) ? Yes; I posted a note re-opening the tree yesterday (or late Monday night; I can't remember that far back). We've just been too tired to do a lot since the release. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Wed Oct 18 18:52:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 12:52:52 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > We've just been too tired to do a lot since the release. ;) LOL! You're the very soul of diplomacy, Fred -- but I guess, overall, it really is prudent not to mention all our recent suicide attempts . my-wrists-are-killing-me-ly y'rs - tim From skip at mojam.com Wed Oct 18 19:19:25 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> Message-ID: <14829.56221.303087.523464@beluga.mojam.com> Tim> my-wrists-are-killing-me-ly y'rs - tim You need my typing watcher: http://www.musi-cal.com/~skip/python/watch.py Only problem is I never figured out how to make it watch keystrokes directly. It detects mouse movement. Since I do most of my typing in Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the mouse a little... I've tried, so far unsuccessfully, to make this a SourceForge project. I've even asked for help from SF, but their response wasn't helpful, and the round-trip time for a response is too long to make pursuing that path worthwhile. The watch project is at http://sourceforge.net/projects/watch/ All I have is a CVSROOT/modules file. Nothing I've tried has successfully imported the one project file into cvs. If anyone has any suggestions for kickstarting this thing, it would be much appreciated. Thx, Skip From thomas at xs4all.net Wed Oct 18 20:43:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 18 Oct 2000 20:43:19 +0200 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> Message-ID: <20001018204319.L12812@xs4all.nl> On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote: > Tim> my-wrists-are-killing-me-ly y'rs - tim > You need my typing watcher: Given his remark about suicide attempts, I'm not sure if Tim really meant 'RSI' when he wrote that :-) > http://www.musi-cal.com/~skip/python/watch.py > Only problem is I never figured out how to make it watch keystrokes > directly. It detects mouse movement. Since I do most of my typing in > Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the > mouse a little... Funny, a colleague of mine has a similar tool. Also written in Python, I think, though it may have been created in his Perl Period. On a linux box, you can determine keystrokes by using /proc/interrupts. At least, if your keyboard has an interrupt all for itself. (Pretty likely, really :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Oct 18 21:11:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <20001018204319.L12812@xs4all.nl> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> Message-ID: <14829.62936.109759.567547@beluga.mojam.com> Thomas> On a linux box, you can determine keystrokes by using Thomas> /proc/interrupts. At least, if your keyboard has an interrupt Thomas> all for itself. (Pretty likely, really :) Thanks, Neil S. sent me a patch for that already. I'll try to work it into the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or other Unix flavors? I suspect I'll just have to bite the bullet and work in platform-dependent code for this. Skip From esr at thyrsus.com Wed Oct 18 21:36:01 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 18 Oct 2000 15:36:01 -0400 Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500 References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <20001018153601.A18127@thyrsus.com> Skip Montanaro : > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Might this monitoring function be a candidate for the Python library when it's done? -- Eric S. Raymond A man with a gun is a citizen. A man without a gun is a subject. From cgw at fnal.gov Wed Oct 18 21:53:09 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov> Skip Montanaro writes: > > Thanks, Neil S. sent me a patch for that already. I'll try to work it into > the code. Anyone have any idea how to monitor keystrokes on Windows, Mac or > other Unix flavors? I suspect I'll just have to bite the bullet and work in > platform-dependent code for this. Can't tell you about Windows or Mac, but for Unix I'd read the file driver/timers.c in the XScreensaver distribution (www.jwz.org). This code is pretty sophisticated and runs on all the major Unix flavors. From skip at mojam.com Wed Oct 18 22:22:45 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov> References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com> <14829.65445.421622.258893@buffalo.fnal.gov> Message-ID: <14830.1685.932659.181060@beluga.mojam.com> Charles> ... but for Unix I'd read the file driver/timers.c in the Charles> XScreensaver distribution (www.jwz.org). This code is pretty Charles> sophisticated and runs on all the major Unix flavors. Thanks, Charles. I will check it out. Those of you who are former (or current) od users will appreciate Jamie Zawinski's home page even if you're not interested in this topic. I revisit his site periodically. I'm never disappointed... Skip From est at hyperreal.org Wed Oct 18 22:30:46 2000 From: est at hyperreal.org (est at hyperreal.org) Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT) Subject: [Python-Dev] Ready for Python 2.1 ? In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro at "Oct 18, 2000 03:22:45 pm" Message-ID: <20001018203047.27215.qmail@hyperreal.org> Skip Montanaro discourseth: > > Those of you who are former (or current) od users will appreciate Jamie > Zawinski's home page even if you're not interested in this topic. I revisit > his site periodically. I'm never disappointed... Looks more like emacs hexl-mode to me. Hmm..I guess you got this thread off topic. :) E From martin at loewis.home.cs.tu-berlin.de Wed Oct 18 23:09:36 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 18 Oct 2000 23:09:36 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> What is the reason for not publishing Python 2.0 on SF for download? SF certainly wouldn't be the primary source, but I think at least the source distribution should be available there, with the release notes telling where to get binary distributions (BeOpen, ActiveState, who else?) Regards, Martin From tim_one at email.msn.com Wed Oct 18 23:34:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 18 Oct 2000 17:34:38 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: [Martin v. Loewis] > What is the reason for not publishing Python 2.0 on SF for download? From gstein at lyra.org Thu Oct 19 00:44:13 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 18 Oct 2000 15:44:13 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400 References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> Message-ID: <20001018154413.A31010@lyra.org> On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote: > [Martin v. Loewis] > > What is the reason for not publishing Python 2.0 on SF for download? > > >From BeOpen.com's POV, so long as they were paying major bills, they would > rather have download traffic tickle their ad banners than SF's ad banners. > > >From our (PythonLabs) POV, another publishing site is more work, and one URL > is about as good as any other. Besides, rising to the top of SF's "most > active" list has not been an explicit life goal for any of us . And here is where the larger community can help. Presuming that non-admins can publish files, then we could take on the burden of publishing the files via SF. > > SF certainly wouldn't be the primary source, but I think at least the > > source distribution should be available there, with the release notes > > telling where to get binary distributions (BeOpen, ActiveState, who > > else?) > > I didn't see any advantage claimed for publishing on SF. Without an > advantage, the work/benefit ratio is infinite. Work == 0 for you guys, presuming that non-admins can publish. [ off to take a look... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at mems-exchange.org Thu Oct 19 18:20:37 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 12:20:37 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us> Before we all become focused on new features for Python 2.1, it would be nice to do a bit more work on raising awareness of the new features in 2.0. There's little point in developing software if you don't actually tell anyone about it, after all. I'd like to suggest that people try to write some brief articles, just a few pages long, each covering a particular feature in some detail. Looking through the list of new stuff, the most significant features are: * Unicode support. (Perl's UTF-8 support still seems incomplete, with developers referring to it as "unusable", so we should definitely try and point out that we have working Unicode support right now.) * Distutils: an introduction to writing setup scripts for simple Python modules, packages, and C extensions. * The new XML tools. * The new gettext support. * Maybe the linuxaudiodev module, too. Any other suggestions? If the story of how a particular feature was implemented is interesting, then that would also make a fine topic for a more developer-oriented publication such as DDJ. SRE or Unicode may be the best candidates for this sort of thing, as their implementation presented various tricky technical problems along the way. Any volunteers? --amk From gvwilson at nevex.com Thu Oct 19 18:53:31 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > Before we all become focused on new features for Python 2.1, it would be > nice to do a bit more work on raising awareness of the new features in 2.0. "Doctor Dobb's Journal" would be very interested in articles --- 3000 words (plus or minus), plus some code examples and diagrams. > * Unicode support. (Perl's UTF-8 support still seems incomplete, with > developers referring to it as "unusable", so we should definitely try and > point out that we have working Unicode support right now.) Definitely --- the practical details of implementing Unicode, and a Unicode-aware regular expression engine, would be very interesting to our readers. However, please steer clear of saying, "And anyway, Perl is broken." (I just got a review copy of Hunt and Thomas's book on Ruby. There are three places in the first two chapters where they say, "And Ruby has more users in Japan than Python." I'll finish the book anyway.) > * Distutils: an introduction to writing setup scripts for simple > Python modules, packages, and C extensions. Possibly interesting; would be more so if Distutils could be applied/was being applied to installation problems in other languages. > * The new XML tools. Definitely. > * The new gettext support. > * Maybe the linuxaudiodev module, too. These are both probably too specialized... > Any other suggestions? The garbage collector: Java and Ruby both score points by having full garbage collection, so its availability in Python 2.0 (along with a discussion of the things that might break or change as a result) would be very interesting. Thanks, Greg (a contributing editor with DDJ) From nas at arctrix.com Thu Oct 19 12:09:52 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 19 Oct 2000 03:09:52 -0700 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019030952.A32671@glacier.fnational.com> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: > The garbage collector: Java and Ruby both score points by having full garbage > collection, so its availability in Python 2.0 (along with a discussion of the > things that might break or change as a result) would be very interesting. This is on my todo list. I think there are some interesting implementation issues. Also, the article would be useful documentation for python-dev type people. Neil From akuchlin at mems-exchange.org Thu Oct 19 19:32:08 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:32:08 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: ; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >"Doctor Dobb's Journal" would be very interested in articles --- 3000 words >(plus or minus), plus some code examples and diagrams. I was thinking more about on-line places such as oreillynet.com/python/, but DDJ would be better still. >The garbage collector: Java and Ruby both score points by having full garbage >collection, so its availability in Python 2.0 (along with a discussion of the >things that might break or change as a result) would be very interesting. Arising out of lunch-time discussion, a comparison of how different FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection would be interesting, though perhaps unsuitable for DDJ, since the topic is a rather unfocused one. --amk From martin at loewis.home.cs.tu-berlin.de Thu Oct 19 19:31:58 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 19 Oct 2000 19:31:58 +0200 Subject: [Python-Dev] This Project Has Not Released Any Files Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> [Tim Peters] > From BeOpen.com's POV, so long as they were paying major bills, they > would rather have download traffic tickle their ad banners than SF's > ad banners. Even though this should have been clear to me all the time, stating it explicitly triggers alarms for me. I just checked, and it appears that Python 2.0 is not available for download via ftp. In particular, it is not available via ftp from ftp.python.org! If it was there, mirrors all over the world would pick it up and bring it in a location near me (ftp.fu-berlin.de would be nearest) (*). So while making it available on SF may indeed give no advantage, making it available on python.org would provide users with alternative download locations, so that I don't feel the bandwidth limitation that Web download from pythonlabs.com produces. That would be a clear advantage to me, at least. Of course, having ftp mirrors would mean that many downloads do not tickle anybody's ad banners - which would probably be in the interest of other users as well, just not in the interest of BeOpen. So I'm curious how this conflict of interest is resolved... Regards, Martin (*) ftp://ftp.python.org/python/src/README does not even mention Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Note that some mirrors only collect the this directory (src), and the doc and contrib siblings, while the ftp master site, , has much more. "Much more" may be true, just nothing recent... I probably should ask ftpmaster.python.org to put Python-2.0.tar.gz in that directory. From akuchlin at mems-exchange.org Thu Oct 19 19:42:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 13:42:19 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >(*) ftp://ftp.python.org/python/src/README does not even mention >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says Unless one of the BeOpen Pythoneers is already going to do this, I'll go ahead and drop the relevant files into places. Guys? While we're at it, how about making the filenames for the source code consistent? -rw-r--r-- 1 guido psa 2533053 Apr 13 1999 py152.tgz -rw-r--r-- 1 1103 psa 2259957 Oct 31 1998 pyth151.tgz -rw-r--r-- 1 guido psa 1907724 May 31 1995 python1.2.tar.gz -rw-r--r-- 1 guido psa 2037062 Oct 12 1995 python1.3.tar.gz -rw-r--r-- 1 guido psa 2252481 Oct 25 1996 python1.4.tar.gz -rw-r--r-- 1 guido psa 2904353 Jan 3 1998 python1.5.tar.gz I like pythonX.X.tar.gz best, and will change the filenames (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. Though isn't the standard GNU naming convention more like python-1.5.tar.gz? --amk From esr at thyrsus.com Thu Oct 19 20:05:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 19 Oct 2000 14:05:48 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019140548.A21315@thyrsus.com> Andrew Kuchling : > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? It is, and I wish we'd move to it as did the Perl guys. It makes life substantially easier to have really uniform naming conventions, especially for programs like the Metalabs file clerk. -- Eric S. Raymond Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' From mwh21 at cam.ac.uk Thu Oct 19 20:01:29 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Oct 2000 19:01:29 +0100 Subject: [Python-Dev] 2.0 articles In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400" References: <20001019122037.C21214@kronos.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Before we all become focused on new features for Python 2.1, it would > be nice to do a bit more work on raising awareness of the new features > in 2.0. There's little point in developing software if you don't > actually tell anyone about it, after all. > > I'd like to suggest that people try to write some brief articles, just > a few pages long, each covering a particular feature in some detail. [snip] > Any volunteers? It's not as exciting as Unicode or XML, but I've thrashed out a few hundred words on the new "setdefault" dictionary method. It's up here: http://starship.python.net/crew/mwh/hacks/setdefault.html Tell me what you think! There's the beginning of a longer example in a comment at the bottom, but I felt it was getting a bit long-winded to be of interest. Cheers, M. -- If i don't understand lisp, it would be wise to not bray about how lisp is stupid or otherwise criticize, because my stupidity would be archived and open for all in the know to see. -- Xah, comp.lang.lisp From gstein at lyra.org Thu Oct 19 20:52:53 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:52:53 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> Message-ID: <20001019115253.W31108@lyra.org> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >... > Of course, having ftp mirrors would mean that many downloads do not > tickle anybody's ad banners - which would probably be in the interest > of other users as well, just not in the interest of BeOpen. So I'm > curious how this conflict of interest is resolved... Stating that a "conflict of interest" even EXISTS is a rather sorry statement on things. -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Oct 19 20:54:36 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 19 Oct 2000 11:54:36 -0700 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> Message-ID: <20001019115436.X31108@lyra.org> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: > On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: > >(*) ftp://ftp.python.org/python/src/README does not even mention > >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says > > Unless one of the BeOpen Pythoneers is already going to do this, I'll > go ahead and drop the relevant files into places. Guys? Please... just do it. >... > I like pythonX.X.tar.gz best, and will change the filenames (leaving > bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed. > Though isn't the standard GNU naming convention more like > python-1.5.tar.gz? I'm with Eric -- go for the GNU standard. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at mems-exchange.org Thu Oct 19 21:11:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 19 Oct 2000 15:11:42 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us> On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote: >On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> Unless one of the BeOpen Pythoneers is already going to do this, I'll >> go ahead and drop the relevant files into places. Guys? >Please... just do it. I charged ahead and did it anyway; the Pythoneers can spank me for it later. (Worse, maybe they'll do something *bad* to me...) There were already doc/1.6/ and doc/2.0/ directories, and binaries (Windows, RPMs) were in /pub/python/2.0/, along with the source. So I only touched /pub/python/src/. All the releases and betas are now consistently named python-X.Y.Z.tar.gz. I've left symlinks in place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final releases, but didn't bother making links for releases older than 1.5.1 or for beta versions, so any FTP URLs pointing directly to those files will be broken. --amk From jeremy at alum.mit.edu Fri Oct 20 18:28:19 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <20001019115436.X31108@lyra.org> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote: >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote: >> >(*) ftp://ftp.python.org/python/src/README does not even mention >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says >> >> Unless one of the BeOpen Pythoneers is already going to do this, >> I'll go ahead and drop the relevant files into places. Guys? GS> Please... just do it. In the interest of making the distribution as widely available as possible, I've placed files on SourceForge and at http://www.python.org/2.0/ >> ... I like pythonX.X.tar.gz best, and will change the filenames >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless >> vetoed. Though isn't the standard GNU naming convention more >> like python-1.5.tar.gz? GS> I'm with Eric -- go for the GNU standard. I used the file name conventions that we used throughout the 2.0 release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU standard or not (didn't realize it was a standard; don't know where to find said standard; or is it just a custom?) Jeremy From jeremy at alum.mit.edu Fri Oct 20 18:31:47 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT) Subject: [Python-Dev] 2.0 articles In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us> References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote: >> "Doctor Dobb's Journal" would be very interested in articles --- >> 3000 words (plus or minus), plus some code examples and diagrams. AMK> I was thinking more about on-line places such as AMK> oreillynet.com/python/, but DDJ would be better still. And, of course, there's the Python conference: http://python9.org/ >> The garbage collector: Java and Ruby both score points by having >> full garbage collection, so its availability in Python 2.0 (along >> with a discussion of the things that might break or change as a >> result) would be very interesting. AMK> Arising out of lunch-time discussion, a comparison of how AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with AMK> garbage collection would be interesting, though perhaps AMK> unsuitable for DDJ, since the topic is a rather unfocused one. A comparison of different FFIs with respect to garbage collection might be interesting; hard to say without seeing what the conclusions are. Jeremy From akuchlin at mems-exchange.org Fri Oct 20 18:26:56 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:26:56 -0400 Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400 References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote: >release cycle, e.g. Python-2.0.tar.gz. I don't know if that's the GNU >standard or not (didn't realize it was a standard; don't know where to >find said standard; or is it just a custom?) See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24 Though I think here the standard is just codifying an existing custom that's proved convenient. www.fsf.org seems unresponsive at the moment, hence the strange link; is *every* Web site in the world breaking today for some reason? --amk From akuchlin at mems-exchange.org Fri Oct 20 18:28:10 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Oct 2000 12:28:10 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400 References: <20001019122037.C21214@kronos.cnri.reston.va.us> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net> Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us> On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote: >And, of course, there's the Python conference: http://python9.org/ That's preaching to the converted, though. --amk From fdrake at acm.org Fri Oct 20 18:51:44 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT) Subject: [Python-Dev] This Project Has Not Released Any Files In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net> References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net> Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ There's a separate python-rpms "Package"; the RPM files should go there (I think). -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From thomas at xs4all.net Fri Oct 20 22:21:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 20 Oct 2000 22:21:18 +0200 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: ; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100 References: Message-ID: <20001020222118.M12812@xs4all.nl> On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote: > "Jean-Claude Levieux" writes: > > I just tried to compile Python 2.0. > > on BSDI BSD/OS 4.0.1 [ Sorry, missed the original message. Used the Archive to find it, tho ] > Random guess, but you are using a ANSI C compiler, aren't you? Python > 2.0 now demands that. BSDI uses gcc, so that's not the problem. Neither are these three warnings: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype /usr/include/wchar.h:17: warning: function declaration isn't a prototype (or any other warnings regarding 'function decl isn't a prototype) They are a result of Python using '-Wstrict-prototypes' by default, if the compiler is gcc. It just means BSDI declares a few functions without specifying argument lists (prototypes) and has nothing to do with Python (other than that Python always defines CFLAGS to contain -Wstrict-prototypes.) There isn't an easy way to get this 'fixed', unfortunately. If you want to quench the warnings, you'll have to edit ./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile, and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly, because it's overwritten by the 'makesetup' script, which parses the Setup file.) As for the other error, that's really an error :( ../libpython2.0.a(fileobject.o): In function portable_fseek': /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined reference to `TELL64' The problem is that BSDI has an 'off_t' type that is larger than the 'long' type, and Python's configure makes the flawed assumption that this means BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug is even present with BSDI 4.1, and probably more platforms. You can fix this by editing './config.h' after running './configure', and commenting out the HAVE_LARGEFILE_SUPPORT line; changing this: #define HAVE_LARGEFILE_SUPPORT 1 into something like this: /* #define HAVE_LARGEFILE_SUPPORT 1 */ (You can just remove the line as well.) The downside of both these 'hacks' (excuse me, 'hotfixes'), is that you'll have to reedit the files again after running configure again (or something that runs configure, like 'config.status'.) I see a total of three bugs here: Python adds -Wstrict-prototypes even though it can generate a lot of warnings that aren't related to Python; there is no way to override the CFLAGS variable (you can pass it to configure, and it uses it at first, but then just overwrites it); and mis-detecting large file support. I can't decide which of the last two is the biggest bug :-) I would write a patch for the lot of 'm, but I'm in the middle of getting ready to head to London for the Apache conference (any other Pythonistas going ? :) and Have I Got News For You is about to start on BBC1. If you don't do it, Jean-Claude, I'll submit bugreports on these when I'm back, next Thursday. (Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1. You can leave them on for 4.1, but 4.0.1 has very broken threads, and it will cause lots of problems in the signal module if you leave them on. You can disable them by using '--with-threads=no' -- this is also listed in the README, by the way. And note that BSDI 4.1 only has the large file support problem, none of the others, and I strongly suggest upgrading for other reasons as well.) Python-dev: CC'd because this is material for a bugfix-release. There are likely to be other platforms hit by the large filesupport misdetection. Don't think this is enough to warrant a bugfix release (it's not *that* brownbaggy) but it should definately go in if there is one ;P If I or someone else didn't fix it by the time a bugfix release is considered, please hit me. I also appologize for not properly testing Python 2.0 on BSDI 4.0.1 or 4.1... We still have those machines, but we are using less and less of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux :) BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all- -those-good-sides-too-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at ActiveState.com Fri Oct 20 22:54:59 2000 From: trentm at ActiveState.com (Trent Mick) Date: Fri, 20 Oct 2000 13:54:59 -0700 Subject: [Python-Dev] Re: Compiling python 2.0 In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200 References: <20001020222118.M12812@xs4all.nl> Message-ID: <20001020135459.C1562@ActiveState.com> On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote: > As for the other error, that's really an error :( > > ../libpython2.0.a(fileobject.o): In function portable_fseek': > /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined > reference to `TELL64' > > The problem is that BSDI has an 'off_t' type that is larger than the 'long' > type, and Python's configure makes the flawed assumption that this means > BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug > is even present with BSDI 4.1, and probably more platforms. You can fix this > by editing './config.h' after running './configure', and commenting out the > HAVE_LARGEFILE_SUPPORT line; changing this: > > #define HAVE_LARGEFILE_SUPPORT 1 > > into something like this: > > /* #define HAVE_LARGEFILE_SUPPORT 1 */ > > (You can just remove the line as well.) The downside of both these 'hacks' > (excuse me, 'hotfixes'), is that you'll have to reedit the files again after > running configure again (or something that runs configure, like > 'config.status'.) This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see a pattern) http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 It was fixed by adding a hack in fileobject.c to *define* TELL64. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470 For the quickfix, the same hack could be used for BSDI. As you suggest Thomas, the proper fix is to patch configure.in such that it does not report that these system support largefiles. I don't have the time to do this right away, nor do I have one of these boxes on which to test it. I can try to make a patch though. We don't you file a bug and assign it to me. Trent -- Trent Mick TrentM at ActiveState.com From martin at loewis.home.cs.tu-berlin.de Fri Oct 20 22:54:02 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 20 Oct 2000 22:54:02 +0200 Subject: [Python-Dev] This Project Has Released Files Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de> > In the interest of making the distribution as widely available as > possible, I've placed files on SourceForge and at > http://www.python.org/2.0/ Thanks! also to anybody else contributing to the release process, in particular to amk for his ongoing maintainance of various pieces on python.org, and his efforts in getting the word out. Regards, Martin From cgw at fnal.gov Fri Oct 13 17:11:03 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT) Subject: [Python-Dev] can't build with threads on OSF/1 Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov> Sorry, I don't have time to investigate this fully right now. Maybe this weekend. For now this is just a heads-up. Hopefully, something is just misconfigured on this system. The machine in question is running OSF1 V4.0 878 alpha I can only build Python from current CVS sources on OSF/1 if I specify --without-thread. If I don't specify this I get the following errors at link time: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach Below find the output of cc -V as well as the output of ./configure and make (sorry for the flood, I assume too much detail is better than not enough) creating cache ./config.cache checking MACHDEP... osf1V4 checking for --without-gcc... checking for --with-cxx=... no checking for gcc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for --with-suffix... checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... cc -E checking for AIX... no checking for minix/config.h... no checking whether cc accepts -OPT:Olimit=0... no checking whether cc accepts -Olimit 1500... yes checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... no checking for poll.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for db_185.h... no checking for db.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for pty.h... yes checking for libutil.h... no checking for ndbm.h... yes checking for db1/ndbm.h... no checking for gdbm/ndbm.h... no checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of char... 1 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking size of fpos_t... 8 checking for long long support... yes checking size of long long... 8 checking for uintptr_t support... no checking size of off_t... 8 checking whether to enable large file support... no checking size of time_t... 4 checking for pthread_t... yes checking size of pthread_t... 8 checking for --with-next-framework... no checking for --with-dyld... no checking SO... .so checking LDSHARED... ld -shared -expect_unresolved "*" checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... no checking for shl_load in -ldld... no checking for --with-pydebug... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for --with-libs... no checking for --with-dec-threads... no checking for --with-threads... yes checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... yes checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking for --with-cycle-gc... yes checking for --with-libdb... yes checking for dbopen... no checking for --with-wctype-functions... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for dlopen... yes checking DYNLOADFILE... dynload_shlib.o checking for alarm... yes checking for chown... yes checking for clock... yes checking for confstr... yes checking for ctermid... yes checking for ctermid_r... no checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... yes checking for fpathconf... yes checking for ftime... yes checking for ftruncate... yes checking for getgroups... yes checking for getlogin... yes checking for getpeername... yes checking for getpid... yes checking for getpwent... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for mremap... no checking for nice... yes checking for pathconf... yes checking for pause... yes checking for plock... yes checking for poll... yes checking for pthread_init... no checking for putenv... yes checking for readlink... yes checking for select... yes checking for setegid... yes checking for seteuid... yes checking for setgid... yes checking for setlocale... yes checking for setregid... yes checking for setreuid... yes checking for setsid... yes checking for setpgid... yes checking for setuid... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... yes checking for strftime... yes checking for strptime... yes checking for symlink... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for tempnam... yes checking for timegm... no checking for times... yes checking for tmpfile... yes checking for tmpnam... yes checking for tmpnam_r... no checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for _getpty... no checking for openpty... yes checking for forkpty... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... yes checking for ftell64... no checking for ftello... no checking for statvfs... yes checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... yes checking for setpgrp... yes checking for gettimeofday... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for member tm_zone in aggregate type struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for inline... __inline checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... yes checking gethostbyname_r with 6 args... yes checking for __fpu_control... no checking for __fpu_control in -lieee... no checking for --with-fpectl... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for genuine getopt... yes checking what malloc(0) returns... null checking for wchar.h... yes checking for usable wchar_t... no checking whether byte ordering is bigendian... no checking whether right shift extends the sign bit... yes checking for socklen_t... no updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Grammar/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.config creating config.h (cd Modules; make -f Makefile.pre Makefile) + cp ./Setup.in Setup rm -rf ../libpython2.0.a /bin/sh ./makesetup Setup.config Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Grammar `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo yes >hassignal; break; fi; done cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all ../Parser/pgen ./Grammar Compiling (meta-) parse tree into NFA grammar Making DFA for 'single_input' ... Making DFA for 'file_input' ... Making DFA for 'eval_input' ... Making DFA for 'funcdef' ... Making DFA for 'parameters' ... Making DFA for 'varargslist' ... Making DFA for 'fpdef' ... Making DFA for 'fplist' ... Making DFA for 'stmt' ... Making DFA for 'simple_stmt' ... Making DFA for 'small_stmt' ... Making DFA for 'expr_stmt' ... Making DFA for 'augassign' ... Making DFA for 'print_stmt' ... Making DFA for 'del_stmt' ... Making DFA for 'pass_stmt' ... Making DFA for 'flow_stmt' ... Making DFA for 'break_stmt' ... Making DFA for 'continue_stmt' ... Making DFA for 'return_stmt' ... Making DFA for 'raise_stmt' ... Making DFA for 'import_stmt' ... Making DFA for 'import_as_name' ... Making DFA for 'dotted_as_name' ... Making DFA for 'dotted_name' ... Making DFA for 'global_stmt' ... Making DFA for 'exec_stmt' ... Making DFA for 'assert_stmt' ... Making DFA for 'compound_stmt' ... Making DFA for 'if_stmt' ... Making DFA for 'while_stmt' ... Making DFA for 'for_stmt' ... Making DFA for 'try_stmt' ... Making DFA for 'except_clause' ... Making DFA for 'suite' ... Making DFA for 'test' ... Making DFA for 'and_test' ... Making DFA for 'not_test' ... Making DFA for 'comparison' ... Making DFA for 'comp_op' ... Making DFA for 'expr' ... Making DFA for 'xor_expr' ... Making DFA for 'and_expr' ... Making DFA for 'shift_expr' ... Making DFA for 'arith_expr' ... Making DFA for 'term' ... Making DFA for 'factor' ... Making DFA for 'power' ... Making DFA for 'atom' ... Making DFA for 'listmaker' ... Making DFA for 'lambdef' ... Making DFA for 'trailer' ... Making DFA for 'subscriptlist' ... Making DFA for 'subscript' ... Making DFA for 'sliceop' ... Making DFA for 'exprlist' ... Making DFA for 'testlist' ... Making DFA for 'dictmaker' ... Making DFA for 'classdef' ... Making DFA for 'arglist' ... Making DFA for 'argument' ... Making DFA for 'list_iter' ... Making DFA for 'list_for' ... Making DFA for 'list_if' ... Adding FIRST sets ... Writing graminit.c ... Writing graminit.h ... cp graminit.h ./../Include/graminit.h cp graminit.c ./../Python/graminit.c cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"' ./getplatform.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" all cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"' -DPREFIX='"/usr/local"' -DEXEC_PREFIX='"/usr/local"' -DVERSION='"2.0"' -DVPATH='""' ./getpath.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. #define _POSIX_THREADS /* 1003.1c (pthreads) comformant */ -------------------------------------------------------------------^ cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c if test ! -f libpython2.0.a; then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true; else true; fi for i in Parser Grammar Objects Python Modules; do (cd $i; make VERSION="2.0" add2lib); done ar cr ../libpython2.0.a acceler.o grammar1.o listnode.o node.o parser.o parsetok.o tokenizer.o bitset.o metagrammar.o myreadline.o if test ! -f ../Modules/hassignal; then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o; else echo leaving intrcheck.o out; fi leaving intrcheck.o out touch add2lib ar cr ../libpython2.0.a abstract.o bufferobject.o classobject.o cobject.o complexobject.o fileobject.o floatobject.o frameobject.o funcobject.o intobject.o listobject.o longobject.o dictobject.o methodobject.o moduleobject.o object.o rangeobject.o sliceobject.o stringobject.o tupleobject.o typeobject.o unicodeobject.o unicodectype.o touch add2lib ar cr ../libpython2.0.a bltinmodule.o exceptions.o ceval.o compile.o codecs.o errors.o frozen.o frozenmain.o getargs.o getcompiler.o getcopyright.o getmtime.o getplatform.o getversion.o graminit.o import.o importdl.o marshal.o modsupport.o mystrtoul.o pyfpe.o pystate.o pythonrun.o structmember.o sysmodule.o traceback.o dynload_shlib.o thread.o if test ! -f ../Modules/hassignal; then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o; else echo leaving sigcheck.o out; fi leaving sigcheck.o out touch add2lib if test -f hassignal; then echo removing sigcheck.o intrcheck.o; ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null; else echo leaving sigcheck.o intrcheck.o in; fi removing sigcheck.o intrcheck.o *** Exit 2 (ignored) ar cr ../libpython2.0.a threadmodule.o gcmodule.o bsddbmodule.o regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmodule.o _sre.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule.o timemodule.o operator.o _codecsmodule.o unicodedata.o unicodedatabase.o ucnhash.o _localemodule.o fcntlmodule.o pwdmodule.o grpmodule.o errnomodule.o selectmodule.o socketmodule.o mmapmodule.o md5module.o md5c.o shamodule.o rotormodule.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o getpath.o main.o getbuildinfo.o touch add2lib echo 0 >buildno cd Modules; make OPT="-O -Olimit 1500" python.o cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c expr `cat buildno` + 1 >buildno1 mv -f buildno1 buildno cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` ./Modules/getbuildinfo.c ar cr libpython2.0.a getbuildinfo.o ranlib libpython2.0.a true cd Modules; make OPT="-O -Olimit 1500" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link cc python.o ../libpython2.0.a -ldb -lpthreads -lm -o python ld: Unresolved: __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach *** Exit 1 Stop. *** Exit 1 Stop. DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878) /usr/lib/cmplrs/cc/ld: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $ $RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $ $RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $ $RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $ $RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $ $RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $ $RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $ $RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $ $RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $ $RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $ $RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $ $RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $ $RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $ $RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $ $RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $ $RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $ $RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $ $RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $ $RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $ $RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $ $RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $ $RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $ $RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $ $RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $ $RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $ $RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $ $RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $ $RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $ $RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $ $RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $ $RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $ $RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $ $RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $ $RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $ $RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $ $RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $ $RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $ $RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $ $RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $ $RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $ $RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $ $RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $ $RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $ $RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $ $RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $ $RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $ $RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $ $RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $ $RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $ $RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $ $RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $ $RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $ $RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $ habitat_id = realtime_12:1991 $RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $ $RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $ $RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $ $RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $ $RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $ $RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $ /usr/lib/cmplrs/cc/ftoc: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ /usr/lib/cmplrs/cc/cord: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ $RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $ $RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $ $RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $ $RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $ $RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $ $RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $ $RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $ $RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $ $RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $ $RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $ $RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $ $RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $ $RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $ $RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $ $RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $ $RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $ $RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $ $RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $ $RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $ $RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $ $RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $ $RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $ $RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $ $RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $ $RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $ $RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $ $RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $ $RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $ $RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $ $RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $ $RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $ $RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $ $RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $ $RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $ $RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $ $RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $ $RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $ $RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $ $RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $ $RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $ $RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $ $RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $ $RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $ $RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $ $RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $ $RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $ $RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $ $RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $ $RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $ $RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $ $RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $ $RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $ $RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $ $RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $ $RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $ $RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $ $RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $ $RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $ $RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $ $RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $ $RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $ $RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $ $RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $ $RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $ $RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $ $RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $ $RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $ $RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $ $RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $ $RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $ $RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $ $RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $ $RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $ $RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $ $RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $ $RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $ $RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $ $RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $ $RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $ $RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $ $RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $ $RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $ $RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $ $RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $ $RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $ ldtbread.c: 1.1 1/7/82 /usr/lib/cmplrs/cc/crt0.o: $RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $ cc (cc) Digital UNIX Compiler Driver 3.11 From effbot at telia.com Mon Oct 23 19:44:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 19:44:49 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid> looks like Tcl's parent company has ceased to be: http://biz.yahoo.com/bw/001020/ca_interwo.html "The Ajuba team will be assimilated into Interwoven's existing technical staff much as the Neonyoyo team was immediately after its acquisition in June. The Ajuba product line will be discontinued." From guido at python.org Mon Oct 23 22:12:49 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 15:12:49 -0500 Subject: [Python-Dev] Starship down ? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200." <39F43EAC.1A518A27@lemburg.com> References: <39F43EAC.1A518A27@lemburg.com> Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! Yeah, this is very unfortunate. It's the same problem that's keeping pytholabs.com down. The BeOpen systems staff is working on it, but I don't know what the problem is or when it will be fixed. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr at thyrsus.com Mon Oct 23 21:40:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 15:40:16 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> Message-ID: <20001023154016.A2722@thyrsus.com> Fredrik Lundh : > looks like Tcl's parent company has ceased to be: This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support? It seems to me that the Tcl world has been in increasing disarray for the last two years. Its growth doesn't seem to have matched Perl's or Python's; no strong community site analogous to python.org or CPAN has emerged; and John Osterhout's attempt to commercialize the language have led to a series of false starts and erratic moves. And Osterhout cheerfully acknowledges that on a technical level that Tcl has been pushed past the natural limits of applicability for its design approach. Tcl's long-term prognosis looks, to me, increasingly poor. Which suggests to me that some move toqwards making Python less dependent on Tk would be a good thing. I understand that we can't simply drop Tkinter. But I think it might be worth another look at alternatives (notably wxPython) to consider bringing one into the core distribution during 2.x, so that later on we can plan to move Tk to "unsupported -- legacy". -- Eric S. Raymond You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948) From guido at python.org Mon Oct 23 23:08:13 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 23 Oct 2000 16:08:13 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400." <20001023154016.A2722@thyrsus.com> References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> [ESR] > This raises anew a question I've been meaning to bring up for the last > week: is it finally time to move away from Python's dependence on > Tcl/Tk for GUI support? > > It seems to me that the Tcl world has been in increasing disarray for > the last two years. Its growth doesn't seem to have matched Perl's or > Python's; no strong community site analogous to python.org or CPAN has > emerged; and John Osterhout's attempt to commercialize the language > have led to a series of false starts and erratic moves. And Osterhout > cheerfully acknowledges that on a technical level that Tcl has been > pushed past the natural limits of applicability for its design > approach. > > Tcl's long-term prognosis looks, to me, increasingly poor. Which > suggests to me that some move toqwards making Python less dependent > on Tk would be a good thing. > > I understand that we can't simply drop Tkinter. But I think it > might be worth another look at alternatives (notably wxPython) to > consider bringing one into the core distribution during 2.x, so that > later on we can plan to move Tk to "unsupported -- legacy". Yes, it may be time to have this discussion again. Of course, Tcl/Tk still has a much larger following than wxWindows, and it is more stable too. (For example, it's easy to cause crashes -- not just exceptions -- by leaving out an initialization call in wxPython.) Plus, Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc. The Scintilla text widget comes close (and surpasses Tkinter in some respects, while coming short in others), but I know of no widget in a popular widget set that offers anything close to the Canvas widget. There are other choices too, all of which have Python support already: gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Mon Oct 23 22:21:18 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:21:18 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us> Fredrik Lundh wrote: > looks like Tcl's parent company has ceased to be: I checked out comp.lang.tcl after hearing about this. Ousterhout posted to say that an official statement will be coming out today or tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see what he says the core team is going to do... On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote: >This raises anew a question I've been meaning to bring up for the last >week: is it finally time to move away from Python's dependence on >Tcl/Tk for GUI support? It seems to me that supporting MacOS is the big problem for cross-platform GUIs. There are several different systems such as Qt that aim for portability across Windows and Unix, but add in the MacOS and the options really decrease. How good is wxWindows support for MacOS? Or will MacOS X fix the problem? I know MacOS X uses a BSD-based underlying kernel, but don't know if it will support X Windows out of the box. If people can only use MacOS-specific GUI APIs, then software such as Tk would still need to be ported specially to MacOS X. --amk From akuchlin at mems-exchange.org Mon Oct 23 22:30:11 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 16:30:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: >The Scintilla text widget comes close (and surpasses Tkinter in some >respects, while coming short in others), but I know of no widget in a >popular widget set that offers anything close to the Canvas widget. I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a fork of the Tk widget that was then substantially enhanced to be a general-purpose display engine, with antialiasing, alpha compositing, more attention to performance, and other fancy features. I don't know if the corresponding text widget (which is Pango, www.pango.org, I think) is equally featureful. --amk From gvwilson at nevex.com Mon Oct 23 22:33:48 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT) Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <20001023154016.A2722@thyrsus.com> Message-ID: > Fredrik Lundh : > > looks like Tcl's parent company has ceased to be: > Eric Raymond: > This raises anew a question I've been meaning to bring up for the last week: > is it finally time to move away from Python's dependence on Tcl/Tk for GUI > support? Yes please. > It seems to me that the Tcl world has been in increasing disarray for the > last two years. Its growth doesn't seem to have matched Perl's or Python's; > no strong community site analogous to python.org or CPAN has emerged; I have been told by two different publishers that they can't even give Tcl books away any longer. It's also interesting that the new Ruby book from Hunt and Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or Perl (I saw three mentions in the first ten minutes of the fact that Ruby is more widely used in Japan than Python). Also interesting that the Ruby GUI toolkit they describe is Tk-based... > I understand that we can't simply drop Tkinter. But I think it might be > worth another look at alternatives (notably wxPython) to consider bringing > one into the core distribution during 2.x, so that later on we can plan to > move Tk to "unsupported -- legacy". I thought about using wxPython in the most recent run of my Python course, but decided to stick to Tkinter because: - There isn't a wxWindows/wxPython book (matters a lot when organizations are trying to decide what to adopt for long-term use). - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. - There aren't as many tools on top of wxPython as there are on top of Tkinter. In particular, I think that a vector drawing package on top of wxPython that did what Sketch does, but on Windows as well as Linux, would make a great subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Thanks, Greg From effbot at telia.com Mon Oct 23 23:02:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:02:58 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... from an open-source perspective, Tcl might be more alive than ever: http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-) From esr at thyrsus.com Mon Oct 23 23:15:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:15:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023171503.B2889@thyrsus.com> Guido van Rossum : > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). I'm glad you brought up GTK+. Of all the alternatives you mentioned, it seems to me the most likely to attract long-term cross-platform support by lots of developers (GNOME, Nautilus and Sun Microsystems seem like a tough trio to beat on this score). Thus, GTK+ may be be the safest alternative in terms of being least likely to strand us N years down the road. The GTK+ API seems like a nice clean design, and there is already a Python binding. Any comment from anybody on how stable it is? Are the text and canvas widgets anywhere near competitive with Tk's? There are hints of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port? -- Eric S. Raymond .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) From trentm at ActiveState.com Mon Oct 23 23:06:41 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 23 Oct 2000 14:06:41 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <20001023140641.A3899@ActiveState.com> On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote: > There are other choices too, all of which have Python support already: ... > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). XUL. Though slappin' a GUI together in XUL is not all the same as for the other toolkits. Layout with XML, functionality with JavaScript and Python (and/or Perl of C++). Trent -- Trent Mick TrentM at ActiveState.com From effbot at telia.com Mon Oct 23 23:33:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 23 Oct 2000 23:33:02 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid> andrew wrote: > I checked out comp.lang.tcl after hearing about this. Ousterhout > posted to say that an official statement will be coming out today or > tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see > what he says the core team is going to do... they just updated their site: http://www.ajubasolutions.com/company/whatsnew.html "Tcl is not a core technology at Interwoven, and Interwoven will not invest in the development of Tcl. However, Ajuba has transferred responsibility for Tcl core development to the newly formed Tcl Core Team /.../ We expect the Tcl Core Team to evolve Tcl at a much faster rate than any single organization could achieve by itself. "Over the next few weeks Ajuba will release in open- source form many of the Tcl packages that we deve- loped for our products. Stay tuned for more info... From akuchlin at mems-exchange.org Mon Oct 23 23:26:18 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 23 Oct 2000 17:26:18 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: ; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400 References: <20001023154016.A2722@thyrsus.com> Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us> Some details begin to emerge at http://www.ajubasolutions.com/company/whatsnew.html It looks like some of their proprietary code will be released as open source, possibly including the TclPro development environment. The new company will not be funding Tcl/Tk development, and instead it's up to the 14 members of the recently-formed Tcl core team. I don't know if any of those people are being paid to work on Tcl, but probably at least some of them are. I expect this will cause a good deal disruption, perhaps even a fatal amount, particularly if core developers such as Jeffrey Hobbs no longer work on Tcl full-time. --amk From esr at thyrsus.com Mon Oct 23 23:58:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 17:58:20 -0400 Subject: [Python-Dev] Re: ajuba acquired by interwoven In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400 References: <20001023154016.A2722@thyrsus.com> <20001023172618.A23898@kronos.cnri.reston.va.us> Message-ID: <20001023175820.A3117@thyrsus.com> Andrew Kuchling : > Some details begin to emerge at > http://www.ajubasolutions.com/company/whatsnew.html > > It looks like some of their proprietary code will be released as open > source, possibly including the TclPro development environment. The > new company will not be funding Tcl/Tk development, and instead it's > up to the 14 members of the recently-formed Tcl core team. I don't > know if any of those people are being paid to work on Tcl, but > probably at least some of them are. I expect this will cause a good > deal disruption, perhaps even a fatal amount, particularly if core > developers such as Jeffrey Hobbs no longer work on Tcl full-time. Not necessarily... Good for Tcl: they *have* a core team now Bad for Tcl: at 14 it's too big, unless there's some inner core of no more than three or four architects. Good for Tcl: Much of the proprietary code will go open. Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are on the new core team. Not clear whether their time available will increase or decrease. Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users. With good leadership, they could manage the transition to something resembling the Apache Software Foundation's organization. If so, Tcl might actually improve. -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From robin at alldunn.com Tue Oct 24 01:03:44 2000 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:03:44 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES> I'm not on python-dev so please be sure to copy me on replies. "Greg Wilson" wrote: > > I thought about using wxPython in the most recent run of my Python course, but > decided to stick to Tkinter because: > > - There isn't a wxWindows/wxPython book (matters a lot when organizations are > trying to decide what to adopt for long-term use). > This is something I am hoping to change in the near future. I have a lot of ideas, have been putting an outline together, and have a phone conference with a potential publisher tomorrow. > - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. > > - There aren't as many tools on top of wxPython as there are on top of Tkinter. > In particular, I think that a vector drawing package on top of wxPython that > did what Sketch does, but on Windows as well as Linux, would make a great > subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Hint received and understood... "Andrew Kuchling" akuchlin at mems-exchange.org wrote: > > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. There are several different systems such as Qt > that aim for portability across Windows and Unix, but add in the MacOS > and the options really decrease. How good is wxWindows support for > MacOS? My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. It's in use in at least a few commercial applications around the world. The next step I guess is getting it wrapped up in wxPython, which should just be a matter of porting some of the low level startup and helper code, and putting some ifdef's in the SWIG interface files for things that may be different in the Mac version of wxWindows. Unfortunately, given the current state of the amount of my spare time and relative Mac-illiterate-ness, it's either going to require someone else to work on it and be wxPython-Mac's champion, or somebody needs to fund my ramp-up and development time so I can cut back on other things. The good news is that I have been loaned a Mac and CodeWarior and such to play with, I just haven't found the time to play much lately. "Guido van Rossum" guido at python.org wrote: > Plus, Tk has two very high quality widgets: the Canvas and Text > widgets are unsurpassed in functionality and robustness by other > widget sets. You can draw more lines or characters per second in most > toolkits, but few toolkits offer the convenience of marks and tags, > not having to deal with refresh events, being able to group objects, > move them around, change attributes, etc., etc., etc. > > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), Just in case anybody didn't know already, wxWindows/wxPython has a wrapper around Scintilla available called wxStyledTextCtrl. > but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. wxWindows has a canvas widget in development right now. I've been trying to nudge the developers working on it towards features found in the tk canvas and the GNOME canvas widget. I have high hopes for it but I'm not sure how long it will be before it gets to the same level as the others. -- Robin Dunn Software Craftsman robin at AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From esr at thyrsus.com Tue Oct 24 01:29:54 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 23 Oct 2000 19:29:54 -0400 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700 References: <036501c03d45$81aefae0$3225d2d1@ARES> Message-ID: <20001023192954.A3313@thyrsus.com> Robin Dunn : > Unfortunately, given the current > state of the amount of my spare time and relative Mac-illiterate-ness, it's > either going to require someone else to work on it and be wxPython-Mac's > champion, or somebody needs to fund my ramp-up and development time so I can > cut back on other things. This is exactly what CoSource and SourceXchange are for. Post your Mac port as a project there and see who ponies up money. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From MarkH at ActiveState.com Tue Oct 24 01:19:33 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 10:19:33 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001023140641.A3899@ActiveState.com> Message-ID: Trimmed all CCs [Guido] > and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). [Trent "David Ascher" Mick responds] > XUL. Though slappin' a GUI together in XUL is not all the same as for > the other toolkits. Layout with XML, functionality with > JavaScript and Python (and/or Perl of C++). As a fairly irrelevant (at this point in time) observation: Something about the Mozilla XUL engine seems "right". It is large and complex, but their XML based layout engine, and powerful "code-less" widget creation has a lot of potential IMO. It is very very new and rough. It is very tightly bound with Mozilla itself and javascript, although efforts are underway to separate it from both. It is huge, and constantly changing. It has been designed for tomorrow, and struggles along today. But it may well turn out to be and expressive and compelling model for the future. So, if we can just continue to disagree for the next 2 or 3 years, it may well become something worth considering ;-) Mark. From robin at alldunn.com Tue Oct 24 01:56:59 2000 From: robin at alldunn.com (Robin Dunn) Date: Mon, 23 Oct 2000 16:56:59 -0700 Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven References: <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com> Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES> > > This is exactly what CoSource and SourceXchange are for. Post your Mac port > as a project there and see who ponies up money. Now why didn't I think of that??? Thanks for the idea! -- Robin Dunn Software Craftsman robin at AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From DavidA at ActiveState.com Tue Oct 24 06:00:51 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: > The Scintilla text widget comes close (and surpasses Tkinter in some > respects, while coming short in others), but I know of no widget in a > popular widget set that offers anything close to the Canvas widget. > > There are other choices too, all of which have Python support already: > gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David > Ascher can fill me in). The mozilla toolkits has more names than I care to remember. =) The most generic name is XPFE, although there are some parts of it with nicer names like XUL (pronounced Zool) and XBL. It also heavily uses XML, DTDs, CSS, etc. Mozilla is definitely a long-term investment in our part. For example, currently it's not possible to have Python code inline in the XUL (XML) code, and JavaScript is the only option there. We'll be working w/ the Netscape and Mozilla crowds to fix that, but it's not there yet. That said, Mozilla does have a fairly strong vision for the future, allows some of the benefits of the web technologies to transfer to the GUI world (designers, not coders, can do the UI work). In terms of the closest equivalent to the Canvas widget, apart from XUL itself, which is very hierarchical, there is the promise of SVG support, which will give you a lot more than the Canvas. That, too, is not quite ready for prime time yet. Hope this is helpful, --david From cgw at fnal.gov Tue Oct 24 06:32:04 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov> David Ascher writes: > > That said, Mozilla does have a fairly strong vision for the future, allows > some of the benefits of the web technologies to transfer to the GUI world > (designers, not coders, can do the UI work). Sounds great for the future, but I want to inject a few of my unsolicated, opinionated observations - today, in 2000, the Mozilla stuff is *far* from usable. If you want to produce nice, professional looking GUI apps which fit nicely with the desktop (rather that having their own completely different look-and-feel) it's hard to beat Gtk+ or Tkinter. Tkinter is still quite viable, especially if cross-plaform support is important. Some of the examples in Grayson's book are quite beautiful. It will be a long time until XPFE/XUL/whatchamacallit gets to this level of viability. Also consider that Sun (and HP?) now ship Gnome by default, rather than CDE (or so I hear, anyway). I predict that Gnome compatibility will become more and more of a desirable feature. Evidence of the above is the "Galeon" project. It's widely perceived that Mozilla has a nice rendering engine (Gecko) wrapped up in a dreadful GUI (XPFE). So the Galeon project places the Gecko engine inside a Gtk+/Gnome GUI, which provides a much more pleasant user experience. There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/ And, finally, IMO, the work being done on PyGtk is of high quality. I'm using it currently in production code. From DavidA at ActiveState.com Tue Oct 24 07:12:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: > There's also a (preliminary) port of Gtk+ to Win32: > http://www.gimp.org/~tml/gimp/win32/ FWIW, the last time I checked, this was useless. I'd be glad to be wrong, but I'm not holding my breath. Not surprisingly, the GTK crowd, which is rooted in Linux tradition (!), has little interest in Win32 ports, and even less experience in that world. Until that happens, a lot of platform-agnostic projects and vendors will have a hard time w/ GTK. I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included). --david From tim_one at email.msn.com Tue Oct 24 07:20:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:20:07 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com> Message-ID: [ESR] > ... > and John Osterhout's attempt to commercialize the language have led to > a series of false starts and erratic moves. We don't want to criticize anyone for that: PythonLabs' attempts *not* to commercialize Python may yet make Tcl's path look as straight and true as a laser beam . obliquely y'rs - tim From tim_one at email.msn.com Tue Oct 24 07:31:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 24 Oct 2000 01:31:07 -0400 Subject: [Python-Dev] Starship down ? In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com> Message-ID: [MAL] > The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! [GvR] > Yeah, this is very unfortunate. It's the same problem that's keeping > pytholabs.com down. The BeOpen systems staff is working on it, but I > don't know what the problem is or when it will be fixed. FYI, pythonlabs.com is up again, but Starship is still down. We only said it's the same problem because we didn't know what either problem was. And, we still don't! long-distance-ly y'rs - tim From cgw at fnal.gov Tue Oct 24 07:34:23 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.4292.807070.848419@buffalo.fnal.gov> Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov> David Ascher writes: >cgw> There's also a (preliminary) port of Gtk+ to Win32: >cgw> http://www.gimp.org/~tml/gimp/win32/ > > FWIW, the last time I checked, this was useless. That's what I meant by "preliminary" ;-) > I don't mean to diss GTK, just pointing out that cross-platform solutions > are important to a whole lot of communities (Python included). Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face. Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win, seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and they will just hate it. (Yes, this is based on observations of actual paying customers). I have a little bit of experience with cross-platform development - having used a lot of these tools - at my last job, after evaluating just about everything, we bought into (against my advice!) a doomed commercial product called Visix Galaxy (for which I immediately created a set of Python bindings). The problem with all of these things, of course, is that the more cross-platform they are, the more "lowest-common-denominator" they are forced to become. Tkinter, with widgets like Canvas, was really pretty amazing - for its day - feature-rich *and x-platform. But even this broke down if you started using fancy features like drawing with dashed lines - works on X, not on Windows (last time I checked, anyway) - the more you start pushing the limits of the toolkit, the more the portability breaks down. Tkinter-is-dead-long-live-Tkinter'ly yrs, -C From MarkH at ActiveState.com Tue Oct 24 07:48:34 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Tue, 24 Oct 2000 16:48:34 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov> Message-ID: > Right. Cross-platform is very important, but so is native > look-and-feel, and this is where (IMO) XPFE falls flat on its face. Actually, my experience with XPFE from a look-and-feel POV has been pretty positive. It is true they have re-implemented most widgets rather than use native ones, and also true that you can make these widgets look nothing like native LAF - but generally, my experience with Mozilla and the "classic" skin is that it is close enough that it is very hard to tell. It looks more like "subtle enhancements", in the same way IE provides "subtle enhancements" > seems like it could be a real winner. If the x-platform GUI doesn't > use native dialog boxes and filechoosers, users REALLY notice this and Agreed. However, XPFE works fine here IMO. Again, I do not want to propose XPFE as viable today, and I agree it may never be viable. Most other critisisms posted are valid, but I don't think that LAF is one such problem with XPFE. Mark. From paul at prescod.net Tue Oct 24 08:29:42 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:29:42 -0700 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> Message-ID: <39F52C56.214B28A1@prescod.net> Fredrik Lundh wrote: > >... > > http://sourceforge.net/projects/tcl > http://sourceforge.net/projects/tktoolkit > > and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo > will rock ;-) Perhaps this could be an opportunity to split Tcl and Tk more cleanly. People like Fredrick and his Perl/Ruby/... equivalents could get more deeply involved in setting direction. It would be interesting to contrast the number of Tcl versus Tk users right now. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Tue Oct 24 08:40:49 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 23 Oct 2000 23:40:49 -0700 Subject: [Python-Dev] Gradual migration Message-ID: <39F52EF1.A201C6D9@prescod.net> Python 3K. It is the repository for our hopes and dreams. We tend to invoke it in three different situations: 1. in delaying discussions of gee-whiz features (e.g. static type checking) 2. in delaying hairy implementation re-factoring that we don't want to undertake right now. 3. in delaying painful backwards-compatibility breakage I think it is somewhat debatable whether we really need to or should do these three things all at once but that's a separate discussion for another day. (the other experiment may inform our decision) I want to focus on "3" -- breakage. Rather than delaying painful backwards-compatibility breakage I thing we should make it less painful. We should decide where we are going long before we ask our users to move there. I think we should start including alternatives to syntaxes and features that we know are broken. Once people move to the alternatives we can "reassign" or remove the original syntax with much less pain. In other words, rather than telling people "here's a new version, your code is broken, sorry." We should tell them: "we're going to break code. Here's an alternative syntax that you can use that will be interpreted the same in the old and new versions -- please move to this new syntax as quickly as possible." I'll outline some examples of the strategy. You may or may not like details of the particular proposals but you might still agree with the strategy. Also, I don't claim that all of the proposals are fully fleshed-out...again, it's the strategy I'm most interested in. I don't even agree with every feature change I describe below -- they are just some I've heard of for Python 3000. In other words ** this is not a design document for Python 3000! ** Separating byte arrays from strings: 1. immediately introduce two new functions: binopen("foo").read() -> byte array stropen("foo","UTF-8".read() -> u"...." 2. warn about string literals that have embedded non-Unicode characters 3. deprecate extension modules that return "old fashioned" string arrays 4. after a period where all strings have been restricted to Unicode-compatibility, merge the Unicode and string types. 5. deprecate the special Unicode u"" syntax as an imperialist anachronism Reclaiming the division operator from truncating integer division: 1. immediately introduce new functions: div() that does division as we wish it was. 2. add a warning mode to Python (long overdue) 3. with the warning mode on, old-fashioned division triggers a deprecation warning. 4. after three years as a warning situation we expect all in-use Python scripts to have been upgraded to use the new operations and to explicitly truncate integer division when that is what is wanted. 5. at that point we can re-assign the division operator to be a floating point division if we wish. Case insensitivity: 1. Warn whenever a module or class has two __dict__ entries that differ only by case 2. Eventually, disallow that form of name-clash altogether 3. After a period, allow case variations to be equivalent. Unifying types and classes (more vague): 1. Add something like extension class to make type subclassing easier. 2. Informally deprecate modules that do not incorporate it. 3. Replace or fix details of the language and implementation that behave differently for types and classes. (e.g. the type() operator) -- Paul Prescod - Not encumbered by ActiveState consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From pf at artcom-gmbh.de Tue Oct 24 09:47:03 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST) Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm" Message-ID: Hi, Paul Prescod wrote on python-dev at python.org: [...] > Reclaiming the division operator from truncating integer division: [...] Bruce Sherwood and David Scherer suggested a IMHO very clever solution to this particular problem in March/April this year. This thread was first posted to idle-dev and afterwards X-posted to python-dev: http://www.python.org/pipermail/idle-dev/2000-April/000138.html http://www.python.org/pipermail/idle-dev/2000-April/000140.html http://www.python.org/pipermail/python-dev/2000-April/010029.html Unfortunately I'm no native english speaker and have not enough time to make a Python-2.1 PEP from it. May be somebody else wants to go for it? I still believe, this was a very clever Python enhancement, which should be officially proposed. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mal at lemburg.com Tue Oct 24 10:45:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 10:45:03 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <39F54C0F.25798309@lemburg.com> Paul Prescod wrote: > > Python 3K. It is the repository for our hopes and dreams. We tend to > invoke it in three different situations: > > 1. in delaying discussions of gee-whiz features (e.g. static type > checking) > > 2. in delaying hairy implementation re-factoring that we don't > want to undertake right now. > > 3. in delaying painful backwards-compatibility breakage > > I think it is somewhat debatable whether we really need to or should do > these three things all at once but that's a separate discussion for > another day. (the other experiment may inform our decision) I think will simply be a consequence of doing a complete rewrite of the interpreter for Py3K. AFAIR, the only truely feasable solution would be doing the rewrite in a widely portable subset of C++ and then managing classes at that level. Moving to a common and very low-level strategy for classes will allows us to put even the most basic types (strings and numbers) into an inheritence tree. Differences like the ones between Unicode and 8-bit strings would then flesh out as two different subclasses of a generic string type which again is based on a generic sequence type. The same could be done for dictionaries: special ones for just string keys, case insensitive lookups, etc. could all be subclasses of a generic mapping class. Dito for numbers (and division strategies). By following this principle there won't be all that much breakage, since the old functionality will still be around, only the defaults will have changed. Add to this pluggable compilers and ceval loops, plus a nice way of configuring the lot on a per-module basis and you're set. (Ok, it's a fluffy clouds image, but you get the picture ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 24 17:57:43 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 10:57:43 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200." <39F54C0F.25798309@lemburg.com> References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com> > Paul Prescod wrote: > > > > Python 3K. It is the repository for our hopes and dreams. We tend to > > invoke it in three different situations: > > > > 1. in delaying discussions of gee-whiz features (e.g. static type > > checking) > > > > 2. in delaying hairy implementation re-factoring that we don't > > want to undertake right now. > > > > 3. in delaying painful backwards-compatibility breakage > > > > I think it is somewhat debatable whether we really need to or should do > > these three things all at once but that's a separate discussion for > > another day. (the other experiment may inform our decision) Marc-Andre Lemburg replied: > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. > > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. > > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. > > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. > > Dito for numbers (and division strategies). > > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. > > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Good job in channeling me, Marc-Andre! I'm sure that's not exactly how it's going to be, but on the face of it, this sure sounds like a reasonable possible route. Do you want to be the author for PEP-3000? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Oct 24 18:13:37 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 11:13:37 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST." <39F52EF1.A201C6D9@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com> > I want to focus on "3" -- breakage. Rather than delaying painful > backwards-compatibility breakage I thing we should make it less painful. > We should decide where we are going long before we ask our users to move > there. I think we should start including alternatives to syntaxes and > features that we know are broken. Once people move to the alternatives > we can "reassign" or remove the original syntax with much less pain. Absolutely. Whenever possible, we should try to plan for migration in Python 2.x. > In other words, rather than telling people "here's a new version, your > code is broken, sorry." We should tell them: "we're going to break code. > Here's an alternative syntax that you can use that will be interpreted > the same in the old and new versions -- please move to this new syntax > as quickly as possible." It would also help if we could produce automatic translation tools that will convert the old syntax into the new. This desire may restrict our choices however: the translation tools don't have runtime information to go by. It's easy enough to change obsolete syntax into new syntax, but it's hard to decide whether a particular "/" operator should be changed into an integer divide ("//") or left alone. > I'll outline some examples of the strategy. You may or may not like > details of the particular proposals but you might still agree with the > strategy. Also, I don't claim that all of the proposals are fully > fleshed-out...again, it's the strategy I'm most interested in. I don't > even agree with every feature change I describe below -- they are just > some I've heard of for Python 3000. In other words ** this is not a > design document for Python 3000! ** I think the proper approach is to start a separate migration process for each of these proposed changes. Each should be paced separately (the pace may depend on how hard to swallow the change is for users as well as how hard it is to implement the new functionality) and for each, a separate PEP in the 3000 series should be started. I can even see that several PEPs will be needed in some cases (e.g. one to describe the new syntax, one to to flesh out the implementation, and one to decide on the migration steps). I won't comment on Paul's examples, that's for the various PEP processes. --Guido van Rossum (home page: http://www.python.org/~guido/) From cgw at fnal.gov Tue Oct 24 17:21:45 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <14837.14407.954185.466011@buffalo.fnal.gov> Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov> Mark Hammond writes: > > > Agreed. However, XPFE works fine here IMO. > > > cgw> "Here" means on MS-Win, right? Maybe that's why our perceptions are > cgw> so different. > > Correct. Although I have run it under Linux a few times, I wouldnt really > know LAF issues if I tripped over them there ;-) > > Mark. It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not agree!) Gnome is gathering momentum, especially now that Sun has joined the Gnome Foundation. With outfits like Eazel, Helix Code, etc, turning out high-quality products, things are moving fast in the Gnome/Gtk+ world and it seems clear to me that this will be the major desktop platform for Unix machines in the upcoming decade. Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up. OK, enough off-topic rambling (for now), -C From akuchlin at mems-exchange.org Tue Oct 24 17:43:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 11:43:26 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote: >It's certainly true that the lack of a consistent look and feel for >Linux apps has been somewhat of a problem historically. However, with >the emergence of Gnome, it seems that there is finally some >convergence. (Althought people in the KDE/Qt camp will certainly not Careful... while people may try to port GTk+ to Windows, porting GNOME is a different kettle of wax, because GNOME needs GTk+ but also entails gnome-libs and gnome-vfs and Bonobo and esound and lots of other things, which provide services such as object embedding that wouldn't be required -- or would be very different -- on Windows. I don't know if anyone is trying to tease apart GNOME into a Windows-suitable subset; it seems like it would be a difficult task. Qt is at least a toolkit that aims at cross-platform portability, though there again, the KDE environment built on top of it is not going to be portable to anything that isn't Unix. Both the Qt and GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only real possibilities. This is why, every time this debate comes up, we end up sticking with Tk; it may suck, but all the other systems don't support everything... Maybe the best approach is to follow /F's lead with Tkinter3000, and reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that *is* what Tkinter3000 is, right?) What's the problem we're trying to solve here? * Is it that the problem that the Tkinter module is a bad API for GUI programming? * Or is it that the Tk implementation is slow or bulky? * Or do we just dislike having to require Tcl as well as Tk? Can someone articulate why Tk should be replaced? --amk From gvwilson at nevex.com Tue Oct 24 17:52:00 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: > Andrew Kuchling wrote: > What's the problem we're trying to solve here? > > * Is it that the problem that the Tkinter module is a bad API for > GUI programming? > > * Or is it that the Tk implementation is slow or bulky? > > * Or do we just dislike having to require Tcl as well as Tk? > > Can someone articulate why Tk should be replaced? I can articulate why I'm unhappy with the current set-up: 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los Alamos before my first Python course cost me several hours, and I had to do it again two months' later. I've run into similar problems with multiple Tcl installations on Windows machines (personal use). 2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python). Performance doesn't really matter --- I've never had students complain about speed, although I've never asked them to build something large enough that refresh would be an issue. I don't have experience teaching wxPython, so I can't comment on the relative teachability of its API vs. Tk's. Hope this helps, Greg From paul at prescod.net Tue Oct 24 18:12:12 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:12:12 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> Message-ID: <39F5B4DC.C226D8F6@prescod.net> "M.-A. Lemburg" wrote: > >... > > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. AFAIR, the only truely feasable > solution would be doing the rewrite in a widely portable > subset of C++ and then managing classes at that level. I disagree for a variety of reasons: * implementation language and Python inheritance semantics are almost completely distinct. After all, we have Python implementations in a variety of languages with minor incompatibilities. Python could have a proper type/class merging even if it were written in assembly language. So let's leave implementation language aside. * there is a hell of a lot we can do to make the type/class split less visible without a major rewrite. For instance, lists could have a __getitem__ method so that they "act like" instances. Instances could return their methods in a dir() so that they "act like" built-in objects. So there is no reason to wait for a complete rewrite to start on this path. * It may even be the case that we can get from here to complete merged type/class semantics WITHOUT a rewrite. If a mad genious had not written stackless Python I would have sworn up and down that stackless Python would require a Python rewrite. It didn't. If another slightly less mad genious had not integrated ints and longs I would never have believed it possible without another rewrite. Someone needs to do an analysis of what it takes to merge types and classes and *demonstrate* that it requires a rewrite rather than *asserting* that it requires a rewrite. In other words, let's stop sprinkling the "major rewrite" pixie dust on hard problems and instead decide where we want to go and how we want to get there! > Moving to a common and very low-level strategy for classes > will allows us to put even the most basic types (strings and > numbers) into an inheritence tree. I don't know what you mean by a "low-level strategy" for classes. It's not like we can somehow use C++ vtables without giving up Python's dynamicity. Python's class handling is about as low-level as it can get in my humble opinion. > Differences like the > ones between Unicode and 8-bit strings would then flesh > out as two different subclasses of a generic string type which > again is based on a generic sequence type. Of course that's where we want to go but it doesn't avoid the backwards compatibility problems. We can do this today using proxying. > The same could be done for dictionaries: special ones for > just string keys, case insensitive lookups, etc. could all > be subclasses of a generic mapping class. We can easily do this today. > Dito for numbers (and division strategies). There's no way I'm going to let you get away with that little sleight of hand. How is inheritance holy water going to allow us to change the semantics of: 5/2 without breaking code?? The same goes for a.b = 5 versus a.B = 5 C++ does not help. Inheritance does not help. Pluggable compilers do not help. We *will* break code. We just need to decide whether to do it in a thoughtful way that gives people a chance to migrate or put off decisions until the last possible moment and then spring it on them with no between-version upgrade path. > By following this principle there won't be all that much > breakage, since the old functionality will still be around, > only the defaults will have changed. When you change defaults you break code. Keeping the old functionality around is barely helpful. Nobody has EVER proposed a change to Python where something that was previously possible is now made impossible. So whatever our strategy, the PROBLEM is changing defaults. The solution is telling people what defaults are changing in what timeline and discouraging them from depending on the old defaults. > Add to this pluggable compilers and ceval loops, plus a nice > way of configuring the lot on a per-module basis and you're > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) Sounds mythical. I'm trying to take it out of the realm of fluffy clouds and bring it into the world that people can plan their businesses and coding strategies around. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Tue Oct 24 18:30:17 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 24 Oct 2000 09:30:17 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> Message-ID: <39F5B919.4B80A526@prescod.net> Guido van Rossum wrote: > > ... > > I think the proper approach is to start a separate migration process > for each of these proposed changes. I agree. As a more concrete extension to my last email, I propose the following doctrine: """ No major documented feature should be removed or have changed semantics in Python 3000 or any other new version of Python until users have had a year (preferably MORE!) of upgrade time. Upgrade time entails the following parts: 1. the released Python version has a new recommended way to accomplish the task in a manner that will remain available in the "breakage version" e.g. a div() function that people can use for a few years while the semantics of "/" are in transition. 2. the mechanism/syntax that will be removed is formally deprecated. The documentation would say, e.g. "You should not use '/' for now. It is changing semantics in the future." 3. the released Python version sports a runtime warning to tell users that the mechanism/syntax is going away. "CompatibilityError: Future versions of Python will have different semantics for the '/' operator. Please use div() instead." The actual "right" amount of upgrade time depends on the extent of the breakage and its ease of detection. """ I can PEP this if people agree. I think that the user community would appreciate our effort to promise not to break code suddenly and capriciously. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry at wooz.org Tue Oct 24 18:26:13 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? References: <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.47141.817450.488896@anthem.concentric.net> >>>>> "GW" == Greg Wilson writes: GW> 2. (Lack of) native look and feel. This is a complete GW> show-stopper for many of the outfits I've dealt with (and not GW> just with Python). On the other hand, it's incredibly easy to whip together a GUI in Tk for simple applications. Yes, Tk gets painful as applications grow, but I'd hate to abandon such a simple, well-known toolkit for a complicated, hard-to-learn but powerful native look-and-feel one. You don't /always/ care about strict native LAF. Or to restate: I'd hate to have to make that choice. If we can't satisfy both requirements (mandatory-native-LAF and rapid prototyping friendliness), we may need to continue to support multiple toolkits. the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs, -Barry From guido at python.org Tue Oct 24 19:39:38 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:39:38 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400." References: Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los > Alamos before my first Python course cost me several hours, and I had > to do it again two months' later. I've run into similar problems with > multiple Tcl installations on Windows machines (personal use). For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and install our own Tcl/Tk binaries, in a place that doesn't affect or require existing Tcl/Tk installations. Maybe we can do the same for Unix binary distributions? I believe Jeremy has already had to create a separate RPM for _tkinter because there are too many different versions of Tcl/Tk out there -- it shouldn't be hard to install our own altogether. > 2. (Lack of) native look and feel. This is a complete show-stopper for > many of the outfits I've dealt with (and not just with Python). Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much. Or are you saying that IDLE isn't designed as a typical Microsoft app? That's quite a separate issue from the widget look-and-feel! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at wooz.org Tue Oct 24 18:40:50 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <14837.48018.547379.464959@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> * implementation language and Python inheritance semantics PP> are almost completely distinct. After all, we have Python PP> implementations in a variety of languages with minor PP> incompatibilities. Python could have a proper type/class PP> merging even if it were written in assembly language. So PP> let's leave implementation language aside. Jython experience backs this up. It would be incredibly convenient if we could just map Java classes to Python classes, so that for example, we'd have in Java a PyException class that is exceptions.Exception with minimal or no Java wrappings. And Finn nearly did this. The problem that we ran into with Java is that it allows only single inheritance. So you couldn't create a Python exception that multiply inherited from two or more other Python exceptions. Doesn't happen often, but it does happen, so is that an acceptable tradeoff? C++ might be better in this particular respect, but there will be other issues, because as soon as you start transparently showing the implementation's classes into Python, you inherit their semantics and restrictions as well. Just saying that it's tricky. -Barry From guido at python.org Tue Oct 24 19:54:39 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 12:54:39 -0500 Subject: [Python-Dev] Gradual migration In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST." <39F5B919.4B80A526@prescod.net> References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com> <39F5B919.4B80A526@prescod.net> Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com> > As a more concrete extension to my last email, I propose the following > doctrine: > > """ > No major documented feature should be removed or have changed semantics > in Python 3000 or any other new version of Python until users have had a > year (preferably MORE!) of upgrade time. Upgrade time entails the > following parts: > > 1. the released Python version has a new recommended way to > accomplish the task in a manner that will remain available in the > "breakage version" e.g. a div() function that people can use for a few > years while the semantics of "/" are in transition. > > 2. the mechanism/syntax that will be removed is formally deprecated. > The documentation would say, e.g. "You should not use '/' for now. It is > changing semantics in the future." > > 3. the released Python version sports a runtime warning to tell > users that the mechanism/syntax is going away. "CompatibilityError: > Future versions of Python will have different semantics for the '/' > operator. Please use div() instead." > > The actual "right" amount of upgrade time depends on the extent of the > breakage and its ease of detection. > """ > > I can PEP this if people agree. I think that the user community would > appreciate our effort to promise not to break code suddenly and > capriciously. Go for it. I have little bandwidth to think about this deeply, but what you're proposing here sounds like a good approach. Certainly it will make it easier if I can point to this PEP when I get the next FUD email about "should I bother to learn Python 2.0 when Py3K is going to be all different?"... --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Tue Oct 24 19:07:12 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 19:07:12 +0200 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid> paul wrote: > Perhaps this could be an opportunity to split Tcl and Tk more cleanly. > People like Fredrick and his Perl/Ruby/... equivalents could get more > deeply involved in setting direction. I'm waiting for the Tcl/Tk developers to grow up -- they still fear that any attempt to make it easier to use Tk from other languages would be to "give up the crown jewels" :-( From effbot at telia.com Tue Oct 24 18:59:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 24 Oct 2000 18:59:23 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid> andrew wrote: > Maybe the best approach is to follow /F's lead with Tkinter3000, and > reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that > *is* what Tkinter3000 is, right?) nope -- at least not initially. the first two steps are a new Tk glue layer, and an extension API that allows you to write new widgets in pure Python. also see: http://w1.132.telia.com/~u13208596/tkinter/index.htm ::: I have plans for how to take the Tkinter API *and* the new extension API beyond Tk, but let's save that for another day... ::: > Can someone articulate why Tk should be replaced? beats me ;-) From cgw at fnal.gov Tue Oct 24 18:54:35 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov> Andrew Kuchling writes: > > Careful... while people may try to port GTk+ to Windows, porting GNOME > is a different kettle of wax, because GNOME needs GTk+ but also > entails gnome-libs But I was never seriously advocating Gtk+ on Windows. This was just a footnote. I shouldn't have even mentioned the Windows Gtk+ port because it just muddied the water. The major point I was trying to make is that toolkits like Tkinter and WxWindows, which try to delegate to the native widget sets whenever possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which reimpliment all the widgets from scratch, are doomed to fail. (IMO, of course). What I believe we need is a suitable abstraction which uses MFC on MS-Win platforms and Gtk+ on Unix. And which also doesn't, due to the abstraction, take away too many features. I don't know that much about MFC, but for a simple example - Gtk+ offers an option for its canvas widget to do all drawing in antialised mode (by the way, this is slow but produces very nice looking results). It would be a shame if the abstraction layer didn't allow for things like this to be used. > This is why, every time this debate comes up, we > end up sticking with Tk; it may suck, but all the other systems don't > support everything... Right. FWIW, in my day-to-day work, if it has to run on MS-Win I use Tkinter, and if MS-Win is not an issue I use PyGtk. Fermilab will be showing some network monitoring software at the Supercomputing 2000 conference next month, and it's mostly all stuff I whipped up a few days using Tkinter. From gmcm at hypernet.com Tue Oct 24 19:14:42 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 13:14:42 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F58B42.26855.490B8F73@localhost> Paul Prescod wrote: ... > .... It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. But that's exactly what COM does. not-to-be-taken-as-an-endorsement-ly y'rs - Gordon From akuchlin at mems-exchange.org Tue Oct 24 19:15:14 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 24 Oct 2000 13:15:14 -0400 Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200 References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid> Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote: >I'm waiting for the Tcl/Tk developers to grow up -- they still >fear that any attempt to make it easier to use Tk from other >languages would be to "give up the crown jewels" :-( In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. --amk From gvwilson at nevex.com Tue Oct 24 19:58:59 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson: > > I can articulate why I'm unhappy with the current set-up: > > 1. Requiring Tcl is fragile. > Guido van Rossum: > For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and > install our own Tcl/Tk binaries OK. > > Greg Wilson: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > Guido van Rossum: > Really? Are you sure that's not just general resistence against new things? Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development. Thanks, Greg From guido at python.org Tue Oct 24 21:04:55 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 14:04:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400." References: Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> > Well, my students' resistance to novelty is low enough that they're > willing to take a Python course :-). This comes up every time I > teach; no idea whether it has any impact on the usability of > completed applications, but I believe it makes people less likely to > choose Tkinter when starting development. Can you elaborate on the line of argument that you typically hear? What do you say to dispel it? --Guido van Rossum (home page: http://www.python.org/~guido/) From nas at arctrix.com Tue Oct 24 13:56:11 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 04:56:11 -0700 Subject: [Python-Dev] A small step to removing the type/class split Message-ID: <20001024045611.B9993@glacier.fnational.com> I've run into a problem with ExtensionClass which I believe can only be fixed by modifying Python. I will try to explain. I have an ExtensionClass which defines __cmp__. Depending on the objects being compared, the __cmp__ method may never be called. This is due to code in object.c that looks like this: if (PyInstance_Check(v) || PyInstance_Check(w)) { try to use use __cmp__ method } else { try number coerce and fall back on type name comparison } Extension classes can never pass the PyInstance_Check predicate. I've searched for all occurances of PyInstance_Check in the 2.0 source. In many places that PyInstance_Check occurs a more general "is this an instance-like type" check would seem to be more suitable. Here is my proposal: * Define a new type flag Py_TPFLAGS_INSTANCE. * Create a new predicate Py_IsInstance which checks for this flag. * Set this flag on PyInstance_Type. * Replace most occurances of PyInstance_Check with Py_IsInstance. Extension types (like ExtensionClass) can then define the type flag Py_TPLAGS_INSTANCE and be treated as an instance type by the Python interpreter. This should make it quite a bit easier to make extension types behave like "real" classes. Comments? Neil From mal at lemburg.com Tue Oct 24 21:37:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:37:30 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> Message-ID: <39F5E4FA.9FD6D35@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > >... > > > > I think will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. AFAIR, the only truely feasable > > solution would be doing the rewrite in a widely portable > > subset of C++ and then managing classes at that level. > > I disagree for a variety of reasons: > > * implementation language and Python inheritance semantics are almost > completely distinct. After all, we have Python implementations in a > variety of languages with minor incompatibilities. Python could have a > proper type/class merging even if it were written in assembly language. > So let's leave implementation language aside. Hey, think of it as opportunity: we can reuse much of C++'s optimizations and the integration of Python and C++ applications will get *much* easier. A rewrite shouldn't scare anyone away -- much of the existing code can be reused since only the Python C APIs of the various types will have to be rewritten, not the logic behind the types. Besides, Py3K will be a project which runs in parallel to the 2.x development (at least that's what I've read on some BeOpen webpage), so there's really not much to worry about wrt to breakage, etc. People will be able to test-drive Py3K while using the 2.x series. > * there is a hell of a lot we can do to make the type/class split less > visible without a major rewrite. For instance, lists could have a > __getitem__ method so that they "act like" instances. Instances could > return their methods in a dir() so that they "act like" built-in > objects. So there is no reason to wait for a complete rewrite to start > on this path. Right. I didn't want to say that things cannot be done prior to the rewrite, only that a rewrite will give us much more options that we currently have. > * It may even be the case that we can get from here to complete merged > type/class semantics WITHOUT a rewrite. If a mad genious had not written > stackless Python I would have sworn up and down that stackless Python > would require a Python rewrite. It didn't. If another slightly less mad > genious had not integrated ints and longs I would never have believed it > possible without another rewrite. Someone needs to do an analysis of > what it takes to merge types and classes and *demonstrate* that it > requires a rewrite rather than *asserting* that it requires a rewrite. > > In other words, let's stop sprinkling the "major rewrite" pixie dust on > hard problems and instead decide where we want to go and how we want to > get there! See above. > > Moving to a common and very low-level strategy for classes > > will allows us to put even the most basic types (strings and > > numbers) into an inheritence tree. > > I don't know what you mean by a "low-level strategy" for classes. It's > not like we can somehow use C++ vtables without giving up Python's > dynamicity. Python's class handling is about as low-level as it can get > in my humble opinion. With "low-level" I meant trying to build Python classes and instances on top of a very thin layer on top of C++ classes, e.g. all slots could be implemented using true C++ methods with additional logic to override them using dynamically bound Python method objects. > > Differences like the > > ones between Unicode and 8-bit strings would then flesh > > out as two different subclasses of a generic string type which > > again is based on a generic sequence type. > > Of course that's where we want to go but it doesn't avoid the backwards > compatibility problems. Huh ? I was talking about clear design... not ways to avoid b/w compatibility. Merging Unicode and strings will hurt one way or another. This is simply a consequence of using strings as binary containers where Unicode is meant for text only use. > We can do this today using proxying. Could you explain this ? > > The same could be done for dictionaries: special ones for > > just string keys, case insensitive lookups, etc. could all > > be subclasses of a generic mapping class. > > We can easily do this today. No we can't: Python's use of pointer compares to find out which type it is dealing with prevent this. > > Dito for numbers (and division strategies). > > There's no way I'm going to let you get away with that little sleight of > hand. How is inheritance holy water going to allow us to change the > semantics of: > > 5/2 > > without breaking code?? > > The same goes for > > a.b = 5 > > versus > > a.B = 5 > > C++ does not help. Inheritance does not help. Pluggable compilers do not > help. We *will* break code. We just need to decide whether to do it in a > thoughtful way that gives people a chance to migrate or put off > decisions until the last possible moment and then spring it on them with > no between-version upgrade path. Just tell Python to use the correct class for what the code was written for (and this could be done by plugging in a 2.0 compiler). The instances of those classes would still work together with other semantics by virtue of exposing the same interface, yet the internals would work differently, e.g. a module using case insensitive lookup would be compiled using case insensitive dictionaries as namespaces. > > By following this principle there won't be all that much > > breakage, since the old functionality will still be around, > > only the defaults will have changed. > > When you change defaults you break code. Keeping the old functionality > around is barely helpful. Nobody has EVER proposed a change to Python > where something that was previously possible is now made impossible. So > whatever our strategy, the PROBLEM is changing defaults. The solution is > telling people what defaults are changing in what timeline and > discouraging them from depending on the old defaults. All true. I was just referring to the possibility of keeping the old semantics around in case some module relies on them. In this ideal world, a simple "define pythonlevel=2.0" would suffice to make the old module work with Py3k. > > Add to this pluggable compilers and ceval loops, plus a nice > > way of configuring the lot on a per-module basis and you're > > set. (Ok, it's a fluffy clouds image, but you get the picture ;-) > > Sounds mythical. I'm trying to take it out of the realm of fluffy clouds > and bring it into the world that people can plan their businesses and > coding strategies around. Hmm, wasn't Py3k meant as sandbox for new experiments ? The 2.x series is for doing business with, IMHO at least. At the current dev speed we'll have plenty of time to get Py3k rock solid. Then we can add all the backward compatibility layers we want to it. If the design is a good, adding these layers won't pose much of a problem. Why spoil all the fun when we haven't even started thinking about all the possibilities we could use to make Py3k a success ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Oct 24 21:54:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 21:54:39 +0200 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F5E8FF.5F18C71E@lemburg.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Sounds fine, except that the "isinstance()" behaviour would have to be defined somewhere / somehow... a mapping of slots to __special_methods__ would be a good start. BTW, mxProxy does some of this mapping already... you may want to have a look. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm at hypernet.com Tue Oct 24 22:01:25 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 24 Oct 2000 16:01:25 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F5B255.22108.49A43169@localhost> Greg Wilson: > > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > > many of the outfits I've dealt with (and not just with Python). > > > Guido van Rossum: > > Really? Are you sure that's not just general resistence against new things? > > Well, my students' resistance to novelty is low enough that they're willing to > take a Python course :-). This comes up every time I teach; no idea whether it > has any impact on the usability of completed applications, but I believe it > makes people less likely to choose Tkinter when starting development. As I see it, Tk, like SQL, has the property that it's dead easy to get something crappy running, but it takes a real expert (like /F) to make it good. With wxPython, though, it's easy (if somewhat tedious) to get something good - at least as far as normal "forms" style GUIs. I'm not taking sides - I dabble in both and will never be an expert at either. But for clients using Windows, I use wxPython because it's indistinguishable from native Win32. (BTW, MFC is lagging further and further behind native Win32 - I believe MS considers it "legacy".) - Gordon From barry at wooz.org Tue Oct 24 22:06:23 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT) Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <14837.60351.887533.801888@anthem.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> I've run into a problem with ExtensionClass which I believe NS> can only be fixed by modifying Python. I will try to explain. NS> I have an ExtensionClass which defines __cmp__. Depending on NS> the objects being compared, the __cmp__ method may never be NS> called. This is due to code in object.c that looks like this: | if (PyInstance_Check(v) || PyInstance_Check(w)) { | try to use use __cmp__ method | } | else { | try number coerce and fall back on type name comparison | } I hit a similar wall when I tried (a long time ago) to take a boolean class I'd written in Python and make it a built-in type. The problem was that in Python I could compare a Boolean instance against any other object for truth equivalence, but because of this hack, I couldn't do the same with the built-in type. | * Define a new type flag Py_TPFLAGS_INSTANCE. | * Create a new predicate Py_IsInstance which checks for this | flag. | * Set this flag on PyInstance_Type. | * Replace most occurances of PyInstance_Check with | Py_IsInstance. NS> Extension types (like ExtensionClass) can then define the type NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by NS> the Python interpreter. This should make it quite a bit NS> easier to make extension types behave like "real" classes. I'm not sure how well this addresses what I ran into. Would PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set? Does that actually make sense? How does this interact with the rich comparisons idea? Seems like this is a hack that doesn't quite get at the heart of the matter, worthwhile as it may be given the current implementation. -Barry From barry at wooz.org Tue Oct 24 22:11:54 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] getting at the current frame Message-ID: <14837.60682.437334.797392@anthem.concentric.net> I've been playing around with ideas for internationalizing Mailman, which naturally leads to string interpolation. To see why, think about making the following code translatable: def trade(yours, mine): print 'if you give me %s, i will give you %s' % (yours, mine) Because the order of the interpolated values may change in the translated string, you really have to do something like: def trade(yours, mine): print 'if you give me %(yours)s, i will give you %(mine)s' % { 'yours': yours, 'mine' : mine, } which actually will look something like this in real code: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % { 'yours': yours, 'mine' : mine, } The string wrapped in _() is what gets translated here. Okay, we all know that's a pain, right? Lots of people have proposed solutions. I've looked briefly at !?ng's Itpl.py, but I think it probably does too much by adding evaluation. I can define _() to make the problem somewhat more convenient: def _(s): try: raise Exception except Exception: frame = sys.exc_info()[2].tb_frame.f_back d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d Now I can write the code like this: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') All well and good and doable in Python today, except getting the current frame with the exception raising trick is slooow. A simple proposed addition to the sys module can improve the performance by about 8x: def _(s): frame = sys.getcaller(1) d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d The implementation of sys.getcaller() is given in the below patch. Comments? I think this particular addition is too small for a PEP, although ?!ng still owns PEP 215 (which needs filling in). -Barry -------------------- snip snip -------------------- Index: sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.78 diff -u -r2.78 sysmodule.c --- sysmodule.c 2000/09/01 23:29:28 2.78 +++ sysmodule.c 2000/10/24 17:50:30 @@ -15,6 +15,8 @@ */ #include "Python.h" +#include "compile.h" +#include "frameobject.h" #include "osdefs.h" @@ -284,6 +286,38 @@ } #endif +static char getcaller_doc[] = +"getcaller([depth]) -> frameobject\n\ +\n\ +By default, return the frame object at the top of the call stack. If an\n\ +integer depth is given, return the frame object that many calls below the\n\ +top of the stack. If that is deeper than the call stack, a ValueError is\n\ +raised."; + + +static PyObject * +sys_getcaller(PyObject *self, PyObject *args) +{ + PyFrameObject *f = PyThreadState_Get()->frame; + int depth = -1; + + if (!PyArg_ParseTuple(args, "|i:getcaller", &depth)) + return NULL; + + while (depth > 0 && f != NULL) { + f = f->f_back; + --depth; + } + if (f == NULL) { + PyErr_SetString(PyExc_ValueError, + "call stack is not deep enough"); + return NULL; + } + Py_INCREF(f); + return (PyObject*)f; +} + + #ifdef Py_TRACE_REFS /* Defined in objects.c because it uses static globals if that file */ extern PyObject *_Py_GetObjects(PyObject *, PyObject *); @@ -313,6 +347,7 @@ {"getrefcount", sys_getrefcount, 1, getrefcount_doc}, {"getrecursionlimit", sys_getrecursionlimit, 1, getrecursionlimit_doc}, + {"getcaller", sys_getcaller, 1, getcaller_doc}, #ifdef USE_MALLOPT {"mdebug", sys_mdebug, 1}, #endif From nas at arctrix.com Tue Oct 24 15:45:35 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 06:45:35 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400 References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net> Message-ID: <20001024064535.A10253@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote: [on Py_TPLAGS_INSTANCE] > I'm not sure how well this addresses what I ran into [with a > boolean extension type]. Would PyBooleanObject then have to > have it's Py_TPFLAGS_INSTANCE flag set? Does that actually > make sense? I think it would address your problem but I don't know if the name of the flag makes sense. Code around PyInstance_Check() usually looks like this: if (PyInstance_Check(obj)) { PyObject *foo = PyObject_GetAttrString(obj, "__foo__"); ... } else { ... } There is not a lot of code that assumes (obj->ob_type == PyInstance_Type) after a PyInstance_Check(). That's encouraging. > How does this interact with the rich comparisons idea? I don't know. I think I am trying to a address a deeper problem here. > Seems like this is a hack that doesn't quite get at the heart > of the matter, worthwhile as it may be given the current > implementation. Yes, I have that feeling as well. More deep thinking is probably required. :) Neil From mal at lemburg.com Tue Oct 24 22:45:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 24 Oct 2000 22:45:28 +0200 Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <39F5F4E8.1188E1E0@lemburg.com> "Barry A. Warsaw" wrote: > [...] > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. I have a similar function in mxTools. I would use a different name though... something like "sys.getframe()". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Tue Oct 24 23:50:32 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 16:50:32 -0500 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST." <20001024045611.B9993@glacier.fnational.com> References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com> > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: > > * Define a new type flag Py_TPFLAGS_INSTANCE. > * Create a new predicate Py_IsInstance which checks for this > flag. > * Set this flag on PyInstance_Type. > * Replace most occurances of PyInstance_Check with > Py_IsInstance. > > Extension types (like ExtensionClass) can then define the type > flag Py_TPLAGS_INSTANCE and be treated as an instance type by the > Python interpreter. This should make it quite a bit easier to make > extension types behave like "real" classes. > > Comments? Good analysis of a problem -- but I disagree on the solution. Rather than formalizing the exceptions made for instances, we should work on eradicating the differences between classes and types. I believe that the plans for rich comparisons would or could also take care of this. I hope I'll have more time soon to explore this. --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at wooz.org Tue Oct 24 22:49:04 2000 From: barry at wooz.org (barry at wooz.org) Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <39F5F4E8.1188E1E0@lemburg.com> Message-ID: <14837.62912.897422.392307@anthem.concentric.net> >>>>> "M" == M writes: M> I have a similar function in mxTools. I would use a different M> name though... something like "sys.getframe()". Works for me. Thanks, -Barry From guido at python.org Wed Oct 25 00:16:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 17:16:00 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400." <14837.63819.667508.794728@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com> > GvR> Agreed. I think it's good to have the functionality > GvR> available, but it's also good to make it *real* clear not to > GvR> mess with it unless you really know what you're doing. Maybe > GvR> it should be in a separate module or at least have a leading > GvR> _underscore. > > I think you're fairly safe from mischief since the only writable > attributes of a frame object are f_trace, f_exc_type, f_exc_value, and > f_exc_traceback. The same caveats about f_globals and f_locals apply > as with the dicts returned by locals() and globals(). It's not so much that it's easy to do damage with. I have a philosophical problem with making this a feature that people can use whenever they feel like. It's a messy feature and its use should limited as an implementation aid for language features like variable substitution. The other, perhaps more major, problem with this it is that you can't easily wrap functions that use it in other functions. Normally, if there's a function foo(arg) that does something, I can write a function wrapfoo(arg) that does something else, then calls foo(arg), and then does another thing. But if foo() uses getframe(), that's not so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame. A way around this would be to implement foo as a call to (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()). Then _wrapfoo(arg, frame) could be defined as a wrapper around _foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()). This is another reason to be very selective in the use of getframe(). --Guido van Rossum (home page: http://www.python.org/~guido/) From nas at arctrix.com Tue Oct 24 16:37:12 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Tue, 24 Oct 2000 07:37:12 -0700 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500 References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <20001024073712.A10539@glacier.fnational.com> On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote: > Rather than formalizing the exceptions made for instances, we > should work on eradicating the differences between classes and > types. Yes, I see this now. Those PyInstance_Check() calls should really go away. Instead, the type should be responsible for providing different behavior. > I believe that the plans for rich comparisons would or could > also take care of this. I've just briefly looked at the proposal. It consists of two parts. One is splitting __cmp__ into __gt__, __lt__, etc. That is a separate issue to the one we are dicussing. The other part is directly related. In order for types to define their own comparison behavior, it proposes that types have an optional pointer to a rich comparison function in the type structure. I think this is the right idea but it doesn't go far enough. Every operation should be implementable by the type. Code like: if (PyString_Check(obj)) { something } else if (PyInstance_Check(obj)) { something else } ... should disappear unless it is need for performance reasons. I think we are close to achieving this goal. I'll try to come up with a proposal. Neil From barry at wooz.org Tue Oct 24 23:34:54 2000 From: barry at wooz.org (barry at wooz.org) Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> Message-ID: <14838.126.77589.541148@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> The other, perhaps more major, problem with this it is that GvR> you can't easily wrap functions that use it in other GvR> functions. Normally, if there's a function foo(arg) that GvR> does something, I can write a function wrapfoo(arg) that does GvR> something else, then calls foo(arg), and then does another GvR> thing. But if foo() uses getframe(), that's not so easy: the GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame. GvR> A way around this would be to implement foo as a call to GvR> (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, GvR> sys.getframe()). Then _wrapfoo(arg, frame) could be defined GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as GvR> _wrapfoo(arg, sys.getframe()). Darn good point. So where could we put it? It's a useful introspection device. If it goes in a separate module, should that perhaps be called `reflection'? Or maybe `runtime'? Or maybe "sys._getframe()" is good enough. -Barry From guido at python.org Wed Oct 25 01:13:43 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Oct 2000 18:13:43 -0500 Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400." <14838.126.77589.541148@anthem.concentric.net> References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com> > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. sys._getframe() is good enough. --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA at ActiveState.com Wed Oct 25 01:08:28 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov> Message-ID: > Back in my former life, when I was still worrying about Windows, the > company I worked for bought into a commerical x-platform GUI toolkit > called Galaxy (I mentioned this earlier). Galaxy re-implemented all > the native widgets, kind of like XPFE does. One issue with this was > that MS seemed to change something about the widgets in every release > - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came > out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, > Win98 came out. Now I hear there's something called Windows ME. Have > they changed the look-and-feel again? Seems to me like all the > widget-reimplementors are doomed to playing eternal catch-up. Back in a former life of _mine_, I was one of two people who understood the architecture of Neuron Data's Open Interface Toolkit. It used the same strategy. Not sure what that has to do with Python, though it was a very fun project. It was also fun to turn on the Mac 'theme' on a Decwindows box (we're talking 1989 or so =). The funniest story about that job involves Cray and black and white monitors, but that's a story for another time, another place. --da From greg at cosc.canterbury.ac.nz Wed Oct 25 01:18:59 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT) Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us> Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Andrew Kuchling : > It seems to me that supporting MacOS is the big problem for > cross-platform GUIs. It appears that we can't rely on anyone else to provide and support a GUI properly across all three platforms. If we want one, it looks like we'll have to do it ourselves. How about reviving and building upon stdwin? I quite liked stdwin, despite its limitations, because it was small and simple, and it worked on both Mac and Unix. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From est at hyperreal.org Tue Oct 24 23:58:43 2000 From: est at hyperreal.org (est at hyperreal.org) Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT) Subject: [Python-Dev] Re: getting at the current frame In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org" at "Oct 24, 2000 05:34:54 pm" Message-ID: <20001024215843.7507.qmail@hyperreal.org> barry at wooz.org discourseth: > > Darn good point. So where could we put it? It's a useful > introspection device. If it goes in a separate module, should that > perhaps be called `reflection'? Or maybe `runtime'? Or maybe > "sys._getframe()" is good enough. Hmm..I'd think `reification' instead of `reflection'. My understanding was that reification involves taking an implicit language entity and making it an expressed value (e.g., getframe() or call_with_current_continuation()) while reflection goes in the opposite direction (e.g., eval()). pedantically, e From greg at cosc.canterbury.ac.nz Wed Oct 25 03:14:52 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT) Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <20001024073712.A10539@glacier.fnational.com> Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Neil Schemenauer : > Those PyInstance_Check() calls should really go away. Instead, the > type should be responsible for providing different behavior. Yes, that's the crux of the problem, I think. Another place where this is a nuisance is where it assumes that if x has any tp_as_sequence slots and y has any tp_as_number slots, then x*y is a sequence replication operation. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From esr at thyrsus.com Wed Oct 25 06:56:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 21:56:27 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200 References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid> Message-ID: <20001024215627.B1147@thyrsus.com> Fredrik Lundh : > > Can someone articulate why Tk should be replaced? > > beats me ;-) My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become effectively unmaintained in the foreseeable future. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr at thyrsus.com Wed Oct 25 07:29:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 24 Oct 2000 22:29:17 -0700 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300 References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> Message-ID: <20001024222917.I1147@thyrsus.com> Greg Ewing : > It appears that we can't rely on anyone else to provide and > support a GUI properly across all three platforms. If we > want one, it looks like we'll have to do it ourselves. I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance. -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From barry at wooz.org Wed Oct 25 05:11:54 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> Message-ID: <14838.20346.451094.231019@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. Cool, I'll upload the patch to SF. -Barry From barry at wooz.org Wed Oct 25 05:44:10 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT) Subject: [Python-Dev] Re: getting at the current frame References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com> <14838.126.77589.541148@anthem.concentric.net> <200010242313.SAA19938@cj20424-a.reston1.va.home.com> <14838.20346.451094.231019@anthem.concentric.net> Message-ID: <14838.22282.676715.200546@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "GvR" == Guido van Rossum writes: GvR> sys._getframe() is good enough. BAW> Cool, I'll upload the patch to SF. Patch #102106 http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 (includes doc patch) -Barry From tim_one at email.msn.com Wed Oct 25 09:10:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 03:10:36 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F54C0F.25798309@lemburg.com> Message-ID: [MAL] > ... > I think will simply be a consequence of doing a complete rewrite > of the interpreter for Py3K. Not just to be my usual self , but I do see a from-scratch rewrite as being less likely as the years go by. There's nothing I know of in Guido's plans that can't be done incrementally instead -- and if he doesn't either, selling a total- rewrite project to an employer is probably impossible. The most successful projects I've seen and been on *did* rewrite all the code routinely, but one subsystem at a time. This happens when you're tempted to add a hack, realize it wouldn't be needed if an entire area were reworked, and mgmt is bright enough to realize that hacks compound in fatal ways over time. The "ain't broke, don't fix" philosophy is a good guide here, provided you've got a very low threshold for insisting "it's broke" <0.4 wink>. if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means- *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs - tim From moshez at math.huji.ac.il Wed Oct 25 09:49:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 24 Oct 2000, Guido van Rossum wrote: > Maybe we can do the same for Unix binary distributions? I don't know what you mean by "UNIX" binary distributions: each UNIX has its own sets of horrors in the distribution arena. Personally, I don't care what we do about RPMs, since I'm not a Red Hat user. However, this should probably be more Red Hat's job then ours. Debian, on the other hand, would probably do this much better then Python-Dev can, without gratutitous Tcl/Tk installations. For other unices, most people install from sources anyway, which mostly means I should get off my butt and start working on the Sumo interpreter. > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. I don't know how to break this to you, but you're not the average computer user . -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal at lemburg.com Wed Oct 25 10:10:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 25 Oct 2000 10:10:46 +0200 Subject: [Python-Dev] Gradual migration References: Message-ID: <39F69586.E017DA7E@lemburg.com> Tim Peters wrote: > > [MAL] > > ... > > I think this will simply be a consequence of doing a complete rewrite > > of the interpreter for Py3K. > > Not just to be my usual self , but I do see a from-scratch rewrite as > being less likely as the years go by. There's nothing I know of in Guido's > plans that can't be done incrementally instead -- and if he doesn't either, > selling a total- rewrite project to an employer is probably impossible. > > The most successful projects I've seen and been on *did* rewrite all the > code routinely, but one subsystem at a time. This happens when you're > tempted to add a hack, realize it wouldn't be needed if an entire area were > reworked, and mgmt is bright enough to realize that hacks compound in fatal > ways over time. The "ain't broke, don't fix" philosophy is a good guide > here, provided you've got a very low threshold for insisting "it's broke" > <0.4 wink>. As I mentioned in the posting, the idea was from the "fluffy clouds" area. The rewrite would only involve the core type system and perhaps the core interpreter layout (parser, compiler, etc. all wrapped in classes) -- most of the existing code would be reusable. The idea behind this is somewhat like what you do when starting out a project based on a few simple functions and then reorganizing the code into a class-based approach. There's no need to rewrite all the type internals, just the type interfaces. Python has long reached a level of complexity that is counter- productive when it comes to adding new extension types. Just think of all the problems people have with coercion, the integration of user defined and internal types, the missing links between types and classes, etc. etc. BTW, why all the talk about "employers" ? Much of Python's code base was written without any employer knowing about it ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Wed Oct 25 12:40:56 2000 From: jim at interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:40:56 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> Message-ID: <39F6B8B8.E3242929@interet.com> Andrew Kuchling wrote: > Can someone articulate why Tk should be replaced? I don't know whether Tk should replaced, but I can explain why I don't use it for our commercial Python application. It is just too big and complicated. Windows comes with a built-in GUI, and I hesitate to install another scripting language (Tcl) and its libraries, and then install a big system which has frequently been out of phase with Python releases just to access the Windows GUI. What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks. JimA From jim at interet.com Wed Oct 25 12:47:05 2000 From: jim at interet.com (James C. Ahlstrom) Date: Wed, 25 Oct 2000 06:47:05 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> Message-ID: <39F6BA29.3CAB4C0E@interet.com> Guido van Rossum wrote: > > 2. (Lack of) native look and feel. This is a complete show-stopper for > > many of the outfits I've dealt with (and not just with Python). > > Really? Are you sure that's not just general resistence against new > things? To me, and I suspect may others, the app I use most often on > Windows is Netscape -- talk about lack of native look-and-feel! It's > never bothered me all that much. In the past I have resolutely demanded native Windows look and feel in my apps. In fact, I have been tiresome on the topic. Now I am changing my mind. Lots of prominent Windows apps now depart from Microsoft LAF, and I have the impression that users are getting used to it. I still think the usual File menu items and file open/save dialogs should be standard, but I am less concerned about other controls. For a look at how to really do controls, check out software for kids. Just my 1.e-2$. JimA From guido at python.org Wed Oct 25 14:11:35 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:11:35 -0500 Subject: [Python-Dev] Why not revive stdwin? In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST." <20001024222917.I1147@thyrsus.com> References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz> <20001024222917.I1147@thyrsus.com> Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com> > Greg Ewing : > > It appears that we can't rely on anyone else to provide and > > support a GUI properly across all three platforms. If we > > want one, it looks like we'll have to do it ourselves. Eric Raymond: > I fear this is much too big a job to be practical -- not just in the > additional code but the downstream maintainance. Well said. The "roll your own" approach has been attempted before, but simply isn't worth the time and effort. After all, Python is a glue language! (And stdwin would really look pathetic in this time.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 25 14:25:29 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:25:29 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400." <39F6B8B8.E3242929@interet.com> References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> > Andrew Kuchling wrote: > > > Can someone articulate why Tk should be replaced? Jim Ahlstrom replied: > I don't know whether Tk should replaced, but I > can explain why I don't use it for our commercial > Python application. > > It is just too big and complicated. Windows comes > with a built-in GUI, and I hesitate to install > another scripting language (Tcl) and its libraries, > and then install a big system which has frequently been > out of phase with Python releases just to access the > Windows GUI. To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers. > What if a user calls with a problem? Why should I > have to debug their Tcl library path problems? No > thanks. The Tcl library paths are all taken care of by the new installer strategy. Really, give it a try. It Just Works! (SM) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Oct 25 14:27:28 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 07:27:28 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400." <39F6BA29.3CAB4C0E@interet.com> References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com> > In the past I have resolutely demanded native Windows look > and feel in my apps. In fact, I have been tiresome on the topic. > > Now I am changing my mind. Lots of prominent Windows apps now > depart from Microsoft LAF, and I have the impression that users > are getting used to it. I still think the usual File menu > items and file open/save dialogs should be standard, but I > am less concerned about other controls. For a look > at how to really do controls, check out software for > kids. Just my 1.e-2$. Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player? --Guido van Rossum (home page: http://www.python.org/~guido/) From jim at digicool.com Wed Oct 25 14:21:41 2000 From: jim at digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:21:41 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com> Message-ID: <39F6D055.584C4FEA@digicool.com> Guido van Rossum wrote: > (snip) > Rather than formalizing the exceptions made for instances, we should > work on eradicating the differences between classes and types. Yee ha! I couldn't agree more. :) > I believe that the plans for rich comparisons would or could also take > care of this. I assume that rich comparison's have new slots with signatures that don't assume objects of the same type. > I hope I'll have more time soon to explore this. Me too. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jim at digicool.com Wed Oct 25 14:25:53 2000 From: jim at digicool.com (Jim Fulton) Date: Wed, 25 Oct 2000 08:25:53 -0400 Subject: [Python-Dev] A small step to removing the type/class split References: <20001024045611.B9993@glacier.fnational.com> Message-ID: <39F6D151.70F47CFF@digicool.com> Neil Schemenauer wrote: > > I've run into a problem with ExtensionClass which I believe can > only be fixed by modifying Python. I will try to explain. > > I have an ExtensionClass which defines __cmp__. Depending on the > objects being compared, the __cmp__ method may never be called. > This is due to code in object.c that looks like this: > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > try to use use __cmp__ method > } > else { > try number coerce and fall back on type name comparison > } > > Extension classes can never pass the PyInstance_Check predicate. > I've searched for all occurances of PyInstance_Check in the 2.0 > source. In many places that PyInstance_Check occurs a more > general "is this an instance-like type" check would seem to be > more suitable. > > Here is my proposal: (snip) I think you got some good answers later in the thread. I'll point out that a work around is to make your ExtensionClass a numeric type. Numeric types have different comparison semantics that allow you to get around this limitation. I did this a few months back for acquisition wrappers. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From gvwilson at nevex.com Wed Oct 25 14:38:12 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com> Message-ID: > Guido van Rossum: > Can you elaborate on the line of argument that you typically hear > [objections to Tkinter]? What do you say to dispel it? From guido at python.org Wed Oct 25 15:53:48 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 08:53:48 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400." References: Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> > From some feedback forms from old runs of my Python course (with spelling > corrections :-) > > 1. "My users don't care what programs are written in. They just care > if they're easy to use. They won't care if Python programs have > the same look and feel on different computers, because they won't > ever think of [name of program] as a Python program. To them, it > will be a Windows program that looks funny." > > 2. "You said three times in the intro lecture this morning that the > most important thing in a GUI was consistency. Then you told us to > write GUIs that look different from everything else on the desktop." > > 3. "I'm confused: I didn't realize that Python was a library on top of > TCL." > > I spent a minute drawing blob diagrams to answer #3; I think most students > understood, but the person who asked the question was clearly still confused. > > I didn't try to dispel #1 or #2, because I agree with them: my > experience is that consistent look and feel are crucial for making > non-programmers less afraid of pressing the wrong button or making > the program "do weird things". Other people with more experience > creating end-user applications may have different views. This is helpful. Can you elaborate on what elements of the Windows look-and-feel are missing in Tkinter? As far as I know, the menu bars, file selection dialogs, scroll bars, dialog boxes and so on have a thoroughly native look-and-feel, since Tk implements these as wrappers around the native widgets. IDLE doesn't look very different from Notepad! So what's missing? A toolbar with icons? That would be easy to add using existing Tk controls (Pmw has it too). The multiple document interface? It sucks -- and even Word 2000 has gone away from that! What kind of GUIs did you teach them exactly? If you started with basic Tkinter widgets, sure, it looks different than anything else. But that depends on the widget layout in the program, not on the widget library used! --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at scottb.demon.co.uk Wed Oct 25 15:55:40 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 25 Oct 2000 14:55:40 +0100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <002301c03e8b$42cbc280$060210ac@private> I choose to use wxPython over TK because: 1. wxPython has a reasonable event model 2. wxPython allows me build one object hierarchy 3. TK requires I manage two object hierarchies, TK's and my classes 4. Hooking events to TK seems clumsy from Python As others have said better docs on wxPython would be nice and its to easy to crash the world from wxPython. Barry From claird at starbase.neosoft.com Wed Oct 25 16:58:53 2000 From: claird at starbase.neosoft.com (Cameron Laird) Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters Message-ID: <200010251458.JAA77237@starbase.neosoft.com> I can rarely afford to dip into Python-Dev. My head is exploding too much of the time as it is. Maybe I can help with the recent Tkinter discussions, though. 1. Tcl's going to be around for a long time. Here's the insider scoop on what the Ajuba Solutions announcement means: insiders don't know. That is, *nobody* is sure how Tcl will develop. It'll survive, though, for quite a while. Do NOT worry that it'll suddenly dry up and blow away. I'm working on a more detailed explanation of Tcl processes. It'll probably take a few weeks, though. In the meantime, just ignore the mess, and understand that the Tcl Core Team includes bright people who'll land on their feet somehow. 2. I agree that MacOS is the thorny problem for the standard Pysolution. I'd be happy to discuss the possibilities (Tkinter? wxWindows? Qt?!? GTK+?!!?!? ...) with a smaller group, and, of course, Fredrik, Robin, Guido, ... all are quite knowledgeable about these matters. There are a few things you should know about the Tcl side. The bad is that Tk is barely maintained for MacOS. It's really rather miserable. On the other hand, Jim Ingham is now an Apple employee, and things could change in a hurry, at any time. The good is that Tk starts far ahead of any competitor. It has already solved most of the hard problems. All it needs is a little maintenance. 3. Is there a way to have Tk without contamination by Tcl? More than ever. This is what makes me most cheerful about Tkinter's prospects. The Tcl Core Team has largely given up its hangups about co-operating with foreigners (or its hangups that barbarians have hangups about co- operating with Tcl). This is a *very* good time for someone like Fredrik to establish a working relationship, and get CVS access. I really think Tk can be maintained by a different group than Tcl. Perl, Ruby, ... folks are also receptive to the idea (I've talked with them). For pointers to some of what's happening in this area, see Also, you should know that my favorite enhancement to Tk is a remodularization called TkGS. This should improve performance under Win*, make it more portable to BeOS, improve access by Python, and so on. 4. Greg's right that some publishers are dumping Tcl. Not all, though. If it matters, we can go into details. 5. Pango is indeed cool, but it's different from [text]. The world is probably moving to Pango and similar implementations. The world will be missing much of what [text] offers. 6. ANYONE with an urge to get out a Python-related idea should pursue it. *DDJ*'s a great outlet. It's far from the only one. If people have ideas about articles, but are held back by lack of time/ fluency/contacts/..., *please* get in touch with me. I'll find a way at least to give articles a fair chance at being published. Cameron Laird +1 281 996 8546 FAX http://starbase.neosoft.com/~claird/misc.writing/publications.html From cgw at fnal.gov Wed Oct 25 17:31:38 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com> References: <200010251458.JAA77237@starbase.neosoft.com> Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov> Cameron Laird writes: > I can rarely afford to dip into Python-Dev. My head is exploding > too much of the time as it is. > > Maybe I can help with the recent Tkinter discussions, though. > 2. I agree that MacOS is the thorny problem for > the standard Pysolution. What is the impact of the fact that MacOS X will run X? Doesn't this open the door to a lot of new possibilities, at least if we don't need to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just way too big to even think about dropping (or deprecating) support for it? From tim_one at email.msn.com Wed Oct 25 18:23:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 12:23:30 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: [Guido, on finding Tcl/Tk under Windows] > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. That's different -- > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > installer was optionally run. The version issues are also resolved > this way: you are guaranteed to get exactly the Tcl/Tk version that > was tested by the developers. Unless you're Fredrik, alas . Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course). >> What if a user calls with a problem? Why should I >> have to debug their Tcl library path problems? No >> thanks. > The Tcl library paths are all taken care of by the new installer > strategy. > > Really, give it a try. It Just Works! (SM) I'll second that! "Mystery startup errors" from the Python+Tcl+Tk+Windows combo were at least weekly questions on c.l.py for 1.5.2, often daily. I've seen none for 1.6 or 2.0. and-all-it-took-was-avoiding-ms's-recommended-practices-ly y'rs - tim From guido at python.org Wed Oct 25 19:46:55 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 12:46:55 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400." References: Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com> > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. [Tim] > Unless you're Fredrik, alas . Apparently Tcl still honors library > envars first if they exist, and if some other installation or use of Tcl/Tk > set those, you can still end up w/ a mix. *Much* better than before, though, > and I don't recall ay instance of this happening in real life so far apart > from /F (who had no problem figuring it out, of course). Hm... In FixTk, TCL_LIBRARY is set explicitly. Perhaps it should set TK_LIBRARY explicitly too? --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm at ActiveState.com Wed Oct 25 19:11:42 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 25 Oct 2000 10:11:42 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400 References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <20001025101142.B8625@ActiveState.com> On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote: > [Guido, on finding Tcl/Tk under Windows] > > To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't > > have to install Tcl/Tk or its libraries -- it is installed > > *transparently* by the Python Windows installer. That's different -- > > and better -- than what happened in 1.5.2, where a separate Tcl/Tk > > installer was optionally run. The version issues are also resolved > > this way: you are guaranteed to get exactly the Tcl/Tk version that > > was tested by the developers. > > Unless you're Fredrik, alas . ...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it. Trent -- Trent Mick TrentM at ActiveState.com From pf at artcom-gmbh.de Wed Oct 25 19:02:45 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST) Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am" Message-ID: Hi, Charles G Waldman: > > 2. I agree that MacOS is the thorny problem for > > the standard Pysolution. > > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? It will take years, before MacOS X will find its way onto the desk of the average Apple Mac user. The Mac s mostly used in the graphics and printing industry (our cutsomers) where people normally don't even think about a OS upgrade, if they don't have to. They usually run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other so called creative software on the version of the OS they had on the machine when they bought it. THese machines are usually used through a period of at least four years. So MacOS X might simplify things for software vendors from 2004 on and later. Regards, Peter From guido at python.org Wed Oct 25 20:21:58 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:21:58 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST." <20001025101142.B8625@ActiveState.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> > ...Or anybody installing ActivePython for that matter. We give instructions > that the latest version of Tcl/Tk has to be installed separately, but Tk is > *not* bundled with it. And that's a shame. Any chance that will be fixed any time soon? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at alum.mit.edu Wed Oct 25 15:36:46 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> ...Or anybody installing ActivePython for that matter. We give >> instructions that the latest version of Tcl/Tk has to be >> installed separately, but Tk is *not* bundled with it. GvR> And that's a shame. Any chance that will be fixed any time GvR> soon? I think a version of Tkinter packaged with a distutils setup script is the best answer for Unix platforms. As a Linux user, I do *not* want to install a second copy of Tcl/Tk. If we have a distutil-Tkinter, e.g. ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz then a user can download it and run "python setup.py install" to build a Tkinter against their installed version of Tk. This will be straightforward on many Linux systems, because they ship with Tk installed. Jeremy From jeremy at alum.mit.edu Wed Oct 25 15:41:30 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT) Subject: [Python-Dev] build problems under Solaris Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net> There are two bug reports about build problems under Solaris (117508 and 117606). I don't have access to a Solaris machine, so I can't do anything to help these users. Since ActivePython is shipped for Solaris, I assume that you (or someone else at AS) does have access to a Solaris machine. Can you take a look at these problems? Or assign them to someone else who can? Jeremy From guido at python.org Wed Oct 25 20:50:07 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 13:50:07 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400." <14838.57838.841831.632628@bitdiddle.concentric.net> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> > I think a version of Tkinter packaged with a distutils setup script is > the best answer for Unix platforms. As a Linux user, I do *not* want > to install a second copy of Tcl/Tk. Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was, so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself, one for Python+Tkinter, one for Perl/Tk (that's a separate code base anyway so you already have this today -- if you install Perl/Tk, that is), and one for Ruby. Given modern disk sizes I don't think it's a problem. We do the same for Windows, for good reasons: so we can be independent of whatever Tcl/Tk version is already installed. > If we have a distutil-Tkinter, e.g. > ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz > then a user can download it and run "python setup.py install" to build > a Tkinter against their installed version of Tk. This will be > straightforward on many Linux systems, because they ship with Tk > installed. Of course that's easier. But less robust. (And why is there an "8.0" in the filename if it works with other Tcl/Tk versions???) --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Wed Oct 25 20:11:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:11:34 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> Message-ID: <39F72256.C7F93BFB@prescod.net> "M.-A. Lemburg" wrote: > > ... > > > * implementation language and Python inheritance semantics are almost > > completely distinct. After all, we have Python implementations in a > > variety of languages with minor incompatibilities. Python could have a > > proper type/class merging even if it were written in assembly language. > > So let's leave implementation language aside. > > Hey, think of it as opportunity: we can reuse much of C++'s > optimizations and the integration of Python and C++ applications > will get *much* easier. We could make integrating C++ and Python easier through CXX or Py_Cpp. Perhaps we should ship one of those with Python 2.1. Anyhow, integrating C++ and Python is not really so hard, in my experience. > A rewrite shouldn't scare anyone away -- much of the existing > code can be reused since only the Python C APIs of the various > types will have to be rewritten, not the logic behind the types. I wasn't really addressing the issue of backwards compatibility of extensions -- I was talking about Python programs. Nevertheless, I can't resist: Porting your app to the Python APIs is often the majority of the work in a particular extension. A lot of Python extensions consist only of API glue! > Besides, Py3K will be a project which runs in parallel to the > 2.x development (at least that's what I've read on some BeOpen > webpage), so there's really not much to worry about wrt to > breakage, etc. People will be able to test-drive Py3K while > using the 2.x series. I don't see how that helps. If you can't write programs that work both on the old interpreter and the new one then you need to have a "switch over" day. The whole point of my doctrine is that Python 3K should run all code that the version of Python immediately before it did. The most it can do in terms of breakage is to warn about error messages. In that case it doesn't matter much whether Python 3K is available at the same time as 2.X or emerges from Guido's head fully formed. > > * there is a hell of a lot we can do to make the type/class split less > > visible without a major rewrite. For instance, lists could have a > > __getitem__ method so that they "act like" instances. Instances could > > return their methods in a dir() so that they "act like" built-in > > objects. So there is no reason to wait for a complete rewrite to start > > on this path. > > Right. I didn't want to say that things cannot be done prior > to the rewrite, only that a rewrite will give us much more > options that we currently have. Okay, so do you agree with the rule expressed here: http://www.python.org/pipermail/python-dev/2000-October/016785.html > > I don't know what you mean by a "low-level strategy" for classes. It's > > not like we can somehow use C++ vtables without giving up Python's > > dynamicity. Python's class handling is about as low-level as it can get > > in my humble opinion. > > With "low-level" I meant trying to build Python classes and > instances on top of a very thin layer on top of C++ classes, > e.g. all slots could be implemented using true C++ methods with > additional logic to override them using dynamically bound > Python method objects. I don't think that there is really interesting magic in a C++ compiler. A vtable is an array of pointers to functions. We've already implemented the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and smart pointers are a little more interesting from a code maintenance and simplicity point of view. But even then I think that we could get to a C++ implementation through incremental rewrites. > > > Differences like the > > > ones between Unicode and 8-bit strings would then flesh > > > out as two different subclasses of a generic string type which > > > again is based on a generic sequence type. > > > > Of course that's where we want to go but it doesn't avoid the backwards > > compatibility problems. > > Huh ? I was talking about clear design... not ways to avoid > b/w compatibility. But the whole point of my original article was backwards compatibility!!! I didn't address an implementation strategy for Py3K at all. > Merging Unicode and strings will hurt one > way or another. This is simply a consequence of using strings > as binary containers where Unicode is meant for text only use. The question I wanted to address is how we can *minimize the pain*. > ... > > C++ does not help. Inheritance does not help. Pluggable compilers do not > > help. We *will* break code. We just need to decide whether to do it in a > > thoughtful way that gives people a chance to migrate or put off > > decisions until the last possible moment and then spring it on them with > > no between-version upgrade path. > > Just tell Python to use the correct class for what the > code was written for (and this could be done by plugging in > a 2.0 compiler). The instances of those classes would still work > together with other semantics by virtue of exposing the same > interface, yet the internals would work differently, e.g. > a module using case insensitive lookup would be compiled using > case insensitive dictionaries as namespaces. A mode switch solutiion is fraught with dangers. First there is the issue of the correct default for the mode switch. http://www.python.org/pipermail/python-dev/2000-April/010029.html Second, there are dangers cutting and pasting between modules. Anyhow, even if we allow a mode switch we need to be able to help people to upgrade their modules in a reasonable time. That's what the message I cited advocates. >... > Why spoil all the fun when we haven't even started thinking > about all the possibilities we could use to make Py3k a > success ? Asking for a map of where we are going and how we will get here is "spoiling all of the fun?" I'm not sure what you are reacting to -- I didn't advise one implementation strategy or another -- I just said that we should employ a strategy that minimizes sudden and surprising code breakage. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From fdrake at acm.org Wed Oct 25 20:06:50 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From paul at prescod.net Wed Oct 25 20:18:16 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:18:16 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <39F723E8.2AC6787@prescod.net> Charles G Waldman wrote: > > ... > What is the impact of the fact that MacOS X will run X? Doesn't this > open the door to a lot of new possibilities, at least if we don't need > to support Mac OS[6-9]. Or is the installed base of MacOS[6-9] just > way too big to even think about dropping (or deprecating) support for > it? Would Mac users go for: "first install X. Then you can run Python." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From guido at python.org Wed Oct 25 21:14:57 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 14:14:57 -0500 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400." <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com> <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com> > > Why not? Because if every app using Tcl/Tk did that there would be > > hundreds of copies of Tcl/Tk on your disk? I don't think that > > argument flies; only a few other major languages use Tcl/Tk this was, > > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? Of course not, but large and important ones may. Some already do, e.g. Alice, Zope, Ultraseek. I have no problem with this. (The saving grace is that none of these needs to recursively include Tcl. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From gvwilson at nevex.com Wed Oct 25 20:17:24 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT) Subject: [Python-Dev] Gradual migration In-Reply-To: <39F72256.C7F93BFB@prescod.net> Message-ID: > Paul Prescod: > Anyhow, integrating C++ and Python is not really so hard, in my experience. ...unless you are using heavily-templated code, e.g. every damn class you've been asked to wrap up seems to be derived from something in the STL... Greg From cgw at fnal.gov Wed Oct 25 20:18:56 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT) Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters In-Reply-To: <39F723E8.2AC6787@prescod.net> References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov> Paul Prescod writes: > > Would Mac users go for: "first install X. Then you can run Python." > I should probably just shut up, because I really don't know enough about Mac OS X, but what I was wondering is whether OS X will actually *use* the X Window System. Of course we don't want to tell users that they have to go install X on their own. From tim_one at email.msn.com Wed Oct 25 20:18:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 25 Oct 2000 14:18:55 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> Message-ID: [Guido] > Why not? Because if every app using Tcl/Tk did that there would be > hundreds of copies of Tcl/Tk on your disk? I don't think that > argument flies; only a few other major languages use Tcl/Tk this was, [Fred Drake] > So should every application written in Python install it's own copy > of Python, since there may be unexpected incompatibilities between > versions? So long as Python doesn't guarantee binary compatibility across releases, that's the only thing that works. Play PySol lately ? From paul at prescod.net Wed Oct 25 20:27:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:27:33 -0700 Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov> <39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov> Message-ID: <39F72615.40B38862@prescod.net> Charles G Waldman wrote: > >... > > I should probably just shut up, because I really don't know enough > about Mac OS X, but what I was wondering is whether OS X will actually > *use* the X Window System. Of course we don't want to tell users that > they have to go install X on their own. And become just another Unix? Then how would they get people to pay the Macintosh usability premium? Seriously, maybe someday as a "Linux compatibility mode" but I don't think it is officially proposed. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From paul at prescod.net Wed Oct 25 20:30:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 25 Oct 2000 11:30:34 -0700 Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration) References: Message-ID: <39F726CA.9D472E50@prescod.net> Peter Funk wrote: > > .. > > Bruce Sherwood and David Scherer suggested a IMHO very clever solution to > this particular problem in March/April this year. This thread was first > posted to idle-dev and afterwards X-posted to python-dev: > > http://www.python.org/pipermail/idle-dev/2000-April/000138.html > http://www.python.org/pipermail/idle-dev/2000-April/000140.html > http://www.python.org/pipermail/python-dev/2000-April/010029.html Tim's last message on it doesn't sound overwhelmingly positiive to me! Also, don't forget that Python is also a command line so "version pragmas" cause additional complexity there. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From DavidA at ActiveState.com Wed Oct 25 20:59:35 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time) Subject: [Python-Dev] build problems under Solaris In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net> Message-ID: On Wed, 25 Oct 2000, Jeremy Hylton wrote: > There are two bug reports about build problems under Solaris (117508 > and 117606). I don't have access to a Solaris machine, so I can't do > anything to help these users. Since ActivePython is shipped for > Solaris, I assume that you (or someone else at AS) does have access to > a Solaris machine. Can you take a look at these problems? Or assign > them to someone else who can? Sure, we'll take a look. --david From akuchlin at mems-exchange.org Wed Oct 25 23:51:40 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 17:51:40 -0400 Subject: [Python-Dev] 2.0 articles Message-ID: I'd like to begin writing an article about 2.0's Unicode support. Before beginning, has anyone else already begun this task? If yes, please let me know... (Incidentally, did a 2.0 press release ever go out? Is someone going to write one?) --amk From MarkH at ActiveState.com Thu Oct 26 00:18:27 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 09:18:27 +1100 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com> Message-ID: [Trent] > > ...Or anybody installing ActivePython for that matter. We > > give instructions that the latest version of Tcl/Tk has to > > be installed separately, but Tk is *not* bundled with it. [Guido] > And that's a shame. Any chance that will be fixed any time soon? Not presuming to speak for anyone, least of all the ActivePython product manager :-) I don't think it will be "fixed", as it is not considered "broken". It was an explicit choice to leave out Tcl/Tk. And my recollection is that the "feedback" address sees more requests for wxPython than Tcl/Tk. We make it pretty clear Tcl/Tk is not included - I assume that everyone who cares about that simply uses BeOpen releases or source tarballs. [When I say "wont be fixed", I mean it is unlikely to appear in the core ActivePython release. It almost certainly will be supported as an add-on, whatever that turns out to mean exactly ;-] Mark. From guido at python.org Thu Oct 26 02:15:31 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 19:15:31 -0500 Subject: [Python-Dev] 2.0 articles In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400." References: Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) No; and not me... --Guido van Rossum (home page: http://www.python.org/~guido/) From MarkH at ActiveState.com Thu Oct 26 01:29:52 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Thu, 26 Oct 2000 10:29:52 +1100 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: [From a mail in idle-dev - dropped idle-dev and all CCs] [idle-dev poster] > > >>> import sys > > >>> f = open('some-output-file', 'w') > > >>> sys.stdout = f > > >>> # do some stuff > > >>> sys.stdout = sys.__stdout__ > > > > Because on entry, sys.stdout is already redirected > > (not reflected in sys.__stdout__) [Guido] > Where did you get this idiom? You should never use sys.__stdout__ > this way! The proper idiom is > > save_stdout = sys.stdout > try: > sys.stdout = f > # do some stuff > finally: > sys.stdout = save_stdout > > If you know of any places that are promoting direct use of __stdout__, > please let them know this is wrong. If you are contemplating to use > this in code examples you intend to distribute, please don't! I admit that I first became aware of sys.__stdout__ after seeing this exact same idiom in other peoples code. I always assumed that this is _exactly_ what sys.__stdout__ was to be used for! The following examples exist: * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. * Tools/il8n/pygettext.py - ditto * Tools/idle/PyParse.py - disabled, debugging output function - presumably to get around sys.stdout redirection - but this sounds suspect as an idiom to me too! So what _is_ it intended for? Mark. From greg at cosc.canterbury.ac.nz Thu Oct 26 02:16:02 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT) Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com> Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz> > If you started with basic Tkinter widgets, sure, it looks different > than anything else. But that depends on the widget layout in the > program, not on the widget library used! This is one of my main gripes about the Tk API. The default behaviours of all its layout managers suck. In order to get a layout that looks pleasant and/or conforms to some style guide, you have to set a whole slew of options every time you place a widget. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From barry at wooz.org Thu Oct 26 02:17:38 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.30754.217582.20441@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> * Tools/il8n/pygettext.py That's embarassing. ;) Here's a patch, but I'm not going to check it in because I think a /much/ better idiom to adopt is to use extended print instead. I need to make some updates to pygettext.py soon, so I'll probably just 2.0-ify it at the same time. -Barry -------------------- snip snip -------------------- Index: pygettext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v retrieving revision 1.9 diff -u -r1.9 pygettext.py --- pygettext.py 2000/05/02 19:28:30 1.9 +++ pygettext.py 2000/10/26 00:16:22 @@ -283,6 +283,7 @@ options = self.__options timestamp = time.ctime(time.time()) # common header + stdout = sys.stdout try: sys.stdout = fp # The time stamp in the header doesn't have the same format @@ -314,7 +315,7 @@ print 'msgid', normalize(k) print 'msgstr ""\n' finally: - sys.stdout = sys.__stdout__ + sys.stdout = stdout def main(): From gmcm at hypernet.com Thu Oct 26 02:39:14 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 25 Oct 2000 20:39:14 -0400 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <39F744F2.17759.4FC8E6D4@localhost> > [Guido] > > > Where did you get this idiom? You should never use sys.__stdout__ > > this way! The proper idiom is > > > > save_stdout = sys.stdout > > try: > > sys.stdout = f > > # do some stuff > > finally: > > sys.stdout = save_stdout [Mark] > So what _is_ it intended for? A fail-safe. The recommended idiom might also be called "plays well with others"; a barbarian notion that fortunately has not infected most import hacks or program exits... works-for-me-so-buzz-off-ly y'rs - Gordon From akuchlin at mems-exchange.org Thu Oct 26 04:40:03 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 25 Oct 2000 22:40:03 -0400 Subject: [Python-Dev] 2.0 press release In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500 References: <200010260015.TAA02798@cj20424-a.reston1.va.home.com> Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us> On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote: >> (Incidentally, did a 2.0 press release ever go out? Is someone going >> to write one?) >No; and not me... Little-known fact: Guido actually does nothing but sit in his pyjamas (with feet!) all day, drinking cocoa, eating Hostess Twinkies and watching Tiny Toons, while his long-suffering co-workers implement and debug the fantastically complex algorithms that go into Python. Here's some rough text: Can someone with a clue about writing a good press release give this a look? --amk Reston, VA, Oct 25 2000: The Python development team today announced the release of version 2.0 of the Python programming language. Version 2.0 adds a number of significant new features: * Unicode support, in the form of a new Unicode data type, library additions for conversion to/from various encodings, and support for displaying Unicode strings in Tk widgets. * New language features: garbage collection of cycles, list comprehensions, augmented assignment, string methods. * Distutils, a new system for making Python modules and extensions easily available to a wider audience with very little overhead for build/release/install mechanics. * Improved XML support, including support for the Simple API for XML (SAX2), a miniature Document Object Model (DOM), and the Expat parser. * Many library improvements, including HTTP/1.1 support, an enhanced curses module, the ability to read and write ZIP-format files, support for the Windows registry, and many more minor improvements. * Ports to new platforms: 64-bit Windows on the Itanium processor, Windows CE, and Darwin/MacOS X. Python is an interpreted, object-oriented, high-level programming language. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for rapid application development, as well as for use as a scripting or glue language to connect existing components together. Python's simple, easy to learn syntax emphasizes readability and therefore reduces the cost of program maintenance, and it supports modules and packages, encouraging program modularity and code reuse. Many extension modules for Python have been written to interface with other libraries and applications. Some of the available modules include: * Support for many relational databases (Oracle, Sybase, MySQL) * GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME) * Internet protocols (LDAP, WebDAV, XML-RPC, SOAP) * Mathematics (Numeric Python) Python is used for many different purposes, particularly cross-platform rapid development, Web development, and scripting of scientific applications. Some of the applications using Python include: * Zope, the leading Open Source web application server * The Mailman mailing list manager * The Reportlab PDF document generation toolset * XXX suggestions? XXX too darn many lists here? The Python interpreter and the extensive standard library are available free of charge and are distributed under an open-source license. Ports have been made to all major platforms, such as Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.) New versions are developed collaboratively by a core group of over 20 developers. About BeOpen: About Python: More information about Python can be obtained from the official Python website, http://www.python.org. (XXX Do you include About sections for the companies that provide quotes?) Press contacts: XXX whose address? From guido at python.org Thu Oct 26 06:02:11 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 25 Oct 2000 23:02:11 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100." References: Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com> > So what _is_ it intended for? Example: IDLE redirects sys.stderr so that it gets displayed in the Python Shell window with a different text color. But occasionally I need to debug IDLE and the bug is in the text drawing. Then it's nice if I can write to __stderr__, which goes to the console. Or suppose I'm in a regular interactive session and I've managed to screw myself by assigning a bogus file object to sys.stdout (it happens :-). If I know that, I can type sys.stdout = sys.__stdout__ at the >>> prompt and save myself -- so I don't have to restart the session and perhaps lose valuable data. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at acm.org Thu Oct 26 05:55:13 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary In-Reply-To: References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Mark Hammond writes: > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. > * Tools/il8n/pygettext.py - ditto I've just fixed these two; too bad checkin messages aren't getting sent. ;( > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > to get around sys.stdout redirection - but this sounds suspect as an idiom > to me too! I've left this one for someone with a good idea about what to do about it. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake at acm.org Thu Oct 26 06:31:33 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <20001025222406.A8389@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> [Moved over from a discussion in the bugs list; this relates to bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470 Please be sure to CC: Jon on all replies.] Jon Ribbens writes: > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without > changes is unexpected enough to warrant mentioning in a paragraph of its > own, completely explicitly. The '.in' suffix is usually used for files which > autoconf is going to use to create a new file from - you cannot usually > simply copy the file yourself. An experienced admin installing Python is > more likely to believe the README is wrong than what it tells them to do > is correct. Why does the Setup.in file exist in the first place? Surely it > should be named 'Setup.dist' (and an identical file 'Setup' exist right from > the start). Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. Since this doesn't help if the source and build directories differ, configure.in can be modified to create Setup if (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. I have the changes to configure.in, configure, Setup*, and Modules/Makefile.pre.in ready, but I still need to update the instructions in the README & possibly elsewhere. Does this sound agreeable? -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From effbot at telia.com Thu Oct 26 09:15:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 09:15:45 +0200 Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary References: Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid> mark wrote: > > If you know of any places that are promoting direct use of __stdout__, > > please let them know this is wrong. If you are contemplating to use > > this in code examples you intend to distribute, please don't! > > I admit that I first became aware of sys.__stdout__ after seeing this exact > same idiom in other peoples code. I always assumed that this is _exactly_ > what sys.__stdout__ was to be used for! > > The following examples exist: and several examples in the eff-bot guide. guess I'll have to fix it in the second edition... From ping at lfw.org Thu Oct 26 10:09:44 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: On Tue, 24 Oct 2000, Barry A. Warsaw wrote: > > Okay, we all know that's a pain, right? Lots of people have proposed > solutions. I've looked briefly at !?ng's Itpl.py, but I think it > probably does too much by adding evaluation. Do you think a variant of Itpl that only looked up variable names would solve your problem? > I can define _() to make the problem somewhat more convenient: > > def _(s): > try: > raise Exception > except Exception: > frame = sys.exc_info()[2].tb_frame.f_back > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d How about this routine to get the current frame: inspect.currentframe(). Could i humbly re-request approval for inspect.py in the standard library? http://lfw.org/python/inspect.py It's been up there for a long time, there's lots of good stuff in it, and previous feedback on this list has all been fairly positive -- there just hasn't been an explicit approval for inclusion. This is probably because we were busy trying to get 2.0 released (even though inspect.py was proposed here before ascii.py, and ascii.py did get accepted). I think the functionality it provides is important to supporting the language definition. It abstracts away the special secret attributes and protects us from future changes in the internals. If there are changes that need to be made before it can be accepted, i'd be happy to make them. -- ?!ng From effbot at telia.com Thu Oct 26 10:36:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 10:36:14 +0200 Subject: [Python-Dev] getting at the current frame References: Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py > > It's been up there for a long time hey, you still haven't fixed the *2 bug... > I think the functionality it provides is important to supporting the > language definition. It abstracts away the special secret attributes > and protects us from future changes in the internals. agreed. > inspect.py was proposed here before ascii.py, and ascii.py did get > accepted as part of the curses package, yes. From ping at lfw.org Thu Oct 26 10:53:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid> Message-ID: On Thu, 26 Oct 2000, Fredrik Lundh wrote: > > It's been up there for a long time > > hey, you still haven't fixed the *2 bug... Sorry -- looks like an older version than the one i have on my local disk, which did get fixed. The one on the website is now up to date. http://lfw.org/python/inspect.py -- ?!ng From jon+sourceforge at unequivocal.co.uk Thu Oct 26 11:39:01 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 10:39:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <20001026103901.A11873@snowy.squish.net> "Fred L. Drake, Jr." wrote: > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > Does this sound agreeable? Sounds cool. I would mention in the first part of the install instructions about the Setup file, that you edit it to change the available modules (this concept is not obvious if you don't know how Python works!), that you can edit it now but if you have not installed Python before it is best to try building without editing it first and that there are more instructions further down the README. You might like to mention 'readline' here too to head-off newsgroup questions about why up-arrow doesn't work ;-). Cheers Jon From guido at python.org Thu Oct 26 13:38:34 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:38:34 -0500 Subject: [Python-Dev] sys.__stdout__ In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400." <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> > > * Tools/idle/PyParse.py - disabled, debugging output function - presumably > > to get around sys.stdout redirection - but this sounds suspect as an idiom > > to me too! > > I've left this one for someone with a good idea about what to do > about it. Don't touch it! This one is needed because at this point sys.stdout and sys.stderr are redirected to a window where you don't want the parser debug output to show up. (I mentioned this example in my previous post.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 26 13:45:49 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:45:49 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400." <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com> [Fred] > Ok, here's the plan: Change Setup.in to Setup.dist, and provide a > copy as Setup. Since this doesn't help if the source and build > directories differ, configure.in can be modified to create Setup if > (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. > I have the changes to configure.in, configure, Setup*, and > Modules/Makefile.pre.in ready, but I still need to update the > instructions in the README & possibly elsewhere. > Does this sound agreeable? Sure, except I'm not comfortable with having two files with identical contents under CVS control. How about not checking in Setup, but creating it in configure if it doesn't exist? This is necessary also for the following reason: when you build in a different tree than the source tree, you should get a fresh copy of Setup in the build tree -- another copy of Setup in the source tree is useless. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Oct 26 13:48:20 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 06:48:20 -0500 Subject: [Python-Dev] getting at the current frame In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST." References: Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com> > Could i humbly re-request approval for inspect.py in the standard library? > > http://lfw.org/python/inspect.py To avoid that we forget about this again, and to make sure it gets proper treatment, could you submit it through the patch manager? No need to turn it into a context diff, just upload the entire file. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Thu Oct 26 12:21:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:21:05 +0200 Subject: [Python-Dev] A small step to removing the type/class split In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300 References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz> Message-ID: <20001026122105.N12812@xs4all.nl> On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote: > Neil Schemenauer : > > Those PyInstance_Check() calls should really go away. Instead, the > > type should be responsible for providing different behavior. > Yes, that's the crux of the problem, I think. > Another place where this is a nuisance is where it > assumes that if x has any tp_as_sequence slots and y > has any tp_as_number slots, then x*y is a sequence > replication operation. This is screwed in more than one way. The logic of which 'type' operation has precedence isn't even internally consistent. The case of 'x*y' and 'x+y' check the tp_as_number and tp_as_sequence slots in a *different order*, so 'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way 'round, I forget. I'm also struggling to catch up on my mail since Apachecon had little to no connectivity, so I don't feel like checking :) Brainwashed-into-Apache-2.0-forever-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Oct 26 12:51:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 26 Oct 2000 12:51:30 +0200 Subject: [Python-Dev] ViewCVS on Sourceforge Message-ID: <20001026125130.O12812@xs4all.nl> I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon Travis and Gregory Trubetskoy where there as well, but my memory is a bit hazy) and since he's probably in some airplane over the atlantic right now, I'll run away and steal his idea ;) We were kind of reflecting how nice it would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and it doesn't need write access to the repository itself. So how about we run ViewCVS on python.sourceforge.net ourselves ? We could do it now, in fact, with the complete CVS snapshot that gets made every once in a while (that *does* still get made & backupped, right ?) though it would obviously be a lot more useful if ViewCVS just had direct access to the repository. I'm not sure how accessible that repository is, however. Cursory searches on shell.sourceforge.net doesn't show anything, except that the python-cvs.tgz that's in /home/projects/python is apparently the one used for the move to sourceforge :-) Can we get access to the repository directly, even if it's only semi-realtime ? (I wouldn't mind doing a couple of rsync's in cron to keep it up to date) If anything, running ViewCVS will show SourceForge how much nicer it is... ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jon+sourceforge at unequivocal.co.uk Thu Oct 26 13:01:27 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 12:01:27 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> Message-ID: <20001026120127.B11873@snowy.squish.net> Guido van Rossum wrote: > Sure, except I'm not comfortable with having two files with identical > contents under CVS control. How about not checking in Setup, but > creating it in configure if it doesn't exist? I think that would be fine so long as the README file makes it clear that you edit the Setup file after './configure' but before 'make'. Cheers Jon From mal at lemburg.com Thu Oct 26 13:23:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 13:23:19 +0200 Subject: [Python-Dev] 2.0 articles References: Message-ID: <39F81427.FF4223C2@lemburg.com> Andrew Kuchling wrote: > > I'd like to begin writing an article about 2.0's Unicode support. > Before beginning, has anyone else already begun this task? If yes, > please let me know... I've already started something in that direction. The plan is to write down the story of adding Unicode support to Python, the pifalls, solutions, hacks, etc. I'll probably submit it to DDJ. A article about *using* Unicode support would of course be a nice complement to get a feeling of how it's like working with the implementation :-) > (Incidentally, did a 2.0 press release ever go out? Is someone going > to write one?) > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at acm.org Thu Oct 26 14:21:08 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT) Subject: [Python-Dev] sys.__stdout__ In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com> References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> <200010261138.GAA04678@cj20424-a.reston1.va.home.com> Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com> I wrote: > I've left this one for someone with a good idea about what to do > about it. Guido van Rossum replied: > Don't touch it! This one is needed because at this point sys.stdout > and sys.stderr are redirected to a window where you don't want the > parser debug output to show up. See, I knew someone would come up with a better idea! ;) -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From skip at mojam.com Thu Oct 26 14:31:36 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT) Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> Message-ID: <14840.9256.408848.728486@beluga.mojam.com> Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. I don't like the idea that a file I am supposed to edit (Setup) would be in the CVS repository where it could conceivably get messed with by a "cvs up" command. The current makefile target that emits a warning if Setup.in (.dist) is newer than Setup should be sufficient to alert users when Setup needs to be looked at. -- Skip Montanaro (skip at mojam.com) http://www.mojam.com/ http://www.musi-cal.com/ From skip at mojam.com Thu Oct 26 14:34:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT) Subject: [Python-Dev] getting at the current frame In-Reply-To: References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.9409.491061.671168@beluga.mojam.com> Ping> Could i humbly re-request approval for inspect.py in the standard Ping> library? Ping> http://lfw.org/python/inspect.py +1. I've written functions over the years to do some small bits of what inspect.py does. I'd much rather have those things in a standard place with more eyeballs checking them for correctness. Skip From akuchlin at mems-exchange.org Thu Oct 26 14:56:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 26 Oct 2000 08:56:26 -0400 Subject: [Python-Dev] 2.0 articles In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200 References: <39F81427.FF4223C2@lemburg.com> Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us> On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote: >A article about *using* Unicode support would of course >be a nice complement to get a feeling of how it's like working And that's what I want to write, so it works out nicely; great! Finn, your comment has been noted; I'll take note of any differences with Jython's Unicode support. A draft will be announced on python-dev, whenever it actually gets done. --amk From mal at lemburg.com Thu Oct 26 15:07:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 26 Oct 2000 15:07:35 +0200 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> Message-ID: <39F82C97.12D04C85@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > > * implementation language and Python inheritance semantics are almost > > > completely distinct. After all, we have Python implementations in a > > > variety of languages with minor incompatibilities. Python could have a > > > proper type/class merging even if it were written in assembly language. > > > So let's leave implementation language aside. > > > > Hey, think of it as opportunity: we can reuse much of C++'s > > optimizations and the integration of Python and C++ applications > > will get *much* easier. > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > C++ and Python is not really so hard, in my experience. Ok, you can use SWIG to get most of the work done, but the interface between the C++ object world and the Python object world is one big mess -- all implementations I've seen use shadow objects or proxies to interface from one to the other... with lots of temporary objects used for the linkup. Having Python itself written in C++ we could do *much* better. But that's only a nice side-effect. The real argument here is that we can push the type logic one layer further down. Ideal would be a level of integration such as the one implemented in JPython or Jython. > > A rewrite shouldn't scare anyone away -- much of the existing > > code can be reused since only the Python C APIs of the various > > types will have to be rewritten, not the logic behind the types. > > I wasn't really addressing the issue of backwards compatibility of > extensions -- I was talking about Python programs. Nevertheless, I can't > resist: > > Porting your app to the Python APIs is often the majority of the work in > a particular extension. A lot of Python extensions consist only of API > glue! True, but we're lucky, since we could provide a compatibility layer on top of the new API. BTW, I think I now know what your main concern is: the Python level compatibility. I was talking of what goes on under the hood and still think that Py3K should be used as a chance to simplify the Python backend. As simplification often means generalization, we'll open up new doors for future developments along the way. > > > I don't know what you mean by a "low-level strategy" for classes. It's > > > not like we can somehow use C++ vtables without giving up Python's > > > dynamicity. Python's class handling is about as low-level as it can get > > > in my humble opinion. > > > > With "low-level" I meant trying to build Python classes and > > instances on top of a very thin layer on top of C++ classes, > > e.g. all slots could be implemented using true C++ methods with > > additional logic to override them using dynamically bound > > Python method objects. > > I don't think that there is really interesting magic in a C++ compiler. > A vtable is an array of pointers to functions. We've already implemented > the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and > smart pointers are a little more interesting from a code maintenance and > simplicity point of view. But even then I think that we could get to a > C++ implementation through incremental rewrites. Naa, the whole type slot interface is one big mess (sorry, Guido :-). some slots are packaged, some are not, some are NULL, some are not, there are oodles of sometimes weird dependencies between the slots which are not really documented, etc. etc. The slot design has serious drawbacks and should be replaced by something more reliable, preferably C++ methods. That way, we'll get some more "type" safety into Python and its extensions. Note that porting old extensions won't be all that hard: a class reusing the existing slot functions as methods should suffice in many cases. > > Why spoil all the fun when we haven't even started thinking > > about all the possibilities we could use to make Py3k a > > success ? > > Asking for a map of where we are going and how we will get here is > "spoiling all of the fun?" I'm not sure what you are reacting to -- I > didn't advise one implementation strategy or another -- I just said that > we should employ a strategy that minimizes sudden and surprising code > breakage. Ok, we've been talking about different things here: with "spoiling the fun" I meant putting ropes on possible changes to the C backend. You are talking about the frontend and I agree with you that there should be a clear upgrade path from the 2.x series to Py3K w/r to the Python side of things. So I guess it's time for some PEPs now... the upgrade path PEP and the fluffy clouds PEP. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Thu Oct 26 16:42:40 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 09:42:40 -0500 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100." <20001026120127.B11873@snowy.squish.net> References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com> > I think that would be fine so long as the README file makes it clear that > you edit the Setup file after './configure' but before 'make'. One thing -- it's perfectly fine to edit Setup after running Make for the first time. You just have to run Make again. The Makefiles are designed for this. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Thu Oct 26 15:56:40 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 06:56:40 -0700 Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> Message-ID: <39F83818.38EA64AE@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Having Python itself written in C++ we could do *much* better. Agree. > ... > > The slot design has serious drawbacks and should be replaced by > something more reliable, preferably C++ methods. That way, we'll > get some more "type" safety into Python and its extensions. I agree that the slot stuff is broken but my solution would be to junk it and use the same mechanism for looking up "type methods" and "instance methods". I can think of two ways to make that perform reasonably: one is method caching and the other is by building interface objects where methods are invoked by index -- basically vtables. But if the same mechanism is going to accelerate Python and C types alike then it can't really use C++ vtables because how do you generate a vtable at runtime for a new Python class? (you could also think of it as a COM interface object) > So I guess it's time for some PEPs now... the upgrade path > PEP and the fluffy clouds PEP. Good timing. I just finished the first draft of the upgrade path PEP. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From barry at wooz.org Thu Oct 26 15:24:49 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> <14840.9409.491061.671168@beluga.mojam.com> Message-ID: <14840.12449.241947.715016@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> Could i humbly re-request approval for inspect.py in the Ping> standard library? Ping> http://lfw.org/python/inspect.py SM> +1. I've written functions over the years to do some small SM> bits of what inspect.py does. I'd much rather have those SM> things in a standard place with more eyeballs checking them SM> for correctness. I've downloaded it, and will take a look. From jim at interet.com Thu Oct 26 16:03:43 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:03:43 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> Message-ID: <39F839BF.DD1B86BF@interet.com> Guido van Rossum wrote: > To me this all sounds like FUD. True, but FUD is real and I have no apologies. > Since Python 1.6 and 2.0, you don't > have to install Tcl/Tk or its libraries -- it is installed > *transparently* by the Python Windows installer. We don't use the Python Windows installer. Our app has to use its own installer, and I would then have to run two installers, one of which I don't understand. Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors. JimA From jim at interet.com Thu Oct 26 16:06:02 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 10:06:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> Message-ID: <39F83A4A.26E543A3@interet.com> Guido van Rossum wrote: > Even Microsoft is violating its own (boring) style guide, when they > think it appeals to a specific audience. Have you seen their Media > Player? Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design. JimA From gward at mems-exchange.org Thu Oct 26 16:18:50 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 10:18:50 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us> On 26 October 2000, James C. Ahlstrom said: > Guido van Rossum wrote: > > > Even Microsoft is violating its own (boring) style guide, when they > > think it appeals to a specific audience. Have you seen their Media > > Player? > > Yes, very slick. My daughter has an app where you click on > doors to access parts of the program. Nice design. This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end. Go look for "User Interface Hall of Shame" at your friendly neighbourhood search engine for many enjoyable rants against bad GUI design, including the "emulate the real world" school of thought. Anyways, this is not a usability mailing list... back to our regularly scheduled python-dev... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From paul at prescod.net Thu Oct 26 16:28:12 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:28:12 -0700 Subject: [Python-Dev] Gradual migration PEP Message-ID: <39F83F7C.2241158F@prescod.net> PEP: XXX Title: Guidelines for introducing backwards incompatibilities Version: $Revision: 1.0 $ Author: Paul Prescod Status: Draft Type: Standards Track Python-Version: All Created: 25-Oct-2000 Abstract In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behaviour of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. Implementation Details Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. Scope These guidelines apply to future versions of Python that introduce backward-incompatible behaviour. Backward incompatible behaviour is a major deviation in Python interpretation from an earlier behaviour described in the standard Python documentation. Removal of a feature also constitutes a change of behaviour. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! Steps For Introducting Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. Local Variables: mode: indented-text indent-tabs-mode: nil End: From paul at prescod.net Thu Oct 26 16:35:48 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 26 Oct 2000 07:35:48 -0700 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F84144.105D1754@prescod.net> Mark Hammond wrote: > >... > > I don't think it will be "fixed", as it is not considered "broken". It was > an explicit choice to leave out Tcl/Tk. And my recollection is that the > "feedback" address sees more requests for wxPython than Tcl/Tk. That's all true. We also make it very easy to find the right version of Tcl/Tk and will probably go even farther in this direction in the future. Built-in Tcl/Tk support is not out of the question but there are various user confusion issues: "Why are there two GUI frameworks in this development environment? Why are there two development environments in this development environment? Doesn't ActiveState have yet another GUI framework and development environment under development?" "Why do I need Tcl at all? What is its relationship with Python? There are clear benefits to including Tcl/Tk but there are also costs and its possible we'll weigh them differently in the future. BTW: ActivePython does include Tkinter. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html From gmcm at hypernet.com Thu Oct 26 16:49:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 10:49:20 -0400 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <39F80C30.5448.52D32F94@localhost> [Paul] > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. ... or a number of others (but SWIG falls very short when it comes to things like C++ references)... [Marc-Andre] > Ok, you can use SWIG to get most of the work done, but the interface > between the C++ object world and the Python object world is one > big mess -- all implementations I've seen use shadow objects > or proxies to interface from one to the other... with lots of > temporary objects used for the linkup. While I agree it's messy, those are not the objectionable qualities. Any refcounted C++ system is going to have proxies (smart pointers / refcounting stack-safe "reference" objects to the real heap-based objects). And while I think we'd be better off with a C++ implementation, I would warn that C++'s notion of inheritence is in conflict with Python's. It won't be "as above, so below" (unless we screw interpreting and go straight to native code). Assuming that the class / type dichotomy actually gets healed, that is. > ... The real argument here is > that we can push the type logic one layer further down. Ideal would > be a level of integration such as the one implemented in JPython > or Jython. Nope. If you heal the class / type split, there's really only one underlying type object. Unless you go the other way, and write "native" code (as JPython does). All of the existing C++ interfaces / helpers deal only with type objects (at least, those that I've examined, which is most of them). In fact, only ExtensionClass attempts to deal with the class / type split, and while it's a masterpiece, I think it's a great example of everything to avoid in Py3K. - Gordon From barry at wooz.org Thu Oct 26 16:58:23 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT) Subject: [Python-Dev] Gradual migration References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com> <39F83818.38EA64AE@prescod.net> Message-ID: <14840.18063.152674.534458@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I agree that the slot stuff is broken but my solution would be PP> to junk it and use the same mechanism for looking up "type PP> methods" and "instance methods". I can think of two ways to PP> make that perform reasonably: one is method caching and the PP> other is by building interface objects where methods are PP> invoked by index -- basically vtables. But if the same PP> mechanism is going to accelerate Python and C types alike then PP> it can't really use C++ vtables because how do you generate a PP> vtable at runtime for a new Python class? (you could also PP> think of it as a COM interface object) Objective-C! :) From effbot at telia.com Thu Oct 26 17:14:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 17:14:28 +0200 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid> jim wrote: > Sorry to be such an old fuddy-duddy, but you will > get the same reaction from most commercial software > vendors. Make that nearly ALL vendors. what reaction? are you saying that your own installer can install the Python DLL but not the Tk DLL? From gmcm at hypernet.com Thu Oct 26 17:05:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 26 Oct 2000 11:05:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us> References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400 Message-ID: <39F80FDE.6102.52E19102@localhost> James C. Ahlstrom said: > > Yes, very slick. My daughter has an app where you click on > > doors to access parts of the program. Nice design. [Greg Ward] > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I once interviewed with a game designer (sports games - popular ones, too). He spent half an hour slamming MS's UI (his games run on Windows). Then he pulled up his latest (opening to a sports stadium) and said "Now here's a real UI". So I said "Show me how it works". The bozo ended up clicking on random things on the screen until something finally happened. no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs - Gordon From barry at wooz.org Thu Oct 26 17:36:37 2000 From: barry at wooz.org (barry at wooz.org) Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT) Subject: [Python-Dev] getting at the current frame References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <14840.20357.734136.911927@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: >> Okay, we all know that's a pain, right? Lots of people have >> proposed solutions. I've looked briefly at !?ng's Itpl.py, but >> I think it probably does too much by adding evaluation. KY> Do you think a variant of Itpl that only looked up variable KY> names would solve your problem? I think it would calm my objections, yes. I'll observe that I think there may be a middle ground between my approach and Itpl. I've found a couple of situations where I want a minimal form of evaluation, e.g. I want attributes to be expanded (and methods called), but not a general evaluation facility. So for example, I'd like to be able to say: print _("The name of the mailing list is %(mlist.listname())s") What worries me about a general evaluation framework is that we then have to be really really careful about security and origin of the strings we're using here. Maybe we'd need to adopt something like Perl's taint strings. KY> How about this routine to get the current frame: KY> inspect.currentframe(). It uses the same intentional-exception trick to get at the current frame. It's about 8x faster to do it in C. I'll note that your version raises and catches a string exception, while mine uses an exception instance. I don't see much difference in speed between the two. KY> If there are changes that need to be made before it can be KY> accepted, i'd be happy to make them. Sent under a separate private response... -Barry From gward at mems-exchange.org Thu Oct 26 18:03:09 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 26 Oct 2000 12:03:09 -0400 Subject: [Python-Dev] getting at the current frame In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400 References: <14837.60682.437334.797392@anthem.concentric.net> Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us> On 24 October 2000, Barry A. Warsaw said: > All well and good and doable in Python today, except getting the > current frame with the exception raising trick is slooow. A simple > proposed addition to the sys module can improve the performance by > about 8x: > > def _(s): > frame = sys.getcaller(1) > d = frame.f_globals.copy() > d.update(frame.f_locals()) > return the_translation_of(s) % d > > The implementation of sys.getcaller() is given in the below patch. > Comments? I think this particular addition is too small for a PEP, > although ?!ng still owns PEP 215 (which needs filling in). +1. Not sure if I would call that function 'getcaller()' or 'getframe()'; could go either way. In my implementation of this (I guess everyone has one!), I also have a couple of convenience functions: def get_caller_env (level=1): """get_caller_env(level : int = 1) -> (globals : dict, locals : dict) Return the environment of a caller: its dictionaries of global and local variables. 'level' has same meaning as for 'caller()'. """ def get_frame_info (frame): """get_frame_info(frame) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from an execution frame. """ def get_caller_info (level=1): """get_caller_info(level : int = 1) -> (filename : string, lineno : int, function_name : string, code_line : string) Extracts and returns a tuple of handy information from some caller's execution frame. 'level' is the same as for 'caller()', i.e. if level is 1 (the default), gets this information about the caller of the function that is calling 'get_caller_info()'. """ These are mainly used by my unit-testing framework (which you'll no doubt remember, Barry) to report where test failures originate. Very handy! Looks like Ping's inspect.py has something like my 'get_frame_info()', only it's called 'getframe()'. Obviously this is the wrong name if Barry's new function gets added as 'sys.getframe()'. How 'bout this: sys.getframe(n) - return stack frame for depth 'n' inspect.getframeinfo(frame) - return (filename, line number, function name, lines-of-code) Although I haven't grokked Ping's module enough to know if that rename really fits his scheme. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From jon+sourceforge at unequivocal.co.uk Thu Oct 26 18:57:01 2000 From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens) Date: Thu, 26 Oct 2000 17:57:01 +0100 Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500 References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com> Message-ID: <20001026175701.A4983@snowy.squish.net> Guido van Rossum wrote: > One thing -- it's perfectly fine to edit Setup after running Make for > the first time. You just have to run Make again. The Makefiles are > designed for this. Mention this too ;-) From fdrake at acm.org Thu Oct 26 19:24:54 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT) Subject: [Python-Dev] Setup changes are checked in Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com> I've checked in the changes to the handling of the Modules/Setup file as we've discussed here. - Setup.in is now Setup.dist - Setup is created by configure - README and other instructions, comments, and documentation has been updated to reflect these changes -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From fdrake at acm.org Thu Oct 26 19:30:22 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT) Subject: [Python-Dev] development version of docs online Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Do people want to be notified when the development copy of the documentation is update? There was a comment from someone that they didn't know where the online copy was. I can send the update notice to python-dev instead of just to myself if everyone wants it, or I can send it to some other (appropriate) list. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From trentm at ActiveState.com Thu Oct 26 19:42:30 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 26 Oct 2000 10:42:30 -0700 Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400 References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: <20001026104230.B23283@ActiveState.com> On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote: > > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they Yes, please. Trent -- Trent Mick TrentM at ActiveState.com From jim at interet.com Thu Oct 26 21:34:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:34:03 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <14837.14407.954185.466011@buffalo.fnal.gov> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid> Message-ID: <39F8872B.92D69403@interet.com> Fredrik Lundh wrote: > > jim wrote: > > Sorry to be such an old fuddy-duddy, but you will > > get the same reaction from most commercial software > > vendors. Make that nearly ALL vendors. > > what reaction? > > are you saying that your own installer can install the > Python DLL but not the Tk DLL? Not exactly. I am saying I don't want to use the standard Python Windows installer. And I am saying I don't want to install Tk because it is big, complicated, and requires Tcl and its libraries. My installer does install the Python DLL python15.dll, so I guess I could study how to install Tk and duplicate the functionality of the Windows installer, and install Tk too. But why would I want to? JimA From jim at interet.com Thu Oct 26 21:38:40 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 26 Oct 2000 15:38:40 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us> Message-ID: <39F88840.3F619707@interet.com> Greg Ward wrote: > This is generally considered Bad Form by usability types. I think it > boils down to this: the computer is not the real world, and trying to > emulate the real world on the computer is cutesy but a dead end. I agree up to a point, and my own app doesn't use doors. But kids like this kind of design, have no trouble understanding it, and people wouldn't write this if they didn't think it would sell. I just meant that people have a larger tolerance for non-Microsoft GUI design ideas than I thought up to now. JimA From skip at mojam.com Thu Oct 26 22:10:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? Message-ID: <14840.36793.19348.903534@beluga.mojam.com> Just came across this error while running configure: checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The problem was that /tmp was full - sort of. The system says there's no space: % cat /etc/termcap > /tmp/termcap bash: /tmp/termcap: No space left on device but df disagrees: % df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 153667 88796 56935 61% / Short term workaround is to run configure with TMPDIR set somewhere else. Perhaps this is something to put in a gcc-specific or Unix-specific section of the README file. I didn't see anything, and the message emitted by configure gave no hint at the cause of the problem. I realized what it was because I've been scratching my head about this problem for a couple weeks. If this is deemed useful I'll modify README and check it in. If not, no big deal. (I have no idea why the system thinks /tmp is full... sigh ...) Skip From cgw at fnal.gov Thu Oct 26 22:14:53 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com> References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov> Skip Montanaro writes: > > Just came across this error while running configure: > > checking for gcc... gcc > checking whether the C compiler (gcc ) works... no > configure: error: installation or configuration problem: C compiler cannot create executables. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. Personally, I don't think this is useful. I don't think the Python README is the place to list everything that can go wrong during ./configure. The generic advice is "If something goes wrong during ./configure, read through config.log to see what went wrong" I'm curious what is in your config.log when this error occurs! From nas at arctrix.com Thu Oct 26 15:29:49 2000 From: nas at arctrix.com (Neil Schemenauer) Date: Thu, 26 Oct 2000 06:29:49 -0700 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001026062949.A14618@glacier.fnational.com> > The problem was that /tmp was full - sort of. You might try "df -i". You could be out inodes but still have blocks. Neil From guido at python.org Thu Oct 26 23:29:33 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 26 Oct 2000 16:29:33 -0500 Subject: [Python-Dev] Gradual migration PEP In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST." <39F83F7C.2241158F@prescod.net> References: <39F83F7C.2241158F@prescod.net> Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com> Paul, Your deprecation PEP looks good. A few comments: - I think that the one-year period may depend on the feature. Some may require an even longer time. Others less. - I think there will be cases where run-time checks are the only way to detect use of the old feature (e.g. I'm still struggling with how to change the division semantics). But this shouldn't stop it from becoming a PEP. Please arrange for a PEP number with Barry, the PEPmaster. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas at xs4all.net Fri Oct 27 00:58:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 00:58:41 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700 References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <20001027005841.R12812@xs4all.nl> On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote: > > The problem was that /tmp was full - sort of. > You might try "df -i". You could be out inodes but still have > blocks. Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks, or some other filesystem resource. Not often the case for something like /tmp, but definately possible on some filesystems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Oct 27 01:02:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 27 Oct 2000 01:02:24 +0200 Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500 References: <14840.36793.19348.903534@beluga.mojam.com> Message-ID: <20001027010224.S12812@xs4all.nl> On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote: > Short term workaround is to run configure with TMPDIR set somewhere else. > Perhaps this is something to put in a gcc-specific or Unix-specific section > of the README file. I didn't see anything, and the message emitted by > configure gave no hint at the cause of the problem. I realized what it was > because I've been scratching my head about this problem for a couple weeks. > If this is deemed useful I'll modify README and check it in. If not, no big > deal. If you start adding things like that, also consider all the other possibilities of configure being wrong. I hinted at one of them a couple of weeks back, I think. (Somehow, 'last saturday', when I headed for London for the Apachecon, feels like about two months ago :P) It's perfectly possible for configure to be able to run gcc, gcc to be able to create working binaries, but every check for a function or datatype failing because the more 'involved' include files are missing. This is easy to do on Linux, (removing /usr/src/linux, for instance) but not impossible on other systems either. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From greg at cosc.canterbury.ac.nz Fri Oct 27 02:21:26 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001027005841.R12812@xs4all.nl> Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz> Thomas Wouters : > Or failing that, it could be out of 'indirect' or 'doubly-indirect' > blocks, I think they're allocated from the same pool as data blocks. What *can* happen is that you can run out of "large" blocks. The BSD-style filesystem stores files bigger than 8k in blocks made up of 8 contiguous 1k blocks. If the filesystem is nearly full, or contains a large number of small files, you can find that it's impossible to create any more files > 8k, even though there appears to be plenty of free space, because the space is too fragmented. I don't think that's what's happening here, though, since I've only ever seen it happen when the filesystem was about 99% full. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From tim_one at email.msn.com Fri Oct 27 03:13:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 26 Oct 2000 21:13:02 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? In-Reply-To: <39F8872B.92D69403@interet.com> Message-ID: [Guido] > are you saying that your own installer can install the > Python DLL but not the Tk DLL? [James Ahlstrom] > Not exactly. I am saying I don't want to use the standard > Python Windows installer. And I am saying I don't want to install > Tk because it is big, complicated, and requires Tcl and its libraries. > > My installer does install the Python DLL python15.dll, so > I guess I could study how to install Tk and duplicate the > functionality of the Windows installer, and install Tk too. > But why would I want to? That's up to you and your customers. What Guido has been telling you is that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is trivial: it merely copies some Tcl/Tk files into the Python installation tree. It no longer runs the Scriptics installer, mucks with the path, changes any envars, copies any files to outside of the Python tree, or even sets anything up in the registry for Tcl/Tk. You may not *want* to install Tcl/Tk, but, if you would like to, there's no longer any basis for fearing it's difficult, obscure, delicate or error-prone. don't-know-about-those-wrt-other-gui-pkgs-ly y'rs - tim From skip at mojam.com Fri Oct 27 05:54:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov> References: <14840.36793.19348.903534@beluga.mojam.com> <14840.37053.829696.379140@buffalo.fnal.gov> Message-ID: <14840.64651.444849.757658@beluga.mojam.com> Charles> The generic advice is "If something goes wrong during Charles> ./configure, read through config.log to see what went wrong" Agreed. Charles> I'm curious what is in your config.log when this error occurs! That's why I was thinking ("hmmm... perhaps a README bit"). It wasn't giving me obvious "no space" messages. I've concluded that it's probably best to forget it anyway. If it's a problem with configure or gcc messages, it's best addressed there. Skip From skip at mojam.com Fri Oct 27 05:57:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT) Subject: [Python-Dev] A possible bit for a README or FAQ? In-Reply-To: <20001026062949.A14618@glacier.fnational.com> References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com> Message-ID: <14840.64780.673428.672300@beluga.mojam.com> Neil> You might try "df -i". You could be out inodes but still have Neil> blocks. Thanks, that indeed seems to be the problem: % df -i /tmp Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda5 39k 39k 7 100% / I don't believe in all my years of fiddling with Unix systems I've ever run out of inodes with a third of the disk space left. Now to identify the culprit. Skip From mal at lemburg.com Fri Oct 27 12:15:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 27 Oct 2000 12:15:53 +0200 Subject: [Python-Dev] Starship is still down... Message-ID: <39F955D9.279864FD@lemburg.com> It's been over a week since I posted my last gripe about our community server starship being unreachable. Nothing has happened so far... is there any chance on getting the server up and running again ? I am a bit concerned about the lack of support here: starship should be considered a very important part in the Python universe (after all, many Python extension packages and goodies are available from that site). With the frequent downtimes we recently had, I think people will get a wrong picture about the Python community support. Here's a traceroute from Germany to starship: traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets 1 193.158.137.129 (193.158.137.129) 24 ms 23 ms 23 ms 2 193.158.137.130 (193.158.137.130) 24 ms 35 ms 25 ms 3 D-gw13.D.net.DTAG.DE (212.185.10.22) 67 ms 24 ms 35 ms 4 K-gw13.K.net.DTAG.DE (194.25.124.137) 26 ms 25 ms 25 ms 5 F-gw13.F.net.DTAG.DE (194.25.121.101) 32 ms 33 ms 33 ms 6 TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98) 113 ms 127 ms 131 ms 7 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113) 115 ms 117 ms 134 ms 8 mae-east-switch0.maee.above.net (208.184.210.9) 134 ms 114 ms 123 ms 9 core1-mae-east-oc3-1.iad.above.net (209.133.31.225) 122 ms 116 ms 115 ms 10 sjc2-iad-oc48.sjc2.above.net (216.200.127.26) 184 ms 186 ms 185 ms 11 core5-core3-oc48.sjc2.above.net (208.185.156.66) 183 ms 184 ms 186 ms 12 sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37) 299 ms 183 ms !H 188 ms !H 13 * * * 14 * * * ... It looks as if ABOVE.NET is having some serious routing problems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Fri Oct 27 12:43:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 27 Oct 2000 06:43:22 -0400 Subject: [Python-Dev] Starship is still down... In-Reply-To: <39F955D9.279864FD@lemburg.com> Message-ID: [MAL] > It's been over a week since I posted my last gripe about > our community server starship being unreachable. Afraid Manus Head still gets the Most Outraged award for this one. > Nothing has happened so far... is there any chance on getting the server > up and running again ? Works for me, but only very recently. OTOH, my posts to python.org mailing lists started black-holing, so it's not like Python-Dev will actually see this post . Here's a trace from my box (in Virginia); it may take a while for recent routing changes to propagate: 1 tnt32.tco2.da.uu.net [206.115.222.61] 2 GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2] 3 156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50] 4 517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198] 5 294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26] 6 POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25] 7 137.39.52.102 8 beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139] 9 sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42] 10 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139] 11 pacbellpsfoc3.ca.us.prserv.net [165.87.161.5] 12 core3-g2-0.snfc21.pbi.net [209.232.130.78] 13 rback26-fe2-0.snfc21.pbi.net [216.102.187.153] 14 adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65] 15 starship.python.net [63.202.160.91] > I am a bit concerned about the lack of support here: starship > should be considered a very important part in the Python > universe (after all, many Python extension packages and goodies > are available from that site). With the frequent downtimes > we recently had, I think people will get a wrong picture about > the Python community support. They're getting an accurate view of current Starship support. So it goes. Plans for better support *are* in progress, but for reasons that won't become clear until later, you haven't heard anything about them yet. for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs - tim From jim at interet.com Fri Oct 27 14:23:11 2000 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 27 Oct 2000 08:23:11 -0400 Subject: [Python-Dev] What to choose to replace Tkinter? References: Message-ID: <39F973AF.80D3BDBE@interet.com> Tim Peters wrote: > That's up to you and your customers. What Guido has been telling you is > that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is > trivial: it merely copies some Tcl/Tk files into the Python installation > tree. It no longer runs the Scriptics installer, mucks with the path, Oh, OK. That is much better. JimA From skip at mojam.com Fri Oct 27 18:15:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT) Subject: [Python-Dev] Starship is still down... In-Reply-To: References: <39F955D9.279864FD@lemburg.com> Message-ID: <14841.43579.261191.986406@beluga.mojam.com> Tim> Here's a trace from my box (in Virginia); ... Tim's trace doesn't show times. Looks to me like Pacbell is having trouble (note the huge leap in response time): ... 13 beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50) 30.387 ms 27.426 ms 28.392 ms 14 beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139) 27.614 ms 27.349 ms 27.250 ms 15 sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42) 71.581 ms 72.535 ms 72.429 ms 16 sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139) 71.635 ms 71.420 ms 71.483 ms 17 pacbellpsfoc3.ca.us.prserv.net (165.87.161.5) 71.070 ms 71.606 ms 71.301 ms 18 core4-g2-0.snfc21.pbi.net (209.232.130.77) 70.986 ms 71.129 ms 73.628 ms 19 rback26-fe2-0.snfc21.pbi.net (216.102.187.153) 72.696 ms 77.658 ms 83.046 ms 20 adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65) 3841.343 ms 3705.648 ms 3911.584 ms 21 adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91) 3683.340 ms 3867.550 ms 3653.732 ms Skip From petrilli at amber.org Fri Oct 27 22:15:18 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Fri, 27 Oct 2000 16:15:18 -0400 Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...) In-Reply-To: ; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200 References: <14838.64730.225260.148853@buffalo.fnal.gov> Message-ID: <20001027161518.B3942@trump.amber.org> Peter Funk [pf at artcom-gmbh.de] wrote: > > It will take years, before MacOS X will find its way onto the desk > of the average Apple Mac user. The Mac s mostly used in the graphics > and printing industry (our cutsomers) where people normally don't > even think about a OS upgrade, if they don't have to. They usually > run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other > so called creative software on the version of the OS they had on > the machine when they bought it. THese machines are usually used > through a period of at least four years. I think this is a bit incorrect. Almost every Mac user that I interact with (including all the users hre at Digital Creations) have OS X running and using it at various levels. Mostly it's waiting for people like Adobe to release Carbon applications. Graphics designers will be the first to move to OS X, not thel ast, as they will ge the most fromt he increased stability and performance. It all depends on your market. The best goal for Mac OS would be to aim at full Carbon compliance, and not write to Cocoa, or to the original MacOS toolkit. This would let you run on all releases after 8.0 I believe (maybe even 7.6). Chris -- | Christopher Petrilli | petrilli at amber.org From guido at python.org Sat Oct 28 03:42:42 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 27 Oct 2000 20:42:42 -0500 Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com> To all Python users and developers: Less than half a year ago, I moved with my team to BeOpen.com, in the hope of finding a new permanent home for Python development. At BeOpen, we've done several good things for Python, such as moving the Python and Jython development process to SourceForge, and the successful release of Python 2.0. Unfortunately, BeOpen.com's original plans for PythonLabs didn't work out as hoped, and we weren't able to reach mutual agreement on workable alternative plans -- despite trying for months. I am proud to have found a new home for my entire team: starting today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself are working for Digital Creations. We will be spending part of our time on core Python development (including Jython and Mailman) and part of our time on Python infrastructure improvements that also benefit Zope. Python will remain Open Source; Digital Creations has no desire to monetize or brand the Python language or specific Python distributions. All future work we do on Python as Digital Creations employees will be owned by a non-profit organization yet to be created. We think of this new organization as the Python Software Foundation. In the meantime (while the PSF is under construction) I will own such copyrights personally. We're excited to be working for Digital Creations: they are one of the oldest companies active in the Python community, one of the companies most committed to Python, and they have a great product! Plus, we know they have deep financial backing. We trust that Digital Creations will provide a stable home for Python for many years. Digital Creations has also offered to take over hosting of the python.org and starship sites. On behalf of the Python community, we're grateful for this support of the two prime community sites for Python, and we expect to be implementing the transitions shortly. These are exciting times for the PythonLabs team -- and also for Python and its community. Mainstream successes for Python are showing up everywhere, and we're proud to be a part of such a smart and friendly community. A great year lies ahead! --Guido van Rossum (home page: http://www.python.org/~guido/) From jim at digicool.com Sat Oct 28 04:45:02 2000 From: jim at digicool.com (Jim Fulton) Date: Fri, 27 Oct 2000 22:45:02 -0400 Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations References: Message-ID: <39FA3DAE.ADB2C8B1@digicool.com> Guido van Rossum wrote: > (snip) > I am proud to have found a new home for my entire team: starting > today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself > are working for Digital Creations. We will be spending part of our > time on core Python development (including Jython and Mailman) and > part of our time on Python infrastructure improvements that also > benefit Zope. Needless to say (but I'll say it anyway), Digital Creations is proud and thrilled that the this team has joined us. These are indeed exciting times! Jim -- Jim Fulton mailto:jim at digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org From martin at loewis.home.cs.tu-berlin.de Sat Oct 28 12:14:00 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:14:00 +0200 Subject: [Python-Dev] getting at the current frame Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> > which actually will look something like this in real code: > > def trade(yours, mine): > print _('if you give me %(yours)s, i will give you %(mine)s') % { > 'yours': yours, > 'mine' : mine, > } > > The string wrapped in _() is what gets translated here. > > Okay, we all know that's a pain, right? What's wrong with def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % vars() Look Ma, no magic! Regards, Martin From effbot at telia.com Sat Oct 28 12:43:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 28 Oct 2000 12:43:05 +0200 Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com> Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid> fred wrote: > At any rate, there has been activity in the source tree; you just > might want to do a CVS update to see what's changed. There have been > a number of bug fixes, a fair number of documentation updates, and > many of the modules in the standard library have been passed through > Tim Peter's reindent.py script (look in Tools/scripts/). now that this has been done, emacs users might want to add something like the following to their local configuration (based on code by jwz, so it should work...) ::: (defun python-mode-untabify () (save-excursion (goto-char (point-min)) (while (re-search-forward "[ \t]+$" nil t) (delete-region (match-beginning 0) (match-end 0))) (goto-char (point-min)) (if (search-forward "\t" nil t) (untabify (1- (point)) (point-max)))) nil) (add-hook 'python-mode-hook '(lambda () (make-local-variable 'write-contents-hooks) (add-hook 'write-contents-hooks 'python-mode-untabify))) From martin at loewis.home.cs.tu-berlin.de Sat Oct 28 12:51:20 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 28 Oct 2000 12:51:20 +0200 Subject: [Python-Dev] build problems under Solaris Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de> > I don't have access to a Solaris machine, so I can't do anything to > help these users. The patch in 117606 looks right to me: gcc on Solaris (and on any other platform) needs -shared to build shared library; configure currently passes -G. I haven't actually tried the patch, since it is a pain to extract it from the SF bug report page. What happens is that gcc passes -G to the linker, which correctly produces a shared library. However, gcc also links crt1/crti into the library, which causes the reference to main. 117508 looks like a user error to me. On its own, configure would not try to link -ldb, unless it detects the presence of db.h. My guess is that there is a libdb in /usr/local, so a gcc configure finds it, whereas the native compiler doesn't. Later, the linker even finds a -ldb library, but somehow this doesn't have dbopen. So it could be that the BSDDB installation on that system is screwed. Regards, Martin From barry at scottb.demon.co.uk Sat Oct 28 13:14:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:14:45 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F82C97.12D04C85@lemburg.com> Message-ID: <000601c040d0$474ce1d0$060210ac@private> > > We could make integrating C++ and Python easier through CXX or Py_Cpp. > > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating > > C++ and Python is not really so hard, in my experience. Integrating C++ and Python well is hard in a general library. CXX tries to make objects that look and feel like Python objects. But to do that we have to figure out the details of how python uses objects. You have no docs on the subject so we read the source code. Barry CXX maintainer From barry at scottb.demon.co.uk Sat Oct 28 13:23:50 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 28 Oct 2000 12:23:50 +0100 Subject: [Python-Dev] Gradual migration In-Reply-To: <39F80C30.5448.52D32F94@localhost> Message-ID: <000701c040d1$8beecf00$060210ac@private> [Gordon wrote] > All of the existing C++ interfaces / helpers deal only with type > objects (at least, those that I've examined, which is most of > them). In fact, only ExtensionClass attempts to deal with the > class / type split, and while it's a masterpiece, I think it's a > great example of everything to avoid in Py3K. Py_Cpp support C++ classes you can derived from in Python. Once I get my head around the proxy interface I'll try and add that to CXX. CXX today allows you to create C++ class that you can use from Python, but not derive from. Barry CXX maintainer From moshez at math.huji.ac.il Sun Oct 29 08:59:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST) Subject: [Python-Dev] development version of docs online In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote: > Do people want to be notified when the development copy of the > documentation is update? There was a comment from someone that they > didn't know where the online copy was. I can send the update notice > to python-dev instead of just to myself if everyone wants it, or I can > send it to some other (appropriate) list. I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that means I'm getting it twice. My foot is used to being shot at though) -- Moshe Zadka -- 95855124 http://advogato.org/person/moshez From barry at wooz.org Mon Oct 30 17:14:53 2000 From: barry at wooz.org (barry at wooz.org) Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST) Subject: [Python-Dev] Re: getting at the current frame References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de> Message-ID: <14845.40573.917058.905009@anthem.concentric.net> >>>>> "MvL" == Martin v Loewis writes: MvL> What's wrong with MvL> def trade(yours, mine): print _('if you give me MvL> %(yours)s, i will give you %(mine)s') % vars() MvL> Look Ma, no magic! Except that I also want globals() to be included and vars() doesn't include that. I really want: d = globals().copy() d.update(locals()) but I've also noticed that you sometimes want attribute following so you can do things like _('the name of the list is %(mlist.listname)') -Barry From barry at wooz.org Mon Oct 30 18:35:25 2000 From: barry at wooz.org (Barry A. Warsaw) Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213 References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <14845.45405.867829.722598@anthem.concentric.net> Well, it looks like checkin messages are flowing again. Yay! From mal at lemburg.com Mon Oct 30 18:54:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 30 Oct 2000 18:54:50 +0100 Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) References: <200010301715.JAA32564@slayer.i.sourceforge.net> Message-ID: <39FDB5EA.B60EA39A@lemburg.com> Jeremy Hylton wrote: > > Update of /cvsroot/python/python/dist/src/Python > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python > > Modified Files: > ceval.c > ... > N.B. The CALL_FUNCTION implementation is getting really hairy; should > review it to see if it can be simplified. How about a complete redesign of the whole call mechanism ?! I have an old patch somewhere which reorganizes the Python calling mechanism into something more sane than what we have in ceval.c now. Should I try to find it for someone to use as basis for the reorg (don't have time for this myself) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at alum.mit.edu Mon Oct 30 15:59:00 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST) Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213) In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com> References: <200010301715.JAA32564@slayer.i.sourceforge.net> <39FDB5EA.B60EA39A@lemburg.com> Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net> >>>>> "MAL" == M -A Lemburg writes: MAL> Jeremy Hylton wrote: >> >> Update of /cvsroot/python/python/dist/src/Python In directory >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python >> >> Modified Files: ceval.c ... N.B. The CALL_FUNCTION >> implementation is getting really hairy; should review it to see >> if it can be simplified. MAL> How about a complete redesign of the whole call mechanism ?! MAL> I have an old patch somewhere which reorganizes the Python MAL> calling mechanism into something more sane than what we have in MAL> ceval.c now. MAL> Should I try to find it for someone to use as basis for the MAL> reorg (don't have time for this myself) ? I'd be interested in looking at it. Jeremy From tim_one at email.msn.com Mon Oct 30 20:36:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:36:55 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? Message-ID: C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall test_extcall test test_extcall failed -- Writing: '3', expected: '' 1 test failed: test_extcall C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v test_extcall test_extcall test_extcall () {} (1,) {} (1, 2) {} (1, 2, 3) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3, 4, 5) {} (1, 2, 3) {'b': 5, 'a': 4} (1, 2, 3, 4, 5) {'b': 7, 'a': 6} (1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8} TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 TypeError: not enough arguments to g(); expected 1, got 0 1 () {} 1 (2,) {} 1 (2, 3) {} 1 (2, 3, 4, 5) {} 0 (1, 2) {} 1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} {'b': 2, 'c': 3, 'a': 1} keyword parameter 'x' redefined in call to g() keyword parameter 'b' redefined in function call keywords must be strings h() got an unexpected keyword argument 'e' * argument must be a sequence ** argument must be a dictionary 3 512 1 3 3 unbound method must be called with instance as first argument unbound method must be called with instance as first argument 1 test OK. From fdrake at acm.org Mon Oct 30 21:38:09 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com> Tim Peters writes: > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall > > test_extcall > test test_extcall failed -- Writing: '3', expected: '' > 1 test failed: test_extcall I get the same thing on Linux. The output appears identical to what Tim got. -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From jeremy at alum.mit.edu Mon Oct 30 17:48:08 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net> This output matches the output file I just checked in under Lib/test/output/test_extcall. Looks like I failed to check in this change. Jeremy From tim_one at email.msn.com Mon Oct 30 20:54:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 30 Oct 2000 14:54:14 -0500 Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: [Jeremy] > This output matches the output file I just checked in under > Lib/test/output/test_extcall. Looks like I failed to check in this > change. Thank you -- works on Windows now. It should work on Linux too, if Linux knows what's good for it . From fdrake at acm.org Mon Oct 30 21:56:13 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST) Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere? Expected? Bug? In-Reply-To: References: <14845.42568.358062.805095@bitdiddle.concentric.net> Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com> Tim Peters writes: > Thank you -- works on Windows now. It should work on Linux too, if Linux > knows what's good for it . It does. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations