From 483d4abd3dac958654ee21199d8cc48e78aa73e6 Mon Sep 17 00:00:00 2001 From: Matthias Bussonnier Date: Wed, 22 Jun 2016 11:40:40 -0700 Subject: [PATCH] Convert pep-0042 to Rst --- pep-0042.txt | 412 ++++++++++++++++++++++++++------------------------- 1 file changed, 208 insertions(+), 204 deletions(-) diff --git a/pep-0042.txt b/pep-0042.txt index ff130eef9..d8eb3a597 100644 --- a/pep-0042.txt +++ b/pep-0042.txt @@ -5,325 +5,329 @@ Last-Modified: $Date$ Author: Jeremy Hylton 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. +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 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): +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. +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.) +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: + 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 - will work it in when it's easy. - ) + 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 + http://www.python.org/sf/215555 - - Non-accidental IEEE-754 support (Infs, NaNs, settable traps, etc). - Big project. +* 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 - authentication. See SourceForge bug #210619 for information: +* The urllib module should support proxies which require + authentication. See SourceForge bug #210619 for information: - http://www.python.org/sf/210619 + 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 + 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. +* 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 + 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 + 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 + 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 + 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 " 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 " should be + parsed correctly. - http://www.python.org/sf/210678 + 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 + 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. + 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): + 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 + 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 + 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 + 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 + 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 + 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 + http://www.python.org/sf/221115 - - The debugger (pdb) should understand packages. +* The debugger (pdb) should understand packages. - http://www.python.org/sf/210631 + 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: + :: - - The data exceeds some size, or + I wonder if it would be a good idea to have a new kind of + temporary file that stored data in memory unless: - - Somebody asks for a fileno. + - The data exceeds some size, or - Then the cgi module (and other apps) could use this thing in a - uniform way. + - Somebody asks for a fileno. - http://www.python.org/sf/415692 + Then the cgi module (and other apps) could use this thing in a + uniform way. - - 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. + http://www.python.org/sf/415692 - Proposal: +* 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. - - add an optional argument giving the delimiter string to be - appended, defaulting to "\n" + Proposal: - - possibly special-case None as the delimiter string to avoid - adding the pad bytes too??? + - add an optional argument giving the delimiter string to be + appended, defaulting to "\\n" - http://www.python.org/sf/415694 + - possibly special-case None as the delimiter string to avoid adding + the pad bytes too??? - - pydoc should be integrated with the HTML docs, or at least - be able to link to them. + http://www.python.org/sf/415694 - http://www.python.org/sf/405554 +* pydoc should be integrated with the HTML docs, or at least be able + to link to them. - - Distutils should deduce dependencies for .c and .h files. + http://www.python.org/sf/405554 - http://www.python.org/sf/472881 +* Distutils should deduce dependencies for .c and .h files. - - asynchat is buggy in the face of multithreading. + http://www.python.org/sf/472881 - http://www.python.org/sf/595217 +* asynchat is buggy in the face of multithreading. - - It would be nice if the higher level modules (httplib, smtplib, - nntplib, etc.) had options for setting socket timeouts. + http://www.python.org/sf/595217 - http://www.python.org/sf/723287 +* It would be nice if the higher level modules (httplib, smtplib, + nntplib, etc.) had options for setting socket timeouts. - - The curses library is missing two important calls: newterm() and - delscreen() + http://www.python.org/sf/723287 - http://www.python.org/sf/665572, http://bugs.debian.org/175590 +* The curses library is missing two important calls: newterm() and + delscreen() - - 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. + http://www.python.org/sf/665572, http://bugs.debian.org/175590 - - reST as a standard library module +* 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. - - The import lock could use some redesign. - - http://www.python.org/sf/683658 +* reST as a standard library module - - 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?) +* The import lock could use some redesign. - - Support new widgets and/or parameters for Tkinter + http://www.python.org/sf/683658 - - 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.) +* 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?) - http://www.python.org/sf/633930 +* Support new widgets and/or parameters for Tkinter - - Decide on a clearer deprecation policy (especially for modules) - and act on it. +* 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://mail.python.org/pipermail/python-dev/2002-April/023165.html + http://www.python.org/sf/633930 - - Provide alternatives for common uses of the types module; - Skip Montanaro has posted a proto-PEP for this idea: +* Decide on a clearer deprecation policy (especially for modules) and + act on it. - http://mail.python.org/pipermail/python-dev/2002-May/024346.html + http://mail.python.org/pipermail/python-dev/2002-April/023165.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. +* Provide alternatives for common uses of the types module; Skip + Montanaro has posted a proto-PEP for this idea: - - Lazily tracking tuples? + http://mail.python.org/pipermail/python-dev/2002-May/024346.html - http://mail.python.org/pipermail/python-dev/2002-May/023926.html - http://www.python.org/sf/558745 +* 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. - - 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.) +* 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. +* 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 + 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. + 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. +* Python could use a GUI builder. - http://www.python.org/sf/210820 + 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 + 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 + 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 + 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 + http://bugs.python.org/issue588756 - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + End: