48 captures
25 Jun 2018 - 12 Dec 2024
Sep OCT Nov
28
2019 2020 2021
success
fail

About this capture

COLLECTED BY

Collection: Common Crawl

Web crawl data from Common Crawl.
TIMESTAMPS

The Wayback Machine - http://web.archive.org/web/20201028192733/https://devguide.python.org/langchanges/
  

Navigation



● index
● next |
● previous |

●Python »
   Python Developer's Guide »  
|  






20. Changing the Python Language


On occasion people come up with an idea on how to change or improve Python as a programming language. This document is meant to explain exactly what changes have a reasonable chance of being considered and what the process is to propose changes to the language.

20.1. What Qualifies


First and foremost, it must be understood that changes to the Python programming language are difficult to make. When the language changes, every Python programmer already in existence and all Python programmers to come will end up eventually learning about the change you want to propose. Books will need updating, code will be changed, and a new way to do things will need to be learned. Changes to the Python programming language are never taken lightly.
Because of the seriousness that language changes carry, any change must be beneficial to a large proportion of Python users. If the change only benefits a small percentage of Python developers then the change will not be made. A good way to see if your idea would work for a large portion of the Python community is to ask on python-list or python-ideas. You can also go through Python’s stdlib and find examples of code which would benefit from your proposed change (which helps communicate the usefulness of your change to others). For further guidance, see Suggesting new features and language changes.
Your proposed change also needs to be Pythonic. While only the Steering Council can truly classify something as Pythonic, you can read the Zen of Python for guidance.

20.2. PEP Process


Once you are certain you have a language change proposal which will appeal to the general Python community, you can begin the process of officially proposing the change. This process is the Python Enhancement Proposal (PEP) process. PEP 1 describes it in detail.
You will first need a PEP that you will present to python-ideas. You may be a little hazy on the technical details as various core developers can help with that, but do realize that if you do not present your idea to python-ideas or python-list ahead of time you may find out it is technically not possible (e.g., Python’s parser will not support the grammar change as it is an LL(1) parser). Expect extensive comments on the PEP, some of which will be negative.
Once your PEP has been modified to be of proper quality and to take into account comments made on python-ideas, it may proceed to python-dev. There it will be assigned a PEP dictator and another general discussion will occur. Once again, you will need to modify your PEP to incorporate the large amount of comments you will receive.
The PEP dictator decides if your PEP is accepted (typically based on whether most core developers support the PEP). If that occurs then your proposed language change will be introduced in the next release of Python. Otherwise your PEP will be recorded as rejected along with an explanation as to why so that others do not propose the same language change in the future.

20.3. Suggesting new features and language changes


The python-ideas mailing list is specifically intended for discussion of new features and language changes. Please don’t be disappointed if your idea isn’t met with universal approval: as the long list of Rejected and Withdrawn PEPs in the PEP Index attests, and as befits a reasonably mature programming language, getting significant changes into Python isn’t a simple task.
If the idea is reasonable, someone will suggest posting it as a feature request on the issue tracker, or, for larger changes, writing it up as a draft PEP.
Sometimes core developers will differ in opinion, or merely be collectively unconvinced. When there isn’t an obvious victor then the Status Quo Wins a Stalemate as outlined in the linked post.
For some examples on language changes that were accepted please read Justifying Python Language Changes.

 



Table of Contents



●20. Changing the Python Language

●20.1. What Qualifies
●20.2. PEP Process
●20.3. Suggesting new features and language changes


Sections



●1. Getting Started
●2. Where to Get Help
●3. Lifecycle of a Pull Request
●4. Running & Writing Tests
●5. Increase Test Coverage
●6. Helping with Documentation
●7. Documenting Python
●8. Silence Warnings From the Test Suite
●9. Fixing “easy” Issues (and Beyond)
●10. Issue Tracking
●11. Triaging an Issue
●12. Following Python’s Development
●13. Porting Python to a new platform
●14. How to Become a Core Developer
●15. Developer Log
●16. Accepting Pull Requests
●17. Development Cycle
●18. Continuous Integration
●19. Adding to the Stdlib
●20. Changing the Python Language

●20.1. What Qualifies
●20.2. PEP Process
●20.3. Suggesting new features and language changes


●21. Experts Index
●22. gdb Support
●23. Exploring CPython’s Internals
●24. Changing CPython’s Grammar
●25. Design of CPython’s Compiler
●26. Design of CPython’s Garbage Collector
●27. Updating standard library extension modules
●28. Coverity Scan
●29. Dynamic Analysis with Clang
●30. Running a buildbot worker
●31. Core Developer Motivations and Affiliations
●32. Git Bootcamp and Cheat Sheet
●33. Appendix: Topics

Previous topic


19. Adding to the Stdlib

Next topic


21. Experts Index

This Page



● Show Source  







Navigation



● index
● next |
● previous |

●Python »
   Python Developer's Guide »  
|  


© Copyright 2011-2020, Python Software Foundation.  
 The Python Software Foundation is a non-profit corporation. Please donate.
 
 Last updated on Oct 26, 2020.  Found a bug?
  Created using Sphinx 1.8.5.