Re: [Python-Dev] 2.4 & 2.5 beta 3 crash
I did something similar to what Andrew suggested.
http://python.org/sf/1542451
Could everyone interested take a look and offer more test cases?
n
--
On 8/17/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 18, 2006 at 12:26:33AM +0200, Armin Rigo wrote:
> > Without more inspection, I'd say that this looks like it won't do the
> > right thing about nested finally's, as in:
>
> I guess it'll have to loop back up through the block stack:
>
> for (j=i- 1; j>=0; j--) {
>switch (c->u->u_fblock[j].fb_type) {
> case FINALLY_TRY:
>raise error;
> case LOOP:
>j=0; /* Exit the loop */
>break;
> default:
>break;
> }
> }
>
> --amk
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __del__ unexpectedly being called twice
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/293acf433a39583b/bfd4af9c6008a34e ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 & 2.5 beta 3 crash
Neal Norwitz wrote: > I did something similar to what Andrew suggested. > > http://python.org/sf/1542451 > > Could everyone interested take a look and offer more test cases? > Note that this needs to be fixed in the compiler package too. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ unexpectedly being called twice
"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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. Should we assume you meant 2.4 and 2.5? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ unexpectedly being called twice
"Terry Reedy" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > > "Duncan Booth" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> 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. > > Should we assume you meant 2.4 and 2.5? > Probably. 2.5b3 to be a bit more precise. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes and win64
The _ctypes extension module does currently not even build on Win64. I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently. The win64 msi installer installs the ctypes package anyway, but it cannot be imported. I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package. Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
Thomas Heller schrieb: > I suggest that it should be removed from the 2.5 win64 msi installers, so that > at least, when it is ready, can be installed as separate package. Unfortunately, I won't be able to work on this until the release is made. Feel free to work on it, but I suggest to just not worry about it. There are many other problems with Win64 still, e.g. the test suite doesn't pass. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> I suggest that it should be removed from the 2.5 win64 msi installers, so >> that >> at least, when it is ready, can be installed as separate package. > > Unfortunately, I won't be able to work on this until the release is > made. Feel free to work on it, but I suggest to just not worry about > it. > > There are many other problems with Win64 still, e.g. the test suite > doesn't pass. And tons of compiler warnings, IIRC. If the state is still experimental, IMO it should be marked as such. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed building 2.5rc1 pythoncore on VC8
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How does this help? Re: [Python-checkins] r51366 - python/trunk/Lib/idlelib/NEWS.txt python/trunk/Lib/idlelib/idlever.py
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 <[EMAIL PROTECTED]> 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" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed building 2.5rc1 pythoncore on VC8
VC8 is not a supported compiler at this point. However, patches are greatly accepted. The _types module was added late and probably VC6 and VC8 project files did not get updated. You can search for the necessary mods to the VC7 proj file(s) on python-checkins. n -- On 8/18/06, christopher baus <[EMAIL PROTECTED]> wrote: > 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 > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
Thomas Heller schrieb: >> There are many other problems with Win64 still, e.g. the test suite >> doesn't pass. > > And tons of compiler warnings, IIRC. If the state is still experimental, > IMO it should be marked as such. Most of the compiler warnings are irrelevant for most of the applications, and some are bogus (in the sense that the code is perfectly fine as it stands). Not sure what "experimental" would mean; it normally means that it may change or may be abandoned as a failure. I don't think this is the case with this port (although I do want to drop IA-64 binaries in 2.6, due to lack of interest). If you think it means "has known bugs", then this applies to all Python releases on all target systems, ever (just look at the open bugs list). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed building 2.5rc1 pythoncore on VC8
> VC8 is not a supported compiler at this point. However, patches are > greatly accepted. > > The _types module was added late and probably VC6 and VC8 project > files did not get updated. You can search for the necessary mods to > the VC7 proj file(s) on python-checkins. > Index: pythoncore.vcproj === --- pythoncore.vcproj (revision 1020) +++ pythoncore.vcproj (working copy) @@ -1,7 +1,7 @@ + + ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] patch to add socket module project to vc8 solution
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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch to add socket module project to vc8 solution
> This is a patch to add the socket module project to the vc8 solution. > Sorry the patch got munged by my mail client. I attached it instead. addsocket.patch Description: Binary data ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] One-line fix for urllib2 regression
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.spawnlp() missing on Windows in 2.4?
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/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.spawnlp() missing on Windows in 2.4?
Guido van Rossum wrote: > 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. :-) > "Availability: Unix, Windows. spawnlp(), spawnlpe(), spawnvp() and spawnvpe() are not available on Windows. New in version 1.6." One could argue that it presented poorly, but it reads completely correct. Alternatively one could says "The 'p' variants are unavailable on Windows." but that would be assuming someone understand there was a scheme to the names :-) -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
Martin v. Löwis wrote: > Thomas Heller schrieb: > >>>There are many other problems with Win64 still, e.g. the test suite >>>doesn't pass. >> >>And tons of compiler warnings, IIRC. If the state is still experimental, >>IMO it should be marked as such. > > > Most of the compiler warnings are irrelevant for most of the > applications, and some are bogus (in the sense that the code > is perfectly fine as it stands). > > Not sure what "experimental" would mean; it normally means > that it may change or may be abandoned as a failure. I don't > think this is the case with this port (although I do want > to drop IA-64 binaries in 2.6, due to lack of interest). > > If you think it means "has known bugs", then this applies to > all Python releases on all target systems, ever (just look > at the open bugs list). > Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is), and that the developers would therefore expect a higher proportion of bug reports on this release to be associated with those platforms. Committed to fixing, blah blah blah ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.spawnlp() missing on Windows in 2.4?
Scott Dial wrote: > Guido van Rossum wrote: > >>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. :-) >> > > > "Availability: Unix, Windows. spawnlp(), spawnlpe(), spawnvp() and > spawnvpe() are not available on Windows. New in version 1.6." > > One could argue that it presented poorly, but it reads completely > correct. Alternatively one could says "The 'p' variants are unavailable > on Windows." but that would be assuming someone understand there was a > scheme to the names :-) > How about: "Availability: Unix; Windows PARTIAL (spawnlp(), spawnlpe(), spawnvp() and spawnvpe() are not implemented). New in version 1.6" regards Steve PS: It's not resting, it has gone to meet its maker. It has joined the choir celestial, it has shuffled off this mortal coil, its clock has ceased to cycle, it is no more, it is an X-box. Oh, sorry, that's a Microsoft product isn't it. -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Questions on unittest behaviour
[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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line fix for urllib2 regression
John J Lee wrote: > 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? As the committer of the original patch, I have reviewed it and I'm for it. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
Steve Holden schrieb: > Reasonable enough, but I suspect that Thomas' suggestion might save us > from raising false hopes. I'd suggest that the final release > announcement point out that this is the first release containing > specific support for 64-bit architectures (if indeed it is) It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), and was released for Win64 throughout Python 2.4. ActiveState has been releasing an AMD64 package for some time now. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions on unittest behaviour
Collin Winter wrote: > [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. On this point, I believe the current behaviour is correct and should be kept. If setUp() fails internally (such that the test step isn't going to be run) it needs to cleanup after itself, just like any other function. That way, the tearDown() method is allowed to assume that setUp() succeeded completely, instead of having to guard against the possibility that setUp() may have died partway through. IOW, I consider the setUp() method in your example to be buggy. It should be written something like this: def setUp(self) lock_file(testfile) # open_socket(), connect_to_database(), etc try: something_that_may_raise_an_exception() except: unlock_file(testfile) raise def tearDown(self): unlock_file(testfile) Alternatively, someone who prefers your style (with a tearDown() method that can handle a partially executed call to the setUp() method), can just write it as: def setUp(self) try: lock_file(testfile) # open_socket(), connect_to_database(), etc something_that_may_raise_an_exception() except: self.tearDown() raise def tearDown(self): if file_is_locked(testfile): unlock_file(testfile) Consider the parallel to PEP 343's __enter__ and __exit__ methods - __exit__ is allowed to assume that it will only be called if __enter__ succeeded, because that is part of the semantics of the with statement. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions on unittest behaviour
On 8/19/06, Collin Winter <[EMAIL PROTECTED]> wrote: > 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) > > 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. > Most existing tearDown() code assumes that setUp() has been successfully called -- after all, that's what the docs say. It's also the behaviour of other xUnit frameworks. If this change is made, people will have to go through their tearDown() methods and add checks like the one in your example in order to make their tests correct. Further, it won't be obvious that their tearDown() methods are incorrect until something happens to make their setUp() methods incorrect. I don't think this change is a good one. However, if it does go in, it definitely shouldn't go in as a bug fix. cheers, jml ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
