Mailman 3 August 2006 - Python-Dev

Questions on unittest behaviour
by Jim Jewett Aug. 21, 2006

Aug. 21, 2006

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. > … [View More]

1 0

uuid module - byte order issue
by Oren Tirosh Aug. 20, 2006

Aug. 20, 2006

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' &… [View More]

2 3

SSH Key Added
by Jackilyn Hoxworth Aug. 20, 2006

Aug. 20, 2006

Can I have this key added? -- Jackilyn Hoxworth

1 0

Questions on unittest behaviour
by Collin Winter Aug. 20, 2006

Aug. 20, 2006

[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, … [View More]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 [View Less]

3 4

os.spawnlp() missing on Windows in 2.4?
by Guido van Rossum Aug. 20, 2006

Aug. 20, 2006

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 Aug. 19, 2006

Aug. 19, 2006

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 … [View More]

3 2

One-line fix for urllib2 regression
by John J Lee Aug. 19, 2006

Aug. 19, 2006

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 Aug. 19, 2006

Aug. 19, 2006

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-… [View More]

1 1

Failed building 2.5rc1 pythoncore on VC8
by christopher baus Aug. 19, 2006

Aug. 19, 2006

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 Aug. 18, 2006

Aug. 18, 2006

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 … [View More]

2 2