Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/10/7 Antoine Pitrou solip...@pitrou.net: Python 3 complains at startup and is a bit more explicit: $ ./python -c '1' - Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [Errno 9] Bad file descriptor Abandon Of course, if it is stderr that you explicitly close, you lose all reporting: $ ./python -c '1' 2- Abandon Hmm, how does Python 3's pythonw work on Windows? (I don't have a Windows installation of Python 3 to hand at the moment) 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-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/10/8 Paul Moore p.f.mo...@gmail.com: 2009/10/7 Antoine Pitrou solip...@pitrou.net: Python 3 complains at startup and is a bit more explicit: $ ./python -c '1' - Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [Errno 9] Bad file descriptor Abandon Of course, if it is stderr that you explicitly close, you lose all reporting: $ ./python -c '1' 2- Abandon Hmm, how does Python 3's pythonw work on Windows? (I don't have a Windows installation of Python 3 to hand at the moment) When running pythonw, fileno(stdout) is negative, so sys.stdout is set to None, and print() silently returns. But the situation is not perfect, see http://bugs.python.org/issue6501 where Apache provides a stdout, but python cannot determine the encoding because there is no console. -- Amaury Forgeot d'Arc ___ 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] PEP 389: argparse - new command line parsing module
Paul Moore wrote: Traceback (most recent call last): File hello.py, line 13, in module main() File hello.py, line 7, in main sys.stdout.flush() IOError: [Errno 9] Bad file descriptor (Question - is it *ever* possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!) Of course; simply use the - pseudo-redirection, which has been a standard sh feature (later inherited by ksh and bash, but not csh) for ~30 years. The error message is amusing, too: $ python -c 'print foo' - close failed in file object destructor: Error in sys.excepthook: Original exception was: Adding an explicit flush results in a more understandable error message: Traceback (most recent call last): File string, line 1, in module IOError: [Errno 9] Bad file descriptor ___ 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] PEP 389: argparse - new command line parsing module
Hrvoje Niksic hrvoje.niksic at avl.com writes: Of course; simply use the - pseudo-redirection, which has been a standard sh feature (later inherited by ksh and bash, but not csh) for ~30 years. The error message is amusing, too: $ python -c 'print foo' - close failed in file object destructor: Error in sys.excepthook: Original exception was: Python 3 complains at startup and is a bit more explicit: $ ./python -c '1' - Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [Errno 9] Bad file descriptor Abandon Of course, if it is stderr that you explicitly close, you lose all reporting: $ ./python -c '1' 2- Abandon 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] PEP 389: argparse - new command line parsing module
Yuvgoog Greenle wrote: I know this might come through as bike shedding but it's just customary python that every module have it's own exception types as to not mix them up with others. Not in my Python world it isn't. While that is sometimes the right answer, more often the right answer is to properly scope your try/except statement in order to avoid catching exceptions from code you aren't interested in. If you end up stuck with a library call that lacks both granularity and specificity of exceptions then you live with it (and maybe file a bug report/feature request with the library author). 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] PEP 389: argparse - new command line parsing module
I haven't checked if it's possible, but I suggest Argparse have it's own exception class that inherits from SystemExit and that exception would be thrown. ParseError, or something similar. I suggest this just because it would be more readable I guess and would exactly explain why this code exits. On Sat, Oct 3, 2009 at 8:15 AM, Nick Coghlan ncogh...@gmail.com wrote: Toshio Kuratomi wrote: About exit(), I agree with others about wanting to catch the exception myself and then choosing to exit from the code. I'm not sure that it's actually useful in practice, though...it might just feel cleaner but not actually be that helpful. As others have pointed out, if you want to do that then you can just catch SystemExit. 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/ubershmekel%40gmail.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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com wrote: I haven't checked if it's possible, but I suggest Argparse have it's own exception class that inherits from SystemExit and that exception would be thrown. ParseError, or something similar. I suggest this just because it would be more readable I guess and would exactly explain why this code exits. I've never seen such an idiom before (subclassing SystemExit) but it would certainly be possible create an ArgumentParserExit exception like that. Then you would have your choice of overriding .exit() or catching the exception. 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] PEP 389: argparse - new command line parsing module
Steven Bethard wrote: On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com wrote: I haven't checked if it's possible, but I suggest Argparse have it's own exception class that inherits from SystemExit and that exception would be thrown. ParseError, or something similar. I suggest this just because it would be more readable I guess and would exactly explain why this code exits. I've never seen such an idiom before (subclassing SystemExit) but it would certainly be possible create an ArgumentParserExit exception like that. Then you would have your choice of overriding .exit() or catching the exception. Steve Why not just catch SystemExit? If you want a custom exception the overriding .exit() should be sufficient. I'd be much more interested in Guido's suggestion of auto-generated custom help messages for sub-commands. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
Steven Bethard wrote:
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com
wrote:
I haven't checked if it's possible, but I suggest Argparse have it's
own exception class that inherits from SystemExit and that exception
would be thrown.
I've never seen such an idiom before (subclassing SystemExit) but it
would certainly be possible create an ArgumentParserExit exception
like that. Then you would have your choice of overriding .exit() or
catching the exception.
Why not just catch SystemExit? If you want a custom exception the overriding
.exit() should be sufficient.
I'm certainly fine with that -- I'm just trying to make sure I've
addressed whatever needs addressed to get argparse in.
I'd be much more interested in Guido's suggestion of auto-generated custom
help messages for sub-commands.
Maybe I misunderstood, but I think this is already the default
argparse behavior, no?
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
parser.parse_args(['--help'])
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
# top level argument help
parser.parse_args(['--help'])
usage: [-h] [--foo FOO] {1,2} ...
positional arguments:
{1,2}
optional arguments:
-h, --help show this help message and exit
--foo FOO
# help for subparser 1
parser.parse_args(['1', '--help'])
usage: 1 [-h] [--bar BAR]
optional arguments:
-h, --help show this help message and exit
--bar BAR
# help for subparser 2
parser.parse_args(['2', '--help'])
usage: 2 [-h] baz
positional arguments:
baz
optional arguments:
-h, --help show this help message and exit
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] PEP 389: argparse - new command line parsing module
Steven Bethard wrote:
[snip...]
I'd be much more interested in Guido's suggestion of auto-generated custom
help messages for sub-commands.
Maybe I misunderstood, but I think this is already the default
argparse behavior, no?
Cool. I didn't realise that help for subcommands was already
implemented. :-)
Michael
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
parser.parse_args(['--help'])
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
# top level argument help
parser.parse_args(['--help'])
usage: [-h] [--foo FOO] {1,2} ...
positional arguments:
{1,2}
optional arguments:
-h, --help show this help message and exit
--foo FOO
# help for subparser 1
parser.parse_args(['1', '--help'])
usage: 1 [-h] [--bar BAR]
optional arguments:
-h, --help show this help message and exit
--bar BAR
# help for subparser 2
parser.parse_args(['2', '--help'])
usage: 2 [-h] baz
positional arguments:
baz
optional arguments:
-h, --help show this help message and exit
Steve
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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] PEP 389: argparse - new command line parsing module
Yuvgoog Greenle wrote: On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: [snip...] Why not just catch SystemExit? If you want a custom exception the overriding .exit() should be sufficient. I'd be much more interested in Guido's suggestion of auto-generated custom help messages for sub-commands. Check it out: def ParseAndRun(): crazy_external_function_that_might_exit() # Argparse blah blah parser.parse_args() if __name__ == __main__: try: ParseAndRun() except SystemExit: # was it crazy_external_function_that_might_exit or an argparse error? I know this might come through as bike shedding but it's just customary python that every module have it's own exception types as to not mix them up with others. Then subclass and override .exit() as discussed - or put proper exception handling around the call to parse_args() (optionally rethrowing with whatever custom exception type you wish). Michael --yuv -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: [snip...] Why not just catch SystemExit? If you want a custom exception the overriding .exit() should be sufficient. I'd be much more interested in Guido's suggestion of auto-generated custom help messages for sub-commands. Check it out: def ParseAndRun(): crazy_external_function_that_might_exit() # Argparse blah blah parser.parse_args() if __name__ == __main__: try: ParseAndRun() except SystemExit: # was it crazy_external_function_that_might_exit or an argparse error? I know this might come through as bike shedding but it's just customary python that every module have it's own exception types as to not mix them up with others. --yuv ___ 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] PEP 389: argparse - new command line parsing module
On Sun, 4 Oct 2009 03:38:31 am Yuvgoog Greenle wrote:
Check it out:
def ParseAndRun():
crazy_external_function_that_might_exit()
# Argparse blah blah
parser.parse_args()
if __name__ == __main__:
try:
ParseAndRun()
except SystemExit:
# was it crazy_external_function_that_might_exit or an
argparse error?
Does it matter? What difference does it make?
I know this might come through as bike shedding but it's just
customary python that every module have it's own exception types as
to not mix them up with others.
You are mistaken.
import os
os.path.split(45)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.6/posixpath.py, line 82, in split
i = p.rfind('/') + 1
AttributeError: 'int' object has no attribute 'rfind'
Plain, ordinary AttributeError, not OSModuleSubclassOfAttributeError.
I could show a thousand other examples. It simply isn't true that all,
or even most, modules have their own exception types.
There's no reason to treat SystemExit as special in this regard.
optparse, for example, calls sys.exit(), which operates by raising
SystemExit. Ordinary SystemExit, not a special module-specific
subclass.
--
Steven D'Aprano
___
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] PEP 389: argparse - new command line parsing module
On Sun, 4 Oct 2009 04:46:19 am Yuvgoog Greenle wrote: I just think that if a parser error is causing the SystemExit, I would rather catch a parser error than catching a SystemExit for the sake of readability. It saves me the comments: # Catching SystemExit because parse_args() throws SystemExit on parser errors. But why are you catching the error? As a general rule, you *want* your command line app to exit if it can't understand the arguments you pass to it. What else can it do? Guess what you wanted? Assuming you have a reason for catching the exception, I don't see that there's any difference in readability between these: parser = argparse.ArgumentParser() setup_args(parser) try: ns = parser.parse_args() except argparse.ParserError: process_error() else: main(ns) and: parser = argparse.ArgumentParser() setup_args(parser) try: ns = parser.parse_args() except SystemExit: process_error() else: main(ns) You don't need a comment warning that you are catching SystemExit because parse_args raises SystemExit, any more than you need a comment saying that you are catching ValueError because some function raises ValueError. The fact that you are catching an exception implies that the function might raise that exception. A comment like: Catching SystemExit because parse_args() throws SystemExit on parser errors. is up them with comments like this: x += 1 # Add 1 to x. -- Steven D'Aprano ___ 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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 8:29 PM, Steven D'Aprano st...@pearwood.info wrote: I could show a thousand other examples. It simply isn't true that all, or even most, modules have their own exception types. I might be wrong on this. Your point is extra true for modules in the standard library (which is what we're talking about for argparse). I just think that if a parser error is causing the SystemExit, I would rather catch a parser error than catching a SystemExit for the sake of readability. It saves me the comments: # Catching SystemExit because parse_args() throws SystemExit on parser errors. # Subclassing ArgumentParser and overriding exit because I don't want to exit() upon parser errors. So I'm sorry if what I said was irrelevant. I've never written or taken part of writing a std-lib module. --yuv ___ 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] PEP 389: argparse - new command line parsing module
* Steven D'Aprano wrote: You don't need a comment warning that you are catching SystemExit because parse_args raises SystemExit, any more than you need a comment saying that you are catching ValueError because some function raises ValueError. The fact that you are catching an exception implies that the function might raise that exception. A comment like: Catching SystemExit because parse_args() throws SystemExit on parser errors. is up them with comments like this: x += 1 # Add 1 to x. It's semantically different. You usually don't catch SystemExit directly, because you want your programs to be stopped. Additionally, a library exiting your program is badly designed, as it's unexpected. Thatswhy such a comment is useful. Here's what I'd do: I'd subclass SystemExit in this case and raise the subclass from argparse. That way all parties here should be satisifed. (I do the same all the time in my signal handlers - that's another reason I'd rather not catch SystemExit directly as well :-) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 ___ 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] PEP 389: argparse - new command line parsing module
Steven D'Aprano wrote: On Sun, 4 Oct 2009 04:46:19 am Yuvgoog Greenle wrote: I just think that if a parser error is causing the SystemExit, I would rather catch a parser error than catching a SystemExit for the sake of readability. It saves me the comments: # Catching SystemExit because parse_args() throws SystemExit on parser errors. But why are you catching the error? As a general rule, you *want* your command line app to exit if it can't understand the arguments you pass to it. What else can it do? Guess what you wanted? There are uses of argparse outside of command line apps. For example, I use it to parse --options for IPython %magic commands. Of course, I just subclass ArgumentParser and replace the .error() method. I require a particular IPython exception type in order for the error to be recognized correctly in the %magic subsystem. The other use case, as mentioned earlier, was for debugging your parser on the interactive prompt. A custom subclass may also be able to hold more machine-readable information about the error than the formatted error message, but I don't have any particular use cases about what may be the most useful. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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] PEP 389: argparse - new command line parsing module
On Sun, 4 Oct 2009 05:35:04 am André Malo wrote: * Steven D'Aprano wrote: You don't need a comment warning that you are catching SystemExit because parse_args raises SystemExit, any more than you need a comment saying that you are catching ValueError because some function raises ValueError. The fact that you are catching an exception implies that the function might raise that exception. A comment like: Catching SystemExit because parse_args() throws SystemExit on parser errors. is up them with comments like this: x += 1 # Add 1 to x. It's semantically different. You usually don't catch SystemExit directly, because you want your programs to be stopped. Exactly -- so why catch it at all? But even if there is a good reason to catch it, there's still no reason to subclass SystemExit unless argparse wants to distinguish different types of fatal error, and allow code to catch some but not all. But frankly, if I'm having a hard time thinking of a reason to catch SystemExit, I'm having an even harder time thinking why you'd want to (say) catch SystemExitTooManyArguments but not SystemExitMissingArgument. Additionally, a library exiting your program is badly designed, as it's unexpected. It's not unexpected for an argument parser. Do you know any applications that run when given invalid arguments? As a general rule, what can the application do? Guess what you wanted? Thatswhy such a comment is useful. The comment doesn't tell you anything that wasn't obvious from the code. It is pointless. Here's what I'd do: I'd subclass SystemExit in this case and raise the subclass from argparse. In the following code snippet: try: ns = argparse.parse_args() except SystemExit: ... is there any confusion between SystemExit raised by parse_args and SystemExit raised by other components? *What* other components? If SystemExit was raised in that try block, where could it have come from other than parse_args? Do you write comments like these? try: value = mydict[key] except KeyError: # Catch KeyError raised by dict lookup ... try: n = mylist.index(x) except ValueError: # Catch ValueError raised by mylist.index ... Useless comments are worse than no comments, because useless comments waste the readers' time and they risk becoming out of sync with the code and turning into misleading comments. That way all parties here should be satisifed. No. It wastes the time of the argparse developer, it wastes the time of people learning argparse, it wastes the time of people who read the code and wonder what's the difference between SystemExit and ArgparseSystemExit. (Answer: there is no difference.) -- Steven D'Aprano ___ 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] PEP 389: argparse - new command line parsing module
On Sun, 4 Oct 2009 08:21:46 am Robert Kern wrote: There are uses of argparse outside of command line apps. For example, I use it to parse --options for IPython %magic commands. Of course, I just subclass ArgumentParser and replace the .error() method. Exactly. There are uses for catching SystemExit, which is why it's an exception and not an unconditional exit. But they're rare, and not difficult to deal with: in your case, having argparse raise a subclass of SystemExit won't help you, you would still need to subclass, and in other cases, you can just catch SystemExit. The other use case, as mentioned earlier, was for debugging your parser on the interactive prompt. A custom subclass may also be able to hold more machine-readable information about the error than the formatted error message, but I don't have any particular use cases about what may be the most useful. Nobody has requested that the exception expose more information. They've requested that argparse paint the SystemExit a slightly different shade of yellow to the colour it already is -- this is pure bike-shedding. Subclassing SystemExit just in case someday in the indefinite future there comes a need to add extra information to the exception falls foul of You Ain't Gonna Need It. Keep it simple -- if, someday, such a need becomes apparent, then subclass. -- Steven D'Aprano ___ 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] PEP 389: argparse - new command line parsing module
On 09/29/2009 04:38 PM, Steven Bethard wrote: On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard: If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. Note: on Unix systems, --help should still print to the terminal, not pop up a GUI text box with the help information. So being able to override the behaviour might be good but it is more than a simple, GUI vs console distinction. Are we talking about anything else than --help output (for the printing question)? About exit(), I agree with others about wanting to catch the exception myself and then choosing to exit from the code. I'm not sure that it's actually useful in practice, though...it might just feel cleaner but not actually be that helpful. -Toshio signature.asc Description: OpenPGP digital signature ___ 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] PEP 389: argparse - new command line parsing module
Toshio Kuratomi wrote: About exit(), I agree with others about wanting to catch the exception myself and then choosing to exit from the code. I'm not sure that it's actually useful in practice, though...it might just feel cleaner but not actually be that helpful. As others have pointed out, if you want to do that then you can just catch SystemExit. 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] PEP 389: argparse - new command line parsing module
2009/9/30 Robert Kern robert.k...@gmail.com: I am blissfully unaware of the problems Paul mentioned about Windows GUI-mode programs. :-) I'm not sure what would make a program GUI-mode or not. Certainly, I have written Python programs that use wxPython and PyQt on Windows that print to stdout/stderr, and they appear to work fine. It's the difference between using python.exe and pythonw.exe. There's a flag in the executable header saying whether the executable is console mode or gui mode. GUI mode programs are run (by the OS) without a console (or if run from a console prompt, they automatically detach from that console, much like Unix programs which fork themselves to leave the terminal group (did I get the terminology right?) but done by the OS). As a result, the program has no valid stdin/out/err handles. Any attempt to write to them causes the program to crash. Traceback (most recent call last): File hello.py, line 13, in module main() File hello.py, line 7, in main sys.stdout.flush() IOError: [Errno 9] Bad file descriptor (Question - is it *ever* possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!) 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-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Thu, Oct 01, 2009 at 09:58:59AM +0100, Paul Moore wrote: (Question - is it *ever* possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!) Yes, at startup you just have the file descriptors your parent process gave you. This may or may not include 0, 1, and 2, and may or may not include other descriptors too. I seem to recall there have been security holes caused in the past by people assuming 0-2 will exist. ___ 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] PEP 389: argparse - new command line parsing module
Yuvgoog Greenle ubershmekel at gmail.com writes: +1 for adding argparse and eventually deprecating optparse, -0 for deprecating getopt. 2. Big modules - 1 uber-module for each subject that does everything. Maybe logging is an example of this. I'm not sure that it is, if you mean code size. In Python 2.5, logging is 1300 SLOC, less than say tarfile, pickletools, pydoc and decimal. Regards, Vinay Sajip ___ 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] PEP 389: argparse - new command line parsing module
Brett Cannon brett at python.org writes: Obviously if one of the getopt supporters has a better way of doing this then please speak up. I'm not a getopt supporter per se - I'm +1 for argparse - but Opster provides some nice syntax sugar on top of getopt, and can be seen here: http://blogg.ingspree.net/blog/2009/09/14/opster/ I've contacted Steven about a similar approach for argparse, and we're waiting for Yuvgoog's work on argparse(func) to be done to see if there's a feasible similar approach. ___ 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] PEP 389: argparse - new command line parsing module
On a tangent -- a use case that I see happening frequently but which is pretty poorly supported by optparse is a command-line that has a bunch of general flags, then a 'subcommand name', and then more flags, specific to the subcommand. Most here are probably familiar with this pattern from SVN, Hg, and other revision control systems (P4 anyone?) with a rich command-line interface. There are some variants, e.g. whether global and subcommand-specific flags may overlap, and whether flags may follow positional args (Hg and SVN seem to differ here a bit). I've helped write at least two tools at Google that have this structure; both used different approaches, and neither was particularly easy to get right. Getting all the different --help output to make sense was mostly a manual process. (E.g. foo --help should print the general flags and the list of known subcommands, whereas foo --help subcommand should print flags and other usage info about the specific subcommand.) Also switching out to different calls based on the subcommand should/might be part of this. I would be willing to live with a third option parser in the stdlib if it solved this problem well. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 389: argparse - new command line parsing module
On 2009-09-29 18:38 PM, Steven Bethard wrote: I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. I use argparse (and previously optparse) frequently to handle the command line arguments of GUI apps. I tend to use them in the same way as CLI programs, though, since I usually only use command line arguments when starting the GUIs from the terminal. I am blissfully unaware of the problems Paul mentioned about Windows GUI-mode programs. I'm not sure what would make a program GUI-mode or not. Certainly, I have written Python programs that use wxPython and PyQt on Windows that print to stdout/stderr, and they appear to work fine. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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] PEP 389: argparse - new command line parsing module
On 2009-09-30 11:38 AM, Guido van Rossum wrote: On a tangent -- a use case that I see happening frequently but which is pretty poorly supported by optparse is a command-line that has a bunch of general flags, then a 'subcommand name', and then more flags, specific to the subcommand. Most here are probably familiar with this pattern from SVN, Hg, and other revision control systems (P4 anyone?) with a rich command-line interface. There are some variants, e.g. whether global and subcommand-specific flags may overlap, and whether flags may follow positional args (Hg and SVN seem to differ here a bit). I've helped write at least two tools at Google that have this structure; both used different approaches, and neither was particularly easy to get right. Getting all the different --help output to make sense was mostly a manual process. (E.g. foo --help should print the general flags and the list of known subcommands, whereas foo --help subcommand should print flags and other usage info about the specific subcommand.) Also switching out to different calls based on the subcommand should/might be part of this. I would be willing to live with a third option parser in the stdlib if it solved this problem well. I don't think argparse supports the foo --help subcommand OOB. I think it would be simple to modify argparse to make it do so. It does support general options followed by a subcommand with options, though. http://argparse.googlecode.com/svn/tags/r101/doc/other-methods.html#sub-commands -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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] PEP 389: argparse - new command line parsing module
On Sep 30, 2009, at 12:58 PM, Robert Kern wrote: I don't think argparse supports the foo --help subcommand OOB. I think it would be simple to modify argparse to make it do so. It does support general options followed by a subcommand with options, though. Right. I've made it kind of work in Mailman 3, but it would be nice for argparse to support this out of the box. Note that I think you want two forms: foo help subcommand foo subcommand --help to basically print the same help text. This is the way bzr does it for example and it works great. Other than that, I think argparse supports Guido's use case very nicely. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] PEP 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 09:21, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Brett Cannon brett at python.org writes: Obviously if one of the getopt supporters has a better way of doing this then please speak up. I'm not a getopt supporter per se - I'm +1 for argparse - but Opster provides some nice syntax sugar on top of getopt, and can be seen here: http://blogg.ingspree.net/blog/2009/09/14/opster/ I've contacted Steven about a similar approach for argparse, and we're waiting for Yuvgoog's work on argparse(func) to be done to see if there's a feasible similar approach. I am reluctant to jump on these argument parsing decorators until they have existed outside the standard library for a while and have settled down as I suspect some people want to use annotations to do type conversion/checking, others don't, etc. -Brett ___ 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] PEP 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote: Right. I've made it kind of work in Mailman 3, but it would be nice for argparse to support this out of the box. Note that I think you want two forms: foo help subcommand foo subcommand --help to basically print the same help text. This is the way bzr does it for example and it works great. In some commands, options as well as subcommands can change subsequent parsing. The iptables command is a good example of a command-line program that follows this practice. From the man page: after [a module name is specified], various extra command line options become available, depending on the specific module. You can specify multiple extended match modules in one line, and you can use the -h or --help options after the module has been specified to receive help specific to that module. In the case of iptables, module names are specified as options, not as subcommands. From my cursory reading of the documentation, it looks like argparse can only add subparsers for subcommands. Is there any way to add subparsers based on options instead (as iptables does)? Also, is it possible to add these subparsers dynamically? For example, you would want to be able to load a module immediately after parsing the name instead of having to keep a predetermined list of all module names. I'm pretty sure that bzr dynamically loads modules this way. Can argparse help with this? Sorry for all of the questions. I ask them because I have some experience with adding the above features to optparse, and it was a lot of work to get it right. It also seems like there are a lot of programs that need to load modules dynamically. I would be really excited if argparse made this easier than optparse did. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] PEP 389: argparse - new command line parsing module
On 2009-09-30 15:17 PM, Andrew McNabb wrote:
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote:
Right. I've made it kind of work in Mailman 3, but it would be nice for
argparse to support this out of the box. Note that I think you want two
forms:
foo help subcommand
foo subcommand --help
to basically print the same help text. This is the way bzr does it for
example and it works great.
In some commands, options as well as subcommands can change subsequent
parsing. The iptables command is a good example of a command-line
program that follows this practice. From the man page:
after [a module name is specified], various extra command line options
become available, depending on the specific module. You can specify
multiple extended match modules in one line, and you can use the -h or
--help options after the module has been specified to receive help
specific to that module.
In the case of iptables, module names are specified as options, not as
subcommands.
From my cursory reading of the documentation, it looks like argparse can
only add subparsers for subcommands. Is there any way to add subparsers
based on options instead (as iptables does)?
I have not done so, but I suspect so. The implementation of .add_subparsers()
adds to the positional argument list, but one could be written to append to the
option list.
Also, is it possible to add these subparsers dynamically? For example,
you would want to be able to load a module immediately after parsing the
name instead of having to keep a predetermined list of all module names.
I'm pretty sure that bzr dynamically loads modules this way. Can
argparse help with this?
Not out-of-box, but it looks fairly straightforward to plug in. The subparser
logic is mostly encapsulated in the _SubparsersAction class. You can register a
new class for it:
parser.register('action', 'parsers', MySubParsersAction)
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
___
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] PEP 389: argparse - new command line parsing module
Brett Cannon brett at python.org writes: I am reluctant to jump on these argument parsing decorators until they have existed outside the standard library for a while and have settled down as I suspect some people want to use annotations to do type conversion/checking, others don't, etc. I agree - it's just an approach which shows some promise and is worth exploring. I'm not suggesting jumping in with both feet. But it does show about getopt that perhaps there's life in the old dog yet ;-) Regards, Vinay Sajip ___ 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] PEP 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb amcn...@mcnabbs.org wrote: From my cursory reading of the documentation, it looks like argparse can only add subparsers for subcommands. Is there any way to add subparsers based on options instead (as iptables does)? Currently this is not supported, but it would be a nice feature. Also, is it possible to add these subparsers dynamically? For example, you would want to be able to load a module immediately after parsing the name instead of having to keep a predetermined list of all module names. I'm pretty sure that bzr dynamically loads modules this way. Can argparse help with this? You can probably already do this. I'm not 100% sure what you want to do, but it's certainly possible to define an argparse.Action that loads a module when it's invoked. It might look something like:: class MyAction(argparse.Action): def __call__(self, parser, namespace, value, option_string=None): mod = __import__(value) # or whatever 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] PEP 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 02:40:20PM -0700, Steven Bethard wrote: Also, is it possible to add these subparsers dynamically? For example, you would want to be able to load a module immediately after parsing the name instead of having to keep a predetermined list of all module names. I'm pretty sure that bzr dynamically loads modules this way. Can argparse help with this? You can probably already do this. I'm not 100% sure what you want to do, but it's certainly possible to define an argparse.Action that loads a module when it's invoked. It might look something like:: class MyAction(argparse.Action): def __call__(self, parser, namespace, value, option_string=None): mod = __import__(value) # or whatever This looks much easier than what I was able to do in optparse. Cool. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] PEP 389: argparse - new command line parsing module
Martin alpha = None Martin beta = False Martin options, args = getopt.getopt(sys.argv[1:],a:b,['alpha=','beta']): Martin for opt, val in options: ... Martin Even though this is many more lines, I prefer it over Martin optparse/argparse: this code has only a single function call, ... Agreed. I have never completely wrapped my brain around optparse. Getopt I just remember. 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 20:44, Martin v. Löwis mar...@v.loewis.de wrote:
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
As Yuvgoog Greenle says, the canonical getopt way is to write
alpha = None
beta = False
options, args = getopt.getopt(sys.argv[1:],a:b,['alpha=','beta']):
for opt, val in options:
if arg in ('-a','--alpha'):
alpha = val
elif arg in ('-b','--beta'):
beta = True
main(alpha, beta, args)
Even though this is many more lines, I prefer it over
optparse/argparse: this code has only a single function call,
whereas the argparse version has three function calls to remember.
The actual processing uses standard Python data structures which
I don't need to look up in the documentation.
Now, Steven, can you show how best to do this in argparse?
This demonstrates my point: you were able to use getopt right away
(even though not in the traditional way), whereas you need to ask
for help on using argparse properly.
Actually, I had to read the docs for getopt. And I chose to not even
try argparse when the creator of the module is cc'ed on the email and
can obviously do a better example using his own code then I could.
-Brett
___
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] PEP 389: argparse - new command line parsing module
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. 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-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 2:31 PM, Paul Moore p.f.mo...@gmail.com wrote: 2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). +1 ___ 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] PEP 389: argparse - new command line parsing module
Paul Moore wrote: 2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). You can override ArgumentParser.error() to raise an exception. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. It looks like this might not be so easy to do. I'd suggest adding a file-like object to the constructor, defaulting to sys.stderr; or maybe an ArgumentParser.print() method that can be overridden. Eric. ___ 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote: 2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). This is behavior that argparse inherits from optparse, but I believe it's still what 99.9% of users want. If you're writing a command line interface, you don't want a stack trace when there's an error message (which is what you'd get if argparse just raised exceptions) you want an exit with an error code. That's what command line applications are supposed to do. If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. 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] PEP 389: argparse - new command line parsing module
On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard: On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote: 2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). This is behavior that argparse inherits from optparse, but I believe it's still what 99.9% of users want. If you're writing a command line interface, you don't want a stack trace when there's an error message (which is what you'd get if argparse just raised exceptions) you want an exit with an error code. That's what command line applications are supposed to do. If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. In making the method public you might want to rename it to something other than print_message. If all the messages are errors, including error in the name would be good. If not, classifying the errors vs non-errors as an extra parameter might be good (in other words... inform the user and continue, or inform the user and exit). Separating the message from the classification is not good, because that leads to dialog boxes having only an OK button, and depending on the message, it can be really inappropriate to display an OK button... buttons named Sorry, Alas!, and Exit or Quit are often more appropriate, even when there is no user choice possible. Clearly if someone is writing a GUI, they are willing to write lots of lines of code to do things... a couple more well-documented lines to integrate argparse into their chosen GUI doesn't seem onerous. Especially if they can cut, paste, and hack from the above-suggested example code, like they do for the rest of their GUI code. Well, at least, cut, paste, and hack is how I write GUIs when I bother. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] PEP 389: argparse - new command line parsing module
s...@pobox.com wrote: I have never completely wrapped my brain around optparse. Getopt I just remember. Seems to me that optparse and argparse are fairly similar in their APIs, and that argparse isn't going to be significantly easier to fit in one's brain than optparse. There's an art to coming up with an API that makes simple things easy and other things possible. I'm not convinced that argparse represents a subsantial enough advancement in that art to justify replacing optparse with it in the stdlib, and thereby forcing everyone to learn a similar-but-different API. -- Greg ___ 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] PEP 389: argparse - new command line parsing module
2009/9/29 Steven Bethard steven.beth...@gmail.com: If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. [...] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Thanks, that's fine for me (as things stand, no need to publicly expose and document _print_message). BTW, the helpful and responsive way you reply to queries is much appreciated. I'm +1 on the PEP (although I see why people want getopt to stay, so I'm happy to leave that and only deprecate optparse). 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-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard: If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. 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] PEP 389: argparse - new command line parsing module
On Sep 29, 2009, at 6:51 PM, Greg Ewing wrote: s...@pobox.com wrote: I have never completely wrapped my brain around optparse. Getopt I just remember. Seems to me that optparse and argparse are fairly similar in their APIs, and that argparse isn't going to be significantly easier to fit in one's brain than optparse. There's no question it is if you're doing more complicated stuff, like extending it or using subcommands. After I converted my code from optparse to argparse, I ended up with less stuff that was more regular and easier to understand. It convinced me that argparse is a win. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] PEP 389: argparse - new command line parsing module
On approximately 9/29/2009 4:38 PM, came the following characters from the keyboard of Steven Bethard: On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard: If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. Hmm. Maybe that is partly why (sadly) so many GUI programs don't offer much in the way of command line options. Of course, many of their users in Windowsland wouldn't know how to tweak the shortcut to invoke them with options anyway, which might be another part. Fortunately, there are some good Windows programs that do offer rich GUIs and also rich command line options (e.g. IrfanView and ImgBurn) An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. I'm not a Tk user, just coming to Python from Perl, where I used Win32::GUI, but when I was looking for a functional and portable GUI development package, Perl didn't have one (still doesn't have one that supports Unicode and printing), and Python does... so here I come to Python and Qt. From my experience in Perl GUI Windowsland, the primary issue with command line parsing is displaying the message in a dialog instead of STDOUT. But the message and the user choices have to be known at the same time to design the dialog box. And, there is nothing so aggravating as to be shown an error message, and the only option is a button that says OK, when it clearly isn't OK. So the tone/type of the messages also needs to be known, even when there are no user choices. The --help option could display the help message, and offer OK. Many errors (particularly unrecoverable ones) should display the error message, and offer an Exit button, or just the close box. A few (although probably only highly customized user options) might want to give the user multiple recovery options. So, I guess I'm in the unfortunate position of seeing the need, but not having used these specific technologies enough to offer an example either. So far, I've only used optparse (just now hearing about argparse in this thread) for command line programs in Python, and I am still just experimenting with Qt, and don't have enough familiarity with it yet to think that what I'm doing is best practices. I think it would be sad to a new replacement for optparse that didn't GUI usage, though, at least in a limited form. The concepts I describe seem sufficient from experience in other environments, and I would think they would be sufficient in Python too, but I'm too new here to state that definitely. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] PEP 389: argparse - new command line parsing module
s...@pobox.com wrote: Nick +1 here as well (although we should definitely find a way to use Nick str.format strings instead of %-format ones... come to think of Nick it, does even the logging module support str.format style Nick formatting in Py3k?) Assuming argparse currently works with versions of Python 2.6 I see no reason to make such a change. This would just introduce needless differences between the version delivered with Python and the PyPI version and make it more difficult for the author to keep the two code bases in sync. Sorry, my phrasing was poor - I should have said as well as rather than instead of. For both existing argparse users and to ease conversion from optparse to argparse, %-formatting support obviously needs to remain. We already have a problem with existing APIs not supporting the new string formatting - let's not make it worse by adding *new* APIs that only support the *old* formatting technique. 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] PEP 389: argparse - new command line parsing module
Greg Ewing wrote: s...@pobox.com wrote: I have never completely wrapped my brain around optparse. Getopt I just remember. Seems to me that optparse and argparse are fairly similar in their APIs, and that argparse isn't going to be significantly easier to fit in one's brain than optparse. There's an art to coming up with an API that makes simple things easy and other things possible. I'm not convinced that argparse represents a subsantial enough advancement in that art to justify replacing optparse with it in the stdlib, and thereby forcing everyone to learn a similar-but-different API. As someone that has written multiple optparse based utility scripts, I would say that yes, argparse is a *huge* improvement. Several things that I implemented for my own use in a rather clumsy fashion (subcommands, aggregated parsers, non-interspersed arguments) have far more elegant support built directly into argparse. For the getopt-vs-opt/argparse discussion, I believe the major distinction is in the relative balance between procedural and declarative style of argument handling. getopt is very procedural - you define a minimal amount regarding the options you accept, but then do the bulk of the command line processing yourself optparse is declarative to some degree, but forces you to drop back to a procedural style to handle arguments and subcommands. argparse takes things even further in a declarative direction by adding explicit support for positional arguments and subcommands. Regards, 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] PEP 389: argparse - new command line parsing module
Paul Moore wrote: I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Actually, sys.exit() *does* raise an exception (i.e. SystemExit) that you can catch if you want. -- Greg ___ 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] PEP 389: argparse - new command line parsing module
On Sep 29, 2009, at 8:25 PM, Nick Coghlan wrote: getopt is very procedural - you define a minimal amount regarding the options you accept, but then do the bulk of the command line processing yourself Right, and we shouldn't underestimate the cognitive load this imposes. All those twisty if-conditions are de-facto part of getopt's API. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] PEP 389: argparse - new command line parsing module
Barry Warsaw wrote: On Sep 29, 2009, at 8:25 PM, Nick Coghlan wrote: getopt is very procedural - you define a minimal amount regarding the options you accept, but then do the bulk of the command line processing yourself Right, and we shouldn't underestimate the cognitive load this imposes. All those twisty if-conditions are de-facto part of getopt's API. People assess the mental cost differently though - for getopt, they tend to assign the cost to the script they're currently writing, while for optparse/argparse they assign the cost to those two libraries being difficult to learn :) Keeping getopt around *and* including a add_getopt_arguments method in argparse is probably the best of both worlds, in that it allows for relatively straightforward evolution of an application: 1. Start with getopt 2. As the getopt argument parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. (Note that getting a good help string for free is one of the biggest gains I currently find in using optparse over getopt. This is especially so once you start making use of option groups) 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan ncogh...@gmail.com wrote: Keeping getopt around *and* including a add_getopt_arguments method in argparse is probably the best of both worlds, in that it allows for relatively straightforward evolution of an application: 1. Start with getopt 2. As the getopt argument parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. One thing that wouldn't be good in this transition is that add_getopt_arguments can only generate the part of the help string that says -a and --author exist as options -- it can't add the additional bit of text that says what they do because that's not provided to the getopt API. I suspect this makes the transition less convenient because with getopt you were probably already manually maintaining a usage message that had at least some of this information, and switching to add_getopt_arguments would mean throwing this information away. 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] PEP 389: argparse - new command line parsing module
On Sep 29, 2009, at 9:18 PM, Nick Coghlan wrote: Keeping getopt around *and* including a add_getopt_arguments method in argparse is probably the best of both worlds, in that it allows for relatively straightforward evolution of an application: 1. Start with getopt 2. As the getopt argument parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. Maybe. I haven't been following this entire thread, but I don't see much point in making it easy to go from getopt to argparse. The two are so different that I think you're either going to jump all in or not. Maybe that's just me though as I really don't see much use for getopt any more (even for throwaway scripts). -Barry PGP.sig Description: This is a digitally signed message part ___ 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw ba...@python.org wrote: Maybe. I haven't been following this entire thread, but I don't see much point in making it easy to go from getopt to argparse. I'm with you on this; specific getopt uses are more likely to be switched to opt/argparse than to shift gradually via hybrid APIs. The two are so different that I think you're either going to jump all in or not. Maybe that's just me though as I really don't see much use for getopt any more (even for throwaway scripts). Heh. I never liked getopt anyway. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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] PEP 389: argparse - new command line parsing module
Steven Bethard wrote:
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an interpreter).
[...]
This is behavior that argparse inherits from optparse, but I believe
it's still what 99.9% of users want. If you're writing a command line
interface, you don't want a stack trace when there's an error message
(which is what you'd get if argparse just raised exceptions) you want
an exit with an error code. That's what command line applications are
supposed to do.
If you're not using argparse to write command line applications, then
I don't feel bad if you have to do a tiny bit of extra work to take
care of that use case. In this particular situation, all you have to
do is subclass ArgumentParser and override exit() to do whatever you
think it should do.
2. There is no chance the parser will print things I don't want it to print.
[...]
There is only a single method in argparse that prints things,
_print_message(). So if you want it to do something else, you can
simply override it in a subclass. I can make that method public if
this is a common use case.
Instead of forcing the user to override the ArgumentParser class to
change how errors are handled, I suggest adding a separate method
ArgumentParser.parse_args_with_exceptions() that raises exceptions
instead of writing to stdout/stderr and never calls sys.exit(). Then
implement ArgumentParser.parse_args() as a wrapper around
parse_args_with_exceptions():
class ArgparseError(Exception):
argparse-specific exception type.
pass
class ArgumentError(ArgparseError):
# ...
class ArgumentParser(...):
# ...
def parse_args_with_exceptions(...):
# like the old parse_args(), except raises exceptions instead of
# writing to stdout/stderr or calling sys.exit()...
def parse_args(self, *args, **kwargs):
try:
self.parse_args_with_exceptions(*args, **kwargs)
except ArgparseError as e:
self.print_usage(_sys.stderr)
self.exit(status=2,
message=(_('%s: error: %s\n') % (self.prog, e,)))
# perhaps catch other exceptions that need special handling...
def error(self, message):
raise ArgparseError(message)
The exception classes should hold enough information to be useful to
non-command-line users, and obviously contain error messages that are
output to stderr by default. This would allow non-command-line users to
call parse_args_with_exceptions() and handle the exceptions however they
like.
Michael
___
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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. But that doesn't tell me why we should deprecate optparse, when it may work perfectly well for some people. Because it's basically unmaintained, and anything you can do in optparse you can do in argparse with almost identical syntax. So encouraging people to move from getopt and optparse to argparse is a net gain for us as Python maintainers -- that's two fewer modules in the standard library that someone has to take care of bug reports for. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote: -1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi +1 on all of this :-) It would be a shame to see getopt go but optparse - argparse seems logical. Floris ___ 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] PEP 389: argparse - new command line parsing module
If the plan is to migrate from optparse to argparse, this could be made a bit easier. If it weren't for the fact that some names are different in argparse than optparse, I believe many optparse usages could port with no change. ___ 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] PEP 389: argparse - new command line parsing module
Neal Becker wrote: If the plan is to migrate from optparse to argparse, this could be made a bit easier. If it weren't for the fact that some names are different in argparse than optparse, I believe many optparse usages could port with no change. The new names in argparse fit with the fact that argparse has a different 'rationale' than optparse. What about an optparse compatibility layer to make porting easier? Although it can't cover the whole optparse API (as explained in the PEP) it could perhaps cover most 'normal' usage? Michael ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
Doug Hellmann wrote: On Sep 27, 2009, at 6:00 PM, Michael Foord wrote: Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. I've used argparse and really like it. I could also have done with the subcommand support in recent changes to unittest. +1 for inclusion. +1 as well. I wish I had been able to use this library for a recent project using sub-commands. +1 here as well (although we should definitely find a way to use str.format strings instead of %-format ones... come to think of it, does even the logging module support str.format style formatting in Py3k?) Reading through the argparse vs optparse comparison in the argparse docs when the topic of possibly adding it came up a few weeks back I kept going yep, I've rolled my own version of that, oh, and that, yeah, that too argparse probably wouldn't have helped me even if I'd known about it (due to license review overhead), but it certainly addressed a whole heap of problems I had encountered in practice, and in ways that were a lot cleaner than the comparatively hacky approaches I had used for my own purposes (internal testing and diagnostic scripts are like that...). 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] PEP 389: argparse - new command line parsing module
Steven Bethard wrote: I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. For 2.x, I'd go even further and only have the PendingDeprecation warnings show up under the -3 command line flag. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote: On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote: -1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi +1 on all of this :-) It would be a shame to see getopt go but optparse - argparse seems logical. +1 from me too - keep getopt, deprecate optparse. ___ 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens jon+python-...@unequivocal.co.uk wrote: On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote: On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote: -1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi +1 on all of this :-) It would be a shame to see getopt go but optparse - argparse seems logical. +1 from me too - keep getopt, deprecate optparse. Ok, sounds like there are a number of supporters for keeping getopt around and just deprecating optparse. For those who'd like to keep getopt around, I have a few questions: * Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative? * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? 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] PEP 389: argparse - new command line parsing module
On Mon, 28 Sep 2009 06:59:32 am Steven Bethard wrote: Why aren't getopt and optparse enough? [snip] As a newbie, I found optparse intimidating because it provided so many features. I expect argparse will be the same, only more so. (Disclaimer: I haven't used argparse, I'm merely making a prediction based on the available functionality.) As it turned out, optparse wasn't anywhere near as difficult to use as I expected it to be, but I suggest that newbies will have the same response to argparse as I had to optparse -- this looks complicated, I'll just roll my own. At least I had the option to use getopt. Not every module needs to be newbie-friendly, but something as fundamental as argument parsing should at least provide a gentle learning curve. Currently, getopt more-or-less plays the role of bare-bones command line parsing, which I think is important. Assuming argparse is added to the std lib, I'm -0.5 on deprecating getopt, 0 on deprecating optparse. -- Steven D'Aprano ___ 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker ndbeck...@gmail.com wrote: If the plan is to migrate from optparse to argparse, this could be made a bit easier. If it weren't for the fact that some names are different in argparse than optparse, I believe many optparse usages could port with no change. I could conceivably add an OptionParser class which:: * Has an add_option method which delegates to add_argument * Has a parse_args method which delegates to parse_known_args * Registers the string names for types that optparse uses That might allow some users to just switch their import as long as they're not using any callbacks, catching any exceptions, extending any APIs, etc. I'm not 100% convinced that it's good to add a subtly different API that people would have to unlearn, but if there's enough support for this, I'm open to the idea. 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] PEP 389: argparse - new command line parsing module
Nick +1 here as well (although we should definitely find a way to use Nick str.format strings instead of %-format ones... come to think of Nick it, does even the logging module support str.format style Nick formatting in Py3k?) Assuming argparse currently works with versions of Python 2.6 I see no reason to make such a change. This would just introduce needless differences between the version delivered with Python and the PyPI version and make it more difficult for the author to keep the two code bases in sync. 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
Antoine Pitrou wrote: Hello, I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. You can add me to that camp as well: +0 on adding argparse -1 on deprecating wide-used modules such as getopt and optparse Note that the last -1 only applies to the module APIs, not the code in those modules. If argparse provides an API compatibility layer for getopt and optparse, the original code of getopt and optparse could go without problem, IMHO, leaving only the mostly empty modules together with compatibility layers. OTOH, as discussed on the stdlib SIG list, those two modules hardly ever require any maintenance, so keeping them as they are is certainly an option as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 28 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PEP 389: argparse - new command line parsing module
M.-A. Lemburg wrote: Antoine Pitrou wrote: Hello, I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. You can add me to that camp as well: +0 on adding argparse -1 on deprecating wide-used modules such as getopt and optparse Note that the last -1 only applies to the module APIs, not the code in those modules. If argparse provides an API compatibility layer for getopt and optparse, the original code of getopt and optparse could go without problem, IMHO, leaving only the mostly empty modules together with compatibility layers. OTOH, as discussed on the stdlib SIG list, those two modules hardly ever require any maintenance, so keeping them as they are is certainly an option as well. Although as also discussed on the stdlib-sig there is also a cost to leaving unmaintained and unneeded modules in the standard library. As we are 'end-of-lifing' Python 2.X there seems to be little point in going down the deprecation route (there won't be enough releases to ever get to module removal) but discussion about the standard library in situations like this is badly needed for 3.X. Certainly a slow deprecation procedure, as suggested by Steven, is warranted. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
* Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative? from the top of http://docs.python.org/library/getopt.html - A more convenient, flexible, and powerful alternative is the optparse module.I think this statement should be emphasized better but it's already there so no worries. * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? Argparse/optparse use a parser instance and getopt doesn't. I think that's a saved line you have to keep saving so this would be the better syntax imho: optlist, args = argparse.getopt(args, 'abc:d:') I was thinking on the general issue of what's better for the std-lib: 1. Mini modules - 3+ small modules in each subject that can be useful in different contexts. For example the xml libs. or 2. Big modules - 1 uber-module for each subject that does everything. Maybe logging is an example of this. I think in general python std-lib went the path of mini modules. Its advantages 1. Each mini module can be coherent and while python isn't really OnlyOneWayToDoIt, each module in itself has OnlyOneWayToDoIt. 2. Documentation is less cluttered by a large amount of functions that all do the same thing but differently. This is very important for python's learning curve. disadvantages: 1. You have to craft your documentation carefully as to be very explicit on why you have all these modules for the same thing. Probably each module should explain it's purpose in relation to the other modules and this explanation should appear at the top of the documentation of each of the mini modules in the subject. Today it would be very hard for me to figure out how the xml modules interrelate, urllib has improved in python3 but still isn't perfect. 2. I could be using some silly way of doing things (getopt) while I really wanted to do it the good way (argparse). I think that while adding getopt functionality to argparse might be nice but would eventually cause clutter. ___ 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] PEP 389: argparse - new command line parsing module
Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Chaining Configuration -- Ugly code to cascade configuration class Unset(object): pass def cascade_value(opt=None, opt_name=None, env_name=None, cfg=None, cfg_section=None, cfg_name=None, default=None): ... ...opt - result of OptionParser.parse_args ...opt_name - string of opt name you want to access ... ...# get from cmd line ...value = Unset() ...if opt and opt_name: ...try: ...value = opt.__getattr__(opt_name) ...except AttributeError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from ENV ...if env_name: ...try: ...value = os.environ[env_name] ...except KeyError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from config file ...if cfg and cfg_section and cfg_name: ...try: ...value = cfg.get(cfg_section, cfg_name) ...except ConfigParser.NoOptionError, e: ...pass ...if not isinstance(value, Unset): ...return value ...return default cascade_value(opt=opt, opt_name='author', cfg=cfg, cfg_section='Properties', cfg_name='author') 'Matt' Does anyone else have interest in such functionality? Is it outside the realm of this PEP? Ideally I'd like to have something like ``env_name``, ``config_key`` named parameters for options, then pass an optional list of configs files to the parser instance. Then rather than looking solely at command line options, argparse could also pull values from config files, then env and finally the command line. cheers, matt harrison 0 - http://www.faqs.org/docs/artu/ch10s02.html ___ 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] PEP 389: argparse - new command line parsing module
m h wrote: Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Integration with command line options is an occasionally-requested feature for ConfigObj. I've always said I would be open to patches... In other words, yes I think there is demand for it. Whether it belongs *immediately* in the standard library is another matter, but if you wrote a layer that unified ConfigParser and argparse I think you will find that people use it. It is well outside the realm of this PEP however. All the best, Michael Foord Chaining Configuration -- Ugly code to cascade configuration class Unset(object): pass def cascade_value(opt=None, opt_name=None, env_name=None, cfg=None, cfg_section=None, cfg_name=None, default=None): ... ...opt - result of OptionParser.parse_args ...opt_name - string of opt name you want to access ... ...# get from cmd line ...value = Unset() ...if opt and opt_name: ...try: ...value = opt.__getattr__(opt_name) ...except AttributeError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from ENV ...if env_name: ...try: ...value = os.environ[env_name] ...except KeyError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from config file ...if cfg and cfg_section and cfg_name: ...try: ...value = cfg.get(cfg_section, cfg_name) ...except ConfigParser.NoOptionError, e: ...pass ...if not isinstance(value, Unset): ...return value ...return default cascade_value(opt=opt, opt_name='author', cfg=cfg, cfg_section='Properties', cfg_name='author') 'Matt' Does anyone else have interest in such functionality? Is it outside the realm of this PEP? Ideally I'd like to have something like ``env_name``, ``config_key`` named parameters for options, then pass an optional list of configs files to the parser instance. Then rather than looking solely at command line options, argparse could also pull values from config files, then env and finally the command line. cheers, matt harrison 0 - http://www.faqs.org/docs/artu/ch10s02.html ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote: Ok, sounds like there are a number of supporters for keeping getopt around and just deprecating optparse. For those who'd like to keep getopt around, I have a few questions: * Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative? +1 * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? 0 * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? Simplicity of the learning curve. Using it is as simple as: getopt.getopt(sys.argv[1:], a:b, [alpha=, beta]) Does argparse allow anything as simple as that? -- Steven D'Aprano ___ 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 4:57 PM, Brett Cannon br...@python.org wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. +1 to what brett said. jesse ___ 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: m h wrote: Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Integration with command line options is an occasionally-requested feature for ConfigObj. I've always said I would be open to patches... In other words, yes I think there is demand for it. Whether it belongs *immediately* in the standard library is another matter, but if you wrote a layer that unified ConfigParser and argparse I think you will find that people use it. It is well outside the realm of this PEP however. What Michael said. ;-) If you'd like to provide a patch for argparse that provides such functionality, I'd be happy to review it. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote: * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? 0 * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? Simplicity of the learning curve. Using it is as simple as: getopt.getopt(sys.argv[1:], a:b, [alpha=, beta]) You forgot the for-loop, nested if/else statements and type conversions. ;-) Does argparse allow anything as simple as that? If you mean, does argparse allow configuration to be specified using the getopt style (a:b, [alpha=, beta]), no, it currently doesn't. But if this is useful functionality, and would reasonably replace the getopt use cases, then I'd be happy to add it. In the simplest version, we might add something like:: options, args = argparse.getopt(a:b, [alpha=, beta]) where you could then use options without any looping:: alpha = options.a or options.alpha beta = options.b or options.beta But if people still like the traditional getopt loop with nested if/elses better, then we might as well just keep getopt around and not add anything to argparse. I'm fine with that too, I just want to make sure that there isn't an obvious deficiency in argparse that we could easily fix. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 07:28:39AM -0700, Steven Bethard wrote: Ok, sounds like there are a number of supporters for keeping getopt around and just deprecating optparse. For those who'd like to keep getopt around, I have a few questions: * Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative? No, I'd encourage such a note. * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? That looks nice indeed. * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? If clearly documented as Hey, getopt users, check this out! then I'd be indifferent to the proposed deprecation of getopt. Regards Floris ___ 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] PEP 389: argparse - new command line parsing module
On 2009-09-28 10:37 AM, Steven Bethard wrote: On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: m h wrote: Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Integration with command line options is an occasionally-requested feature for ConfigObj. I've always said I would be open to patches... In other words, yes I think there is demand for it. Whether it belongs *immediately* in the standard library is another matter, but if you wrote a layer that unified ConfigParser and argparse I think you will find that people use it. It is well outside the realm of this PEP however. What Michael said. ;-) If you'd like to provide a patch for argparse that provides such functionality, I'd be happy to review it. cfgparse appears to fill this role for optparse. It might be straightforward to port it to argparse. http://cfgparse.sourceforge.net/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 9:37 AM, Steven Bethard steven.beth...@gmail.com wrote: On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: m h wrote: Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Integration with command line options is an occasionally-requested feature for ConfigObj. I've always said I would be open to patches... In other words, yes I think there is demand for it. Whether it belongs *immediately* in the standard library is another matter, but if you wrote a layer that unified ConfigParser and argparse I think you will find that people use it. Having it integrated with the option parser is ideal. More people will use it if it is in the stdlib. Just like more people will use argparse. It is well outside the realm of this PEP however. What Michael said. ;-) If you'd like to provide a patch for argparse that provides such functionality, I'd be happy to review it. Patch submitted [0]. Accidentally marked as Defect instead of enhancement. Comments/critiques welcome. 0 - http://code.google.com/p/argparse/issues/detail?id=35q=label%3AType-Defect Cheers, -matt 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 08:49, Steven Bethard steven.beth...@gmail.com wrote:
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments method (as
in my other post)?
0
* If argparse grew an add_getopt_arguments, would you still want to
keep getopt around? And if so, why?
Simplicity of the learning curve. Using it is as simple as:
getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
You forgot the for-loop, nested if/else statements and type conversions. ;-)
=) I do wonder if people who are advocating for getopt sticking around
realize how much extra code must be written to make sure what it gives
back to you is in some sane manner.
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
Now, Steven, can you show how best to do this in argparse? I am
willing to bet that the total number of lines to do this is not that
much more and does not require you to know to use 'or' or the dict
constructor along with dict.get() in order to keep it compact. I can
only imagine what some newbie might try to do in order to be correct
(if they even try).
-Brett
___
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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon br...@python.org wrote:
On Mon, Sep 28, 2009 at 08:49, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments method (as
in my other post)?
0
* If argparse grew an add_getopt_arguments, would you still want to
keep getopt around? And if so, why?
Simplicity of the learning curve. Using it is as simple as:
getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
You forgot the for-loop, nested if/else statements and type conversions. ;-)
=) I do wonder if people who are advocating for getopt sticking around
realize how much extra code must be written to make sure what it gives
back to you is in some sane manner.
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
Now, Steven, can you show how best to do this in argparse?
Here's the same option parsing in argparse:
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
args = parser.parse_args()
main(args.alpha, args.beta)
Or if those final positional arguments were actually meaningful, then
you would add one more argument like this::
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
parser.add_argument('gammas', nargs='*')
args = parser.parse_args()
main(args.alpha, args.beta, args.gammas)
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] PEP 389: argparse - new command line parsing module
for a live demo of how getopt is useful and flexible, I like how Audacity
uses it:
http://www.google.com/codesearch/p?hl=ensa=Ncd=6ct=rc#_hWFOhGz9lE/mezzo/scons/sconsign.pyq=getopt%20%22import%20getopt%22%20file:%5C.py$l=264
To answer your question, it goes like this:
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
for o, a in options:
if o in ('-a', '--alpha'):
alpha = a
elif o in ('-b', '--beta'):
beta = a
main(alpha, beta, args)
Notice a few things:
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an interpreter).
2. There is no chance the parser will print things I don't want it to print.
3. You can do whatever you want using this flow - call a function, a binary
operator (ie | is used in audacity scons example above)
4. in argparse this flow can be emulated and would be nicer, in ('-a',
'--alpha') becomes == 'alpha'
In a perfect world, getopt would be the low level parser that argparse and
optparse rely on. This is not too far fetched btw, all that needs to be done
is add another optional argument to getopt that would allow '-' and '--' to
be replaced with arbitrary signs, OR moving the parsing code from argparse
into getopt.
On Mon, Sep 28, 2009 at 10:57 PM, Steven Bethard
steven.beth...@gmail.comwrote:
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon br...@python.org wrote:
On Mon, Sep 28, 2009 at 08:49, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info
wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments method (as
in my other post)?
0
* If argparse grew an add_getopt_arguments, would you still want to
keep getopt around? And if so, why?
Simplicity of the learning curve. Using it is as simple as:
getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
You forgot the for-loop, nested if/else statements and type conversions.
;-)
=) I do wonder if people who are advocating for getopt sticking around
realize how much extra code must be written to make sure what it gives
back to you is in some sane manner.
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
Now, Steven, can you show how best to do this in argparse?
Here's the same option parsing in argparse:
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
args = parser.parse_args()
main(args.alpha, args.beta)
Or if those final positional arguments were actually meaningful, then
you would add one more argument like this::
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
parser.add_argument('gammas', nargs='*')
args = parser.parse_args()
main(args.alpha, args.beta, args.gammas)
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/ubershmekel%40gmail.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] PEP 389: argparse - new command line parsing module
On 27Sep2009 21:24, Steven Bethard steven.beth...@gmail.com wrote: | On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote: | If you think getopt and optparse should stick around in 3.X, why is | that? If you think there are things that getopt and optparse do better | than argparse, could you please give some examples? | | I personally consider getopt superior to both optparse and argparse. | Those are terribly verbose in specifying arguments, whereas getopt's | sequence-of-letters is really nice and compact. | | Thanks for the concrete example. Although I'm unconvinced that the | characters you save in the sequence of letters in the getopt.getopt | call aren't afterwards wasted on type conversions, if/else statements | and variable assignments in the subsequent loop, it would be pretty | simple to add to argparse something like:: | | ArgumentParser.add_getopt_arguments(options[, long_options]) Yes please! I'm also very fond of the succinct getopt sequence-of-letters style; it works really well for the simple cases. Disclaimer: I've not used the optparse et al modules because getopt has covered my needs and my C background made getopt the natural module to start with. I have written simple getopt-equivalent option parsers a number of times though. (Of course, that choice also drives me to adapt my option wishes to stuff that getopt can do:-) Clarification: this isn't a vote for preferring getopt, it's a vote for availability of the sequence-of-letters style. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ The most annoying thing about being without my files after our disc crash was discovering once again how widespread BLINK was on the web. ___ 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 07:44:50AM +1000, Cameron Simpson wrote: | ArgumentParser.add_getopt_arguments(options[, long_options]) Yes please! I'm also very fond of the succinct getopt sequence-of-letters style; it works really well for the simple cases. The syntax a:b is also widely known; people who are often write small shell scripts are certainly accustomed to it (I am). Clarification: this isn't a vote for preferring getopt, it's a vote for availability of the sequence-of-letters style. +1 Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] PEP 389: argparse - new command line parsing module
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
As Yuvgoog Greenle says, the canonical getopt way is to write
alpha = None
beta = False
options, args = getopt.getopt(sys.argv[1:],a:b,['alpha=','beta']):
for opt, val in options:
if arg in ('-a','--alpha'):
alpha = val
elif arg in ('-b','--beta'):
beta = True
main(alpha, beta, args)
Even though this is many more lines, I prefer it over
optparse/argparse: this code has only a single function call,
whereas the argparse version has three function calls to remember.
The actual processing uses standard Python data structures which
I don't need to look up in the documentation.
Now, Steven, can you show how best to do this in argparse?
This demonstrates my point: you were able to use getopt right away
(even though not in the traditional way), whereas you need to ask
for help on using argparse properly.
I am
willing to bet that the total number of lines to do this is not that
much more and does not require you to know to use 'or' or the dict
constructor along with dict.get() in order to keep it compact.
See above - getopt users don't care about compactness in
the processing.
I can
only imagine what some newbie might try to do in order to be correct
(if they even try).
Depends on the background of the newbie. If they come from C, they
immediately recognize the way of doing things.
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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:44 PM, Martin v. Löwis mar...@v.loewis.de wrote: Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])`` As Yuvgoog Greenle says, the canonical getopt way is to write [snip getopt code] Even though this is many more lines, I prefer it over optparse/argparse: this code has only a single function call, whereas the argparse version has three function calls to remember. The actual processing uses standard Python data structures which I don't need to look up in the documentation. Now, Steven, can you show how best to do this in argparse? This demonstrates my point: you were able to use getopt right away (even though not in the traditional way), whereas you need to ask for help on using argparse properly. I don't think this is fair at all. I am totally unable to write getopt code without checking the documentation -- I don't remember the format string syntax, nor what the function returns. But that's just how library modules work -- if you don't know the library, you have to read the documentation. The only reason getopt is easier for you is that you're already familiar with the API from C. That said, I can certainly understand that folks who use getopt in C would have an easy transition to getopt in Python and a harder transition to argparse. You didn't directly answer my question of whether adding an add_getopt_arguments function would meet your needs, but I infer from your answer above that it wouldn't because you'd still need to make multiple function calls which is your primary complaint. So at this point, I think it's clear that there's nothing I can reasonably add to argparse to make getopt people more comfortable that isn't just duplicating what's already in getopt. So let's just deprecate optparse (as in the PEP), and leave getopt alone (other than adding a note to the documentation suggesting argparse as an alternative). -- 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] PEP 389: argparse - new command line parsing module
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).
I think argprase is a good improvement over what we have now (getopt
and optparse), it's stable, considered best-of-breed by the community
for a while (as shown as how many times argparse has been suggestion
for inclusion), and Steven is already a core committer so is already
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.
On Sun, Sep 27, 2009 at 13:59, Steven Bethard steven.beth...@gmail.com wrote:
[SNIP]
Deprecation of getopt and optparse
==
There is still some debate over the best way (if at all) to encourage
users to move from getopt and optparse to their replacement,
argparse. The current recommendation of this PEP is the following
conservative deprecation strategy:
* Python 3.2, Python 2.7 and any later Python 2.X releases --
PendingDeprecation warnings, which by default are not displayed,
and documentation notes directing users of getopt and optparse to
argparse.
* Python 3.3 -- Same as above
* Python 3.4 -- Deprecation warnings for getopt and optparse, which
by default *are* displayed.
Though this is slower than the usual deprecation process, it seems
prudent to avoid producing any casually visible Deprecation warnings
until Python 3.X has had some additional time to attract developers.
Just to give people ideas of how long these deprecations would last,
if Python 3.2 is released in June 2010 and we continue on our 18 month
release schedule (and actually release that quickly which we typically
don't), then getopt/optparse would have a pending deprecation for 3
years (until June 2013) and a deprecation warning for 1.5 years (until
January 2015), so 4.5 years total once the deprecations began and six
years since Python 3.0 came out. And obviously the deprecation can be
extended if it turns out Python 3 pick up is now at a rate we expect
(but only if people who plan to port are having issues; this does not
concern those who plan to stay on Python 2 indefinitely and do not
care about Python 3).
And we can also document suggestions on how to transition off of
getopt/optparse like Steven has in the argparse code
(http://argparse.googlecode.com/svn/tags/r101/doc/argparse-vs-optparse.html#upgrading-optparse-code).
Open Issues
===
The argparse module supports Python from 2.3 up through 3.2 and as a
result relies on traditional ``%(foo)s`` style string formatting. It
has been suggested that it might be better to use the new style
``{foo}`` string formatting [13]_. This seems like a good idea, but
would break backwards compatibility for existing argparse-based
scripts unless we can come up with a way to reasonably support both
syntaxes.
I see two solutions to this. One is to auto-detect either format and
then do the right thing. Seems potentially messy, although getting the
regex right shouldn't be a problem.
The other option is to rename the module if it is added to the
standard library ala simplejson/json. That would alleviate any issues
with someone including their own copy of argparse with their
application using %()s string interpolation over {}. I don't have a
name to suggest at the moment (nor do I think we should start
discussing that now unless this is a chosen solution), but it would
deal with the problem.
Either way, with {} being the future and talk of someday dropping %, I
think we should make sure the newer syntax is at least supported, if
not the only way to do things.
-Brett
___
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] PEP 389: argparse - new command line parsing module
Brett Cannon wrote:
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).
I think argprase is a good improvement over what we have now (getopt
and optparse), it's stable, considered best-of-breed by the community
for a while (as shown as how many times argparse has been suggestion
for inclusion), and Steven is already a core committer so is already
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.
I've used argparse and really like it. I could also have done with the
subcommand support in recent changes to unittest.
+1 for inclusion.
Michael
On Sun, Sep 27, 2009 at 13:59, Steven Bethard steven.beth...@gmail.com wrote:
[SNIP]
Deprecation of getopt and optparse
==
There is still some debate over the best way (if at all) to encourage
users to move from getopt and optparse to their replacement,
argparse. The current recommendation of this PEP is the following
conservative deprecation strategy:
* Python 3.2, Python 2.7 and any later Python 2.X releases --
PendingDeprecation warnings, which by default are not displayed,
and documentation notes directing users of getopt and optparse to
argparse.
* Python 3.3 -- Same as above
* Python 3.4 -- Deprecation warnings for getopt and optparse, which
by default *are* displayed.
Though this is slower than the usual deprecation process, it seems
prudent to avoid producing any casually visible Deprecation warnings
until Python 3.X has had some additional time to attract developers.
Just to give people ideas of how long these deprecations would last,
if Python 3.2 is released in June 2010 and we continue on our 18 month
release schedule (and actually release that quickly which we typically
don't), then getopt/optparse would have a pending deprecation for 3
years (until June 2013) and a deprecation warning for 1.5 years (until
January 2015), so 4.5 years total once the deprecations began and six
years since Python 3.0 came out. And obviously the deprecation can be
extended if it turns out Python 3 pick up is now at a rate we expect
(but only if people who plan to port are having issues; this does not
concern those who plan to stay on Python 2 indefinitely and do not
care about Python 3).
And we can also document suggestions on how to transition off of
getopt/optparse like Steven has in the argparse code
(http://argparse.googlecode.com/svn/tags/r101/doc/argparse-vs-optparse.html#upgrading-optparse-code).
Open Issues
===
The argparse module supports Python from 2.3 up through 3.2 and as a
result relies on traditional ``%(foo)s`` style string formatting. It
has been suggested that it might be better to use the new style
``{foo}`` string formatting [13]_. This seems like a good idea, but
would break backwards compatibility for existing argparse-based
scripts unless we can come up with a way to reasonably support both
syntaxes.
I see two solutions to this. One is to auto-detect either format and
then do the right thing. Seems potentially messy, although getting the
regex right shouldn't be a problem.
The other option is to rename the module if it is added to the
standard library ala simplejson/json. That would alleviate any issues
with someone including their own copy of argparse with their
application using %()s string interpolation over {}. I don't have a
name to suggest at the moment (nor do I think we should start
discussing that now unless this is a chosen solution), but it would
deal with the problem.
Either way, with {} being the future and talk of someday dropping %, I
think we should make sure the newer syntax is at least supported, if
not the only way to do things.
-Brett
___
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/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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] PEP 389: argparse - new command line parsing module
On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. FWIW, +1 from IPython: we ship a private copy of argparse as well (we use it in several places but we want the basic ipython to be installable just with the stdlib). Steven was gracious enough to relicense it as BSD at our request: http://mail.scipy.org/pipermail/ipython-dev/2009-September/005537.html so we could ship this copy without any GPL incompatibilities, but we'd much rather rely on stdlib components. Best, f ___ 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:31 PM, Fernando Perez fperez@gmail.comwrote: On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. FWIW, +1 from IPython: we ship a private copy of argparse as well (we use it in several places but we want the basic ipython to be installable just with the stdlib). Steven was gracious enough to relicense it as BSD at our request: +1 Coincidentally I was converting several packages to argparse as I saw the python-dev mail come in. A great deal of hairy code needed to jury-rig sub-commands and other advanced processing with optparse is simply disappearing. I like the idea that stdlib can evolve to encompass best of breed solutions and that effort is being expended to improve existing functionality even if it means increasing the diversity of APIs. ~Kevin ___ 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] PEP 389: argparse - new command line parsing module
Hello, I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. 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] PEP 389: argparse - new command line parsing module
On Sep 27, 2009, at 6:00 PM, Michael Foord wrote: Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. I've used argparse and really like it. I could also have done with the subcommand support in recent changes to unittest. +1 for inclusion. +1 as well. I wish I had been able to use this library for a recent project using sub-commands. Doug ___ 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote: I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. Could you elaborate? If you are worried about Python 2.X scripts, note from the PEP that the only things that will ever show up in Python 2.X are: PendingDeprecation warnings, which by default are not displayed, and documentation notes directing users of getopt and optparse to argparse. I think these messages are useful for folks using 2.X who some day would like to migrate to 3.X, and at the same time should have zero effect on existing scripts. If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. 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] PEP 389: argparse - new command line parsing module
-1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi On Mon, Sep 28, 2009 at 6:46 AM, Steven Bethard steven.beth...@gmail.comwrote: On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. 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/ubershmekel%40gmail.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] PEP 389: argparse - new command line parsing module
If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in specifying arguments, whereas getopt's sequence-of-letters is really nice and compact. 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] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. -- 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%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard steven.beth...@gmail.com: On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? -- 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%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in specifying arguments, whereas getopt's sequence-of-letters is really nice and compact. Thanks for the concrete example. Although I'm unconvinced that the characters you save in the sequence of letters in the getopt.getopt call aren't afterwards wasted on type conversions, if/else statements and variable assignments in the subsequent loop, it would be pretty simple to add to argparse something like:: ArgumentParser.add_getopt_arguments(options[, long_options]) Then you could replace your getopt code:: try: opts, args = getopt.getopt(sys.argv[1:], ho:v, [help, output=]) except getopt.GetoptError, err: # print help information and exit: print str(err) # will print something like option -a not recognized usage() sys.exit(2) output = None verbose = False for o, a in opts: if o == -v: verbose = True elif o in (-h, --help): usage() sys.exit() elif o in (-o, --output): output = a else: assert False, unhandled option with argparse code like:: parser = argparse.ArgumentParser() parser.add_getopt_arguments(ho:v, [help, output=]) args = parser.parse_args() verbose = args.v output = args.o or args.output If something like this were available, would you be alright with deprecating getopt? 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
