Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 42 – Feature Requests

Author:
Jeremy Hylton <jeremy at alum.mit.edu>
Status:
Withdrawn
Type:
Process
Created:
12-Sep-2000
Post-History:


Table of Contents

Important

This PEP has been withdrawn.

×

It is obsolete. All new feature requests should either go to the Python bug tracker for very simple requests or the Ideas Discourse category for everything else. The rest of this document is retained for historical purposes only.

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:

    1. BDFL would really like to see some code!
    2. 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.

    https://bugs.python.org/issue215555

  • 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 https://bugs.python.org/issue481171

  • 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. https://bugs.python.org/issue443866

Standard Library

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.

    https://bugs.python.org/issue210821

    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

Building and Installing


Source: https://github.com/python/peps/blob/main/peps/pep-0042.rst

Last modified: 2024-04-14 20:08:31 GMT