Mailman 3 October 2003 - Python-Dev

RE: More informative error messages
by Scott David Daniels 09 Oct '03

09 Oct '03

[Tim Peters] >.... OTOH, almost >every call to a C API function has to test+branch for an error-return value, >and I've often wondered whether a setjmp/longjmp-based hack might allow for >cleaner and more optimizable code (hand-rolled "real exception handling"). > setjmp/longjmp are nightmares for compiler writers. The writers tend to turn off optimizations around them and/or get corner cases wrong. If you read the C standard, precious little is guaranteed around setjmp/longjmp. The C code using disciplined setjmp/longjmp, will read well, probably be be quite optimizable, but .... At least some of the C compilers will mis-optimize such code and others will be painfully slow due to the interaction of two compiler coding strategies: first, emit straightforward sloppy code easily cleaned up in the optimization passes, and second, turn off optimization in the presence of setjmp/longjmp. Maybe the general compiler world has changed, but I had nightmares supporting a language which generated C including setjmp/longjmp calls, and ran it on top of three C compilers. Each compiler had nasty cases to avoid, and the resulting least common denominator was painfully inept. -Scott David Daniels

4 5

obj.__contains__() returns 1/0...
by gminick 09 Oct '03

09 Oct '03

...shouldn't it return True/False? examples: >>> a = 'python' >>> a.__contains__('perl') 0 >>> a.__contains__('python') 1 >>> a = { 'python' : 1, 'ruby' : 1 } >>> a.__contains__('perl') 0 >>> a.__contains__('python') 1 >>> instead of: >>> a = 'python' >>> a.__contains__('perl') False >>> a.__contains__('python') True >>> a = { 'python' : 1, 'ruby' : 1 } >>> a.__contains__('perl') False >>> a.__contains__('python') True >>> The reason for asking is that i.e. obj.__eq__() returns True/False, and besides True/False looks nicer than 1/0 ;> ps. I'll send a patch to sf.net in a matter of minutes. Please, decide if it should be applied, thanks. -- [ Wojtek Walczak - gminick (at) underground.org.pl ] [ <http://gminick.linuxsecurity.pl/> ] [ "...rozmaite zwroty, matowe od patyny dawnosci." ]

1 1

Re: [Python-Dev] Re: More informative error messages
by Kevin J. Butler 08 Oct '03

08 Oct '03

> > >From: Nick Coghlan <ncoghlan(a)iinet.net.au>= > > Given this, perhaps a simple addition to the error string might be > enough to > >help reduce confusion: > > Agreed. >------------- >TypeError: foo() takes exactly 1 argument (2 given). (Note: For bound methods, >the argument count includes the object the method is bound to) >------------- > > Agreed, but then the newbies will wonder what bounds methods are, and to what a method would be bound. Shorter and easier for the uninitiated: TypeError: foo() takes exactly 1 argument (2 given). Counts may include 'self'. kb

1 0

spambayes-checkins -> spambayes-dev, python-checkins -> python-dev
by Skip Montanaro 08 Oct '03

08 Oct '03

Greg> On 06 October 2003, Skip Montanaro said: >> Maybe the Reply-To: for spambayes-checkins should be spambayes-dev >> (and similarly for python-checkins/python-dev). Can that be >> engineered through Mailman? Greg> Yes -- it's on the "General Options" page. Look for Greg> reply_goes_to_list. After seeing your answer I know I asked the wrong question. <wink> I shouldn't have said "Reply-To:". In X?Emacs/VM, I just hit the 'f' key to reply to you and to cc spambayes-dev. Had this been a spambayes-checkins message, it would have been nice if the cc went to spambayes-dev instead of spambayes-checkin. I can probably solve that for myself by tweaking the vm-followup command (what the 'f' key is bound to), but there's probably not a general solution. Setting Reply-To: *might* be okay in a situation like this where you don't want chit-chat on a checkins list to get lost or not seen by the larger audience, but I'd only use it as a last resort. Skip [OT PS] cthulhu.gerg.ca? Is that some sort of pronounceable-only-by-Native- Canadians name?

9 11

ConfigParser items method
by Gordon Williams 07 Oct '03

07 Oct '03

Hi All, There is a consistency problem between the RawConfigParser and the ConfigParser and SafeConfigParser with the items method. In the first case a list of tuples is returned and in the second two a generator is returned. This is quite confusing and I thought that this was a bug, but the docs indicate that this is what is supposed to happen. An items method that returned a list of tuples as it does in the RawconfigParser would be a useful method to have for both ConfigParser and SafeConfigParser. The RawConfigParser docs say that items should return a list: items( section) Return a list of (name, value) pairs for each option in the given section. The ConfigParser docs say that items should return a generator: items( section[, raw[, vars]]) Create a generator which will return a tuple (name, value) for each option in the given section. Optional arguments have the same meaning as for the get() method. New in version 2.3. RawConfigParser returns list: >>> Config.config <ConfigParser.RawConfigParser instance at 0x00E0DAD0> >>> Config.config.items("personal") [('age', '21'), ('company', 'Aztec'), ('name', 'karthik')] >>> ConfigParser and SafeConfigParser return generator: >>> Config.config <ConfigParser.SafeConfigParser instance at 0x00DB1738> >>> Config.config.items("personal") <generator object at 0x00DC3350> >>> for item in Config.config.items("personal"): ... print item ... ('age', '21') ('company', 'Aztec') ('name', 'karthik') >>> Config.config <ConfigParser.ConfigParser instance at 0x00E0D378> >>> Config.config.items("personal") <generator object at 0x00DB1738> >>> for item in Config.config.items("personal"): ... print item ... ('age', '21') ('company', 'Aztec') ('name', 'karthik') It doesn't make sense to me that the same method should return different objects. Maybe another name for ConfigParser and SafeConfigParser would be appropriate to indicate that a generator was being returned. Regards, Gordon Williams

2 5

Re: [spambayes-dev] spambayes-checkins -> spambayes-dev, python-checkins -> python-dev
by T. Alexander Popiel 07 Oct '03

07 Oct '03

In message: <1065529823.993.38.camel@anthem> Barry Warsaw <barry(a)python.org> writes: [ talk of mangling the reply-to on -checkins to point to -dev, iff there is no pre-existing reply-to ] >python-devers and spambayes-devers, you vant I should do dis? +1 - Alex

1 0

test_bsddb hangs with CVS Python
by Jeremy Hylton 07 Oct '03

07 Oct '03

test_bsddb hangs for me everytime. This is a current CVS python with BerkeleyDB 4.1.25. I've tried commenting out test_pop and test_mapping_iteration_methods, but it still hangs somewhere. localhost:~/src/python/build-pydebug> ./python ../Lib/test/test_bsddb.py -v test_change (__main__.TestBTree) ... ok test_clear (__main__.TestBTree) ... ok test_close_and_reopen (__main__.TestBTree) ... ok test_contains (__main__.TestBTree) ... ok test_first_next_looping (__main__.TestBTree) ... ok test_get (__main__.TestBTree) ... ok test_getitem (__main__.TestBTree) ... ok test_has_key (__main__.TestBTree) ... ok test_keyordering (__main__.TestBTree) ... ok test_len (__main__.TestBTree) ... ok test_mapping_iteration_methods (__main__.TestBTree) ... ok test_pop (__main__.TestBTree) ... ok strace says: stat64("./@test", 0xbfffc980) = -1 ENOENT (No such file or directory) stat64("./__db.@test.", {st_mode=S_IFREG|0664, st_size=8192, ...}) = 0 stat64("./@test", 0xbfffc830) = -1 ENOENT (No such file or directory) rename("./__db.@test.", "./@test") = 0 stat64("./@test", {st_mode=S_IFREG|0664, st_size=8192, ...}) = 0 open("./@test", O_RDWR|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0664, st_size=8192, ...}) = 0 pread(3, "\0\0\0\0\1\0\0\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 4096, 0) = 4096 pread(3, "\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\1\5\0"..., 4096, 4096) = 4096 futex(0x4055ad40, FUTEX_WAIT, 0, NULL Jeremy

3 2

Efficient predicates for the standard library
by Gareth McCaughan 07 Oct '03

07 Oct '03

Chris Stork wrote: > Now that there's a useful default meaning for pred, we should give > it a default and make it an optional argument. For this the order of > arguments must be reversed. This is different from itertools consistent > use of iterables as last arguments. I don't know if this is relevant > here. Anyway, since predicates are in general more useful like this > I think it's the better choice. Perhaps that's true for a piece of code given as an example. I don't think it would be sensible if, as you propose, these functions were to be put in the standard library, because there's something better to do with the default args for real applications. def any(pred, *iterables): I think the ability to work with multiple sequences (and not to have to use the argument order iter1, pred, iter2, ...) is more important than the ability to avoid typing "bool,". Another option would be def any(*iterables, pred=bool): for items in imap(None, *iterables): if pred(*items): return True return False which looks to me like it offers the best of both worlds. -- g

4 4

nested packages and import order
by Joerg Sonnenberger 06 Oct '03

06 Oct '03

Hi all, I have a package a.b with the following content: a/b/__init__.py: import a.b dir(a.b) Running this generates a AttributeError for b, obviously the import didn't add b to the module "a". Even though it can be argued that importing a package from within is bad style, this a clearly a bug since its at least surprising. Shouldn't the import create the namespace entry in a after it created the module entry in sys.modules? Joerg P.S.: Please CC me, I'm not subscriped

2 1

RE: Python-Dev Digest, Vol 3, Issue 10
by Schneider, Michael 06 Oct '03

06 Oct '03

Tana, I have a conflict for the 10:30 meeting. Can we get together at 2:00 this afternoon. I'm sorry for the clash, Mike ---------------------------------------------------------------- Michael Schneider Senior Software Engineering Consultant EDS PLM Solutions "The Greatest Performance Improvement Is the transitioning from a non-working state to the working state" -----Original Message----- From: python-dev-request(a)python.org [mailto:python-dev-request@python.org] Sent: Sunday, October 05, 2003 12:02 PM To: python-dev(a)python.org Subject: Python-Dev Digest, Vol 3, Issue 10 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. RE: Efficient predicates for the standard library (Raymond Hettinger) 2. Efficient predicates for the standard library (Raymond Hettinger) ---------------------------------------------------------------------- Message: 1 Date: Sun, 5 Oct 2003 11:46:29 -0400 From: "Raymond Hettinger" <python(a)rcn.com> Subject: RE: [Python-Dev] Efficient predicates for the standard library To: "'Christian Stork'" <cstork(a)ics.uci.edu> Cc: python-dev(a)python.org Message-ID: <000001c38b57$d7e91c20$e841fea9@oemcomputer> Content-Type: text/plain; charset="us-ascii" > Honestly, I assumed that > > x in iterable > > has a short-circuit implementation. Why doesn't it? It does. The ifilter() version is faster only because it doesn't have to continually return values to the 'in' iterator. The speedup is a small constant factor. > Let me just give you the reasons (in no particular order) for my > suggestion to include the `all' and `some/any' predicates: > > 1. Efficiency > Maybe I'm a bit naive here, but it seems to me that since these > predicates involve tight inner loops they offer good potential for > speedup, especially when used often and over many iterations. You're guessing incorrectly. The pure python versions use underlying itertools which run at full C speed. You cannot beat the ifilter() version.. > 2. Readabilty > If we offer universally-used predicates with succinct names which are > available as part of the "batteries included" then that increases > readabilty of code a lot. I put the code in the docs in a form so that people can cut and paste the function definitions it as needed. Then, they can use all(), any(), or no() to their heart's content. > 4. It's *not* trivial! > Contrary to what you imply it's not trivial for everybody to just write > efficient and well designed predicates with well-chosen names. This > discussion is the proof. :-) Cut and paste is easy. Raymond ------------------------------ Message: 2 Date: Sun, 5 Oct 2003 11:49:28 -0400 From: "Raymond Hettinger" <python(a)rcn.com> Subject: [Python-Dev] Efficient predicates for the standard library To: <python-dev(a)python.org> Message-ID: <000101c38b58$42d5da00$e841fea9@oemcomputer> Content-Type: text/plain; charset="us-ascii" > Honestly, I assumed that > > x in iterable > > has a short-circuit implementation. Why doesn't it? It does. The ifilter() version is faster only because it doesn't have to continually return values to the 'in' iterator. The speedup is a small constant factor. > Let me just give you the reasons (in no particular order) for my > suggestion to include the `all' and `some/any' predicates: > > 1. Efficiency > Maybe I'm a bit naive here, but it seems to me that since these > predicates involve tight inner loops they offer good potential for > speedup, especially when used often and over many iterations. You're guessing incorrectly. The pure python versions use underlying itertools which loop at full C speed. You cannot beat the ifilter() version. > 2. Readabilty > If we offer universally-used predicates with succinct names which are > available as part of the "batteries included" then that increases > readabilty of code a lot. I put the code in the docs in a form so that people can cut and paste the function definitions it as needed. Then, they can use all(), any(), or no() to their heart's content. > 4. It's *not* trivial! > Contrary to what you imply it's not trivial for everybody to just write > efficient and well designed predicates with well-chosen names. This > discussion is the proof. :-) Cut and paste is your friend. Raymond ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 3, Issue 10 *****************************************

1 0