R. David Murray rdmur...@bitdance.com 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
anatoly techtonik techto...@gmail.com 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.
Steven Bethard steven.beth...@gmail.com 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
Armin Ronacher armin.ronac...@active-4.com 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
Steven Bethard steven.beth...@gmail.com 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
Armin Ronacher armin.ronac...@active-4.com 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
Steven Bethard steven.beth...@gmail.com 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
Armin Ronacher armin.ronac...@active-4.com 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
R. David Murray rdmur...@bitdance.com 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.
Michael Foord mich...@voidspace.org.uk 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
Nick Coghlan ncogh...@gmail.com 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
Armin Ronacher armin.ronac...@active-4.com 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
Georg Brandl ge...@python.org added the comment:
I think optparse just got a new maintainer.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6247
___
Michael Foord mich...@voidspace.org.uk added the comment:
He has a few important feature requests to deal with as well.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6247
___
Gregory P. Smith g...@krypto.org added the comment:
On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher rep...@bugs.python.org wrote:
Armin Ronacher armin.ronac...@active-4.com added the comment:
@Armin: Doesn't that argument apply to *any* library proposed for
inclusion in the standard
Jesse Noller jnol...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Michael Foord mich...@voidspace.org.uk 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
Mark Lodato its...@hotmail.com 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
Gregory P. Smith g...@krypto.org 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
R. David Murray rdmur...@bitdance.com 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
Eric Smith e...@trueblade.com 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
Steven Bethard steven.beth...@gmail.com 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
Martin v. Löwis mar...@v.loewis.de 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
Ritesh Raj Sarraf r...@researchut.com 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
Steven Bethard steven.beth...@gmail.com added the comment:
On Tue, Jun 9, 2009 at 11:45 PM, Martin v. Löwisrep...@bugs.python.org 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
Eric Smith e...@trueblade.com added the comment:
I'll take a look at it. I've been meaning to use argparse, anyway.
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6247
New submission from Ritesh Raj Sarraf r...@researchut.com:
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:
Martin v. Löwis mar...@v.loewis.de 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
Ritesh Raj Sarraf r...@researchut.com 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
Senthil orsent...@gmail.com 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
Changes by Benjamin Peterson benja...@python.org:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6247
___
___
Ritesh Raj Sarraf r...@researchut.com 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
Martin v. Löwis mar...@v.loewis.de 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
Steven Bethard steven.beth...@gmail.com 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
35 matches
Mail list logo
