Mailman 3 September 2001 - Python-Dev

Python 2.2a3 tagged
by barry＠zope.com Sept. 6, 2001

Sept. 6, 2001

In preparation for the next alpha release, we've tagged the tree and created the branch. The tag on the trunk is r22a3-fork and the branch tag is r22a3-branch. The only people authorized to make checkins on the branch are Guido, Tim, and myself. You can still make checkins on the trunk, but please keep them to a minimum until 2.2a3 is released. If you make any trunk checkins that need to go into 2.2a3, please send Guido, Tim, and I a message directly asking us to merge your trunk change into the branch. Thanks, and watch for the release some time tomorrow. Cheers, -Barry

1 0

very long python files
by The Intermission Elf Sept. 6, 2001

Sept. 6, 2001

Hey Folks, I just got this message from a developer inside of ILM today. Before I start digging, can anyone tell me if this has been dealt with in any version of python more recent than 1.5.2? (and where I might look for this info myself- I'm very unfamiliar with sourceforge and its bug tracker)... thanks! Garrick Meeker writes: | ******** is starting to produce very long project files (over 32K lines) | which it currently can't read. (Because curves are imbedded in the | files, it's not difficult to hit that limit.) | | Here's what I've found so far (in both python 1.4 and 1.5): | | ******** read the file by calling PyRun_SimpleFile. This byte compiles | the entire file into memory and then runs that (which is probably not | ideal). | | The file is tokenized into nodes that have a 'short' for the line | number, so this wraps around to negative numbers. | | The line number is entered into the byte code with a call to | 'com_addint', which calls: | | com_addbyte(c, x & 0xff); | com_addbyte(c, x >> 8); /* XXX x should be positive */ | | (notice that 'x >> 8' for a negative number will be a negative number). | | com_addbyte has a sanity check: | | if (byte < 0 || byte > 255) { | com_error(c, PyExc_SystemError, "com_addbyte: byte out of range"); | | This is what prevents ******** from loading long files. The options I | see are: | | Fix our build of python to fix this problem. We can't change the line | number to 'int' because we'd be changing the byte code, but we could | stop the number from wrapping around. | | Manually read each line from the file and feed it to the interpreter as | if we were interactive. We'd lose the line number information if | there's an error in the file (but we can't save numbers over 32K | anyway). I think it would also be friendlier on memory because it | wouldn't byte compile the entire file first. There is a call to pass | strings in this manner, but I don't know if it will actually work this | way. | | Tommy, have you heard of this before? I know I still missing part of | the story because I can create a simple file with 40K lines of: | | a = 0 | | and python accepts it without error.

3 2

re-ordering sys.path
by Neil Schemenauer Sept. 6, 2001

Sept. 6, 2001

jerome.marant(a)free.fr (Jérôme Marant) in debian-python(a)lists.debian.org: > I am the python-unit maintainer (upstream program called PyUnit) > for python 1.5 and 2.0. > PyUnit has been included in Python 2.1. but I won't give it away > since it does evolve separately from Python releases. > > However, because of PYTHONPATH, the latest version of the module > will never be loaded by the interpreter. > > In 2.0 (and quite the same in 2.1), PYTHONPATH looks like: > > amboise:~$ python2 -c 'import sys; print sys.path' > ['', > '/usr/lib/python2.0', > '/usr/lib/python2.0/plat-linux2', > '/usr/lib/python2.0/lib-dynload', > '/usr/local/lib/python2.0/site-packages', > '/usr/local/lib/site-python', > '/usr/lib/python2.0/site-packages', > '/usr/lib/site-python'] > > So, if the interpreter find the module in its core modules, it > will never see that a newer version of the module was installed > in site-packages. > > Usually, packages installed separately (site-packages) from the > core python modules are more recent that the same modules of > the core, because they evolve faster than python releases. > Manual installations of modules (/usr/local) are usually done > when packages are not up-to-date, so more recent than site modules. > > This is a well known problem since python-xml (PyXML) is both > in 2.0 core and in a separate package and PyXML people have > implemented an ugly hack to work this around. > > So, I'm proposition to reorganize the PYTHONPATH like this : > > ['', > '/usr/local/lib/python2.0/site-packages', > '/usr/local/lib/site-python', > '/usr/lib/site-python' > '/usr/lib/python2.0/site-packages', > '/usr/lib/python2.0', > '/usr/lib/python2.0/plat-linux2', > '/usr/lib/python2.0/lib-dynload', > > ] > > I know that it could lead to some problems but not > that much I think. > > Thanks in advance for your comments. > > PS: it would be usefull to talk to Brendan O'Dea who chose the > same ordering for Perl packages. Will this work? If so, why is it not already done? Neil

4 3

python/dist/src setup.py,1.52,1.53
by Martin von Loewis Sept. 6, 2001

Sept. 6, 2001

> But what if someone installs their own, better version of curses, > e.g. in /usr/local? Maybe you should only disable it if it's darwin > *and* if it's in a standard location? Or if the header file contains > a certain characteristic string? In that case, the user could still put the appropriate instructions into Modules/Setup, which they'd probably do anyway, since they need special -I/-L options. So I agree with the notion that setup.py should only do so much autoconfiguration, and leave special cases to manual configuration through Modules/Setup. However, I dislike the frequent usage of platform in setup.py, where this patch adds another instance of. I believe the autoconf approach "test for features, not system names" is much more flexible. If the curses module requires certain feature, find a way of testing whether the features are present, and only compile _curses if they are. Then it would not be necessary to check whether the system name is "darwin1". This is problematic in particular as different spellings of the platform are expected: It is "darwin1" in some places, and "Darwin1.2" atleast in another place. Regards, Martin

5 7

[development doc updates]
by Fred L. Drake Sept. 6, 2001

Sept. 6, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Documentation for 2.2 alpha 3.

1 0

why doesn't print pass unicode strings on to the file object?
by Fredrik Lundh Sept. 6, 2001

Sept. 6, 2001

is there any reason why "print" cannot pass unicode strings on to the underlying write method? it would be really nice if this piece of code worked as expected: import sys class Wrapper: def __init__(self, file): self.file = file def write(self, data): self.file.write(data.encode("iso-8859-1", "replace")) sys.stdout = Wrapper(sys.stdout) print u"åäö" under 2.2a2 (and earlier versions), this gives me: Traceback (most recent call last): File "\test.py", line 8, in ? print u"åäö" UnicodeError: ASCII encoding error: ordinal not in range(128) (I'm willing to implement this, if the BDFL says so) </F>

2 1

Re: python/dist/src/Objects complexobject.c,2.42,2.43
by Billy G. Allie Sept. 6, 2001

Sept. 6, 2001

"Martin v. Loewis" wrote: > > What's the plan for removing this stuff again when UnixWare fixes > > their bugs? > > There is no plan for that at the moment. Please have a look at > > http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=4… > 710 > > for prior discussion on the matter; the submitter has considered > coming up with an autoconf bug test for the problem, but hasn't > followed up with that - testing for the system apparently turned out > to be the easier route. Easier only in that I am a beginner when it comes to using autoconf. If someone can point me in the right direction, I will work on such a test. I also try to keep current on patches with UnixWare. If I find that the bug has been fixed, I can back out the SCO specific changes. -- ____ | Billy G. Allie | Domain....: Bill.Allie(a)mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie(a)email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |

1 0

python/dist/src/Objects complexobject.c,2.42,2.43
by Martin v. Loewis Sept. 5, 2001

Sept. 5, 2001

> What's the plan for removing this stuff again when UnixWare fixes > their bugs? There is no plan for that at the moment. Please have a look at http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=4… for prior discussion on the matter; the submitter has considered coming up with an autoconf bug test for the problem, but hasn't followed up with that - testing for the system apparently turned out to be the easier route. One possible approach is that UnixWare releases are regularly tested for the presence of the bug. That would be simplified if the nature of the problem was documented somewhere, that also hasn't happened. To retest, it might be easiest to disable the SCO_ macros, and re-run the test suite; test_math will fail if the bug is still present. Once the version of UnixWare is identified that first fixed the bugs, it hopefully is possible to check the value of __SCO_VERSION__ to tell apart the good, the bad, and the ugly. Regards, Martin

2 1

RE: [Python-checkins] CVS: python/dist/src/Objects complexobject.c,2.42,2.43
by Tim Peters Sept. 5, 2001

Sept. 5, 2001

[Martin v. L?wis] > Update of /cvsroot/python/python/dist/src/Objects > In directory usw-pr-cvs1:/tmp/cvs-serv12367/Objects > > Modified Files: > complexobject.c > Log Message: > Patch #453627: Define the following macros when compiling on a > UnixWare 7.x system: > SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. > Work aroudn a bug in the SCO UnixWare atan2() implementation. and so on. What's the plan for removing this stuff again when UnixWare fixes their bugs?

1 0

pycnfig.h.in and UW7
by Guido van Rossum Sept. 5, 2001

Sept. 5, 2001

Hi Martin, Reviewing the checkin message, I just saw some stuff that you added disappear: *************** *** 716,725 **** #define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE #endif - #endif - - /* Define the macros needed if on a UnixWare 7.x system. */ - #if defined(__USLC__) && defined(__SCO_VERSION__) - #define SCO_ACCEPT_BUG /* Use workaround for UnixWare accept() bug */ - #define SCO_ATAN2_BUG /* Use workaround for UnixWare atan2() bug */ - #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif --- 722,724 ---- The removed lines were added by you a few minutes earlier. I did a full cvs update, ran autoconf and autoheader, and checked in the resulting files (after testing everything first). AFAIK, pyconfig.h.in is a generated file, written by autoheader, so those #defines that you added won't stick. I'm not sure where they *should* go though. The normal way to get a variable defined in pyconfig.h.in is complicated; you have to put a template using #undef in acconfig.h.in, and call AC_DEFINE() in configure.in. I think there are a few places in configure.in where -D options are added to OPT or to CC -- I'm not sure why, it could be that the author of the patch didn't know the proper way, or it could be there was a special reason. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 4