pep section enhancements

Signed-off-by: Kenneth Reitz <me@kennethreitz.org>
This commit is contained in:
2018-01-19 08:07:34 -05:00
parent c2291d594c
commit 572c999b07
4 changed files with 79 additions and 5 deletions
+1
View File
@@ -1 +1,2 @@
build
.DS_Store
Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 349 KiB

+78 -5
View File
@@ -3,16 +3,89 @@ Learning the Basics
We've already covered that Python is more about the people than it is about the code. So, let's learn a bit about the organizations and processes these people participate in.
The BDFL
--------
The Python Software Foundation
------------------------------
Guido van Rossum, the creator of Python, is often referred to as the BDFL — the
Benevolent Dictator For Life.
The Python Software Foundation is a nonprofit organization that is responsible for holding and protecting the intellectual property of Python, the Package Index, PyCon, and related. It heavily contributes towards the sustainability of the language and its ecosystem both financially and through infrastructure.
Python Software Foundation
--------------------------
The Python Software Foundation is a nonprofit organization that is responsible for holding and protecting the intellectual property of Python, the Package Index, PyCon, and related. It heavily contributes towards the sustainability of the language and its ecosystem both financially and through infrastructure.
`Learn More about the PSF <http://www.python.org/psf/>`_.
PEPs
----
PEPs (Python Enhncement Proposals) are the documents/process through which Python gets enhanced and changed, over time. The most infamous PEP is `PEP8 <http://pep8.org/>`_, which documents how to properly style Python code within the community.
PEPs (*Python Enhncement Proposals*) are the documents/process through which Python gets enhanced and changed, over time.
The most infamous PEP is `PEP8 <http://pep8.org/>`_, which documents how to properly style Python code within the community.
Anyone can propose a PEP, even you! It's a long process, for good reasons — you have to convince a lot of people that your idea is a good one.
There are three different types of PEPs (as defined by :pep:`1`):
**Standards**
Describes a new feature or implementation.
**Informational**
Describes a design issue, general guidelines, or information to the
community.
**Process**
Describes a process related to Python.
Notable PEPs
~~~~~~~~~~~~
There are a few PEPs that could be considered required reading:
- :pep:`8`: The Python Style Guide.
Read this. All of it. Follow it.
- :pep:`20`: The Zen of Python.
A list of 19 statements that briefly explain the philosophy behind Python.
- :pep:`257`: Docstring Conventions.
Gives guidelines for semantics and conventions associated with Python
docstrings.
You can read more at `The PEP Index <http://www.python.org/dev/peps/>`_.
Submitting a PEP
~~~~~~~~~~~~~~~~
PEPs are peer-reviewed and accepted/rejected after much discussion. Anyone
can write and submit a PEP for review.
Here's an overview of the PEP acceptance workflow:
.. image:: ../_static/pep-0001.png
Python Conferences
--------------------------
The major events for the Python community are developer conferences. The two
most notable conferences are PyCon, which is held in the US, and its European
sibling, EuroPython.
A comprehensive list of conferences is maintained at `pycon.org <http://www.pycon.org/>`_.
Python User Groups
------------------
User Groups are where a bunch of Python developers meet to present or talk
about Python topics of interest. A list of local user groups is maintained at
the `Python Software Foundation Wiki <http://wiki.python.org/moin/LocalUserGroups>`_.
PEPs
----
Anyone can propose a PEP, even you! It's a long process, for good reasons — you have to convince a lot of people that your idea is a good one.