PEP: 42 Title: Feature Requests Version: $Revision$ Author: Jeremy Hylton 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 " 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 - 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 - 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 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: