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,
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:
>
>
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
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.
>
> De
[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
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(), sp
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 irre
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 no
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/)
___
Pyth
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:
h
> 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
Python-Dev@python.org
http://mail.python
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-00A0C
> 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.vcp
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
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
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
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 exte
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
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 w
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
"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
"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 approxima
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
___
P
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
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
25 matches
Mail list logo
