[issue6247] should we include argparse

R. David Murray added the comment: PEP 389 has been accepted. -- components: +Library (Lib) -Extension Modules priority: -> normal resolution: -> accepted stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue6247] should we include argparse

Steven Bethard added the comment: @techtonik: If you have a specific feature request for argparse, I recommend that you file an issue on the argparse tracker[1]. I assure you that despite the fact that you only have need for a couple of the constructor parameters, the rest exist because people h

[issue6247] should we include argparse

anatoly techtonik added the comment: Argparse seems to be overloaded with rarely used features. Instead of providing API to add these features and allow users copy examples it tends to be an all-in- one solution that is hard to use due to abundance of specific parameters. Look at constructor,

[issue6247] should we include argparse

Jesse Noller added the comment: Armin; if you are serious in wanting to help out with the stdlib and core work, feel free to help us discuss this over on the stdlib-sig (http://mail.python.org/pipermail/stdlib-sig/2009-September/000398.html) or help commit patches and fixes for all of the mod

[issue6247] should we include argparse

Gregory P. Smith added the comment: On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher wrote: > > Armin Ronacher added the comment: > >> @Armin: Doesn't that argument apply to *any* library proposed for >> inclusion in the standard library? By which logic we should never add >> anything to the s

[issue6247] should we include argparse

Michael Foord added the comment: He has a few important feature requests to deal with as well. -- ___ Python tracker ___ ___ Python-bu

[issue6247] should we include argparse

Georg Brandl added the comment: I think optparse just got a new maintainer. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-b

[issue6247] should we include argparse

Armin Ronacher added the comment: > It must be convenient to operate in an environment where you can > install new software so easily Armin. Trust me, it is. > For others (including me), the actual package installation is the > least of our hassles and anything that helps us avoid dealing wit

[issue6247] should we include argparse

Nick Coghlan added the comment: It must be convenient to operate in an environment where you can install new software so easily Armin. For those of us that operate in environments where every new piece of software has to go through contracts review to ensure that we can both license it for our

[issue6247] should we include argparse

Michael Foord added the comment: Command line parsing is a basic need, including amongst other standard library modules. argparse has many advantages over optparse (not the least of which is that it has an active maintainer). Several of these features *can't* be added to optparse whilst maintain

[issue6247] should we include argparse

R. David Murray added the comment: I disagree. I think option and argument parsing belongs in the standard (batteries included) library, regardless of how well external package management works. argparse has the advantage over optparse that it has an active maintainer. What we do about the

[issue6247] should we include argparse

Armin Ronacher added the comment: > I can respect that viewpoint. So what do you propose to do with > existing modules like optparse that aren't required to make platform > independent applications and are out of date and basically > unmaintained? One option would be to remove them, but that's p

[issue6247] should we include argparse

Steven Bethard added the comment: [snip] > Fix packaging and do not dump useless stuff into the standard library to > make it appear more modern. Decentralization is modern, not replacing > modules in the stdlib. I can respect that viewpoint. So what do you propose to do with existing modules l

[issue6247] should we include argparse

Armin Ronacher added the comment: > @Armin: Doesn't that argument apply to *any* library proposed for > inclusion in the standard library? By which logic we should never add > anything to the standard library ever again. That's what I say. Do not add anything to the stdlib that is not needed to

[issue6247] should we include argparse

Steven Bethard added the comment: @Armin: Doesn't that argument apply to *any* library proposed for inclusion in the standard library? By which logic we should never add anything to the standard library ever again. Surely you don't mean that, so could you be more specific on what you think is pa

[issue6247] should we include argparse

Armin Ronacher added the comment: Why does this have to go into the standard library? People that want to use it can still install it from PyPI. -sys.maxint from me. -- nosy: +aronacher ___ Python tracker _

[issue6247] should we include argparse

Nick Coghlan added the comment: Only +0 purely because I haven't used argparse myself yet. Otherwise I would probably be +1, since I have several scripts that have fairly kludgy hacked together optparse based approaches to handling positional arguments, subparsers and building new parsers that

[issue6247] should we include argparse

Michael Foord added the comment: This was rejected prior to Steven Bethard becoming involved, so I'm reopening. +1 from me - argparse is a great module to use. -- nosy: +michael.foord resolution: rejected -> status: closed -> open ___ Python tracke

[issue6247] should we include argparse

R. David Murray added the comment: I'm +1 on inclusion one way or another as well. I haven't made time to do anything other than a cursory code review, but as an end user I find the module fits my needs much better than optparse. -- nosy: +r.david.murray __

[issue6247] should we include argparse

Gregory P. Smith added the comment: we should never pretend an old module doesn't exist. leave optparse as optparse. argparse can come in under its own name. we can mark getopt and optparse as deprecated at some point and remove them in 10 years :) +1 on inclusion btw. It looks like it'll o

[issue6247] should we include argparse

Mark Lodato added the comment: I would also like to voice support for including argparse in the standard library. It seems silly to deny a module from being added just because we already have two inferior ones. Argparse adds so many new (and badly needed!) features that it would be very diffic

[issue6247] should we include argparse

Steven Bethard added the comment: Yeah, the % formatting is an artifact of argparse being around before str.format was available. If argparse became part of the standard library, it might be reasonable to change to str.format formatting instead as part of the move. It would mean that folks woul

[issue6247] should we include argparse

Eric Smith added the comment: It's unfortunate (at least to me, but I know I have a skewed view of this) that the help string in add_argument uses %-formatting when formatting the result. I'd much rather it use str.format(). I see a couple of options: - leave it as-is and live with %-formatting

[issue6247] should we include argparse

Eric Smith added the comment: I'll take a look at it. I've been meaning to use argparse, anyway. -- nosy: +eric.smith ___ Python tracker ___ _

[issue6247] should we include argparse

Steven Bethard added the comment: On Tue, Jun 9, 2009 at 11:45 PM, Martin v. Löwis wrote: > It would be useful if several people could confirm that argparse > is *not* horribly designed. A totally reasonable request. Anyone willing to evaluate this can take a look at: http://argparse.googlecod

[issue6247] should we include argparse

Ritesh Raj Sarraf added the comment: I'm not sure about the design part, but as a user, I find both to have very similar interfaces. argparse is better because it handles nargs=*. This has long been asked in optparse. Positional arguments is something I wanted recently, and argparse makes it ve

[issue6247] should we include argparse

Martin v. Löwis added the comment: Steven Bethard wrote: > In particular, the > optparse extension API is horribly designed, and exposes so many > internals of optparse that it's nearly impossible to add any new > features to optparse without breaking this. It would be useful if several people

[issue6247] should we include argparse

Steven Bethard added the comment: I'm happy to contribute argparse to the standard library and volunteer to maintain it. For what it's worth, I don't agree that there are already too many argument parsing libraries in the standard library. I do agree that there are already too many *option* par

[issue6247] should we include argparse

Martin v. Löwis added the comment: > Since they are missing in optparse, and since it doesn't look like > argparse will be included, should I open new bugs for those features > against optparse ? I think chances are very low that any such bug report would be reacted on within the next decade.

[issue6247] should we include argparse

Ritesh Raj Sarraf added the comment: Thanks for the link. As a user, I see many of the features that argparse brings, to be helpful. Since they are missing in optparse, and since it doesn't look like argparse will be included, should I open new bugs for those features against optparse ? --

[issue6247] should we include argparse

Changes by Benjamin Peterson : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue6247] should we include argparse

Senthil added the comment: I hope you read this thread which discusses the same issue. * http://mail.python.org/pipermail/python-list/2007-January/592646.html MvL,effbot and jjlee had shared their views to the original author of argparse module. It did not go anywhere from there. I see that t

[issue6247] should we include argparse

Ritesh Raj Sarraf added the comment: >From the author, Steven Berthard: Sorry about the delay - conferences and moving means that I haven't had as much time for argparse as I'd like. Basically, the way things get into the Python standard library is if a large enough communit

[issue6247] should we include argparse

Martin v. Löwis added the comment: One important prerequisite for including it is that the author of the code contributes it for inclusion (irrespective of any license that may allow us to fork the code), and that he, or somebody else, volunteers to maintain it. IIUC, you are not the author, so

[issue6247] should we include argparse

New submission from Ritesh Raj Sarraf : Shoudl argparse be included in the Python Standard Library. I know we already have getopt and optparse but optparse doesn't support many features easily. (like options without hyphen, nargs=*) Here a little about argparse: argparse: Python command line