pep-0042.txt

PEP: 42
Title: Feature Requests
Version: $Revision$
Last-Modified: $Date$
Author: Jeremy Hylton <jeremy@alum.mit.edu>
Status: Active
Type: Informational
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.

      pickle lacks float('inf')
      http://www.python.org/sf/445484

      Error on handling nan
      http://www.python.org/sf/737648

      Infinite floats don't work in compiled modules on windows
      http://www.python.org/sf/757815

    - 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


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: