2009/10/8 Paul Moore :
> 2009/10/7 Antoine Pitrou :
>> 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 std
2009/10/7 Antoine Pitrou :
> 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, yo
Hrvoje Niksic 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 destru
Paul Moore wrote:
Traceback (most recent call last):
File "hello.py", line 13, in
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 sta
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 t
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 Sy
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 V
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_
* 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 imp
On Sat, Oct 3, 2009 at 8:29 PM, Steven D'Aprano 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 talki
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 Sys
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:
> #
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord 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
Yuvgoog Greenle wrote:
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord 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-
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
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord wrote:
> Steven Bethard wrote:
>> On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle
>> 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
Steven Bethard wrote:
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle 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 beca
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle 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
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.
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 ou
On 09/29/2009 04:38 PM, Steven Bethard wrote:
> On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman
> 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 do
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 yo
2009/9/30 Robert Kern :
> 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,
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.
>
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb 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
Brett Cannon 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 agr
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
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
On Wed, Sep 30, 2009 at 09:21, Vinay Sajip wrote:
> Brett Cannon 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
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 wor
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
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 ha
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,
Brett Cannon 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.
Yuvgoog Greenle 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,
2009/9/30 Greg Ewing :
> 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.
That's a good point...
Paul
___
Steven Bethard wrote:
> On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
>> 2009/9/28 Yuvgoog Greenle :
>>> 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 interpr
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw 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 gradual
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 6: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 getop
Greg Ewing wrote:
> 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.
I was going to mention that. Between c
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 thi
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
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
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 op
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 argpars
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 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
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 o
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman 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
2009/9/29 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 w
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 comi
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 wrote:
2009/9/28 Yuvgoog Greenle :
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing e
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 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 wor
Paul Moore wrote:
2009/9/28 Yuvgoog Greenle :
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 f
On Tue, Sep 29, 2009 at 2:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 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 wor
2009/9/28 Yuvgoog Greenle :
> 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
On Mon, Sep 28, 2009 at 20:44, "Martin v. Löwis" 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
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 sing
On Mon, Sep 28, 2009 at 8:44 PM, "Martin v. Löwis" 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
> 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:],
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
On 27Sep2009 21:24, Steven Bethard wrote:
| On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" 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
for a live demo of how getopt is useful and flexible, I like how Audacity
uses it:
http://www.google.com/codesearch/p?hl=en&sa=N&cd=6&ct=rc#_hWFOhGz9lE/mezzo/scons/sconsign.py&q=getopt%20%22import%20getopt%22%20file:%5C.py$&l=264
To answer your question, it goes like this:
options, args = geto
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon wrote:
> On Mon, Sep 28, 2009 at 08:49, Steven Bethard
> wrote:
>> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
>>> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments meth
On Mon, Sep 28, 2009 at 08:49, Steven Bethard wrote:
> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano 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
On Mon, Sep 28, 2009 at 9:37 AM, Steven Bethard
wrote:
> On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
> 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 th
On 2009-09-28 10:37 AM, Steven Bethard wrote:
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
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
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 doc
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano 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 getop
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
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 h
On Sun, Sep 27, 2009 at 4:57 PM, 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 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
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
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
>
> * 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
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 cam
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
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 o
On Mon, Sep 28, 2009 at 4:09 AM, 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.
I could
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 pred
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens
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
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 deprecati
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
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 argpar
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 fac
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
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 havin
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson
>> wrote:
>>> 2009/9/27 Steven Bethard :
The first release where any real deprecation message would show up is
Python 3.4, more than 3 years away
On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" 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 superio
2009/9/27 Steven Bethard :
> On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson
> wrote:
>> 2009/9/27 Steven Bethard :
>>> 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 pl
2009/9/27 Steven Bethard :
> 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
> 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 sp
-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,
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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 stic
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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?
>
> Transit
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou 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
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
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 m
On Sun, Sep 27, 2009 at 8:31 PM, Fernando Perez wrote:
> 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
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
1 - 100 of 103 matches
Mail list logo
