mirror of https://github.com/python/peps
373 lines
24 KiB
HTML
373 lines
24 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 42 – Feature Requests | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0042/">
|
||
<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 42 – Feature Requests | peps.python.org'>
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0042/">
|
||
<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 42</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 42 – Feature Requests</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Jeremy Hylton <jeremy at alum.mit.edu></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Removed from consideration by sponsor or authors">Withdrawn</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Normative PEP describing or proposing a change to a Python community process, workflow or governance">Process</abbr></dd>
|
||
<dt class="field-even">Created<span class="colon">:</span></dt>
|
||
<dd class="field-even">12-Sep-2000</dd>
|
||
<dt class="field-odd">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><p></p></dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#introduction">Introduction</a></li>
|
||
<li><a class="reference internal" href="#core-language-builtins">Core Language / Builtins</a></li>
|
||
<li><a class="reference internal" href="#standard-library">Standard Library</a></li>
|
||
<li><a class="reference internal" href="#c-api-wishes">C API wishes</a></li>
|
||
<li><a class="reference internal" href="#tools">Tools</a></li>
|
||
<li><a class="reference internal" href="#building-and-installing">Building and Installing</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<div class="admonition note">
|
||
<p class="admonition-title">Note</p>
|
||
<p>This PEP has been <a class="reference external" href="https://github.com/python/peps/pull/108#issuecomment-249603204">withdrawn as obsolete</a>.
|
||
All new feature requests should either go to the <a class="reference external" href="https://bugs.python.org">Python bug tracker</a>
|
||
for very simple requests or the <a class="reference external" href="https://mail.python.org/mailman/listinfo/python-ideas">python-ideas</a> mailing list for
|
||
everything else. The rest of this document is retained for historical
|
||
purposes only.</p>
|
||
</div>
|
||
<section id="introduction">
|
||
<h2><a class="toc-backref" href="#introduction" role="doc-backlink">Introduction</a></h2>
|
||
<p>This PEP contains a list of feature requests that may be considered
|
||
for future versions of Python. Large feature requests should not be
|
||
included here, but should be described in separate PEPs; however a
|
||
large feature request that doesn’t have its own PEP can be listed here
|
||
until its own PEP is created. See <a class="pep reference internal" href="../pep-0000/" title="PEP 0 – Index of Python Enhancement Proposals (PEPs)">PEP 0</a> for details.</p>
|
||
<p>This PEP was created to allow us to close bug reports that are really
|
||
feature requests. Marked as Open, they distract from the list of real
|
||
bugs (which should ideally be less than a page). Marked as Closed,
|
||
they tend to be forgotten. The procedure now is: if a bug report is
|
||
really a feature request, add the feature request to this PEP; mark
|
||
the bug as “feature request”, “later”, and “closed”; and add a comment
|
||
to the bug saying that this is the case (mentioning the PEP
|
||
explicitly). It is also acceptable to move large feature requests
|
||
directly from the bugs database to a separate PEP.</p>
|
||
<p>This PEP should really be separated into four different categories
|
||
(categories due to Laura Creighton):</p>
|
||
<ol class="arabic">
|
||
<li>BDFL rejects as a bad idea. Don’t come back with it.</li>
|
||
<li>BDFL will put in if somebody writes the code. (Or at any rate,
|
||
BDFL will say ‘change this and I will put it in’ if you show up
|
||
with code.)<p>possibly divided into:</p>
|
||
<blockquote>
|
||
<div><ol class="loweralpha simple">
|
||
<li>BDFL would really like to see some code!</li>
|
||
<li>BDFL is never going to be enthusiastic about this, but
|
||
will work it in when it’s easy.</li>
|
||
</ol>
|
||
</div></blockquote>
|
||
</li>
|
||
<li>If you show up with code, BDFL will make a pronouncement. It might
|
||
be ICK.</li>
|
||
<li>This is too vague. This is rejected, but only on the grounds of
|
||
vagueness. If you like this enhancement, make a new PEP.</li>
|
||
</ol>
|
||
</section>
|
||
<section id="core-language-builtins">
|
||
<h2><a class="toc-backref" href="#core-language-builtins" role="doc-backlink">Core Language / Builtins</a></h2>
|
||
<ul>
|
||
<li>The parser should handle more deeply nested parse trees.<p>The following will fail – <code class="docutils literal notranslate"><span class="pre">eval("["*50</span></code> + <code class="docutils literal notranslate"><span class="pre">"]"*50)</span></code> – because
|
||
the parser has a hard-coded limit on stack size. This limit should
|
||
be raised or removed. Removal would be hard because the current
|
||
compiler can overflow the C stack if the nesting is too deep.</p>
|
||
<p><a class="reference external" href="https://bugs.python.org/issue215555">https://bugs.python.org/issue215555</a></p>
|
||
</li>
|
||
<li>Non-accidental IEEE-754 support (Infs, NaNs, settable traps, etc).
|
||
Big project.</li>
|
||
<li>Windows: Trying to create (or even access) files with certain
|
||
magic names can hang or crash Windows systems. This is really a
|
||
bug in the OSes, but some apps try to shield users from it. When
|
||
it happens, the symptoms are very confusing.<p>Hang using files named prn.txt, etc <a class="reference external" href="https://bugs.python.org/issue481171">https://bugs.python.org/issue481171</a></p>
|
||
</li>
|
||
<li>eval and free variables: It might be useful if there was a way to
|
||
pass bindings for free variables to eval when a code object with
|
||
free variables is passed. <a class="reference external" href="https://bugs.python.org/issue443866">https://bugs.python.org/issue443866</a></li>
|
||
</ul>
|
||
</section>
|
||
<section id="standard-library">
|
||
<h2><a class="toc-backref" href="#standard-library" role="doc-backlink">Standard Library</a></h2>
|
||
<ul>
|
||
<li>The urllib module should support proxies which require
|
||
authentication. See SourceForge bug #210619 for information:<p><a class="reference external" href="https://bugs.python.org/issue210619">https://bugs.python.org/issue210619</a></p>
|
||
</li>
|
||
<li>os.rename() should be modified to handle EXDEV errors on platforms
|
||
that don’t allow rename() to operate across filesystem boundaries
|
||
by copying the file over and removing the original. Linux is one
|
||
system that requires this treatment.<p><a class="reference external" href="https://bugs.python.org/issue212317">https://bugs.python.org/issue212317</a></p>
|
||
</li>
|
||
<li>signal handling doesn’t always work as expected. E.g. if
|
||
sys.stdin.readline() is interrupted by a (returning) signal
|
||
handler, it returns “”. It would be better to make it raise an
|
||
exception (corresponding to EINTR) or to restart. But these
|
||
changes would have to applied to all places that can do blocking
|
||
interruptible I/O. So it’s a big project.<p><a class="reference external" href="https://bugs.python.org/issue210599">https://bugs.python.org/issue210599</a></p>
|
||
</li>
|
||
<li>Extend Windows utime to accept directory paths.<p><a class="reference external" href="https://bugs.python.org/issue214245">https://bugs.python.org/issue214245</a></p>
|
||
</li>
|
||
<li>Extend copy.py to module & function types.<p><a class="reference external" href="https://bugs.python.org/issue214553">https://bugs.python.org/issue214553</a></p>
|
||
</li>
|
||
<li>Better checking for bad input to <code class="docutils literal notranslate"><span class="pre">marshal.load*().</span></code><p><a class="reference external" href="https://bugs.python.org/issue214754">https://bugs.python.org/issue214754</a></p>
|
||
</li>
|
||
<li>rfc822.py should be more lenient than the spec in the types of
|
||
address fields it parses. Specifically, an invalid address of the
|
||
form “From: Amazon.com <<a class="reference external" href="mailto:delivers-news2%40amazon.com">delivers-news2<span>@</span>amazon<span>.</span>com</a>>” should be
|
||
parsed correctly.<p><a class="reference external" href="https://bugs.python.org/issue210678">https://bugs.python.org/issue210678</a></p>
|
||
</li>
|
||
<li>cgi.py’s FieldStorage class should be more conservative with memory
|
||
in the face of large binary file uploads.<p><a class="reference external" href="https://bugs.python.org/issue210674">https://bugs.python.org/issue210674</a></p>
|
||
<p>There are two issues here: first, because
|
||
read_lines_to_outerboundary() uses readline() it is possible that a
|
||
large amount of data will be read into memory for a binary file
|
||
upload. This should probably look at the Content-Type header of the
|
||
section and do a chunked read if it’s a binary type.</p>
|
||
<p>The second issue was related to the self.lines attribute, which was
|
||
removed in revision 1.56 of cgi.py (see also):</p>
|
||
<p><a class="reference external" href="https://bugs.python.org/issue219806">https://bugs.python.org/issue219806</a></p>
|
||
</li>
|
||
<li>urllib should support proxy definitions that contain just the host
|
||
and port<p><a class="reference external" href="https://bugs.python.org/issue210849">https://bugs.python.org/issue210849</a></p>
|
||
</li>
|
||
<li>urlparse should be updated to comply with <span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc2396.html"><strong>RFC 2396</strong></a>, which defines
|
||
optional parameters for each segment of the path.<p><a class="reference external" href="https://bugs.python.org/issue210834">https://bugs.python.org/issue210834</a></p>
|
||
</li>
|
||
<li>The exceptions raised by pickle and cPickle are currently
|
||
different; these should be unified (probably the exceptions should
|
||
be defined in a helper module that’s imported by both). [No bug
|
||
report; I just thought of this.]</li>
|
||
<li>More standard library routines should support Unicode. For
|
||
example, urllib.quote() could convert Unicode strings to UTF-8 and
|
||
then do the usual %HH conversion. But this is not the only one!<p><a class="reference external" href="https://bugs.python.org/issue216716">https://bugs.python.org/issue216716</a></p>
|
||
</li>
|
||
<li>There should be a way to say that you don’t mind if <code class="docutils literal notranslate"><span class="pre">str()</span></code> or
|
||
<code class="docutils literal notranslate"><span class="pre">__str__()</span></code> return a Unicode string object. Or a different function
|
||
– <code class="docutils literal notranslate"><span class="pre">ustr()</span></code> has been proposed. Or something…<p><a class="reference external" href="http://sf.net/patch/?func=detailpatch&patch_id=101527&group_id=5470">http://sf.net/patch/?func=detailpatch&patch_id=101527&group_id=5470</a></p>
|
||
</li>
|
||
<li>Killing a thread from another thread. Or maybe sending a signal.
|
||
Or maybe raising an asynchronous exception.<p><a class="reference external" href="https://bugs.python.org/issue221115">https://bugs.python.org/issue221115</a></p>
|
||
</li>
|
||
<li>The debugger (pdb) should understand packages.<p><a class="reference external" href="https://bugs.python.org/issue210631">https://bugs.python.org/issue210631</a></p>
|
||
</li>
|
||
<li>Jim Fulton suggested the following:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">I</span> <span class="n">wonder</span> <span class="k">if</span> <span class="n">it</span> <span class="n">would</span> <span class="n">be</span> <span class="n">a</span> <span class="n">good</span> <span class="n">idea</span> <span class="n">to</span> <span class="n">have</span> <span class="n">a</span> <span class="n">new</span> <span class="n">kind</span> <span class="n">of</span>
|
||
<span class="n">temporary</span> <span class="n">file</span> <span class="n">that</span> <span class="n">stored</span> <span class="n">data</span> <span class="ow">in</span> <span class="n">memory</span> <span class="n">unless</span><span class="p">:</span>
|
||
|
||
<span class="o">-</span> <span class="n">The</span> <span class="n">data</span> <span class="n">exceeds</span> <span class="n">some</span> <span class="n">size</span><span class="p">,</span> <span class="ow">or</span>
|
||
|
||
<span class="o">-</span> <span class="n">Somebody</span> <span class="n">asks</span> <span class="k">for</span> <span class="n">a</span> <span class="n">fileno</span><span class="o">.</span>
|
||
|
||
<span class="n">Then</span> <span class="n">the</span> <span class="n">cgi</span> <span class="n">module</span> <span class="p">(</span><span class="ow">and</span> <span class="n">other</span> <span class="n">apps</span><span class="p">)</span> <span class="n">could</span> <span class="n">use</span> <span class="n">this</span> <span class="n">thing</span> <span class="ow">in</span> <span class="n">a</span>
|
||
<span class="n">uniform</span> <span class="n">way</span><span class="o">.</span>
|
||
</pre></div>
|
||
</div>
|
||
<p><a class="reference external" href="https://bugs.python.org/issue415692">https://bugs.python.org/issue415692</a></p>
|
||
</li>
|
||
<li>Jim Fulton pointed out that binascii’s b2a_base64() function has
|
||
situations where it makes sense not to append a newline, or to
|
||
append something else than a newline.<p>Proposal:</p>
|
||
<ul class="simple">
|
||
<li>add an optional argument giving the delimiter string to be
|
||
appended, defaulting to “\n”</li>
|
||
<li>possibly special-case None as the delimiter string to avoid adding
|
||
the pad bytes too???</li>
|
||
</ul>
|
||
<p><a class="reference external" href="https://bugs.python.org/issue415694">https://bugs.python.org/issue415694</a></p>
|
||
</li>
|
||
<li>pydoc should be integrated with the HTML docs, or at least be able
|
||
to link to them.<p><a class="reference external" href="https://bugs.python.org/issue405554">https://bugs.python.org/issue405554</a></p>
|
||
</li>
|
||
<li>Distutils should deduce dependencies for .c and .h files.<p><a class="reference external" href="https://bugs.python.org/issue472881">https://bugs.python.org/issue472881</a></p>
|
||
</li>
|
||
<li>asynchat is buggy in the face of multithreading.<p><a class="reference external" href="https://bugs.python.org/issue595217">https://bugs.python.org/issue595217</a></p>
|
||
</li>
|
||
<li>It would be nice if the higher level modules (httplib, smtplib,
|
||
nntplib, etc.) had options for setting socket timeouts.<p><a class="reference external" href="https://bugs.python.org/issue723287">https://bugs.python.org/issue723287</a></p>
|
||
</li>
|
||
<li>The curses library is missing two important calls: newterm() and
|
||
delscreen()<p><a class="reference external" href="https://bugs.python.org/issue665572">https://bugs.python.org/issue665572</a>, <a class="reference external" href="http://bugs.debian.org/175590">http://bugs.debian.org/175590</a></p>
|
||
</li>
|
||
<li>It would be nice if the built-in SSL socket type could be used for
|
||
non-blocking SSL I/O. Currently packages such as Twisted which
|
||
implement async servers using SSL have to require third-party
|
||
packages such as pyopenssl.</li>
|
||
<li>reST as a standard library module</li>
|
||
<li>The import lock could use some redesign.<p><a class="reference external" href="https://bugs.python.org/issue683658">https://bugs.python.org/issue683658</a></p>
|
||
</li>
|
||
<li>A nicer API to open text files, replacing the ugly (in some
|
||
people’s eyes) “U” mode flag. There’s a proposal out there to have
|
||
a new built-in type textfile(filename, mode, encoding). (Shouldn’t
|
||
it have a bufsize argument too?)</li>
|
||
<li>Support new widgets and/or parameters for Tkinter</li>
|
||
<li>For a class defined inside another class, the __name__ should be
|
||
“outer.inner”, and pickling should work. (GvR is no longer certain
|
||
this is easy or even right.)<p><a class="reference external" href="https://bugs.python.org/issue633930">https://bugs.python.org/issue633930</a></p>
|
||
</li>
|
||
<li>Decide on a clearer deprecation policy (especially for modules) and
|
||
act on it.<p><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2002-April/023165.html">https://mail.python.org/pipermail/python-dev/2002-April/023165.html</a></p>
|
||
</li>
|
||
<li>Provide alternatives for common uses of the types module; Skip
|
||
Montanaro has posted a proto-PEP for this idea:<p><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2002-May/024346.html">https://mail.python.org/pipermail/python-dev/2002-May/024346.html</a></p>
|
||
</li>
|
||
<li>Use pending deprecation for the types and string modules. This
|
||
requires providing alternatives for the parts that aren’t covered
|
||
yet (e.g. string.whitespace and types.TracebackType). It seems we
|
||
can’t get consensus on this.</li>
|
||
<li>Lazily tracking tuples?<p><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2002-May/023926.html">https://mail.python.org/pipermail/python-dev/2002-May/023926.html</a>
|
||
<a class="reference external" href="https://bugs.python.org/issue558745">https://bugs.python.org/issue558745</a></p>
|
||
</li>
|
||
<li>Make ‘as’ a keyword. It has been a pseudo-keyword long enough.
|
||
(It’s deprecated in 2.5, and will become a keyword in 2.6.)</li>
|
||
</ul>
|
||
</section>
|
||
<section id="c-api-wishes">
|
||
<h2><a class="toc-backref" href="#c-api-wishes" role="doc-backlink">C API wishes</a></h2>
|
||
<ul>
|
||
<li>Add C API functions to help Windows users who are building embedded
|
||
applications where the FILE * structure does not match the FILE *
|
||
the interpreter was compiled with.<p><a class="reference external" href="https://bugs.python.org/issue210821">https://bugs.python.org/issue210821</a></p>
|
||
<p>See this bug report for a specific suggestion that will allow a
|
||
Borland C++ builder application to interact with a python.dll build
|
||
with MSVC.</p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="tools">
|
||
<h2><a class="toc-backref" href="#tools" role="doc-backlink">Tools</a></h2>
|
||
<ul>
|
||
<li>Python could use a GUI builder.<p><a class="reference external" href="https://bugs.python.org/issue210820">https://bugs.python.org/issue210820</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="building-and-installing">
|
||
<h2><a class="toc-backref" href="#building-and-installing" role="doc-backlink">Building and Installing</a></h2>
|
||
<ul>
|
||
<li>Modules/makesetup should make sure the ‘config.c’ file it generates
|
||
from the various Setup files, is valid C. It currently accepts
|
||
module names with characters that are not allowable in Python or C
|
||
identifiers.<p><a class="reference external" href="https://bugs.python.org/issue216326">https://bugs.python.org/issue216326</a></p>
|
||
</li>
|
||
<li>Building from source should not attempt to overwrite the
|
||
Include/graminit.h and Parser/graminit.c files, at least for people
|
||
downloading a source release rather than working from Subversion or
|
||
snapshots. Some people find this a problem in unusual build
|
||
environments.<p><a class="reference external" href="https://bugs.python.org/issue219221">https://bugs.python.org/issue219221</a></p>
|
||
</li>
|
||
<li>The configure script has probably grown a bit crufty with age and
|
||
may not track autoconf’s more recent features very well. It should
|
||
be looked at and possibly cleaned up.<p><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2004-January/041790.html">https://mail.python.org/pipermail/python-dev/2004-January/041790.html</a></p>
|
||
</li>
|
||
<li>Make Python compliant to the FHS (the Filesystem Hierarchy
|
||
Standard)<p><a class="reference external" href="http://bugs.python.org/issue588756">http://bugs.python.org/issue588756</a></p>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0042.rst">https://github.com/python/peps/blob/main/peps/pep-0042.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0042.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="#introduction">Introduction</a></li>
|
||
<li><a class="reference internal" href="#core-language-builtins">Core Language / Builtins</a></li>
|
||
<li><a class="reference internal" href="#standard-library">Standard Library</a></li>
|
||
<li><a class="reference internal" href="#c-api-wishes">C API wishes</a></li>
|
||
<li><a class="reference internal" href="#tools">Tools</a></li>
|
||
<li><a class="reference internal" href="#building-and-installing">Building and Installing</a></li>
|
||
</ul>
|
||
|
||
<br>
|
||
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0042.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> |