Mailman 3 December 2002 - Python-Dev

'unhashable type' and new style classes
by Thomas Heller 31 Dec '02

31 Dec '02

This code class X: def __cmp__(self, other): return 1 c1 = X() d = {} d[c1] = None raises a TypeError, unhashable type, since the class does not define a __hash__ method. This error is no longer raised when X derives from object. Bug (or feature)? Thomas

3 6

Extension modules, Threading, and the GIL
by David Abrahams 30 Dec '02

30 Dec '02

The following message is a courtesy copy of an article that has been posted to comp.lang.python as well. David Abrahams <dave(a)boost-consulting.com> writes: > Aahz <aahz(a)pythoncraft.com> writes: >> I think this thread might be better handled on c.l.py, at least >> until it's understood well enough to be clear whether something does >> need to change in Python. > > I'm pretty certain I understand what's going on. If it would be > better for you to take this to c.l.py, I'm happy to do so, but AFAICT > there _is_ a Python core issue here: there's no way to find out > whether you've already got the GIL**, so if you _might_ have to acquire > it, you must always acquire it. > > **If I'm wrong about that, please let me know. It isn't obvious from > the documentation. This is the continuation of a thread originated on python-dev; I was asked to re-raise it here on python-list until the issue is better understood. The original posting was here: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1482879 The he essence of the problem is that there's no way to write code that uses the Python 'C' API and which has no knowledge of whether it is running on Python's main thread when it is entered. The two respondents were left with some questions; you can read those, and my responses, in the thread at the bottom of the page referenced above. Thanks for your attention, Dave -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

1 0

Proposed contribution to the library: PAX (another XML library)
by Lalo Martins 30 Dec '02

30 Dec '02

PAX - the "Pythonic API for XML" - is a XML-handling library. Like with DOM, you're supposed to first parse the whole stream into the internal representation, and then operate on it. What distinguishes PAX is that its implementation is python-oriented; you iterate trough child nodes via the normal ways (for, getitem, and in 2.2+, an iterator), the attributes are dictionary-based, etc. I used it to successfully reimplement TAL and PageTemplates (used in Zope). This reimplementation (AltPT) is quite stable and in production users in a few dozen servers around the world. PAX also includes a powerful python-oriented transform engine, which I used in Alt-TAL. The code has been tested on Python 2.1, 2.2 and recent CVS checkouts. It not only works, but transparently uses recent interesting features when available - notably, enumerate(). Most of the code is in public domain, and of course I make no objections to switching to PSL. In fact the package was designed all along with the intention of offering it to the standard library (and I like to think that this led me to cleaner design and a readable implementation). It is in active maintenence; if not much development happened in the last few months, it's because it reached some maturity. In fact I just released 1.0alpha1 before sending this mail (15k tar.bz2) PAX has a small site at my very-slow (due to bad connectivity) Zope server at http://python.laranja.org/pax/ - this site, btw, runs on AltPT. The releases can be found there, and the cvs is (for hystorical reasons) at :pserver:anonymous@cvs.sf.net:/cvsroot/flyingcircus module miscfiles/python/pax (because it was originally developed as I needed an XML library for my "flyingcircus" pda project). Should I write a PEP? Or a patch (silly, it would be a quite big patch)? []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/

3 3

test_pyclbr failling
by Neal Norwitz 30 Dec '02

30 Dec '02

test_pyclbr is failing due to the changes in random: test_pyclbr l1=['Random'] l2=['CoreGenerator'] ignore=('_verify',) class=<class 'random.Random'> test test_pyclbr failed -- Traceback (most recent call last): File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 146, in test_others cm('random', ignore=('_verify',)) # deleted File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 97, in checkModule self.assertListEq(real_bases, pyclbr_bases, ignore) File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 33, in assertListEq self.fail("%r missing" % item) File "/home/neal/build/python/dist/src/Lib/unittest.py", line 260, in fail raise self.failureException, msg AssertionError: 'Random' missing Neal

3 2

Fix for bug 597919 (compiler package vs SET_LINENO)
by Michael Hudson 30 Dec '02

30 Dec '02

I've finally come up with a patch I'm 90% happy with for this problem, got my iBook's modem talking to my ISP right and created a diff. Unfortunately, SF's tracker isn't behaving and I'm about to disappear from the internet for a day or so and 2.3a1 is due tomorrow, so it's here: http://starship.python.net/crew/mwh/hacks/compiler-fixes-3.diff There's one outstanding problem with the compiler package to do with code of the form (unary operator)constant which is shown up by test_grammar, but that aside I can compile the test suite and the standard library using the patched compiler package and it runs fine. I'd really like to see this patch in 2.3a1. I'll fix the -literal thing for 2.3a2, but I bet noone notices it in the mean time :) Cheers, M. -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com

1 0

Re: [Python-Dev] GC at exit?
by Michael Hudson 30 Dec '02

30 Dec '02

Aahz <aahz(a)pythoncraft.com> writes: > [Originally posted to comp.lang.python with no response; asking here > before filing a bug report] > > Is garbage collection supposed to run when Python exits? The following > program does not print any output, unless I uncomment the gc.collect() > (or add a for loop that forces GC after creating the cycle): > > import gc > > class A: > pass > > class B: > def __del__(self): > print "Bye-bye!" > > a = A() > b = A() > a.b = b > b.a = a > a.x = B() > > del a > del b > > #gc.collect() One possibility is that the __del__ method *is* being run, but after sys.stdout & so on has been torn down. python -v can help, maybe? Cheers, M. -- Unfortunately, nigh the whole world is now duped into thinking that silly fill-in forms on web pages is the way to do user interfaces. -- Erik Naggum, comp.lang.lisp

1 0

Moving Mac/Lib to Lib/plat-mac before 2.3a1?
by Jack Jansen 30 Dec '02

30 Dec '02

Oops, there something that's been on my todo list for quite a while but that I haven't taken any action on (at least I can put part of the blame on Just, it was his idea and he didn't take any action either:-): moving Mac/Lib to Lib/plat-mac. The main reason for doing this is that most (if not all) of those modules are useable in unix-Python on MacOSX too, and moreover it would make the MacPython-OS9 tree look a little more like the normal Python tree. site.py would get one extra line with a special case (if sys.platform==darwin we not only add plat-darwin to the path but also plat-mac). Is it a good idea to try and get this in before 2.3a1? Is it a better idea to try and get this in between 2.3a1 and the next release (2.3a2? 2.3b1?)? And on the technical implementation: I think I would ask the SF maintainers to *copy* Mac/Lib to Lib/plat-mac, and then manually delete Mac/Lib on the trunk and Lib/plat-mac on the 2.2 maintenance branch. Is that a good idea? A similar case can be made for other Mac subdirs (Mac/Tools->Tools/Mac, Mac/scripts->Tools/Mac/scripts), but that is less essential and can probably wait until later. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

3 2

Weekly Python Bug/Patch Summary
by Skip Montanaro 29 Dec '02

29 Dec '02

Bug/Patch Summary ----------------- 326 open / 3145 total bugs (+4) 104 open / 1855 total patches (+11) New Bugs -------- email: huge address lines blow stack (2002-12-15) http://python.org/sf/654362 make errors better like cgi (2002-12-16) http://python.org/sf/654558 asyncore.py and "handle_expt" (2002-12-16) http://python.org/sf/654766 doctest and exception messages (2002-12-16) http://python.org/sf/654783 datetime docs need review, LaTeX (2002-12-16) http://python.org/sf/654846 Slightly modify locals() doc? (2002-12-17) http://python.org/sf/655271 cPickle not always same as pickle (2002-12-18) http://python.org/sf/655802 binascii.a2b_base64 with non base64 data (2002-12-19) http://python.org/sf/656392 gettext.py crash on bogus preamble (2002-12-24) http://python.org/sf/658233 Accept None for time.ctime() and friends (2002-12-24) http://python.org/sf/658254 cPickle does relative import (2002-12-26) http://python.org/sf/658693 asyncore connect() and winsock errors (2002-12-26) http://python.org/sf/658749 no docs for HTMLParser.handle_pi (2002-12-27) http://python.org/sf/659188 'realpath' function missing from os.path (2002-12-27) http://python.org/sf/659228 optparse store_true uses 1 and 0 (2002-12-28) http://python.org/sf/659604 New Patches ----------- gzip shouldn't ValueError on corruptfile (2002-12-15) http://python.org/sf/654421 Fix bug in IE/CGI [bug 427345] (2002-12-16) http://python.org/sf/654910 commands.py for Windows (2002-12-17) http://python.org/sf/655421 Add warnings to unsafe Cookie classes (2002-12-18) http://python.org/sf/655760 /dev/ptmx support for ptys (cygwin) (2002-12-19) http://python.org/sf/656590 Documentation support for PEP 301 (2002-12-23) http://python.org/sf/658093 PEP 301 implementation (2002-12-23) http://python.org/sf/658094 Mersenne Twister (2002-12-24) http://python.org/sf/658251 skips.txt for regrtest.py (2002-12-24) http://python.org/sf/658316 Add inet_pton and inet_ntop to socket (2002-12-24) http://python.org/sf/658327 email: minimal header encoding (2002-12-24) http://python.org/sf/658407 Fix for bug 494589 (2002-12-25) http://python.org/sf/658599 regex fixes for _strptime (2002-12-26) http://python.org/sf/658820 posixpath missing getctime (2002-12-27) http://python.org/sf/658927 Use PyArg_UnpackTuple where possible (2002-12-28) http://python.org/sf/659536 Closed Bugs ----------- Python 2.1 installs shared libs with mode 0700 (2001-05-17) http://python.org/sf/425007 Left to right (2001-08-06) http://python.org/sf/448679 unreliable file.read() error handling (2002-02-23) http://python.org/sf/521782 lib-dynload/*.so wrong permissions (2002-07-17) http://python.org/sf/583206 property missing doc'd __name__ attr (2002-09-22) http://python.org/sf/612969 missing DECREF's in embedding example (2002-10-21) http://python.org/sf/626275 ftplib bails out on empty responses (2002-11-11) http://python.org/sf/636685 Undocumented side effect of eval (2002-11-20) http://python.org/sf/641111 property() builtin not documented (2002-11-23) http://python.org/sf/642742 .extend() doc, .__doc__ too restrictive (2002-11-29) http://python.org/sf/645777 Closed Patches -------------- install lib-dynload .so files mode 555 (2002-10-26) http://python.org/sf/629278 Fix for major rexec bugs (2002-11-11) http://python.org/sf/636769 Allow keyword args in dict.update() (2002-11-25) http://python.org/sf/643565 Set Next Statement for Python debuggers (2002-11-25) http://python.org/sf/643835

1 0

Re: [Python-Dev] Write All New Import Hooks (PEP 302) in Python, Not C
by Michael Hudson 29 Dec '02

29 Dec '02

Just van Rossum <just(a)letterror.com> writes: > I find this rather ugly, and would only do that if it's crucial that the > pathless importer should be invoked somewhere in the middle of sys.path. > And I don't have a use case for that. There are plenty of use cases for > sys.meta_path. I've not really been following this discussion with utmost care, but the name "meta_path" doesn't move me. Wouldn't sys.importers be better name? Or maybe I'm misunderstanding it's intent -- which is still an argument for a better name. Cheers, M. -- Also, remember to put the galaxy back when you've finished, or an angry mob of astronomers will come round and kneecap you with a small telescope for littering. -- Simon Tatham, ucam.chat, from Owen Dunn's review of the year

4 3

Re: [Python-Dev] Write All New Import Hooks (PEP 302) in Python, Not C
by Michael Hudson 28 Dec '02

28 Dec '02

Just van Rossum <just(a)letterror.com> writes: > Michael Hudson wrote: > > > I've not really been following this discussion with utmost care, but > > the name "meta_path" doesn't move me. Wouldn't sys.importers be > > better name? Or maybe I'm misunderstanding it's intent -- which is > > still an argument for a better name. > > I don't like the name much either, but it _does_ fit quite well as the > idea is that sys.path importing gets invoked through an item on > meta_path. Perhaps this sketch helps a little: > > > sys.meta_path = [ > BuiltinImporter(), # handles builtin modules > FrozenImporter(), # handles frozen modules > PathImporter(), # handles sys.path > ] [...] Right, that's what I thought was roughly the plan -- but I still don't like the name. In this world, sys.path is sort-of subsidiary to sys.meta_path -- which jars, to me at least. It makes sense with a bit of historical knowledge, but not without, IMHO. Of course, these mild gripes shouldn't delay the real work -- but names are important. Cheers, M. -- Remember - if all you have is an axe, every problem looks like hours of fun. -- Frossie -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

1 0