mirror of
https://github.com/kennethreitz-archive/howtopython.org.git
synced 2026-06-05 07:06:15 +00:00
Bruno Alla
90 lines
2.8 KiB
ReStructuredText
90 lines
2.8 KiB
ReStructuredText
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
|
||
--------
|
||
|
||
Guido van Rossum, the creator of Python, is often referred to as the BDFL — the
|
||
Benevolent Dictator For Life.
|
||
|
||
Python Software Foundation
|
||
--------------------------
|
||
|
||
The Python Software Foundation is a non–profit 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/>`_.
|
||
|
||
|
||
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
|
||
----
|
||
|
||
PEPs (*Python Enhancement 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
|
||
|
||
|
||
|