Mailman 3 September 2000 - Python-Dev

Finding landmark when prefix != exec-prefix
by Greg Ward 08 Sep '00

08 Sep '00

Hey all -- this is a bug I noticed in 1.5.2 ages ago, and never investigated further. I've just figured it out a little bit more; right now I can only verify it in 1.5, as I don't have the right sort of 1.6 or 2.0 installation at home. So if this has been fixed, I'll just shut up. Bottom line: if you have an installation where prefix != exec-prefix, and there is another Python installation on the system, then Python screws up finding the landmark file (string.py in 1.5.2) and computes the wrong prefix and exec-prefix. Here's the scenario: I have a Red Hat 6.2 installation with the "official" Red Hat python in /usr/bin/python. I have a local build installed with prefix=/usr/local/python and exec-prefix=/usr/local/python.i86-linux; /usr/local/bin/python is a symlink to ../python.i86-linux/bin/python. (This dates to my days of trying to understand what gets installed where. Now, of course, I could tell you what Python installs where in my sleep with one hand tied behind my back... ;-) Witness: $ /usr/bin/python -c "import sys ; print sys.prefix" /usr $/usr/local/bin/python -c "import sys ; print sys.prefix" /usr ...even though /usr/local/bin/python's library is really in /usr/local/python/lib/python1.5 and /usr/local/python.i86-linux/lib/python1.5. If I erase Red Hat's Python, then /usr/local/bin/python figures out its prefix correctly. Using "strace" sheds a little more light on things; here's what I get after massaging the "strace" output a bit (grep for "string.py"; all that shows up are 'stat()' calls, where only the last succeeds; I've stripped out everything but the filename): /usr/local/bin/../python.i86-linux/bin/lib/python1.5/string.py /usr/local/bin/../python.i86-linux/bin/lib/python1.5/string.pyc /usr/local/bin/../python.i86-linux/lib/python1.5/string.py /usr/local/bin/../python.i86-linux/lib/python1.5/string.pyc /usr/local/bin/../lib/python1.5/string.py /usr/local/bin/../lib/python1.5/string.pyc /usr/local/bin/lib/python1.5/string.py /usr/local/bin/lib/python1.5/string.pyc /usr/local/lib/python1.5/string.py /usr/local/lib/python1.5/string.pyc /usr/lib/python1.5/string.py # success because of Red Hat's # Python installation Well, of course. Python doesn't know what its true prefix is until it has found its landmark file, but it can't find its landmark until it knows its true prefix. Here's the "strace" output after erasing Red Hat's Python RPM: $ strace /usr/local/bin/python -c 1 2>&1 | grep 'string\.py' /usr/local/bin/../python.i86-linux/bin/lib/python1.5/string.py /usr/local/bin/../python.i86-linux/bin/lib/python1.5/string.pyc /usr/local/bin/../python.i86-linux/lib/python1.5/string.py /usr/local/bin/../python.i86-linux/lib/python1.5/string.pyc /usr/local/bin/../lib/python1.5/string.py /usr/local/bin/../lib/python1.5/string.pyc /usr/local/bin/lib/python1.5/string.py /usr/local/bin/lib/python1.5/string.pyc /usr/local/lib/python1.5/string.py /usr/local/lib/python1.5/string.pyc /usr/lib/python1.5/string.py # now fail since I removed /usr/lib/python1.5/string.pyc # Red Hat's RPM /usr/local/python/lib/python1.5/string.py A-ha! When the /usr installation is no longer there to fool it, Python then looks in the right place. So, has this bug been fixed in 1.6 or 2.0? If not, where do I look? Greg PS. what about hard-coding a prefix and exec-prefix in the binary, and only searching for the landmark if the hard-coded values fail? That way, this complicated and expensive search is only done if the installation has been relocated. -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

3 2

Re: [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
by Skip Montanaro 08 Sep '00

08 Sep '00

Bob> The one I used was http://dreamcast.ign.com/review_lists/a.html, Bob> but probably any would do since it's pretty ordinary, and the error Bob> occurs before making any contact with the destination. Bob> By the way, I forgot to mention that I'm running under Windows 2000. Bob, Thanks for the input. I asked for a URL because I thought it unlikely something common would trigger a bug. After all, urllib.urlopen is probably one of the most frequently used Internet-related calls in Python. I can't reproduce this on my Linux system: % ./python Python 2.0b1 (#6, Sep 7 2000, 21:03:08) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import urllib >>> f = urllib.urlopen("http://dreamcast.ign.com/review_lists/a.html") >>> data = f.read() >>> len(data) Perhaps one of the folks on python-dev that run Windows of some flavor can reproduce the problem. Can you give me a simple session transcript like the above that fails for you? I will see about adding a test to the urllib regression test. -- Skip Montanaro (skip(a)mojam.com) http://www.mojam.com/ http://www.musi-cal.com/

1 0

Setup script for Tools/compiler (etc.)
by Greg Ward 08 Sep '00

08 Sep '00

Jeremy -- it seems to me that there ought to be a setup script in Tools/compiler; it may not be part of the standard library, but at least it ought to support the standard installation scheme. So here it is: #!/usr/bin/env python from distutils.core import setup setup(name = "compiler", version = "?", author = "Jeremy Hylton", author_email = "jeremy(a)beopen.com", packages = ["compiler"]) Do you want to check it in or shall I? ;-) Also -- and this is the reason I cc'd python-dev -- there are probably other useful hacks in Tools that should have setup scripts. I'm thinking most prominently of IDLE; as near as I can tell, the only way to install IDLE is to manually copy Tools/idle/*.py to <prefix>/lib/python{1.6,2.0}/site-packages/idle and then write a little shell script to launch it for you, eg: #!/bin/sh # GPW 2000/07/10 ("strongly inspired" by Red Hat's IDLE script ;-) exec /depot/plat/packages/python-2.0b1/bin/python \ /depot/plat/packages/python-2.0b1/lib/python2.0/site-packages/idle/idle.py $* This is, of course, completely BOGUS! Users should not have to write shell scripts just to install and run IDLE in a sensible way. I would be happy to write a setup script that makes it easy to install Tools/idle as a "third-party" module distribution, complete with a launch script, if there's interest. Oh hell, maybe I'll do it anyways... just howl if you don't think I should check it in. Greg -- Greg Ward - software developer gward(a)mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

1 1

DEBUG_SAVEALL feature for gc not in 2.0b1?
by Skip Montanaro 08 Sep '00

08 Sep '00

Neil sent me a patch a week or two ago that implemented a DEBUG_SAVEALL flag for the gc module. If set, it assigns all cyclic garbage to gc.garbage instead of deleting it, thus resurrecting the garbage so you can inspect it. This seems not to have made it into the CS repository. I think this is good mojo and deserves to be in the distribution, if not for the release, then for 2.1 at least. I've attached the patch Neil sent me (which includes code, doc and test updates). It's helped me track down one (stupid) cyclic trash bug in my own code. Neil, unless there are strong arguments to the contrary, I recommend you submit a patch to SF. Skip

4 14

hasattr() and Unicode strings
by Andrew Kuchling 08 Sep '00

08 Sep '00

hasattr(), getattr(), and doubtless other built-in functions don't accept Unicode strings at all: >>> import sys >>> hasattr(sys, u'abc') Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: hasattr, argument 2: expected string, unicode found Is this a bug or a feature? I'd say bug; the Unicode should be coerced using the default ASCII encoding, and an exception raised if that isn't possible. --amk

4 5

python -U fails
by Vladimir.Marangozov＠inrialpes.fr 08 Sep '00

08 Sep '00

Seen on c.l.py (import site fails due to eval on an unicode string): ~/python/Python-2.0b1>python -U 'import site' failed; use -v for traceback Python 2.0b1 (#2, Sep 7 2000, 12:59:53) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> eval (u"1+2") Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: eval() argument 1 must be string or code object >>> The offending eval is in os.py Traceback (most recent call last): File "./Lib/site.py", line 60, in ? import sys, os File "./Lib/os.py", line 331, in ? if _exists("fork") and not _exists("spawnv") and _exists("execv"): File "./Lib/os.py", line 325, in _exists eval(name) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 1

win32all-133 for Python 1.6, and win32all-134 for Python 2.0
by Mark Hammond 07 Sep '00

07 Sep '00

FYI - I'm updating the starship pages, and will make an announcement to the newsgroup soon. But in the meantime, some advance notice: * All new win32all builds will be released from http://www.activestate.com/Products/ActivePython/win32all.html. This is good for me - ActiveState actually have paid systems guys :-) win32all-133.exe for 1.6b1 and 1.6 final can be found there. * win32all-134.exe for the Python 2.x betas is not yet referenced at that page, but is at www.activestate.com/download/ActivePython/windows/win32all/win32all-134.exe If you have ActivePython, you do _not_ need win32all. Please let me know if you have any problems, or any other questions regarding this... Thanks, Mark. _______________________________________________ win32-reg-users maillist - win32-reg-users(a)pythonpros.com http://mailman.pythonpros.com/mailman/listinfo/win32-reg-users

1 0

GPL license issues hit Linux Today
by Guido van Rossum 07 Sep '00

07 Sep '00

http://linuxtoday.com/news_story.php3?ltsn=2000-09-07-001-21-OS-CY-DB Plus my response http://linuxtoday.com/news_story.php3?ltsn=2000-09-07-011-21-OS-CY-SW I'll be off until Monday, relaxing at the beach! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

1 0

Noisy test_gc
by Greg Ward 07 Sep '00

07 Sep '00

Just built 2.0b1, and noticed that the GC test script is rather noisy: ... test_gc gc: collectable <list 0x818cf54> gc: collectable <dictionary 0x822f8b4> gc: collectable <list 0x818cf54> gc: collectable <tuple 0x822f484> gc: collectable <class 0x822f8b4> gc: collectable <dictionary 0x822f8e4> gc: collectable <A instance at 0x818cf54> gc: collectable <dictionary 0x822fb6c> gc: collectable <A instance at 0x818cf54> gc: collectable <dictionary 0x822fb9c> gc: collectable <instance method 0x81432bc> gc: collectable <B instance at 0x822f0d4> gc: collectable <dictionary 0x822fc9c> gc: uncollectable <dictionary 0x822fc34> gc: uncollectable <A instance at 0x818cf54> gc: collectable <dictionary 0x822fbcc> gc: collectable <function 0x8230fb4> test_gdbm ... which is the same as it was the last time I built from CVS, but I would have thought this should go away for a real release... Greg

2 1

Re: [Python-Dev] newimp.py
by Charles G Waldman 07 Sep '00

07 Sep '00

Skip Montanaro writes: > > Charles> How about if you go to one of those CVS trees, cd Lib, and type > Charles> "cvs update newimp.py" ? > > I get > > beluga:Lib% cd ~/src/python/dist/src/Lib/ > beluga:Lib% cvs update newinp.py > cvs server: nothing known about newinp.py That's because you typed "newinp", not "newimp". Try it with an "M" and see what happens. -C

4 4