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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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,
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,
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
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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,
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:
Below is a new PEP based on discussions from the stdlib-sig, which
proposes to add the argparse module to the standard library in Python
2.7 and 3.2.
Looking forward to your feedback!
Steve
http://www.python.org/dev/peps/pep-0389/
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
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
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
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
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
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
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
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
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
-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,
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
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.
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
1 - 100 of 101 matches
Mail list logo
