On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden [EMAIL PROTECTED] wrote:
Tim Golden wrote:
Steven Bethard wrote:
At the sprints, I ran into a bunch of similar errors running the test
suite on my Windows Vista box, even on tests that were properly
cleaning up after themselves in tearDown(). I
def rename_and_remove (filename):
os.rename (filename, filename + .deleted)
os.remove (filename + .deleted)
Isn't this still going to run into problems when the rename
fails because the earlier tests remove still left the .deleted
file around due to some other running desktop search
Yes, that's all I meant: make it the committer's job
to merge or block as appropriate. I just wasn't sure if
there was some reason that this would be difficult or
undesirable.
Ah, yes. It is indeed difficult or undesirable, or was
so in the past: Some committers don't care (didn't
Further, I
assert that there are a greater number of build tools which do not support
cross-compilation, but will build natively on x64 and expect 'PCBuild'
to have libraries they can link with to create an x64 binary.
I'm with Martin on this one as well I think. If I understand correctly,
In the py3k branch I've assigned the audio resource to the winsound
tests. Only regrtest.py -uall or -uaudio runs the winsound test.
Reason:
the test sound was freaking out my poor cat. :/
I feel with your cat ;-).
This would not help on the buildbot since it runs 'rt.bat -d -q -uall -
Martin v. Löwis schrieb:
Can you please explain why this is an important problem?
Dates before 1900 have all passed long ago, so they shouldn't
occur that often in real applications.
Does xmlrpc support dates for 1900? For historic dates the Julian Day
Number family (MJD or JDN) or Rata Die
On Wed, Apr 2, 2008 at 9:58 AM, Trent Nelson [EMAIL PROTECTED] wrote:
In the py3k branch I've assigned the audio resource to the winsound
tests. Only regrtest.py -uall or -uaudio runs the winsound test.
Reason:
the test sound was freaking out my poor cat. :/
I feel with your
Nick Coghlan wrote:
Tim Golden wrote:
I admit: this did occur to me on the train this am. While I
try to think of a robust way to handle this, other people have
proposed variations on pid-based / tempdir based filenames instead
of the same name for each test. In principle this sounds good to
Tim Golden wrote:
I admit: this did occur to me on the train this am. While I
try to think of a robust way to handle this, other people have
proposed variations on pid-based / tempdir based filenames instead
of the same name for each test. In principle this sounds good to me,
but I'm not at
Trent Nelson schrieb:
I think holding a developer accountable for merging or blocking to py3k when
they commit to trunk is a great idea. Who better to pass judgement on such
an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure
Guido van Rossum guido at python.org writes:
Your solution (a counter) seems fine except I think perhaps the
close() call should not raise IOError -- instead, it should set a flag
so that the thread that makes the counter go to zero can close the
thread (after all the file got closed while it
On Wed, Apr 2, 2008 at 11:42 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Martin v. Löwis schrieb:
Can you please explain why this is an important problem?
Dates before 1900 have all passed long ago, so they shouldn't
occur that often in real applications.
In the application where I
Christian Heimes [mailto:[EMAIL PROTECTED]:
Trent Nelson schrieb:
I think holding a developer accountable for merging or blocking to
py3k when they commit to trunk is a great idea. Who better to pass
judgement on such an activity than the person closest to it?
Blocking a revision makes my
Looking into some of the recent Windows buildbot failures, I see things like
this:
sqlite3 : error PRJ0008 : Could not delete file
'c:\buildbot\trunk.heller-windows-amd64\build\PCbuild\amd64\sqlite3_d.dll'.
build-amd64.bat doesn't go through the kill_python.c hoopla, so I figure the
above
That'll kill the first python_d.exe instance it finds matching the
given path; given that our buildbots run trunk/release25-maint/py3k
in parallel
That's actually not a given: we currently *don't* run multiple builds
simultaneously on the same slave.
Unless anyone advises otherwise, I'll
On Wed, Apr 2, 2008 at 3:17 AM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Guido van Rossum guido at python.org writes:
Your solution (a counter) seems fine except I think perhaps the
close() call should not raise IOError -- instead, it should set a flag
so that the thread that makes the
Personally, I've never really understood the purpose of
test_support.TESTFN. Whenever I've needed a temporary file for a test, I
just use the tempfile module (e.g. test_cmd_line_script, test_runpy).
Tests using that module don't care if the old files take 'a while' to
get deleted on
That'll kill the first python_d.exe instance it finds matching the
given path; given that our buildbots run trunk/release25-maint/py3k
in parallel
That's actually not a given: we currently *don't* run multiple builds
simultaneously on the same slave.
I thought the slave lock only applied
On Wed, Apr 2, 2008 at 10:12 PM, Pree Raj [EMAIL PROTECTED] wrote:
Hi,
I have an application that used python on linux.
I want to port it to run on ThreadX.
Can you tell me if this can be possible.
If yes, how can I get started.
I managed to get Python to work under eCos, which is also a
Martin v. Löwis wrote:
Is using a fixed TESTFN just an old approach that predates the existence
of a robust tempfile module in the standard library?
No. I believe the rationale for TESTFN is to provide a fixed name,
precisely so that the test suite doesn't leave tons of garbage around.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a reminder that I am going to start building the next alpha
releases for Python 2.6 and 3.0 now. Please, no checkins unless you
get approval from me, and until you hear that the freeze is lifted.
I am now on freenode #python-dev, IM, and
I think this is fine; we don't really have a notion of compiling for a
native platform, nor is the build machine's architecture factored into
the equation.
Actually, I think it is slightly. IIUC, the AMD64 build currently assumes
it can execute x86 executables in various places. To fix this,
On Wed, Apr 2, 2008 at 8:36 PM, [EMAIL PROTECTED] wrote:
Ralf anyone care to take a look at:
Ralf http://bugs.python.org/issue2014
Ralf It's about xmlrpclib not being able to send datetime objects with
Ralf dates before 1900.
It's actually not xmlrpclib which has the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 2, 2008, at 6:00 PM, Barry Warsaw wrote:
This is a reminder that I am going to start building the next alpha
releases for Python 2.6 and 3.0 now. Please, no checkins unless you
get approval from me, and until you hear that the freeze
24 matches
Mail list logo
