[Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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 found. ...though I don't know what the procedure is. When built against v2.6.4 it runs fine under all v2.6.x. When built under v3.1.1 it runs fine under all v3.1.x. I had always assumed that an extension built with vX.Y.Z would always run under vX.Y.Z-1. Am I wrong in that assumption, or is this a bug in the latest versions? Thanks, Phil ___ 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] Planning a Windows buildbot
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 anyone suggest that a different configuration would be preferable? Thanks to the PSF MSDN license I can pretty much choose whatever I want. I believe Brian Curtin's looking at the possibility of a Win2k8 box which is one reason why I steered away from that. Also because my box -- whenever they hand it over -- will be relatively old. TJG ___ 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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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... > > ImportError: DLL load failed: The specified procedure could not be found. > > ...though I don't know what the procedure is. > > When built against v2.6.4 it runs fine under all v2.6.x. When built under > v3.1.1 it runs fine under all v3.1.x. > > I had always assumed that an extension built with vX.Y.Z would always run > under vX.Y.Z-1. I don't know how well it is handled in python, but this is extremely hard to do in general - you are asking about forward compatibility, not backward compatibility. Is there a reason why you need to do this ? The usual practice is to build against the *oldest* compatible version you can, so that it remains compatible with everything afterwards, cheers, David ___ 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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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 against v3.1.2 and running under v3.1.1. >> >> The error message is... >> >> ImportError: DLL load failed: The specified procedure could not be found. >> >> ...though I don't know what the procedure is. >> >> When built against v2.6.4 it runs fine under all v2.6.x. When built under >> v3.1.1 it runs fine under all v3.1.x. >> >> I had always assumed that an extension built with vX.Y.Z would always run >> under vX.Y.Z-1. > > I don't know how well it is handled in python, but this is extremely > hard to do in general - you are asking about forward compatibility, > not backward compatibility. Yes, I know. > Is there a reason why you need to do this ? The usual practice is to > build against the *oldest* compatible version you can, so that it > remains compatible with everything afterwards, I'm happy to do that if that is the recommendation, although this is the first time I've noticed this sort of problem (since v1.5). Phil ___ 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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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 failed: The specified procedure could not be found. ...though I don't know what the procedure is. When built against v2.6.4 it runs fine under all v2.6.x. When built under v3.1.1 it runs fine under all v3.1.x. I had always assumed that an extension built with vX.Y.Z would always run under vX.Y.Z-1. Am I wrong in that assumption, or is this a bug in the latest versions? It is also possible, that this is a windows issue with Manifest and DLL loading. Welcome in the manifest hell. If Version 2.6.4 is build against another version of the msvcrt as version 2.6.5 than this could happen. Possible solution is to not automatically build the manifest and use one with hard coded versions across one Python version 2.6.X. Regards Wolfgang ___ 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] argparse ambiguity handling
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 OK with this, but just want to know if there is agreement that this is the behavior we want. ___ 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
Re: [Python-Dev] argparse ambiguity handling
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=hello > > is accepted, while: > > --strin=hello > > is marked as ambiguous. > > I'm OK with this, but just want to know if there is agreement that this is > the behavior we want. I don't have a strong feeling about this. What was the behavior before? Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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
Re: [Python-Dev] argparse ambiguity handling
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 1.1, the behavior is: >> >> --string=hello >> >> is accepted, while: >> >> --strin=hello >> >> is marked as ambiguous. >> >> I'm OK with this, but just want to know if there is agreement that this >> is the behavior we want. > > I don't have a strong feeling about this. What was the behavior before? > > Steve At least 1 earlier version said that even exact match was ambiguous. 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. OTOH, I feel this is somewhat inelegant, as it appears to treat exact match as a special case. ___ 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] Email addresses for new committers for python-committers
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 the subscription if I take too long). ___ 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
Re: [Python-Dev] argparse ambiguity handling
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. OTOH, I feel this is somewhat inelegant, as it appears to treat exact match as a special case. How about throwing an error the moment you define a set of options that create this potential ambiguity? ;-) (i.e. force you to define --string1 and --string2 instead of --string and --string2) (Either that, or have an option to turn off ambiguous guessing, and throw the error unless you've turned it off.) ___ 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
Re: [Python-Dev] Email addresses for new committers for python-committers
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 directly (the former is preferred so Georg or Eric can beat me > to the subscription if I take too long). > I'm already subscribed via my first name dot last name @gmail.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
Re: [Python-Dev] argparse ambiguity handling
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 > more elegant solution. OTOH, I feel this is somewhat inelegant, as it > appears to treat exact match as a special case. Surely an exact match *is* a special case - it's an exact match! ___ 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
Re: [Python-Dev] Support byte string API of Windows in Python3?
> 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 were not able to pass a bytes cwd on Windows before, it's fine that you still are not able to. I'm puzzled how your patch could have possibly affected Windows, since it was only change _posixsubprocess.c. So I'm closing the report again. > Amaury also reopened #8394 "ctypes.dlopen() doesn't support surrogates", > because ctypes.CDLL() rejects byte string. Ok, I'll close this as well. Regards, Martin ___ 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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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 specified procedure could not be found. > > ...though I don't know what the procedure is. > > When built against v2.6.4 it runs fine under all v2.6.x. When built under > v3.1.1 it runs fine under all v3.1.x. > > I had always assumed that an extension built with vX.Y.Z would always run > under vX.Y.Z-1. > > Am I wrong in that assumption, or is this a bug in the latest versions? You are not wrong in that assumption, but it still might not be a bug in the latest version. It could also be a bug in MingW or PyQt. Before we can judge on that, we need to understand what exactly happened. As a starting point for further research, try the sxstrace utility of your Vista installation. Regards, Martin ___ 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
Re: [Python-Dev] Planning a Windows buildbot
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 especially interested in. > > Does anyone suggest that a different configuration would be > preferable? Thanks to the PSF MSDN license I can pretty much > choose whatever I want. I believe Brian Curtin's looking at > the possibility of a Win2k8 box which is one reason why I > steered away from that. Also because my box -- whenever they > hand it over -- will be relatively old. If you are truly adventurous (sp?), you could try to setup a Cygwin or MingW target - I don't think we have one of these yet. However, doing so may be pointless as it may be doomed to fail, anyway, in which case there is no point in continuously verifying that failure. If you are a little adventurous, set up VS 2010. We don't have any build slaves for that, either, plus one would have to define a way how the slaves convert the project files (which could either happen manually in SVN, as originally done for VS 2008, or automatically through VS, or automatically through something like PCbuild/vs9to8.py). 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 :-) Regards, Martin ___ 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
Re: [Python-Dev] Email addresses for new committers for python-committers
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 preferred so Georg or Eric can beat me to the subscription if I take too long). I did subscribe earlier today, and replied to the usual "please confirm" email, but instead of the conventional "You're on the list" email I got a slightly ambiguous "You're due to be moderated" email. If you can confirm that I'm subscribed then all well and good. If not, let me know if there's something else I should do. TJG ___ 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
Re: [Python-Dev] Planning a Windows buildbot
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 Microsoft has said it would stop doing Windows releases for Itanium: http://arstechnica.com/microsoft/news/2010/04/microsoft-its-the-end-of-the-line-for-itanium-support.ars I'm not sure there's any point in caring about it anymore. Regards Antoine. ___ 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
Re: [Python-Dev] Planning a Windows buildbot
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 Windows buildbot slave > > Microsoft has said it would stop doing Windows releases for Itanium: > http://arstechnica.com/microsoft/news/2010/04/microsoft-its-the-end-of-the-line-for-itanium-support.ars > > I'm not sure there's any point in caring about it anymore. That's why I put a smiley in that sentence. Regards, Martin ___ 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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
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. >> >> The error message is... >> >> ImportError: DLL load failed: The specified procedure could not be found. >> >> ...though I don't know what the procedure is. >> >> When built against v2.6.4 it runs fine under all v2.6.x. When built under >> v3.1.1 it runs fine under all v3.1.x. >> >> I had always assumed that an extension built with vX.Y.Z would always run >> under vX.Y.Z-1. >> >> Am I wrong in that assumption, or is this a bug in the latest versions? > > You are not wrong in that assumption, but it still might not be a bug in > the latest version. It could also be a bug in MingW or PyQt. > > Before we can judge on that, we need to understand what exactly happened. > > As a starting point for further research, try the sxstrace utility of > your Vista installation. What Vista installation? XP I'm afraid... Phil ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
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:
>>>
>>> parser.add_argument('--version', action='version', version='>> version>')
>>
>> I like this the best. I don't like argparse adding arguments for me.
>
> I concur. This gives me all the flexibility I need to make my programs accept
> exactly the arguments I want and print exactly the information I want to
> present.
But you had this possibility all the time!
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.
--
Tobias
___
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
Re: [Python-Dev] Binary Compatibility Issue with Python v2.6.5 and v3.1.2
>> 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 ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
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 this case, the ambiguity of the "version=" argument is sufficient to elevate it to the level of "attractive nuisance" (particularly given the legacy behaviour of conflicting with typical verbosity options). The default help for the action needs to be fixed, and there are a couple of documentation tweaks to be made, but Steven's decision to remove the feature has a sound rationale. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
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. > > One Obvious Way. > > In this case, the ambiguity of the "version=" argument is sufficient to > elevate it to the level of "attractive nuisance" (particularly given the > legacy behaviour of conflicting with typical verbosity options). The > default help for the action needs to be fixed, and there are a couple of > documentation tweaks to be made, but Steven's decision to remove the > feature has a sound rationale. Exactly my feelings. IMO, straight removal would be fine as well, but a deprecation may be more user-friendly, wrt. the existing code base. Regards, Martin ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
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. > > One Obvious Way. One /Obvious/ Way! To simply check off the "give the program a version" task, /this/ (the version argument) is the way to do it (obvious enough for legions of programmers who are able to use optparse). If you need a more fancy version action, of course, you need to take care of that yourself. > In this case, the ambiguity of the "version=" argument ... What /is/ this ambiguity of the "version=" argument? There is none! Do it the way optparse does it, and all is fine! -- Tobias ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
"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 good reason yourself: > > In the face of ambiguity, refuse the temptation to guess. I didn't guess. The vast majority of *x commandline tools, *including the Python interpreter*, uses '--version' and/or '-V' for the version action, while '-v' is often used for something else, most often verbosity (again: e.g. the Python interpreter). Nobody has argued the converse. The optparse module uses just '--version' option string by default, following the standard. > If you ask "give me a version argument", the question is "how is it > spelled?". IIUC, you originally complained that the spelling of argparse > (i.e. -v/--version) is not good, and that a different spelling should be > used. So it's ambiguous, in which case the feature shouldn't be provided > in the first place. Wrong! Just follow the de-facto standard. There has never been a problem with optparse's version argument, simply because of the fact it conforms with the standard (using just '--version'). Perhaps we wouldn't argue now if they had decided to add '-V' as well, which is AFAIK /never/ used for anything else than the version, either; perhaps this would have been adopted by argparse as well. The optik/optparse people didn't, and the argparse people apparently didn't really look out what options look like in the wild. There is *no* problem with a 'version' argument (which has always been *optional*; nobody is forced to use it) which simply defines the '--version' option to trigger the version option. There has *never* been a problem with the optparse way to do it! Now argparse wants to become a part of Python's standard library; it certainly has advantages over optparse. But the user won't be interested in the difference: "Oh, I see, this is an argparse-based program, so the '-v' is naturally not available for verbosity. Fine!" Up to today, the argparse module had a limited audience. When becoming part of Python, it must follow standards; it should Do The Right Thing by default, and it should keep the usage difference to optparse as small as possible. People should be allowed to rely on the fact that /Python scripts follow the standards/; this is a huge usability gain. Thus, argparse should *continue* to support the version argument, because it is convenient (we use Python because it is convenient!), and it is sufficient in 95% of the cases (I have written lots of optparse scripts, and in exactly one case I wrote the version output myself). It should discontinue the '-v' short option string, because it is non-standard, and it is ambiguous; it is often used for something else, while '-V' isn't (but adding this as a default would like break existing argparse programs, so this is not an option). If the community feels this is necessary, the '-v' could be supported 'invisibly': it should not be visible in the help, and it must not block the usage of '-v' for other purposes. -- Tobias ___ 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
Re: [Python-Dev] argparse ambiguity handling
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.: | >> '--string' | >> '--string2' | >> | >> With the most recent 1.1, the behavior is: | >> | >> --string=hello | >> | >> is accepted, while: | >> | >> --strin=hello | >> | >> is marked as ambiguous. | >> | >> I'm OK with this, but just want to know if there is agreement that this | >> is the behavior we want. | > | > I don't have a strong feeling about this. What was the behavior before? | > Steve | | At least 1 earlier version said that even exact match was ambiguous. | | 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. OTOH, I feel this is somewhat inelegant, as it | appears to treat exact match as a special case. I think the new behaviour is desirable. Plenty of commands have both --foo and --foo-tweak. Usually because --foo came first and --foo-tweak came later, or simply because --foo is the simple and obvious and commonly wanted mode and --foo-tweak is a special case. Real world example: rsync and the --delete* options. I'm sure plenty of others can be found. The new behaviour makes this doable. The old behaviour made it unimplementable. Maybe it is desirable to be _able_ to forbid this arguably-ambiguous option set, but I definitely feel that the current behaviour should be available. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ If it wasn't for lawyers, we wouldn't need them. ___ 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
Re: [Python-Dev] Python 2.7b1 and argparse's version action
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 that it's not excessively inconvenient despite an avowed bias toward EIBTI is the icing, not the cake. Remember, convenience is explicitly subsidiary: "not every 3 line function needs to be a builtin." I have no particular opinion the rest of the debate. ___ 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] Doctests REPORT_ONLY_FIRST_FAILURE ignored
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 if the testcase has a REPORT_xDIFF flag. Why? Because it makes sense. :) The REPORT_xDFF flags makes sense both as parameters to a testrunner, and as flags on a testcase. You might want to permanently set diff flags on tests that generate output that warrants a diff if they fail. REPORT_ONLY_FIRST_FAILURE you would rarely set on a testcase. You don't want that on the testcase, as buildbots wouldn't see the subsequent fails, and developers might think it was only a minor issue. It is a flag you give to the testrunner to stop having the first failure scroll off screen. So you want it to work *always*. You don't want or expect it to stop working just because one testcase had a DIFF flag set. Right? Or did I miss something? If not, I'll provide a patch and put it in the bugtracker. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ 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
