Mailman 3 August 2006 - Python-Dev

Questions on unittest behaviour
by Jim Jewett 21 Aug '06

21 Aug '06

Collin Winter: > [ improvements to unittest] These would all have been (mostly) reasonable when the module was first added to the standard library. But it has been there as an ugly fragile unchanging beast for several years, and is ironically not well endowed with unit tests. I therefore think it might be too late for these changes. > 2) The TestLoader.testMethodPrefix attribute currently allows anything > to be assigned to it, including invalid objects and the empty string. > While the former will cause errors ... you get things like assertEqual(), > failUnlessEqual(), etc, when TestLoader.loadTestsFromTestCase() is run. It makes the interface ugly, and learning harder, but for code this old, either people catch it with the first actual run of their tests suites, or a subclass is handling it (perhaps to trigger a default, or to call functions through a foreign interface). > 3) TestLoader.loadTestsFromTestCase() accepts objects that are not > test cases and will happily look for appropriately-named methods on > any object you give it. This flexibility should be documented, or > proper input validation should be done (a bug fix for 2.5). People are probably using this, so I think a deprecation in 2.6 is the fastest it should change. > 4) TestLoader.loadTestsFromName() (and by extension, > loadTestsFromNames(), too) raises an AttributeError if the name is the > empty string because -- as it correctly asserts -- the object does not > contain an attribute named ''. I recommend that this be tested for and > ValueError be raised (bug fix for 2.5). This seems reasonable for new code, but not this late in 2.5 -- if people are going through an auto-generated list of attributes, they may well be catching AttributeError and not ValueError. > 5) When TestLoader.loadTestsFrom{Name,Names}() are given a name that > resolves to a classmethod on a TestCase subclass, the method is not > invoked. ... > It is not documented which of these tests takes priority: is the > classmethod "a test method within a test case class" or is it a > callable? The same issue applies to staticmethods as well. Documentation probably should get added. -jJ

1 0

uuid module - byte order issue
by Oren Tirosh 20 Aug '06

20 Aug '06

The UUID module uses network byte order, regardless of the platform byte order. On little-endian platforms like Windows the ".bytes" property of UUID objects is not compatible with the memory layout of UUIDs: >>> import uuid >>> import pywintypes >>> s = '{00112233-4455-6677-8899-aabbccddeeff}' >>> uuid.UUID(s).bytes.encode('hex') '00112233445566778899aabbccddeeff' >>> str(buffer(pywintypes.IID(s))).encode('hex') '33221100554477668899aabbccddeeff' >>> Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC 4122 compliant and have an illegal version field. If the correct byte order is used the UUIDs generated by Windows XP are valid version 4 UUIDs: >>> parts = struct.unpack('<LHH8s', pywintypes.CreateGuid()) >>> parts[2] >> 12 # version 4 >>> ord(parts[3][0]) & 0xC0 # variant 128 The first three fields (32 bit time-low, 16 bit time-mid and time-high-and-version) are stored in the platform byte order while the remainder is stored as a vector of 8 bytes. The bytes property and bytes argument to the constructor should use the platform byte order. It would be nice to have explicit little endian and big endian versions available on platforms of either endianness for compatibility in communication and disk formats. There is another issue with version 1 uuid generation: >>> len(set(uuid.uuid1() for i in range(1000))) 992 The problem is that the random clock_seq field is only 14 bits long. If enough UUIDs are generated within the same system clock tick there will be collisions. Suggested solution: use the high-resolution of the time field (100ns) to generate a monotonically increasing timestamp that advances at least by 1 for each call, when time.time() returns the same value on subsequent calls. Oren [*] http://mail.python.org/pipermail/python-dev/2006-June/065869.html

2 3

SSH Key Added
by Jackilyn Hoxworth 20 Aug '06

20 Aug '06

Can I have this key added? -- Jackilyn Hoxworth

1 0

Questions on unittest behaviour
by Collin Winter 19 Aug '06

19 Aug '06

[Sorry for accidentally cross-posting this to python-list] While working on a test suite for unittest these past few weeks, I've run across some behaviours that, while not obviously wrong, don't strike me as quite right, either. Submitted for your consideration: 1) TestCase.tearDown() is only run if TestCase.setUp() succeeded. It seems to me that tearDown() should always be run, regardless of any failures in setUp() or the test method itself. The case I'm considering is something like this, ie, a multi-part setUp(): > def setUp(self) > lock_file(testfile) # open_socket(), connect_to_database(), etc > > something_that_raises_an_exception() > > def tearDown(self): > if file_is_locked(testfile): > unlock_file(testfile) In this pseudo-code example, the file won't be unlocked if some later operation in setUp() raises an exception. I propose that TestCase.run() be changed to always run tearDown(), even if setUp() raise an exception. I'm undecided if this is a new feature (so it should go in for 2.6) or a bug fix; I'm leaning toward the latter. 2) The TestLoader.testMethodPrefix attribute currently allows anything to be assigned to it, including invalid objects and the empty string. While the former will cause errors to be raised when one of TestLoader's loadTestsFrom*() methods is called, the empty string will raise no exception; rather, the loadTestsFrom*() methods will interpret every possible attribute as being a test method, e.g., meaning you get things like assertEqual(), failUnlessEqual(), etc, when TestLoader.loadTestsFromTestCase() is run. I propose protecting testMethodPrefix with a property that validates the assigned value, restricting input to non-empty instances of str. I see this as a bug fix that should go in before 2.5-final. 3) TestLoader.loadTestsFromTestCase() accepts objects that are not test cases and will happily look for appropriately-named methods on any object you give it. This flexibility should be documented, or proper input validation should be done (a bug fix for 2.5). 4) TestLoader.loadTestsFromName() (and by extension, loadTestsFromNames(), too) raises an AttributeError if the name is the empty string because -- as it correctly asserts -- the object does not contain an attribute named ''. I recommend that this be tested for and ValueError be raised (bug fix for 2.5). This of course leads into the question of how much input validation should be done on these names. Should loadTestsFrom{Name,Names}() make sure the names are valid attribute names, or is this overkill? 5) When TestLoader.loadTestsFrom{Name,Names}() are given a name that resolves to a classmethod on a TestCase subclass, the method is not invoked. From the docs: > The specifier name is a ``dotted name'' that may resolve either to a module, a test > case class, a TestSuite instance, a test method within a test case class, or a > callable object which returns a TestCase or TestSuite instance. It is not documented which of these tests takes priority: is the classmethod "a test method within a test case class" or is it a callable? The same issue applies to staticmethods as well. Once I get answers to these questions, I can finish off the last few bits of the test suite and have it ready for 2.5-final. Thanks, Collin Winter

3 4

os.spawnlp() missing on Windows in 2.4?
by Guido van Rossum 19 Aug '06

19 Aug '06

I just got a report from a Windows user that os.spawnlp() is missing from Python 2.4, despite being mentioned in the docs. Can someone confirm this? My Windows box is resting. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

5 4

How does this help? Re: [Python-checkins] r51366 - python/trunk/Lib/idlelib/NEWS.txt python/trunk/Lib/idlelib/idlever.py
by Jim Jewett 19 Aug '06

19 Aug '06

This makes things more consistent for today, but does it really ease maintenance? Why not just change it to: from sys import version as IDLE_VERSION so that it can be ignored from now on? On 8/18/06, anthony.baxter <python-checkins(a)python.org> wrote: > Author: anthony.baxter > Date: Fri Aug 18 09:29:02 2006 > New Revision: 51366 > > Modified: > python/trunk/Lib/idlelib/NEWS.txt > python/trunk/Lib/idlelib/idlever.py > Log: > Updating IDLE's version number to match Python's (as per python-dev > discussion). ============================================================================== > --- python/trunk/Lib/idlelib/idlever.py (original) > +++ python/trunk/Lib/idlelib/idlever.py Fri Aug 18 09:29:02 2006 > @@ -1 +1 @@ > -IDLE_VERSION = "1.2c1" > +IDLE_VERSION = "2.6a0"

3 2

One-line fix for urllib2 regression
by John J Lee 19 Aug '06

19 Aug '06

Revision 50842 made a change to an undocumented interface of urllib2 that I'm sure will break real code. Patch 1542948 reverts the part of that commit that applied to urllib2, and adds a one-line fix in its place that addresses the problem that 50842 fixed. Details are on the patch tracker: http://python.org/sf/1542948 Can somebody commit this for 2.5? John

3 2

patch to add socket module project to vc8 solution
by christopher baus 19 Aug '06

19 Aug '06

This is a patch to add the socket module project to the vc8 solution. Index: pcbuild.sln =================================================================== --- pcbuild.sln (revision 1020) +++ pcbuild.sln (working copy) @@ -2,8 +2,8 @@ # Visual Studio 2005 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "pythoncore", "pythoncore.vcproj", "{CF7AC3D1-E2DF-41D2-BEA6-1E2556CDEA26}" ProjectSection(ProjectDependencies) = postProject + {F0E0541E-F17D-430B-97C4-93ADF0DD284E} = {F0E0541E-F17D-430B-97C4-93ADF0DD284E} {C73F0EC1-358B-4177-940F-0846AC8B04CD} = {C73F0EC1-358B-4177-940F-0846AC8B04CD} - {F0E0541E-F17D-430B-97C4-93ADF0DD284E} = {F0E0541E-F17D-430B-97C4-93ADF0DD284E} EndProjectSection EndProject Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "pythonw", "pythonw.vcproj", "{F4229CC3-873C-49AE-9729-DD308ED4CD4A}" @@ -70,6 +70,8 @@ EndProject Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "make_versioninfo", "make_versioninfo.vcproj", "{F0E0541E-F17D-430B-97C4-93ADF0DD284E}" EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "_socket", "_socket.vcproj", "{324F66C2-44D0-4D50-B979-F9DAE7FD36DB}" +EndProject Global GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Win32 = Debug|Win32 @@ -192,6 +194,14 @@ {F0E0541E-F17D-430B-97C4-93ADF0DD284E}.ReleaseAMD64|Win32.Build.0 = Release|Win32 {F0E0541E-F17D-430B-97C4-93ADF0DD284E}.ReleaseItanium|Win32.ActiveCfg = Release|Win32 {F0E0541E-F17D-430B-97C4-93ADF0DD284E}.ReleaseItanium|Win32.Build.0 = Release|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.Debug|Win32.ActiveCfg = Debug|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.Debug|Win32.Build.0 = Debug|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.Release|Win32.ActiveCfg = Release|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.Release|Win32.Build.0 = Release|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.ReleaseAMD64|Win32.ActiveCfg = ReleaseAMD64|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.ReleaseAMD64|Win32.Build.0 = ReleaseAMD64|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.ReleaseItanium|Win32.ActiveCfg = ReleaseItanium|Win32 + {324F66C2-44D0-4D50-B979-F9DAE7FD36DB}.ReleaseItanium|Win32.Build.0 = ReleaseItanium|Win32 EndGlobalSection GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE

1 1

Failed building 2.5rc1 pythoncore on VC8
by christopher baus 18 Aug '06

18 Aug '06

Hi, I downloaded RC1 to give it a go. I failed to build pythoncore with VC8. The error is: Linking... Creating library .\./python25_d.lib and object .\./python25_d.exp config.obj : error LNK2001: unresolved external symbol _init_types ./python25_d.dll : fatal error LNK1120: 1 unresolved externals Thanks, Chris

2 2

__del__ unexpectedly being called twice
by Duncan Booth 18 Aug '06

18 Aug '06

There's a thread on comp.lang.python at the moment under the subject "It is __del__ calling twice for some instances?" which seems to show that when releasing a long chain of old-style classes every 50th approximately has its finaliser called twice. I've verified that this happens on both Python 1.4 and 1.5. My guess is that there's a bug in the trashcan mechanism: calling the __del__ method means creating a descriptor, and if that descriptor gets queued in the trashcan then releasing it calls the __del__ method a second time. I'm not sure if there is going to be a particularly easy fix for that. Would someone who knows this code (instance_dealloc in classobject.c) like to have a look at it, should I just submit a bug report, or isn't it worth bothering about? The code which exhibits the problem: #!/usr/local/bin/python -d # -*- coding: koi8-u -*- import sys class foo: def __init__(self, other): self.other = other self._deleted = False global ini_cnt ini_cnt +=1 def __del__(self): if self._deleted: print "aargh!" self._deleted = True global del_cnt del_cnt +=1 print "del",del_cnt,"at",id(self) def stat(): print "-"*20 print "ini_cnt = %d" % ini_cnt print "del_cnt = %d" % del_cnt print "difference = %d" % (ini_cnt-del_cnt) ini_cnt = 0 del_cnt = 0 loop_cnt = 55 a = foo(None) for i in xrange(loop_cnt): a = foo(a) stat() a = None stat() The original thread is at: http://groups.google.com/group/comp.lang.python/browse_thread/thread/293acf…

2 2