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
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.
On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson
p...@riverbankcomputing.com 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
On Tue, 20 Apr 2010 21:50:51 +0900, David Cournapeau courn...@gmail.com
wrote:
On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson
p...@riverbankcomputing.com 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
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
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
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker ndbeck...@gmail.com 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:
Steven Bethard wrote:
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker ndbeck...@gmail.com 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
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
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
On Tue, Apr 20, 2010 at 14:42, Brett Cannon br...@python.org 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
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
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, if you
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
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
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
Martin v. Löwis martin at 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
Antoine Pitrou wrote:
Martin v. Löwis martin at 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
On Tue, 20 Apr 2010 22:24:44 +0200, Martin v. Löwis mar...@v.loewis.de
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
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:
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
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
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 more.
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 more.
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 brought up a
On 20Apr2010 15:27, Neal Becker ndbeck...@gmail.com wrote:
| Steven Bethard wrote:
|
| On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker ndbeck...@gmail.com wrote:
| I've noticed argparse ambiguity handling has changed a bit over last few
| revisions.
|
| I have cases where 1 valid input is a
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
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
28 matches
Mail list logo
