If you set up any sort of report flag on the unit test itself, the
default report flags given to the testrunner are ignored. This goes
for all report flags, the REPORT_xDIFF and REPORT_ONLY_FIRST_FAILURE.
I'd suggest that we do allow the testrunner to set
REPORT_ONLY_FIRST_FAILURE by default even i
Tobias Herp writes:
> (we use Python because it is convenient!),
Speak for yourself, I want no part of that "we". I use Python because
it's well defined and well documented and makes sense and provides
powerful operations and runs quickly enough in those applications
where I use it.
The fact t
On 20Apr2010 15:27, Neal Becker wrote:
| Steven Bethard wrote:
|
| > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker wrote:
| >> I've noticed argparse ambiguity handling has changed a bit over last few
| >> revisions.
| >>
| >> I have cases where 1 valid input is a prefix of another:
| >>
| >> e.g
"Martin v. Löwis" schrieb:
>> - many optparse programs use the version argument
>> - many other programmers find this feature very convenient
>> - dropping or deprecating this is a totally unnecessary change
>> (I have not read a single real reason /why/ this should be done).
>
> You actually br
Nick Coghlan schrieb:
> Tobias Herp wrote:
>> No deprecation or removal of the simple and convenient 'version'
>> argument is needed for this. Just omit it, and build your version
>> action yourself. But please notice that there are others who appreciate
>> this simple way to do it and don't need
Nick Coghlan wrote:
> Tobias Herp wrote:
>> No deprecation or removal of the simple and convenient 'version'
>> argument is needed for this. Just omit it, and build your version
>> action yourself. But please notice that there are others who appreciate
>> this simple way to do it and don't need m
Tobias Herp wrote:
> No deprecation or removal of the simple and convenient 'version'
> argument is needed for this. Just omit it, and build your version
> action yourself. But please notice that there are others who appreciate
> this simple way to do it and don't need more.
One Obvious Way.
In
>> As a starting point for further research, try the sxstrace utility of
>> your Vista installation.
>
> What Vista installation? XP I'm afraid...
Then you are out of look. Check the event log, and ask in Windows help
forums for better ways to analyse the problem.
Regards,
Martin
___
Barry Warsaw schrieb:
> On Apr 18, 2010, at 07:30 PM, Eric Smith wrote:
>
>> Steven Bethard wrote:
>>> By the way, we could simplify the typical add_argument usage by adding
>>> "show program's version number and exit" as the default help for the
>>> 'version' action. Then you should just write:
>
On Tue, 20 Apr 2010 22:24:44 +0200, "Martin v. Löwis"
wrote:
> Phil Thompson wrote:
>> When I build my C++ extension on Windows (specifically PyQt with MinGW)
>> against Python v2.6.5 it fails to run under v2.6.4. The same problem
>> exists
>> when building against v3.1.2 and running under v3.1.1.
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> As for the operating system: I don't think it matters at all. Windows XP
>> Home is as fine a platform for this application as Windows 2008 R2
>> Enterprise. What would matter is processor architecture - we don't have
>> an Itanium Wi
Martin v. Löwis v.loewis.de> writes:
>
> As for the operating system: I don't think it matters at all. Windows XP
> Home is as fine a platform for this application as Windows 2008 R2
> Enterprise. What would matter is processor architecture - we don't have
> an Itanium Windows buildbot slave
Mi
On 20/04/2010 20:42, Brett Cannon wrote:
If you are a committer and are NOT subscribed to the python-committers
mailing list (I believe this at least includes Giampaolo, JP, and Brian),
then please either reply to this email with your preferred email address or
let me know directly (the former is
Tim Golden wrote:
> I've got agreement in principle for one of our decommissioned
> servers to be repurposed as a Python buildbot. My idea would
> be to set it up as a Windows 2003 R2 server, at least partly
> because we don't seem to have any Windows server buildbots
> and it's a platform I'm espe
Phil Thompson wrote:
> When I build my C++ extension on Windows (specifically PyQt with MinGW)
> against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
> when building against v3.1.2 and running under v3.1.1.
>
> The error message is...
>
> ImportError: DLL load failed: The s
> Amaury reopened my issue #8393 "subprocess: support undecodable current
> working directory on POSIX OS" because "It does not work on Windows" (bytes
> are rejected).
I see. I'd like to know whether that's an incompatible change. We
shouldn't make incompatible changes in that matter. However,
On Tue, Apr 20, 2010 at 03:27:53PM -0400, Neal Becker wrote:
> I have a preference to allow at least exact matches to succeed even in the
> case of ambiguity - mainly because I accidentally created this already once,
> and I feel it's better to at least work somewhat. Not sure if there is any
>
On Tue, Apr 20, 2010 at 14:42, Brett Cannon wrote:
> If you are a committer and are NOT subscribed to the python-committers
> mailing list (I believe this at least includes Giampaolo, JP, and Brian),
> then please either reply to this email with your preferred email address or
> let me know direc
At 03:27 PM 4/20/2010 -0400, Neal Becker wrote:
I have a preference to allow at least exact matches to succeed even in the
case of ambiguity - mainly because I accidentally created this already once,
and I feel it's better to at least work somewhat. Not sure if there is any
more elegant solution
If you are a committer and are NOT subscribed to the python-committers
mailing list (I believe this at least includes Giampaolo, JP, and Brian),
then please either reply to this email with your preferred email address or
let me know directly (the former is preferred so Georg or Eric can beat me
to
Steven Bethard wrote:
> On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker wrote:
>> I've noticed argparse ambiguity handling has changed a bit over last few
>> revisions.
>>
>> I have cases where 1 valid input is a prefix of another:
>>
>> e.g.:
>> '--string'
>> '--string2'
>>
>> With the most recent
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker wrote:
> I've noticed argparse ambiguity handling has changed a bit over last few
> revisions.
>
> I have cases where 1 valid input is a prefix of another:
>
> e.g.:
> '--string'
> '--string2'
>
> With the most recent 1.1, the behavior is:
>
> --string
I've noticed argparse ambiguity handling has changed a bit over last few
revisions.
I have cases where 1 valid input is a prefix of another:
e.g.:
'--string'
'--string2'
With the most recent 1.1, the behavior is:
--string=hello
is accepted, while:
--strin=hello
is marked as ambiguous.
I'm
Hi,
On 20.04.2010 14:19, Phil Thompson wrote:
When I build my C++ extension on Windows (specifically PyQt with MinGW)
against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
when building against v3.1.2 and running under v3.1.1.
The error message is...
ImportError: DLL load
On Tue, 20 Apr 2010 21:50:51 +0900, David Cournapeau
wrote:
> On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson
> wrote:
>> When I build my C++ extension on Windows (specifically PyQt with MinGW)
>> against Python v2.6.5 it fails to run under v2.6.4. The same problem
>> exists
>> when building again
On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson
wrote:
> When I build my C++ extension on Windows (specifically PyQt with MinGW)
> against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
> when building against v3.1.2 and running under v3.1.1.
>
> The error message is...
>
> Imp
I've got agreement in principle for one of our decommissioned
servers to be repurposed as a Python buildbot. My idea would
be to set it up as a Windows 2003 R2 server, at least partly
because we don't seem to have any Windows server buildbots
and it's a platform I'm especially interested in.
Does
When I build my C++ extension on Windows (specifically PyQt with MinGW)
against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
when building against v3.1.2 and running under v3.1.1.
The error message is...
ImportError: DLL load failed: The specified procedure could not be fou
28 matches
Mail list logo
