Mailman 3 April 2006 - Python-Dev

Re: [Python-Dev] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
by Delaney, Timothy (Tim) 03 Apr '06

03 Apr '06

Guido van Rossum wrote: >> I can't confirm right now (at work, need to install 2.5) but I'm also >> wondering what will happen if KeyboardInterrupt or SystemExit is >> raised from inside the generator when it's being closed via >> __exit__. I suspect a RuntimeError will be raised, whereas I think >> these should pass through. > > I see no reason for this with the current code. Perhaps a previous > version of contextlib.py had this problem? Nah - that was me mis-remembering the contextlib code. They're handled properly. Tim Delaney

1 0

Saving the hash value of tuples
by Noam Raphael 03 Apr '06

03 Apr '06

Hello, I've found out that the hash value of tuples isn't saved after it's calculated. With strings it's different: the hash value of a string is calculated only on the first call to hash(string), and saved in the structure for future use. Saving the value makes dict lookup of tuples an operation with an amortized cost of O(1). Saving the hash value means that if an item of the tuple changes its hash value, the hash value of the tuple won't be changed. I think it's ok, since: 1. Hash value of things shouldn't change. 2. Dicts assume that too. I tried the change, and it turned out that I had to change cPickle a tiny bit: it uses a 2-tuple which is allocated when the module initializes to lookup tuples in a dict. I changed it to properly use PyTuple_New and Py_DECREF, and now the complete test suite passes. I run test_cpickle before the change and after it, and it took the same time (0.89 seconds on my computer). What do you think? I see three possibilities: 1. Nothing should be done, everything is as it should be. 2. The cPickle module should be changed to not abuse the tuple, but there's no reason to add an extra word to the tuple structure and break binary backwards compatibility. 3. Both should be changed. I will be happy to send a patch, if someone shows interest. Have a good day, Noam

4 6

Need Py3k group in trackers
by Guido van Rossum 03 Apr '06

03 Apr '06

Could one of the tracker admins add a Python-3000 group to the SF trackers (while we're still using them :-)? This is so we can easily move proposals between Python 3000 and Python 2.x status. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

SF:1463370 add .format() method to str and unicode
by Crutcher Dunnavant 03 Apr '06

03 Apr '06

>From discussion on python-3000, it occured to me that this shouldn't break anything. This patch adds a .format() method to the string and unicode types. SF:1463370 -- Crutcher Dunnavant <crutcher(a)gmail.com> littlelanguages.com monket.samedi-studios.com

4 3

Firefox searchbar engine for Python bugs
by Anthony Baxter 03 Apr '06

03 Apr '06

I've created a searchbar plugin for the firefox search bar that allows you to search bugs. I think someone created one for the sidebar, but this works in the searchbar at the top of the window. I gave up trying to knit the files into the new website builder, and so it can be found here: http://www.python.org/~anthony/searchbar/ If you can think of other useful searchbar plugins (Python Docs, maybe?) let me know and I'll look at creating them. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

3 3

PEP to list externally maintained modules and where to report bugs?
by Brett Cannon 03 Apr '06

03 Apr '06

I reported some warnings I was getting for ctypes the other day and Martin said I should report it to ctypes. I now get a warning for sqlite on OS X 10.4 about INT32_MIN being redefined (I have stdint.h on my machine and that macro is being redefined in Modules/_sqlite/cursor.c instead of using the C99 version). Anyone else think we need a PEP to point to places where externally maintained code should have bugs or patches reported? I don't want to hunt down a URL for where to do this every time and so it would be nice to have a list of what code needs bugs/patches reported where. Otherwise I am prone to just check my changes into the tree and not get them reported upstream since I want the warnings to go away. =) -Brett

2 1

SF #1462485 - StopIteration raised in body of 'with' statement suppressed
by Delaney, Timothy (Tim) 03 Apr '06

03 Apr '06

Discovered this while playing around with the 2.5 released end of last week. Given: @contextmanager def gen(): print '__enter__' yield print '__exit__' with gen(): raise StopIteration('body') I would expect to get the StopIteration exception raised. Instead it's suppressed by the @contextmanager decorator. I think we should only suppress the exception if it's *not* the exception passed into gen.throw() i.e. it's raised by the generator. Does this sound like the correct behaviour? I've attached tests and a fix implementing this to the bug report. I can't confirm right now (at work, need to install 2.5) but I'm also wondering what will happen if KeyboardInterrupt or SystemExit is raised from inside the generator when it's being closed via __exit__. I suspect a RuntimeError will be raised, whereas I think these should pass through. Tim Delaney

2 1

Whole bunch of test failures on OSX
by skip＠pobox.com 02 Apr '06

02 Apr '06

I'm not sure this is going to be all that helpful. If there's more I can do to help track down these problems, let me know. Last night I ran make test EXTRATESTOPTS='-R :: -uall -r' on my Mac laptop after a fresh svn up. I wasn't ready for how long that would run! I got plenty of test failures: 285 tests OK. 12 tests failed: test_codecencodings_cn test_codecencodings_kr test_codecencodings_tw test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_tw test_decimal test_difflib test_logging test_optparse test_warnings 15 tests skipped: test_al test_cd test_cl test_dl test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_nis test_ossaudiodev test_pep277 test_sunaudiodev test_winreg test_winsound Those skips are all expected on darwin. The test_codecencodings_tw failure looks like this: File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 88, in test_customreplace_encode "test.xmlcharnamereplace")[0], sout) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 74, in xmlcharnamereplace if ord(c) in codepoint2name: File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 260, in ord return _ord(c) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 260, in ord return _ord(c) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 260, in ord return _ord(c) ... many more at the same line ... with "maximum recursion depth exceeded" at the bottom. Similar problem in test_codecmaps_hk except the recursion was in _unichr(): File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 299, in test_mapping_file unich = unichrs(data[1]) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 275, in <lambda> unichrs = lambda s: u''.join(map(unichr, map(eval, s.split('+')))) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 253, in unichr return _unichr(v) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 253, in unichr return _unichr(v) File "/Users/skip/src/python-svn/trunk/Lib/test/test_multibytecodec_support.py", line 253, in unichr return _unichr(v) ... The other codec-related failures looked the same to my casual eye. The test_difflib error was an assertion failure involving a big-ass chunk of HTML: test test_difflib failed -- Traceback (most recent call last): File "/Users/skip/src/python-svn/trunk/Lib/test/test_difflib.py", line 145, in test_html_diff self.assertEqual(actual,expect) AssertionError: '\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\n "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\n\n<html>\n\n<head>\n <meta http-equiv="Content-Type"\n content="text/html; charset=ISO-8859-1" />\n <title></title>\n <style type="text/css">\n table.diff {font-family:Courier; border:medium;}\n .diff_header {background-color:#e0e0e0}\n td.diff_header {text-align:right}\n ... The test_optparse failure: test test_optparse failed -- Traceback (most recent call last): File "/Users/skip/src/python-svn/trunk/Lib/test/test_optparse.py", line 571, in test_float_default self.assertHelp(self.parser, expected_help) File "/Users/skip/src/python-svn/trunk/Lib/test/test_optparse.py", line 176, in assertHelp actual_help + '"\n') AssertionError: help text failure; expected: "usage: test [options] options: -h, --help show this help message and exit -p PROB, --prob=PROB blow up with probability PROB [default: 0.43] "; got: "usage: test [options] options: -h, --help show this help message and exit -p PROB, --prob=PROB blow up with probability PROB [default: 0.43] " Test_logging crashed: test test_logging crashed -- <class 'exceptions.KeyError'>: <logging.StreamHandler instance at 0x2088478> And though it didn't list test_bsddb3 as a failure, it got a bunch of DBLockDeadlockError exceptions. Here are a couple examples: test_bsddb3 Exception in thread reader 0: Traceback (most recent call last): File "/Users/skip/src/python-svn/trunk/Lib/threading.py", line 467, in __bootstrap self.run() File "/Users/skip/src/python-svn/trunk/Lib/threading.py", line 447, in run self.__target(*self.__args, **self.__kwargs) File "/Users/skip/src/python-svn/trunk/Lib/bsddb/test/test_thread.py", line 275, in readerThread rec = dbutils.DeadlockWrap(c.next, max_retries=10) File "/Users/skip/src/python-svn/trunk/Lib/bsddb/dbutils.py", line 62, in DeadlockWrap return function(*_args, **_kwargs) DBLockDeadlockError: (-30995, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Exception in thread reader 3: Traceback (most recent call last): File "/Users/skip/src/python-svn/trunk/Lib/threading.py", line 467, in __bootstrap self.run() File "/Users/skip/src/python-svn/trunk/Lib/threading.py", line 447, in run self.__target(*self.__args, **self.__kwargs) File "/Users/skip/src/python-svn/trunk/Lib/bsddb/test/test_thread.py", line 275, in readerThread rec = dbutils.DeadlockWrap(c.next, max_retries=10) File "/Users/skip/src/python-svn/trunk/Lib/bsddb/dbutils.py", line 62, in DeadlockWrap return function(*_args, **_kwargs) DBLockDeadlockError: (-30995, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') ... For test_decimal it printed: test test_decimal failed -- errors occurred; run in verbose mode for details but when I ran test_decimal manually it ran fine. Same thing for test_warnings: test test_warnings failed -- errors occurred in test.test_warnings.TestModule When I ran it manually it passed. Skip

3 3

TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
by Anthony Baxter 02 Apr '06

02 Apr '06

Now that the bug day has been and gone, it's time to cut 2.5a1. Please consider the trunk FROZEN from 00:00 UTC/GMT on Wednesday the 5th of April. I'll post again when it's unfrozen. Please help in not making the release manager cry because the trunk is broken. Thanks, Anthony

1 0

Re: [Python-Dev] Bug Day on Friday, 31st of March
by Delaney, Timothy (Tim) 02 Apr '06

02 Apr '06

Georg Brandl wrote: > Tim Peters wrote: >> [/F] >>> so, how did it go? a status report / summary would be nice, I >>> think ? > > 19 bugs, 9 patches (which were mostly created to fix one of the bugs). > Not much, but better than nothing and there has been quite a > participation > from "newbies". I've just added 1462485 and 1462700 to be assessed for commit. So make that 11 patches (although technically not finished on the day :) Tim Delaney

1 0