About PEPs
General Information
Python Enhancement Proposals (
PEPs) represent an essential mechanism in the development
and evolution of the Python programming language. These proposals provide the Python developer community
with a way to discuss, analyze, and implement new features, improvements, or significant changes to the language.
PEPs are documents that
describe new ideas or proposed changes for Python. They serve as an official
communication channel between developers and the community, helping to manage and coordinate the development
of the language. Proposals can cover a wide range of topics, such as new functionalities, performance improvements,
syntax changes, or even major changes in the way the language operates.
See [
here] for the official index, sorted by categories.
Types of PEPs
Design PEPs These describe new ideas for improving the language. They can include changes to
syntax, language semantics, or the standard library. An example is
PEP 8, which defines
coding style guidelines for Python code.
Implementation PEPs These provide technical details and specific plans for implementing the
ideas presented in Design PEPs. They describe how a feature will be added or modified in Python.
Informational PEPs These do not propose changes to the language but provide information
or guidelines for the Python community. An example is
PEP 20, also known as the "
Zen of Python",
which presents the fundamental principles of Python development:
(source: peps.python.org/pep-0020)
More about PEP 8
The document can be accessed at:
peps.python.org/pep-0008
and is frequently updated, continuing the original work of the language's creator, Guido van Rossum.
The Python programming language is alive and regularly updated, and
the coding style has evolved over the decades.
Guido states that
any code is more often read than written, so a rigorous consistency of style is necessary,
and
PEP 8 is a comprehensive document that helps us.
Here are some general writing recommendations:
•
Indentation – it is recommended to use 4 spaces per level and avoid tabs. This suggestion is valid
in a way that spaces always occupy a similar space for display, while tabs can use more or less space depending on
the editor used, which can lead to odd appearances or even the inability to read the code in certain situations.
Mixed indentation (tabs + spaces) is not allowed, so choose one option.
•
The length of a line of code should be a maximum of 79 characters. Long or multiline comments
should have a maximum width of 72 characters. The limitations are recommended for ease of reading the code on various devices or multiple windows.
•
Inserting additional lines to separate blocks of code, making them easier to highlight and
understand: 2 lines between function and class definitions, 1 line between class definition, 1 extra line separating
logically related blocks of instructions, etc.
•
Files should be encoded using the UTF-8 standard. All identifiers should contain only ASCII
characters and be written in English for internationalization (see also [
PEP 383]).
•
Module/library imports should be done one per line for better understanding of the used resources.
Imports should use absolute paths whenever possible. Imports using relative paths should be explicit, simple, and short.
Good to know that it exists, interesting to read.
---
In conclusion, we can say that [
PEPs] are the backbone
of Python development, ensuring that the language evolves in a coherent and well-coordinated manner. By understanding them,
we can get closer to the essence and functioning behind the Python language.
Join our Club,
Python 3 is super cool!
