330 lines
11 KiB
Plaintext
330 lines
11 KiB
Plaintext
PEP: 42
|
||
Title: Feature Requests
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Jeremy Hylton <jeremy@alum.mit.edu>
|
||
Status: Final
|
||
Type: Process
|
||
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.
|
||
|
||
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.
|
||
|
||
This PEP should really be separated into four different categories
|
||
(categories due to Laura Creighton):
|
||
|
||
1. BDFL rejects as a bad idea. Don't come back with it.
|
||
|
||
2. 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.)
|
||
|
||
(possibly divided into:
|
||
|
||
2a) BDFL would really like to see some code!
|
||
|
||
2b) 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.
|
||
|
||
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 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).
|
||
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.
|
||
|
||
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
|
||
|
||
Standard Library
|
||
|
||
- 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.
|
||
|
||
http://www.python.org/sf/212317
|
||
|
||
- 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
|
||
interruptable I/O. So it's a big project.
|
||
|
||
http://www.python.org/sf/210599
|
||
|
||
- Extend Windows utime to accept directory paths.
|
||
|
||
http://www.python.org/sf/214245
|
||
|
||
- Extend copy.py to module & function types.
|
||
|
||
http://www.python.org/sf/214553
|
||
|
||
- 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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
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.]
|
||
|
||
- 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...
|
||
|
||
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.
|
||
|
||
http://www.python.org/sf/221115
|
||
|
||
- The debugger (pdb) should understand packages.
|
||
|
||
http://www.python.org/sf/210631
|
||
|
||
- 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:
|
||
|
||
- The data exceeds some size, or
|
||
|
||
- Somebody asks for a fileno.
|
||
|
||
Then the cgi module (and other apps) could use this thing in a
|
||
uniform way.
|
||
|
||
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.
|
||
|
||
Proposal:
|
||
|
||
- add an optional argument giving the delimiter string to be
|
||
appended, defaulting to "\n"
|
||
|
||
- 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.
|
||
|
||
http://www.python.org/sf/405554
|
||
|
||
- Distutils should deduce dependencies for .c and .h files.
|
||
|
||
http://www.python.org/sf/472881
|
||
|
||
- 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,
|
||
nntplib, etc.) had options for setting socket timeouts.
|
||
|
||
http://www.python.org/sf/723287
|
||
|
||
- 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
|
||
packages such as pyopenssl.
|
||
|
||
- reST as a standard library module
|
||
|
||
- 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?)
|
||
|
||
- Support new widgets and/or parameters for Tkinter
|
||
|
||
- 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.
|
||
|
||
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:
|
||
|
||
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.
|
||
|
||
- 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.
|
||
(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.
|
||
|
||
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.
|
||
|
||
|
||
Tools
|
||
|
||
- 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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
http://mail.python.org/pipermail/python-dev/2004-January/041790.html
|
||
|
||
- Make Python compliant to the FHS (the Filesystem Hierarchy Standard)
|
||
|
||
http://bugs.python.org/issue588756
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|