312 lines
11 KiB
Plaintext
312 lines
11 KiB
Plaintext
PEP: 42
|
||
Title: Feature Requests
|
||
Version: $Revision$
|
||
Author: Jeremy Hylton <jeremy@zope.com>
|
||
Status: Active
|
||
Type: Informational
|
||
Created: 12-Sep-2000
|
||
|
||
|
||
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-0000.txt 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
|
||
|
||
- A builtin function that returns the number of bytes an object
|
||
uses internally. Apparently mxTools has a sizeof function that
|
||
returns the size of the object struct itself.
|
||
|
||
http://www.python.org/sf/210835
|
||
|
||
- 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.
|
||
|
||
pickle lacks float('inf')
|
||
http://www.python.org/sf/445484
|
||
|
||
- 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 test suite is incomplete (and probably always will be).
|
||
This is a reminder to people that more regression tests are
|
||
needed.
|
||
|
||
http://www.python.org/sf/210819
|
||
|
||
- The urllib module should support proxies which require
|
||
authenication. 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
|
||
|
||
- Ensure that all .py files in the std library use 4-space indents and
|
||
no hard tabs. This was actually a PEP200 precondition for the
|
||
release of 2.0b1, but got misinterpreted as the weaker condition that
|
||
tabnanny not complain. Tim Peters will do this now, but, since about
|
||
250 files are affected, will wait until after 2.0final is released.
|
||
|
||
http://www.python.org/sf/214557
|
||
|
||
- 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
|
||
|
||
- Generalize eval to accept any mapping objects for locals and globals.
|
||
|
||
http://www.python.org/sf/215126
|
||
|
||
- 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 page.
|
||
|
||
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
|
||
|
||
- every built-in function or method (including all core
|
||
extensions) that accepts a string, dict, or list, should also
|
||
accept a UserString, UserDict, or UserList. (The latter two
|
||
should more generally accept all mappings, all sequences.)
|
||
|
||
http://www.python.org/sf/232493
|
||
|
||
- Fatter math module docs and docstrings.
|
||
|
||
http://www.python.org/sf/426539
|
||
|
||
- 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
|
||
|
||
|
||
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.
|
||
|
||
- Add unsigneds to ParseTuple/BuildValue (due to David Beazley)
|
||
|
||
Since "integers" can now have arbitrary precision and can
|
||
represent large unsigned values, can you add three new format
|
||
characters to PyArg_ParseTuple() and Py_BuildValue() for the C
|
||
datatypes "unsigned int", "unsigned long", and "unsigned long
|
||
long"?
|
||
|
||
The "u" and "l" namespace is a little crowded (and I don't think
|
||
you would want to break that). However, here's one idea:
|
||
|
||
'I' - unsigned int (consistent with H and B)
|
||
'p' - unsigned long ('p' is for positive)
|
||
'P' - unsigned long long
|
||
|
||
http://www.python.org/sf/454896
|
||
|
||
|
||
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
|
||
|
||
- There's a name conflict on case insensitive filesystems (in
|
||
particular Mac OSX) between the directory "Python" and the key
|
||
build target "python". That's currently solved by abusing the
|
||
--with-suffix option, but that's not ideal (since that also
|
||
causes the binary to be *installed* as python.exe). What should
|
||
be the solution?
|
||
|
||
http://www.python.org/sf/222215
|
||
|
||
- 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 CVS
|
||
or snapshots. Some people find this a problem in unusual build
|
||
environments.
|
||
|
||
http://www.python.org/sf/219221
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|