mirror of https://github.com/python/peps
450 lines
34 KiB
HTML
450 lines
34 KiB
HTML
|
||
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<meta name="color-scheme" content="light dark">
|
||
<title>PEP 389 – argparse - New Command Line Parsing Module | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0389/">
|
||
<link rel="stylesheet" href="../_static/style.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
|
||
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
|
||
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
|
||
<meta property="og:title" content='PEP 389 – argparse - New Command Line Parsing Module | peps.python.org'>
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0389/">
|
||
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
|
||
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
|
||
<meta property="og:image:alt" content="Python PEPs">
|
||
<meta property="og:image:width" content="200">
|
||
<meta property="og:image:height" content="200">
|
||
<meta name="description" content="Python Enhancement Proposals (PEPs)">
|
||
<meta name="theme-color" content="#3776ab">
|
||
</head>
|
||
<body>
|
||
|
||
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
||
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Following system colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="9"></circle>
|
||
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected dark colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
|
||
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected light colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="5"></circle>
|
||
<line x1="12" y1="1" x2="12" y2="3"></line>
|
||
<line x1="12" y1="21" x2="12" y2="23"></line>
|
||
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
||
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
||
<line x1="1" y1="12" x2="3" y2="12"></line>
|
||
<line x1="21" y1="12" x2="23" y2="12"></line>
|
||
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
||
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
||
</svg>
|
||
</symbol>
|
||
</svg>
|
||
<script>
|
||
|
||
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
|
||
</script>
|
||
<section id="pep-page-section">
|
||
<header>
|
||
<h1>Python Enhancement Proposals</h1>
|
||
<ul class="breadcrumbs">
|
||
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li>
|
||
<li><a href="../pep-0000/">PEP Index</a> » </li>
|
||
<li>PEP 389</li>
|
||
</ul>
|
||
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
|
||
</button>
|
||
</header>
|
||
<article>
|
||
<section id="pep-content">
|
||
<h1 class="page-title">PEP 389 – argparse - New Command Line Parsing Module</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Steven Bethard <steven.bethard at gmail.com></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd>
|
||
<dt class="field-even">Created<span class="colon">:</span></dt>
|
||
<dd class="field-even">25-Sep-2009</dd>
|
||
<dt class="field-odd">Python-Version<span class="colon">:</span></dt>
|
||
<dd class="field-odd">2.7, 3.2</dd>
|
||
<dt class="field-even">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-even">27-Sep-2009, 24-Oct-2009</dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#acceptance">Acceptance</a></li>
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
||
<li><a class="reference internal" href="#why-aren-t-getopt-and-optparse-enough">Why aren’t getopt and optparse enough?</a></li>
|
||
<li><a class="reference internal" href="#why-isn-t-the-functionality-just-being-added-to-optparse">Why isn’t the functionality just being added to optparse?</a></li>
|
||
<li><a class="reference internal" href="#deprecation-of-optparse">Deprecation of optparse</a></li>
|
||
<li><a class="reference internal" href="#updates-to-getopt-documentation">Updates to getopt documentation</a></li>
|
||
<li><a class="reference internal" href="#deferred-string-formatting">Deferred: string formatting</a></li>
|
||
<li><a class="reference internal" href="#rejected-getopt-compatibility-methods">Rejected: getopt compatibility methods</a></li>
|
||
<li><a class="reference internal" href="#out-of-scope-various-feature-requests">Out of Scope: Various Feature Requests</a></li>
|
||
<li><a class="reference internal" href="#discussion-sys-stderr-and-sys-exit">Discussion: sys.stderr and sys.exit</a></li>
|
||
<li><a class="reference internal" href="#references">References</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="acceptance">
|
||
<h2><a class="toc-backref" href="#acceptance" role="doc-backlink">Acceptance</a></h2>
|
||
<p>This PEP was approved by Guido on python-dev on February 21, 2010 <a class="footnote-reference brackets" href="#id35" id="id1">[17]</a>.</p>
|
||
</section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<p>This PEP proposes inclusion of the argparse <a class="footnote-reference brackets" href="#id18" id="id2">[1]</a> module in the Python
|
||
standard library in Python 2.7 and 3.2.</p>
|
||
</section>
|
||
<section id="motivation">
|
||
<h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2>
|
||
<p>The argparse module is a command line parsing library which provides
|
||
more functionality than the existing command line parsing modules in
|
||
the standard library, getopt <a class="footnote-reference brackets" href="#id19" id="id3">[2]</a> and optparse <a class="footnote-reference brackets" href="#id20" id="id4">[3]</a>. It includes
|
||
support for positional arguments (not just options), subcommands,
|
||
required options, options syntaxes like “/f” and “+rgb”, zero-or-more
|
||
and one-or-more style arguments, and many other features the other
|
||
two lack.</p>
|
||
<p>The argparse module is also already a popular third-party replacement
|
||
for these modules. It is used in projects like IPython (the Scipy
|
||
Python shell) <a class="footnote-reference brackets" href="#id21" id="id5">[4]</a>, is included in Debian testing and unstable <a class="footnote-reference brackets" href="#id22" id="id6">[5]</a>,
|
||
and since 2007 has had various requests for its inclusion in the
|
||
standard library <a class="footnote-reference brackets" href="#id23" id="id7">[6]</a> <a class="footnote-reference brackets" href="#id24" id="id8">[7]</a> <a class="footnote-reference brackets" href="#id25" id="id9">[8]</a>. This popularity suggests it may be
|
||
a valuable addition to the Python libraries.</p>
|
||
</section>
|
||
<section id="why-aren-t-getopt-and-optparse-enough">
|
||
<h2><a class="toc-backref" href="#why-aren-t-getopt-and-optparse-enough" role="doc-backlink">Why aren’t getopt and optparse enough?</a></h2>
|
||
<p>One argument against adding argparse is that there are “already two
|
||
different option parsing modules in the standard library” <a class="footnote-reference brackets" href="#id26" id="id10">[9]</a>. The
|
||
following is a list of features provided by argparse but not present
|
||
in getopt or optparse:</p>
|
||
<ul class="simple">
|
||
<li>While it is true there are two <em>option</em> parsing libraries, there
|
||
are no full command line parsing libraries – both getopt and
|
||
optparse support only options and have no support for positional
|
||
arguments. The argparse module handles both, and as a result, is
|
||
able to generate better help messages, avoiding redundancies like
|
||
the <code class="docutils literal notranslate"><span class="pre">usage=</span></code> string usually required by optparse.</li>
|
||
<li>The argparse module values practicality over purity. Thus, argparse
|
||
allows required options and customization of which characters are
|
||
used to identify options, while optparse explicitly states “the
|
||
phrase ‘required option’ is self-contradictory” and that the option
|
||
syntaxes <code class="docutils literal notranslate"><span class="pre">-pf</span></code>, <code class="docutils literal notranslate"><span class="pre">-file</span></code>, <code class="docutils literal notranslate"><span class="pre">+f</span></code>, <code class="docutils literal notranslate"><span class="pre">+rgb</span></code>, <code class="docutils literal notranslate"><span class="pre">/f</span></code> and <code class="docutils literal notranslate"><span class="pre">/file</span></code>
|
||
“are not supported by optparse, and they never will be”.</li>
|
||
<li>The argparse module allows options to accept a variable number of
|
||
arguments using <code class="docutils literal notranslate"><span class="pre">nargs='?'</span></code>, <code class="docutils literal notranslate"><span class="pre">nargs='*'</span></code> or <code class="docutils literal notranslate"><span class="pre">nargs='+'</span></code>. The
|
||
optparse module provides an untested recipe for some part of this
|
||
functionality <a class="footnote-reference brackets" href="#id28" id="id11">[10]</a> but admits that “things get hairy when you want
|
||
an option to take a variable number of arguments.”</li>
|
||
<li>The argparse module supports subcommands, where a main command
|
||
line parser dispatches to other command line parsers depending on
|
||
the command line arguments. This is a common pattern in command
|
||
line interfaces, e.g. <code class="docutils literal notranslate"><span class="pre">svn</span> <span class="pre">co</span></code> and <code class="docutils literal notranslate"><span class="pre">svn</span> <span class="pre">up</span></code>.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="why-isn-t-the-functionality-just-being-added-to-optparse">
|
||
<h2><a class="toc-backref" href="#why-isn-t-the-functionality-just-being-added-to-optparse" role="doc-backlink">Why isn’t the functionality just being added to optparse?</a></h2>
|
||
<p>Clearly all the above features offer improvements over what is
|
||
available through optparse. A reasonable question then is why these
|
||
features are not simply provided as patches to optparse, instead of
|
||
introducing an entirely new module. In fact, the original development
|
||
of argparse intended to do just that, but because of various fairly
|
||
constraining design decisions of optparse, this wasn’t really
|
||
possible. Some of the problems included:</p>
|
||
<ul>
|
||
<li>The optparse module exposes the internals of its parsing algorithm.
|
||
In particular, <code class="docutils literal notranslate"><span class="pre">parser.largs</span></code> and <code class="docutils literal notranslate"><span class="pre">parser.rargs</span></code> are guaranteed
|
||
to be available to callbacks <a class="footnote-reference brackets" href="#id29" id="id12">[11]</a>. This makes it extremely
|
||
difficult to improve the parsing algorithm as was necessary in
|
||
argparse for proper handling of positional arguments and variable
|
||
length arguments. For example, <code class="docutils literal notranslate"><span class="pre">nargs='+'</span></code> in argparse is matched
|
||
using regular expressions and thus has no notion of things like
|
||
<code class="docutils literal notranslate"><span class="pre">parser.largs</span></code>.</li>
|
||
<li>The optparse extension APIs are extremely complex. For example,
|
||
just to use a simple custom string-to-object conversion function,
|
||
you have to subclass <code class="docutils literal notranslate"><span class="pre">Option</span></code>, hack class attributes, and then
|
||
specify your custom option type to the parser, like this:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">MyOption</span><span class="p">(</span><span class="n">Option</span><span class="p">):</span>
|
||
<span class="n">TYPES</span> <span class="o">=</span> <span class="n">Option</span><span class="o">.</span><span class="n">TYPES</span> <span class="o">+</span> <span class="p">(</span><span class="s2">"mytype"</span><span class="p">,)</span>
|
||
<span class="n">TYPE_CHECKER</span> <span class="o">=</span> <span class="n">copy</span><span class="p">(</span><span class="n">Option</span><span class="o">.</span><span class="n">TYPE_CHECKER</span><span class="p">)</span>
|
||
<span class="n">TYPE_CHECKER</span><span class="p">[</span><span class="s2">"mytype"</span><span class="p">]</span> <span class="o">=</span> <span class="n">check_mytype</span>
|
||
<span class="n">parser</span> <span class="o">=</span> <span class="n">optparse</span><span class="o">.</span><span class="n">OptionParser</span><span class="p">(</span><span class="n">option_class</span><span class="o">=</span><span class="n">MyOption</span><span class="p">)</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">add_option</span><span class="p">(</span><span class="s2">"-m"</span><span class="p">,</span> <span class="nb">type</span><span class="o">=</span><span class="s2">"mytype"</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For comparison, argparse simply allows conversion functions to be
|
||
used as <code class="docutils literal notranslate"><span class="pre">type=</span></code> arguments directly, e.g.:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">parser</span> <span class="o">=</span> <span class="n">argparse</span><span class="o">.</span><span class="n">ArgumentParser</span><span class="p">()</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">add_option</span><span class="p">(</span><span class="s2">"-m"</span><span class="p">,</span> <span class="nb">type</span><span class="o">=</span><span class="n">check_mytype</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>But given the baroque customization APIs of optparse, it is unclear
|
||
how such a feature should interact with those APIs, and it is
|
||
quite possible that introducing the simple argparse API would break
|
||
existing custom Option code.</p>
|
||
</li>
|
||
<li>Both optparse and argparse parse command line arguments and assign
|
||
them as attributes to an object returned by <code class="docutils literal notranslate"><span class="pre">parse_args</span></code>.
|
||
However, the optparse module guarantees that the <code class="docutils literal notranslate"><span class="pre">take_action</span></code>
|
||
method of custom actions will always be passed a <code class="docutils literal notranslate"><span class="pre">values</span></code> object
|
||
which provides an <code class="docutils literal notranslate"><span class="pre">ensure_value</span></code> method <a class="footnote-reference brackets" href="#id30" id="id13">[12]</a>, while the argparse
|
||
module allows attributes to be assigned to any object, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">foo_object</span> <span class="o">=</span> <span class="o">...</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">parse_args</span><span class="p">(</span><span class="n">namespace</span><span class="o">=</span><span class="n">foo_object</span><span class="p">)</span>
|
||
<span class="n">foo_object</span><span class="o">.</span><span class="n">some_attribute_parsed_from_command_line</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Modifying optparse to allow any object to be passed in would be
|
||
difficult because simply passing the <code class="docutils literal notranslate"><span class="pre">foo_object</span></code> around instead
|
||
of a <code class="docutils literal notranslate"><span class="pre">Values</span></code> instance will break existing custom actions that
|
||
depend on the <code class="docutils literal notranslate"><span class="pre">ensure_value</span></code> method.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Because of issues like these, which made it unreasonably difficult
|
||
for argparse to stay compatible with the optparse APIs, argparse was
|
||
developed as an independent module. Given these issues, merging all
|
||
the argparse features into optparse with no backwards
|
||
incompatibilities seems unlikely.</p>
|
||
</section>
|
||
<section id="deprecation-of-optparse">
|
||
<h2><a class="toc-backref" href="#deprecation-of-optparse" role="doc-backlink">Deprecation of optparse</a></h2>
|
||
<p>Because all of optparse’s features are available in argparse, the
|
||
optparse module will be deprecated. However, because of the
|
||
widespread use of optparse, the deprecation strategy contains only
|
||
documentation changes and warnings that will not be visible by
|
||
default:</p>
|
||
<ul>
|
||
<li>Python 2.7+ and 3.2+ – The following note will be added to the
|
||
optparse documentation:<blockquote>
|
||
<div>The optparse module is deprecated and will not be developed
|
||
further; development will continue with the argparse module.</div></blockquote>
|
||
</li>
|
||
<li>Python 2.7+ – If the Python 3 compatibility flag, <code class="docutils literal notranslate"><span class="pre">-3</span></code>, is
|
||
provided at the command line, then importing optparse will issue a
|
||
DeprecationWarning. Otherwise no warnings will be issued.</li>
|
||
<li>Python 3.2+ – Importing optparse will issue a
|
||
PendingDeprecationWarning, which is not displayed by default.</li>
|
||
</ul>
|
||
<p>Note that no removal date is proposed for optparse.</p>
|
||
</section>
|
||
<section id="updates-to-getopt-documentation">
|
||
<h2><a class="toc-backref" href="#updates-to-getopt-documentation" role="doc-backlink">Updates to getopt documentation</a></h2>
|
||
<p>The getopt module will not be deprecated. However, its documentation
|
||
will be updated to point to argparse in a couple of places. At the
|
||
top of the module, the following note will be added:</p>
|
||
<blockquote>
|
||
<div>The getopt module is a parser for command line options whose API
|
||
is designed to be familiar to users of the C getopt function.
|
||
Users who are unfamiliar with the C getopt function or who would
|
||
like to write less code and get better help and error messages
|
||
should consider using the argparse module instead.</div></blockquote>
|
||
<p>Additionally, after the final getopt example, the following note will
|
||
be added:</p>
|
||
<blockquote>
|
||
<div>Note that an equivalent command line interface could be produced
|
||
with less code by using the argparse module:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">argparse</span>
|
||
|
||
<span class="k">if</span> <span class="vm">__name__</span> <span class="o">==</span> <span class="s1">'__main__'</span><span class="p">:</span>
|
||
<span class="n">parser</span> <span class="o">=</span> <span class="n">argparse</span><span class="o">.</span><span class="n">ArgumentParser</span><span class="p">()</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">add_argument</span><span class="p">(</span><span class="s1">'-o'</span><span class="p">,</span> <span class="s1">'--output'</span><span class="p">)</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">add_argument</span><span class="p">(</span><span class="s1">'-v'</span><span class="p">,</span> <span class="n">dest</span><span class="o">=</span><span class="s1">'verbose'</span><span class="p">,</span> <span class="n">action</span><span class="o">=</span><span class="s1">'store_true'</span><span class="p">)</span>
|
||
<span class="n">args</span> <span class="o">=</span> <span class="n">parser</span><span class="o">.</span><span class="n">parse_args</span><span class="p">()</span>
|
||
<span class="c1"># ... do something with args.output ...</span>
|
||
<span class="c1"># ... do something with args.verbose ..</span>
|
||
</pre></div>
|
||
</div>
|
||
</div></blockquote>
|
||
</section>
|
||
<section id="deferred-string-formatting">
|
||
<h2><a class="toc-backref" href="#deferred-string-formatting" role="doc-backlink">Deferred: string formatting</a></h2>
|
||
<p>The argparse module supports Python from 2.3 up through 3.2 and as a
|
||
result relies on traditional <code class="docutils literal notranslate"><span class="pre">%(foo)s</span></code> style string formatting. It
|
||
has been suggested that it might be better to use the new style
|
||
<code class="docutils literal notranslate"><span class="pre">{foo}</span></code> string formatting <a class="footnote-reference brackets" href="#id31" id="id14">[13]</a>. There was some discussion about
|
||
how best to do this for modules in the standard library <a class="footnote-reference brackets" href="#id32" id="id15">[14]</a> and
|
||
several people are developing functions for automatically converting
|
||
%-formatting to {}-formatting <a class="footnote-reference brackets" href="#id33" id="id16">[15]</a> <a class="footnote-reference brackets" href="#id34" id="id17">[16]</a>. When one of these is added
|
||
to the standard library, argparse will use them to support both
|
||
formatting styles.</p>
|
||
</section>
|
||
<section id="rejected-getopt-compatibility-methods">
|
||
<h2><a class="toc-backref" href="#rejected-getopt-compatibility-methods" role="doc-backlink">Rejected: getopt compatibility methods</a></h2>
|
||
<p>Previously, when this PEP was suggesting the deprecation of getopt
|
||
as well as optparse, there was some talk of adding a method like:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">ArgumentParser</span><span class="o">.</span><span class="n">add_getopt_arguments</span><span class="p">(</span><span class="n">options</span><span class="p">[,</span> <span class="n">long_options</span><span class="p">])</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>However, this method will not be added for a number of reasons:</p>
|
||
<ul class="simple">
|
||
<li>The getopt module is not being deprecated, so there is less need.</li>
|
||
<li>This method would not actually ease the transition for any getopt
|
||
users who were already maintaining usage messages, because the API
|
||
above gives no way of adding help messages to the arguments.</li>
|
||
<li>Some users of getopt consider it very important that only a single
|
||
function call is necessary. The API above does not satisfy this
|
||
requirement because both <code class="docutils literal notranslate"><span class="pre">ArgumentParser()</span></code> and <code class="docutils literal notranslate"><span class="pre">parse_args()</span></code>
|
||
must also be called.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="out-of-scope-various-feature-requests">
|
||
<h2><a class="toc-backref" href="#out-of-scope-various-feature-requests" role="doc-backlink">Out of Scope: Various Feature Requests</a></h2>
|
||
<p>Several feature requests for argparse were made in the discussion of
|
||
this PEP:</p>
|
||
<ul class="simple">
|
||
<li>Support argument defaults from environment variables</li>
|
||
<li>Support argument defaults from configuration files</li>
|
||
<li>Support “foo –help subcommand” in addition to the currently
|
||
supported “foo subcommand –help”</li>
|
||
</ul>
|
||
<p>These are all reasonable feature requests for the argparse module,
|
||
but are out of the scope of this PEP, and have been redirected to
|
||
the argparse issue tracker.</p>
|
||
</section>
|
||
<section id="discussion-sys-stderr-and-sys-exit">
|
||
<h2><a class="toc-backref" href="#discussion-sys-stderr-and-sys-exit" role="doc-backlink">Discussion: sys.stderr and sys.exit</a></h2>
|
||
<p>There were some concerns that argparse by default always writes to
|
||
<code class="docutils literal notranslate"><span class="pre">sys.stderr</span></code> and always calls <code class="docutils literal notranslate"><span class="pre">sys.exit</span></code> when invalid arguments
|
||
are provided. This is the desired behavior for the vast majority of
|
||
argparse use cases which revolve around simple command line
|
||
interfaces. However, in some cases, it may be desirable to keep
|
||
argparse from exiting, or to have it write its messages to something
|
||
other than <code class="docutils literal notranslate"><span class="pre">sys.stderr</span></code>. These use cases can be supported by
|
||
subclassing <code class="docutils literal notranslate"><span class="pre">ArgumentParser</span></code> and overriding the <code class="docutils literal notranslate"><span class="pre">exit</span></code> or
|
||
<code class="docutils literal notranslate"><span class="pre">_print_message</span></code> methods. The latter is an undocumented
|
||
implementation detail, but could be officially exposed if this turns
|
||
out to be a common need.</p>
|
||
</section>
|
||
<section id="references">
|
||
<h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2>
|
||
<aside class="footnote-list brackets">
|
||
<aside class="footnote brackets" id="id18" role="doc-footnote">
|
||
<dt class="label" id="id18">[<a href="#id2">1</a>]</dt>
|
||
<dd>argparse
|
||
(<a class="reference external" href="http://code.google.com/p/argparse/">http://code.google.com/p/argparse/</a>)</aside>
|
||
<aside class="footnote brackets" id="id19" role="doc-footnote">
|
||
<dt class="label" id="id19">[<a href="#id3">2</a>]</dt>
|
||
<dd>getopt
|
||
(<a class="reference external" href="http://docs.python.org/library/getopt.html">http://docs.python.org/library/getopt.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id20" role="doc-footnote">
|
||
<dt class="label" id="id20">[<a href="#id4">3</a>]</dt>
|
||
<dd>optparse
|
||
(<a class="reference external" href="http://docs.python.org/library/optparse.html">http://docs.python.org/library/optparse.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id21" role="doc-footnote">
|
||
<dt class="label" id="id21">[<a href="#id5">4</a>]</dt>
|
||
<dd>argparse in IPython
|
||
(<a class="reference external" href="http://mail.scipy.org/pipermail/ipython-dev/2009-April/005102.html">http://mail.scipy.org/pipermail/ipython-dev/2009-April/005102.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id22" role="doc-footnote">
|
||
<dt class="label" id="id22">[<a href="#id6">5</a>]</dt>
|
||
<dd>argparse in Debian
|
||
(<a class="reference external" href="http://packages.debian.org/search?keywords=argparse">http://packages.debian.org/search?keywords=argparse</a>)</aside>
|
||
<aside class="footnote brackets" id="id23" role="doc-footnote">
|
||
<dt class="label" id="id23">[6]<em> (<a href='#id7'>1</a>, <a href='#id27'>2</a>) </em></dt>
|
||
<dd>2007-01-03 request for argparse in the standard library
|
||
(<a class="reference external" href="https://mail.python.org/pipermail/python-list/2007-January/472276.html">https://mail.python.org/pipermail/python-list/2007-January/472276.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id24" role="doc-footnote">
|
||
<dt class="label" id="id24">[<a href="#id8">7</a>]</dt>
|
||
<dd>2009-06-09 request for argparse in the standard library
|
||
(<a class="reference external" href="http://bugs.python.org/issue6247">http://bugs.python.org/issue6247</a>)</aside>
|
||
<aside class="footnote brackets" id="id25" role="doc-footnote">
|
||
<dt class="label" id="id25">[<a href="#id9">8</a>]</dt>
|
||
<dd>2009-09-10 request for argparse in the standard library
|
||
(<a class="reference external" href="https://mail.python.org/pipermail/stdlib-sig/2009-September/000342.html">https://mail.python.org/pipermail/stdlib-sig/2009-September/000342.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id26" role="doc-footnote">
|
||
<dt class="label" id="id26">[<a href="#id10">9</a>]</dt>
|
||
<dd>Fredrik Lundh response to <a class="footnote-reference brackets" href="#id23" id="id27">[6]</a>
|
||
(<a class="reference external" href="https://mail.python.org/pipermail/python-list/2007-January/1086892.html">https://mail.python.org/pipermail/python-list/2007-January/1086892.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id28" role="doc-footnote">
|
||
<dt class="label" id="id28">[<a href="#id11">10</a>]</dt>
|
||
<dd>optparse variable args
|
||
(<a class="reference external" href="http://docs.python.org/library/optparse.html#callback-example-6-variable-arguments">http://docs.python.org/library/optparse.html#callback-example-6-variable-arguments</a>)</aside>
|
||
<aside class="footnote brackets" id="id29" role="doc-footnote">
|
||
<dt class="label" id="id29">[<a href="#id12">11</a>]</dt>
|
||
<dd>parser.largs and parser.rargs
|
||
(<a class="reference external" href="http://docs.python.org/library/optparse.html#how-callbacks-are-called">http://docs.python.org/library/optparse.html#how-callbacks-are-called</a>)</aside>
|
||
<aside class="footnote brackets" id="id30" role="doc-footnote">
|
||
<dt class="label" id="id30">[<a href="#id13">12</a>]</dt>
|
||
<dd>take_action values argument
|
||
(<a class="reference external" href="http://docs.python.org/library/optparse.html#adding-new-actions">http://docs.python.org/library/optparse.html#adding-new-actions</a>)</aside>
|
||
<aside class="footnote brackets" id="id31" role="doc-footnote">
|
||
<dt class="label" id="id31">[<a href="#id14">13</a>]</dt>
|
||
<dd>use {}-formatting instead of %-formatting
|
||
(<a class="reference external" href="http://bugs.python.org/msg89279">http://bugs.python.org/msg89279</a>)</aside>
|
||
<aside class="footnote brackets" id="id32" role="doc-footnote">
|
||
<dt class="label" id="id32">[<a href="#id15">14</a>]</dt>
|
||
<dd>transitioning from % to {} formatting
|
||
(<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2009-September/092326.html">https://mail.python.org/pipermail/python-dev/2009-September/092326.html</a>)</aside>
|
||
<aside class="footnote brackets" id="id33" role="doc-footnote">
|
||
<dt class="label" id="id33">[<a href="#id16">15</a>]</dt>
|
||
<dd>Vinay Sajip’s %-to-{} converter
|
||
(<a class="reference external" href="http://gist.github.com/200936">http://gist.github.com/200936</a>)</aside>
|
||
<aside class="footnote brackets" id="id34" role="doc-footnote">
|
||
<dt class="label" id="id34">[<a href="#id17">16</a>]</dt>
|
||
<dd>Benjamin Peterson’s %-to-{} converter
|
||
(<a class="reference external" href="http://bazaar.launchpad.net/~gutworth/+junk/mod2format/files">http://bazaar.launchpad.net/~gutworth/+junk/mod2format/files</a>)</aside>
|
||
<aside class="footnote brackets" id="id35" role="doc-footnote">
|
||
<dt class="label" id="id35">[<a href="#id1">17</a>]</dt>
|
||
<dd>Guido’s approval
|
||
(<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2010-February/097839.html">https://mail.python.org/pipermail/python-dev/2010-February/097839.html</a>)</aside>
|
||
</aside>
|
||
</section>
|
||
<section id="copyright">
|
||
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
||
<p>This document has been placed in the public domain.</p>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0389.rst">https://github.com/python/peps/blob/main/peps/pep-0389.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0389.rst">2023-09-09 17:39:29 GMT</a></p>
|
||
|
||
</article>
|
||
<nav id="pep-sidebar">
|
||
<h2>Contents</h2>
|
||
<ul>
|
||
<li><a class="reference internal" href="#acceptance">Acceptance</a></li>
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
||
<li><a class="reference internal" href="#why-aren-t-getopt-and-optparse-enough">Why aren’t getopt and optparse enough?</a></li>
|
||
<li><a class="reference internal" href="#why-isn-t-the-functionality-just-being-added-to-optparse">Why isn’t the functionality just being added to optparse?</a></li>
|
||
<li><a class="reference internal" href="#deprecation-of-optparse">Deprecation of optparse</a></li>
|
||
<li><a class="reference internal" href="#updates-to-getopt-documentation">Updates to getopt documentation</a></li>
|
||
<li><a class="reference internal" href="#deferred-string-formatting">Deferred: string formatting</a></li>
|
||
<li><a class="reference internal" href="#rejected-getopt-compatibility-methods">Rejected: getopt compatibility methods</a></li>
|
||
<li><a class="reference internal" href="#out-of-scope-various-feature-requests">Out of Scope: Various Feature Requests</a></li>
|
||
<li><a class="reference internal" href="#discussion-sys-stderr-and-sys-exit">Discussion: sys.stderr and sys.exit</a></li>
|
||
<li><a class="reference internal" href="#references">References</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
|
||
<br>
|
||
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0389.rst">Page Source (GitHub)</a>
|
||
</nav>
|
||
</section>
|
||
<script src="../_static/colour_scheme.js"></script>
|
||
<script src="../_static/wrap_tables.js"></script>
|
||
<script src="../_static/sticky_banner.js"></script>
|
||
</body>
|
||
</html> |