Hi,
I added the -P command line option and the PYTHONSAFEPATH=1
environment variable to Python 3.11 beta 1 to not prepend an "unsafe
path" to sys.path such as the script's directory or the current
directory:
https://docs.python.org/dev/using/cmdline.html#cmdoption-P
Example:
--
$ echo 'N
I am new to open source and think to contribute to python .
I was going through the developer guide and when i run this code "./python -m
test -j3" on my terminal i got this result which say it fail .Now can someone
tell me this is normal or happning to me only . If this happen to everyone how
c
This is a mailing list for the development *of* Python, not *with* Python.
The best way to get help would be to email python-l...@python.org or
python-h...@python.org.
On Tue, Feb 4, 2014 at 10:15 AM, Milani Adelaide wrote:
> Dear support,
> we tried to install Phyton-3.3.3 but we got some prob
Dear support,
we tried to install Phyton-3.3.3 but we got some problems with "make test".
Test whatever failed.
We trid also "make testall" but we got:
Ran 45 tests in 7.897s
FAILED (failures=25, skipped=15)
test test_gdb failed
make: *** [testall] Errore 1
Please could you help us?
Thanks
A
On 1/13/2014 10:16 PM, MRAB wrote:
On 2014-01-14 03:03, Terry Reedy wrote:
On 1/13/2014 7:48 PM, Chris Angelico wrote:
And now for something completely different.
My root buildbot is finally now able to telnet out and get "Connection
refused" errors. (For the curious, the VirtualBox "NAT" mode
On Tue, Jan 14, 2014 at 2:16 PM, MRAB wrote:
> Alternatively:
>
> g = max(self.saved_groups, [1])
>
> or even:
>
> g = max(self.saved_groups or [1])
Patch created and tracker issue opened. I've used something similar to
MRAB's idea as it looks compact. Thanks all!
http://bugs.python.org/issue202
On Tue, Jan 14, 2014 at 2:03 PM, Terry Reedy wrote:
> On 1/13/2014 7:48 PM, Chris Angelico wrote:
>>
>> ValueError: max() arg is an empty sequence
>
>
> try:
>
> g = max(self.saved_groups) + 1
> except ValueError:
> g = 1
>
>
> Unless someone says that it is a bug for posix.getgroups to return
On Tue, Jan 14, 2014 at 2:14 PM, Zachary Ware
wrote:
> On Mon, Jan 13, 2014 at 6:48 PM, Chris Angelico wrote:
>> And secondly, how can I run the tests manually? I can't find a binary
>> inside the buildarea tree. Does it get deleted afterward?
>
> Yes, that's the 'clean' step of the buildbot buil
On 2014-01-14 03:03, Terry Reedy wrote:
On 1/13/2014 7:48 PM, Chris Angelico wrote:
And now for something completely different.
My root buildbot is finally now able to telnet out and get "Connection
refused" errors. (For the curious, the VirtualBox "NAT" mode doesn't
work properly, but the new
On Mon, Jan 13, 2014 at 6:48 PM, Chris Angelico wrote:
> And secondly, how can I run the tests manually? I can't find a binary
> inside the buildarea tree. Does it get deleted afterward?
Yes, that's the 'clean' step of the buildbot build process. I'd
suggest making another clone elsewhere (you c
On 1/13/2014 7:48 PM, Chris Angelico wrote:
And now for something completely different.
My root buildbot is finally now able to telnet out and get "Connection
refused" errors. (For the curious, the VirtualBox "NAT" mode doesn't
work properly, but the new "NAT Network" mode does. Why? I have no
i
And now for something completely different.
My root buildbot is finally now able to telnet out and get "Connection
refused" errors. (For the curious, the VirtualBox "NAT" mode doesn't
work properly, but the new "NAT Network" mode does. Why? I have no
idea. But if anyone else is having the same pro
On 29 Aug 2013 02:34, "Serhiy Storchaka" wrote:
>
> 28.08.13 14:37, Victor Stinner написав(ла):
>
>> No, my question is: how can we detect that a test is never run? Do we
>> need test covertage on the test suite? Or inject faults in the code to
>> test the test suite? Any other idea?
>
>
> Current
28.08.13 14:37, Victor Stinner написав(ла):
No, my question is: how can we detect that a test is never run? Do we
need test covertage on the test suite? Or inject faults in the code to
test the test suite? Any other idea?
Currently a lot of tests are skipped silently. See issue18702 [1].
Perha
It happens that few tests are also never run because of name conflicts.
See issue 16056.
Xavier
On Wed, Aug 28, 2013 at 1:37 PM, Victor Stinner
wrote:
> Hi,
>
> I just noticed that tests using @requires_freebsd_version and
> @requires_linux_version decorator from test.support are never run
> sin
Hi,
I just noticed that tests using @requires_freebsd_version and
@requires_linux_version decorator from test.support are never run
since this commit (almost 2 years ago):
changeset: 72618:3b1859f80e6d
user:Charles-François Natali
date:Mon Oct 03 19:40:37 2011 +0200
files:
Yes, this is question is for python-li...@python.org
On Fri, Jan 4, 2013 at 2:59 PM, Elli Lola wrote:
> $ ./python -m test -v test_urlwithfrag
Where did you get this command from? It looks to me to me that more than
one person is trying the exact same command experiencing the same failure
(exp
On 1/4/2013 5:59 PM, Elli Lola wrote:
Dear python team,
I never used python before and installed it today the first time, so I
have no idea what to do about this failure:
This current-version usage question should have been directed to
python-list. pydev is only for discussion of future versi
Dear python team,I never used python before and installed it today the first time, so I have no idea what to do about this failure:$ ./python -m test -v test_urlwithfrag== CPython 3.3.0 (default, Jan 4 2013, 23:08:00) [GCC 4.6.3]== Linux-3.2.0-35-generic-pae-i686-with-debian-wheezy-sid little-end
Hi,
2011/10/11 Vinay Sajip :
> AssertionError: b"Fatal Python error: PyThreadState_Get: no current
> thread\n\r\n
> This application has requested the Runtime to terminate it in an unusual
> way.\nP
> lease contact the application's support team for more information." !=
> b'Fatal P
> ython err
Vinay Sajip wrote:
> test test_capi failed -- Traceback (most recent call last):
> test test_faulthandler failed -- Traceback (most recent call last):
The tests call abort(), and the handling on Windows is slightly
peculiar. See:
http://bugs.python.org/issue9116
http://bugs.python.org/issue11732
I just cloned and built CPython default on Windows 7 32-bit (in a VM). The build
was successful, but I get crashes when running the regression tests:
test test_capi failed -- Traceback (most recent call last):
File "C:\Users\Vinay\Projects\cpython\lib\test\test_capi.py", line 51, in test
_no_Fat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/03/11 18:27, Antoine Pitrou wrote:
> On Wed, 30 Mar 2011 18:11:53 +0200
> Victor Stinner wrote:
>> Le mercredi 30 mars 2011 à 17:59 +0200, Victor Stinner a écrit :
>>> I'm testing my faulthandler repository on the custom buildbots, here are
>>>
On 15/04/2011 17:49, Martin (gzlist) wrote:
On 14/04/2011, Michael Foord wrote:
I'd be interested to know what is keeping the tests alive even when the
test suite isn't. As far as I know there is nothing else in unittest
that would do that.
The main cause is some handy code for collecting and
On 14/04/2011, Michael Foord wrote:
> I'd be interested to know what is keeping the tests alive even when the
> test suite isn't. As far as I know there is nothing else in unittest
> that would do that.
The main cause is some handy code for collecting and filtering tests
by name, which unintentio
On 14/04/2011 00:23, Martin (gzlist) wrote:
On 07/04/2011, Michael Foord wrote:
On 07/04/2011 20:18, Robert Collins wrote:
Testtools did something to address this problem, but I forget what it
was offhand.
Some issues were worked around, but I don't remember any comprehensive solution.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/14/2011 1:23 AM, Martin (gzlist) wrote:
> On 07/04/2011, Michael Foord wrote:
>> On 07/04/2011 20:18, Robert Collins wrote:
>>>
>>> Testtools did something to address this problem, but I forget what it
>>> was offhand.
>
> Some issues were worke
On 07/04/2011, Michael Foord wrote:
> On 07/04/2011 20:18, Robert Collins wrote:
>>
>> Testtools did something to address this problem, but I forget what it
>> was offhand.
Some issues were worked around, but I don't remember any comprehensive solution.
> The proposed "fix" is to make test suite
On 08/04/2011 02:10, Robert Collins wrote:
On Fri, Apr 8, 2011 at 8:12 AM, Michael Foord wrote:
On 07/04/2011 20:18, Robert Collins wrote:
On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord
wrote:
You mean that the test run keeps the test instances alive for the whole
test
run so instance attrib
On Fri, Apr 8, 2011 at 8:12 AM, Michael Foord wrote:
> On 07/04/2011 20:18, Robert Collins wrote:
>>
>> On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord
>> wrote:
>>>
>>> You mean that the test run keeps the test instances alive for the whole
>>> test
>>> run so instance attributes are also kept ali
On 07/04/2011 20:18, Robert Collins wrote:
On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord wrote:
You mean that the test run keeps the test instances alive for the whole test
run so instance attributes are also kept alive. How would you solve this -
by having calling a TestSuite (which is how a t
On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord wrote:
> You mean that the test run keeps the test instances alive for the whole test
> run so instance attributes are also kept alive. How would you solve this -
> by having calling a TestSuite (which is how a test run is executed) remove
> members fr
On 07/04/2011 17:18, Fabio Zadrozny wrote:
I actually created a bug entry for this
(http://bugs.python.org/issue11798) and just later it occurred that I
should've asked in the list first :)
So, here's the text for opinions:
Right now, when doing a test case, one must clear all the variables
cre
I actually created a bug entry for this
(http://bugs.python.org/issue11798) and just later it occurred that I
should've asked in the list first :)
So, here's the text for opinions:
Right now, when doing a test case, one must clear all the variables
created in the test class, and I believe this sh
On Wed, 30 Mar 2011 18:11:53 +0200
Victor Stinner wrote:
> Le mercredi 30 mars 2011 à 17:59 +0200, Victor Stinner a écrit :
> > I'm testing my faulthandler repository on the custom buildbots, here are
> > some remarks and issues.
>
> Oh, I forgot something: there is an error on hg purge.
[...]
I
Le mercredi 30 mars 2011 à 17:59 +0200, Victor Stinner a écrit :
> I'm testing my faulthandler repository on the custom buildbots, here are
> some remarks and issues.
Oh, I forgot something: there is an error on hg purge.
Example on a Windows buildbot:
C:\Program Files\Mercurial\hg.EXE purge
On Wed, 30 Mar 2011 17:59:02 +0200
Victor Stinner wrote:
>
> I cannot write "#" in the branch field to specify... the branch (only
> the repository). If the branch contains "#", the request looks to be
> ignored (without any warning/error). I merged my faulthandler branch
> into the default branc
Hi,
I'm testing my faulthandler repository on the custom buildbots, here are
some remarks and issues.
The form still refers to SVN ('Branch to build' is relative to
http://svn.python.org/projects/python.) => the branch is relative to
hg.python.org/
I cannot write "#" in the branch field to speci
On Sat, 5 Feb 2011 18:39:21 +
Paul Moore wrote:
> I've not seen any python-dev mails for a day or so. Is there a problem
> with the list?
I think it's just that nobody posted.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
ht
I've not seen any python-dev mails for a day or so. Is there a problem
with the list?
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
Chris Withers schrieb:
> Hi All,
>
> Anyone know what's causing this failure?
>
> test test___all__ failed -- Traceback (most recent call last):
>File "Lib/test/test___all__.py", line 106, in test_all
> self.check_all("profile")
>File "Lib/test/test___all__.py", line 23, in check_all
Hi All,
Anyone know what's causing this failure?
test test___all__ failed -- Traceback (most recent call last):
File "Lib/test/test___all__.py", line 106, in test_all
self.check_all("profile")
File "Lib/test/test___all__.py", line 23, in check_all
exec("from %s import *" % modname, n
Some of my messages appear not to have gotten through.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mai
On Sat, 11 Apr 2009 at 21:10, Nick Coghlan wrote:
Chris Withers wrote:
Hi All,
Got these when running from checkout on Mac OS:
Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it
...
test test_asynchat produced unexpected output:
***
Chris Withers wrote:
> Hi All,
>
> Got these when running from checkout on Mac OS:
>
> Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it
> ...
> test test_asynchat produced unexpected output:
> **
> error: unca
Mark Dickinson wrote:
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers wrote:
Also got the following failure from a py3k checkout:
test test_cmd_line failed -- Traceback (most recent call last):
File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in
test_run_code
0)
AssertionError
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers wrote:
> Also got the following failure from a py3k checkout:
>
> test test_cmd_line failed -- Traceback (most recent call last):
> File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in
> test_run_code
> 0)
> AssertionError: 1 != 0
Ar
Hi All,
Also got the following failure from a py3k checkout:
test test_cmd_line failed -- Traceback (most recent call last):
File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in
test_run_code
0)
AssertionError: 1 != 0
Should I expect this or does someone owe beer? ;-)
Chris
Hi All,
Got these when running from checkout on Mac OS:
Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it
...
test test_asynchat produced unexpected output:
**
error: uncaptured python exception, closing chann
Kristján Valur Jónsson writes:
> But again, it shows how useful assertions can be and why we ought
> not to disable them.
Note that just to be clear, I'm certainly not advocating the disabling
of CRT assertions - just the redirection of them so they don't prevent
unattended test runs from comple
"Martin v. Löwis" writes:
> Notice, however, that the feature was never present in the trunk.
Yep - would be nice if it were to get backported to trunk at some
point but that's a separate discussion ... presumably at some point
py3k will be the trunk anyway, and for better or worst (perhaps due
Kristján Valur Jónsson
Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen;
python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?
Does it need to be backported? I wonder when that was introduced.
Also, what CL was it so I can review it?
2009/3/31 Kristján Valur Jónsso
I guess I'll stop asking after this note, but can anyone give a final
verdict on whether the older "-n" option can be restored to the
buildbot test.bat (from the revision history I'm not actually sure it
was intentionally removed in the first place)?
I have now restored it; it was removed by an
t; Sent: 31. mars 2009 21:31
> To: Kristján Valur Jónsson
> Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen;
> python-dev@python.org
> Subject: Re: [Python-Dev] Test failures under Windows?
>
> 2009/3/31 Kristján Valur Jónsson :
>> Right, my question to micros
submission to the py3k branch.
K
-Original Message-
From: Jesse Noller [mailto:jnol...@gmail.com]
Sent: 31. mars 2009 21:31
To: Kristján Valur Jónsson
Cc: Curt Hagenlocher; mhamm...@skippinet.com.au; David Bolen;
python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows
2009/3/31 Kristján Valur Jónsson :
> Right, my question to microsoft was more about making sure that a
> __crtMessageBox() actually does nothing, when running unattended as a service.
>
> Also, we should be seeing the same problem in non-debug versions, since the
> _set_invalid_parameter_handler(
On Tue, Mar 31, 2009 at 4:07 PM, David Bolen wrote:
> Kristján Valur Jónsson writes:
>
>> Btw, I am working on finding out the test suite failures for
>> test_multiprocessing.
>
> This is all well and good, but I still haven't seen any plausible
> reason for not preventing these popups (in favor
Kristján Valur Jónsson writes:
> Btw, I am working on finding out the test suite failures for
> test_multiprocessing.
This is all well and good, but I still haven't seen any plausible
reason for not preventing these popups (in favor of stderr failures)
during buildbot test runs? I don't get it
Kristján Valur Jónsson wrote:
Btw, I am working on finding out the test suite failures for
test_multiprocessing.
Some of those are caused by force builds on a branch, so make sure the
errors are still occurring before you put too much effort into this. We
made the branch before some recent f
es for
test_multiprocessing.
K
-Original Message-
From: Curt Hagenlocher [mailto:c...@hagenlocher.org]
Sent: 25. mars 2009 12:54
To: Kristján Valur Jónsson
Cc: mhamm...@skippinet.com.au; David Bolen; python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?
2009/3/25 Kristján
Hirokazu Yamamoto writes:
> CRT Assertion was totally disabled before, but recently was enabled,
> and workarounds were patched for problematic functions. (ex: fdopen
> and dup) Probably this *patch* is not perfect. See
> http://bugs.python.org/issue4804
Ah - that ticket may explain why my build
David Bolen wrote:
I don't know why they are happening so frequently now when there was a
reasonable period when they weren't an issue (something about new I/O
support in 3.x perhaps?), but without preventing them it seems the
Windows build slaves are going to become (if not already) quite a bit
David Bolen writes:
>>From what I can see though, the tools/buildbot/test.bat file no longer
> adds the -n option that it used to, although I'm unclear on why it
> might have been removed. Perhaps this was just a regression that was
> accidentally missed, as it appears to have disappeared during
Curt Hagenlocher writes:
> The variation that goes through assert.c should write to stderr for a
> console-mode application, so it's reasonable to assume that we're
> hitting the other code path -- and that Mark's suggestion to use
> CrtSetReportMode would address the issue.
Which is pretty much
2009/3/25 Kristján Valur Jónsson :
>
> I'm going to poke my contacts at Microsoft and ask them if there is
> a way to disable popups like this for a process that runs unattended
> and/or is running as a windows service.
MSVC has shipped with runtime library source since the 16-bit days, so
the eas
I'm going to poke my contacts at Microsoft and ask them if there is a way to
disable popups like this for a process that runs unattended and/or is running
as a windows service.
There is, and Curt pointed out one strategy for achieving this without
losing the checks it provides...
> Curt's
On 25/03/2009 7:58 PM, David Bolen wrote:
Mark Hammond writes:
The issue was that Python unconditionally changed the behaviour of the
CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007.
I was referring to t
ev-bounces+kristjan=ccpgames@python.org] On Behalf Of Mark
Hammond
Sent: 25. mars 2009 08:44
To: David Bolen
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?
On 25/03/2009 10:05 AM, David Bolen wrote:
> Kristján Valur Jónsson writes:
>
>> Now, I know that t
Mark Hammond writes:
> The issue was that Python unconditionally changed the behaviour of the
> CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007. It appeared to just add access to the
necessary functions in th
On 25/03/2009 10:05 AM, David Bolen wrote:
Kristján Valur Jónsson writes:
Now, I know that this msvc behaviour can be disabled, but it was
decided that it was not appropriate to meddle with runtime flags of
the whole process for python.
I must have missed that discussion, but I can't see wha
Kristján Valur Jónsson writes:
> Now, I know that this msvc behaviour can be disabled, but it was
> decided that it was not appropriate to meddle with runtime flags of
> the whole process for python.
I must have missed that discussion, but I can't see what the problem
is if such an override only
> Note that I previously opened http://bugs.python.org/issue5116 with a
> patch to enable this to be controlled from Python via the msvcrt module.
> This would enable the test suite to disable assertions for its entire run.
This patch is fine with me. It might need some documentation, though.
Ho
On Tue, Mar 24, 2009 at 3:45 PM, Antoine Pitrou wrote:
> Mark Hammond gmail.com> writes:
>>
>> Note that I previously opened http://bugs.python.org/issue5116 with a
>> patch to enable this to be controlled from Python via the msvcrt module.
>> This would enable the test suite to disable asserti
Mark Hammond gmail.com> writes:
>
> Note that I previously opened http://bugs.python.org/issue5116 with a
> patch to enable this to be controlled from Python via the msvcrt module.
> This would enable the test suite to disable assertions for its entire run.
We certainly don't want to disable
On 25/03/2009 7:34 AM, "Martin v. Löwis" wrote:
I don't quite remember the -n flag, but I believe that Kristjan
just removed all that stuff, ie. there is now no way to block
CRT assertions anymore.
I
wasn't paying close attention, so maybe there's some other mechanism
in place at this point?
@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Curt
Hagenlocher
Sent: 24. mars 2009 19:14
To: David Bolen
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?
On Tue, Mar 24, 2009 at 11:49 AM, David Bolen wrote:
>
> Kristján
> There was a discussion about this on the py3k mailing list back in
> mid-2007 ("buildbots" thread) and perhaps later as well, at which
> point I believe Martin added an "-n" option to regrtest and the
> buildbot test.bat file to disable the assertions. Is that the py3k
> branch piece you are ref
On Tue, Mar 24, 2009 at 11:49 AM, David Bolen wrote:
>
> Kristján Valur Jónsson writes:
>
>> These issues should be resolved in the py3k branch, but it will need
>> porting to 2.6. Dialogue boxes are annoying, but do they pop up if
>> you run your buildslave as a service without access to the co
Kristján Valur Jónsson writes:
> These issues should be resolved in the py3k branch, but it will need
> porting to 2.6. Dialogue boxes are annoying, but do they pop up if
> you run your buildslave as a service without access to the console?
Not sure what the MSVC++ runtime does with assertion d
David Bolen gmail.com> writes:
>
> Antoine Pitrou pitrou.net> writes:
>
> > Am I the only one getting those?
> > By the way, what happened to the Windows buildbots?
>
> Oops - sorry, mine (XP-4) apparently got stuck with C++ debug
> assertion dialogs (an assertion from the internal close.c mod
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of David
Bolen
Sent: 24. mars 2009 18:02
To: python-dev@python.org
Subject: Re: [Python-Dev] Test failures under Windows?
Antoine Pitrou writes:
> Am I the only one getting those?
> By the way, what happened to the W
Antoine Pitrou writes:
> Am I the only one getting those?
> By the way, what happened to the Windows buildbots?
Oops - sorry, mine (XP-4) apparently got stuck with C++ debug
assertion dialogs (an assertion from the internal close.c module) from
python_d during some earlier build. I try to catch
On Tue, 24 Mar 2009 13:49:28 + (UTC), Antoine Pitrou
wrote:
Hello,
[snip]
By the way, what happened to the Windows buildbots?
It looks like some of them are suffering from problems which I think are
common with buildbot on Windows - primarily difficulty dealing with runaway
processes or
Hello,
I've just tried running test_io under Windows (in a virtual machine) and I get
the following failures:
==
ERROR: test_error_through_destructor (test.test_io.CTextIOWrapperTest)
-
Merry Christmas everyone. Still, just hit 'd'. I'm testing the mpo spam
filter.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ar
Working on the spam filters... hit 'd' now...
S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
(working on spam system - just hit 'd')
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
(messing with the python.org spam filter - please ignore)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 14 Gen, 19:46, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> The test *package* is much older than Python 2.4, but many Python
> distros exclude it from their default configuration. Perhaps there is
> a way to add it back; on many Linux-based systems running apt-get or
> yum with the appropria
The test *package* is much older than Python 2.4, but many Python
distros exclude it from their default configuration. Perhaps there is
a way to add it back; on many Linux-based systems running apt-get or
yum with the appropriate arguments is all it takes. Sorry, I can't
help you with the appropria
Hi,
Today I received a report from a guy who tried to run the test suite
of a module of mine.
The test suite uses the test module for running tests, for temporary
files support and for doing a bunch of other things.
He tested it on CentOS 5 and looks like python 2.5.1 includes the test
module but p
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_ctypes
> test_ctypes
> test test_ctypes failed -- errors occurred; run in verbose mode for details
>
> More de
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_ctypes
> test_ctypes
> test test_ctypes failed -- errors occurred; run in verbose mode for details
>
> More de
I see test failures in current HEAD on my Google Red Hat Linux desktop
that the buildbots don't seem to have:
./python -E -tt ../Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- errors occurred; run in verbose mode for details
More details from running this manually:
$ ./py
Testing submission from dinsdale.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Thomas Wouters wrote:
> I'm seeing spurious test failures in test_timeout, on my own workstation and
> on macteagle.python.org (now that it crashes less; Apple sent over some new
> memory.) The problem is pretty simple: both macteagle and my workstation
> live too closely, network-wise, to www.pyth
Steve Holden wrote:
> Thomas Wouters wrote:
>> I'm thinking that it could probably try to connect to a less reliable
>> website, but that's just moving the problem around (and possibly harassing
>> an unsuspecting website, particularly around release-time.) Perhaps the test
>> should try to connect
I'm seeing spurious test failures in test_timeout, on my own workstation and
on macteagle.python.org (now that it crashes less; Apple sent over some new
memory.) The problem is pretty simple: both macteagle and my workstation
live too closely, network-wise, to www.python.org:
class TimeoutTestCas
I just created a branch for the ssize_t changes I had been working on
for a while. I hope to follow up with a PEP quickly.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
100 matches
Mail list logo
