Merge pull request #31 from Carreau/pep-0042-to-rst
Convert PEP 42 to reST
This commit is contained in:
Brett Cannon
GitHub
commit
3e3c016e52
270
pep-0042.txt
270
pep-0042.txt
|
|
@ -5,28 +5,30 @@ Last-Modified: $Date$
|
|||
Author: Jeremy Hylton <jeremy@alum.mit.edu>
|
||||
Status: Final
|
||||
Type: Process
|
||||
Content-Type: text/x-rst
|
||||
Created: 12-Sep-2000
|
||||
Post-History:
|
||||
|
||||
|
||||
Introduction
|
||||
|
||||
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
|
||||
PEP 0 for details.
|
||||
Introduction
|
||||
============
|
||||
|
||||
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 PEP 0 for details.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
This PEP should really be separated into four different categories
|
||||
(categories due to Laura Creighton):
|
||||
|
|
@ -37,64 +39,62 @@ Introduction
|
|||
BDFL will say 'change this and I will put it in' if you show up
|
||||
with code.)
|
||||
|
||||
(possibly divided into:
|
||||
possibly divided into:
|
||||
|
||||
2a) BDFL would really like to see some code!
|
||||
a) BDFL would really like to see some code!
|
||||
|
||||
2b) BDFL is never going to be enthusiastic about this, but
|
||||
b) BDFL is never going to be enthusiastic about this, but
|
||||
will work it in when it's easy.
|
||||
)
|
||||
|
||||
3. If you show up with code, BDFL will make a pronouncement. It
|
||||
might be ICK.
|
||||
3. If you show up with code, BDFL will make a pronouncement. It might
|
||||
be ICK.
|
||||
|
||||
4. This is too vague. This is rejected, but only on the grounds
|
||||
of vagueness. If you like this enhancement, make a new PEP.
|
||||
4. This is too vague. This is rejected, but only on the grounds of
|
||||
vagueness. If you like this enhancement, make a new PEP.
|
||||
|
||||
|
||||
Core Language / Builtins
|
||||
========================
|
||||
|
||||
- The parser should handle more deeply nested parse trees.
|
||||
* The parser should handle more deeply nested parse trees.
|
||||
|
||||
The following will fail -- eval("["*50 + "]"*50) -- 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.
|
||||
The following will fail -- ``eval("["*50`` + ``"]"*50)`` -- 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.
|
||||
|
||||
http://www.python.org/sf/215555
|
||||
|
||||
- Non-accidental IEEE-754 support (Infs, NaNs, settable traps, etc).
|
||||
* Non-accidental IEEE-754 support (Infs, NaNs, settable traps, etc).
|
||||
Big project.
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
Hang using files named prn.txt, etc
|
||||
http://www.python.org/sf/481171
|
||||
Hang using files named prn.txt, etc http://www.python.org/sf/481171
|
||||
|
||||
- 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.
|
||||
http://www.python.org/sf/443866
|
||||
* 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. http://www.python.org/sf/443866
|
||||
|
||||
Standard Library
|
||||
================
|
||||
|
||||
- The urllib module should support proxies which require
|
||||
* The urllib module should support proxies which require
|
||||
authentication. See SourceForge bug #210619 for information:
|
||||
|
||||
http://www.python.org/sf/210619
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
http://www.python.org/sf/212317
|
||||
|
||||
- signal handling doesn't always work as expected. E.g. if
|
||||
* 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
|
||||
|
|
@ -103,80 +103,80 @@ Standard Library
|
|||
|
||||
http://www.python.org/sf/210599
|
||||
|
||||
- Extend Windows utime to accept directory paths.
|
||||
* Extend Windows utime to accept directory paths.
|
||||
|
||||
http://www.python.org/sf/214245
|
||||
|
||||
- Extend copy.py to module & function types.
|
||||
* Extend copy.py to module & function types.
|
||||
|
||||
http://www.python.org/sf/214553
|
||||
|
||||
- Better checking for bad input to marshal.load*().
|
||||
* Better checking for bad input to ``marshal.load*().``
|
||||
|
||||
http://www.python.org/sf/214754
|
||||
|
||||
- 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 <delivers-news2@amazon.com>" should
|
||||
be parsed correctly.
|
||||
* 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 <delivers-news2@amazon.com>" should be
|
||||
parsed correctly.
|
||||
|
||||
http://www.python.org/sf/210678
|
||||
|
||||
- cgi.py's FieldStorage class should be more conservative with
|
||||
memory in the face of large binary file uploads.
|
||||
* cgi.py's FieldStorage class should be more conservative with memory
|
||||
in the face of large binary file uploads.
|
||||
|
||||
http://www.python.org/sf/210674
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The second issue was related to the self.lines attribute, which
|
||||
was removed in revision 1.56 of cgi.py (see also):
|
||||
The second issue was related to the self.lines attribute, which was
|
||||
removed in revision 1.56 of cgi.py (see also):
|
||||
|
||||
http://www.python.org/sf/219806
|
||||
|
||||
- urllib should support proxy definitions that contain just the
|
||||
host and port
|
||||
* urllib should support proxy definitions that contain just the host
|
||||
and port
|
||||
|
||||
http://www.python.org/sf/210849
|
||||
|
||||
- urlparse should be updated to comply with RFC 2396, which
|
||||
defines optional parameters for each segment of the path.
|
||||
* urlparse should be updated to comply with RFC 2396, which defines
|
||||
optional parameters for each segment of the path.
|
||||
|
||||
http://www.python.org/sf/210834
|
||||
|
||||
- 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.]
|
||||
* 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.]
|
||||
|
||||
- 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!
|
||||
* 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!
|
||||
|
||||
http://www.python.org/sf/216716
|
||||
|
||||
- There should be a way to say that you don't mind if str() or
|
||||
__str__() return a Unicode string object. Or a different
|
||||
function -- ustr() has been proposed. Or something...
|
||||
* There should be a way to say that you don't mind if ``str()`` or
|
||||
``__str__()`` return a Unicode string object. Or a different function
|
||||
-- ``ustr()`` has been proposed. Or something...
|
||||
|
||||
http://sf.net/patch/?func=detailpatch&patch_id=101527&group_id=5470
|
||||
|
||||
- Killing a thread from another thread. Or maybe sending a
|
||||
signal. Or maybe raising an asynchronous exception.
|
||||
* Killing a thread from another thread. Or maybe sending a signal.
|
||||
Or maybe raising an asynchronous exception.
|
||||
|
||||
http://www.python.org/sf/221115
|
||||
|
||||
- The debugger (pdb) should understand packages.
|
||||
* The debugger (pdb) should understand packages.
|
||||
|
||||
http://www.python.org/sf/210631
|
||||
|
||||
- Jim Fulton suggested the following:
|
||||
* Jim Fulton suggested the following:
|
||||
|
||||
::
|
||||
|
||||
I wonder if it would be a good idea to have a new kind of
|
||||
temporary file that stored data in memory unless:
|
||||
|
|
@ -190,139 +190,143 @@ Standard Library
|
|||
|
||||
http://www.python.org/sf/415692
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
Proposal:
|
||||
|
||||
- add an optional argument giving the delimiter string to be
|
||||
appended, defaulting to "\n"
|
||||
appended, defaulting to "\\n"
|
||||
|
||||
- possibly special-case None as the delimiter string to avoid
|
||||
adding the pad bytes too???
|
||||
- possibly special-case None as the delimiter string to avoid adding
|
||||
the pad bytes too???
|
||||
|
||||
http://www.python.org/sf/415694
|
||||
|
||||
- pydoc should be integrated with the HTML docs, or at least
|
||||
be able to link to them.
|
||||
* pydoc should be integrated with the HTML docs, or at least be able
|
||||
to link to them.
|
||||
|
||||
http://www.python.org/sf/405554
|
||||
|
||||
- Distutils should deduce dependencies for .c and .h files.
|
||||
* Distutils should deduce dependencies for .c and .h files.
|
||||
|
||||
http://www.python.org/sf/472881
|
||||
|
||||
- asynchat is buggy in the face of multithreading.
|
||||
* asynchat is buggy in the face of multithreading.
|
||||
|
||||
http://www.python.org/sf/595217
|
||||
|
||||
- It would be nice if the higher level modules (httplib, smtplib,
|
||||
* It would be nice if the higher level modules (httplib, smtplib,
|
||||
nntplib, etc.) had options for setting socket timeouts.
|
||||
|
||||
http://www.python.org/sf/723287
|
||||
|
||||
- The curses library is missing two important calls: newterm() and
|
||||
* The curses library is missing two important calls: newterm() and
|
||||
delscreen()
|
||||
|
||||
http://www.python.org/sf/665572, http://bugs.debian.org/175590
|
||||
|
||||
- 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
|
||||
* 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.
|
||||
|
||||
- reST as a standard library module
|
||||
* reST as a standard library module
|
||||
|
||||
- The import lock could use some redesign.
|
||||
* The import lock could use some redesign.
|
||||
|
||||
http://www.python.org/sf/683658
|
||||
|
||||
- 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?)
|
||||
* 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?)
|
||||
|
||||
- Support new widgets and/or parameters for Tkinter
|
||||
* Support new widgets and/or parameters for Tkinter
|
||||
|
||||
- For a class defined inside another class, the __name__ should be
|
||||
* 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.)
|
||||
|
||||
http://www.python.org/sf/633930
|
||||
|
||||
- Decide on a clearer deprecation policy (especially for modules)
|
||||
and act on it.
|
||||
* Decide on a clearer deprecation policy (especially for modules) and
|
||||
act on it.
|
||||
|
||||
http://mail.python.org/pipermail/python-dev/2002-April/023165.html
|
||||
|
||||
- Provide alternatives for common uses of the types module;
|
||||
Skip Montanaro has posted a proto-PEP for this idea:
|
||||
* Provide alternatives for common uses of the types module; Skip
|
||||
Montanaro has posted a proto-PEP for this idea:
|
||||
|
||||
http://mail.python.org/pipermail/python-dev/2002-May/024346.html
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
- Lazily tracking tuples?
|
||||
* Lazily tracking tuples?
|
||||
|
||||
http://mail.python.org/pipermail/python-dev/2002-May/023926.html
|
||||
http://www.python.org/sf/558745
|
||||
|
||||
- Make 'as' a keyword. It has been a pseudo-keyword long enough.
|
||||
* 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.)
|
||||
|
||||
|
||||
C API wishes
|
||||
============
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
http://www.python.org/sf/210821
|
||||
|
||||
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.
|
||||
Borland C++ builder application to interact with a python.dll build
|
||||
with MSVC.
|
||||
|
||||
|
||||
Tools
|
||||
=====
|
||||
|
||||
- Python could use a GUI builder.
|
||||
* Python could use a GUI builder.
|
||||
|
||||
http://www.python.org/sf/210820
|
||||
|
||||
|
||||
Building and Installing
|
||||
=======================
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
http://www.python.org/sf/216326
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
http://www.python.org/sf/219221
|
||||
|
||||
- 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.
|
||||
* 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.
|
||||
|
||||
http://mail.python.org/pipermail/python-dev/2004-January/041790.html
|
||||
|
||||
- Make Python compliant to the FHS (the Filesystem Hierarchy Standard)
|
||||
* Make Python compliant to the FHS (the Filesystem Hierarchy
|
||||
Standard)
|
||||
|
||||
http://bugs.python.org/issue588756
|
||||
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
|
|
|
|||
Loading…
Reference in New Issue