Sourceforge is used to track bug reports, feature requests, and patches:
https://sourceforge.net/projects/python/
Each of those submissions needs to be reviewed and discussed.
A good way to participate in python development is to spend
some time adding useful comments to each report.
Bug reports
------------
* Sometimes the OP thinks a bug is present when, in fact, Python
is behaving as intended. It is useful to gently steer them in the
right direction, correct their understanding, and have them close
the bug report.
* Sometimes the bug is unique to OP's own environment and it
is helpful to have another person confirm the bug on another
machine.
* Often, a bug report is inadequately specific -- "My 200 line script
doesn't work". Help is needed to refine the report to the simplest
possible demonstration of the error: bool("False")!=False.
* It is even more helpful to specifically identify where the error is
occurring in the source: line 200 in textwrap.py has an and/or problem.
* In many cases, discussion is necessary to ascertain whether the
behavior is truly a bug, a documentation issue, or a natural byproduct
of other important invariants.
* It is also helpful to suggest alternative solutions and discuss the
implications of each.
Patches
--------
* The simplest checks are:
- does it work
- does it have unittests
- does it have a doc patch
* More advanced considerations:
- are there subtle code breakages (one man's bug is another's feature)
- is the change desirable
- would a refactoring have simplified the problem
- are there unintended consequences
- is there a better alternative solution
Feature Requests
-------------------
The basic idea here is to see whether life would truly be better if the
idea were adopted. Considerations include the minimizing the rate of
language growth, ease of implementation, how it fits in with the
rest of the language, and the existence of practice use cases.
Readers of comp.lang.python are also in a good position to make
comments on the idea and how it fits in with stated Python design
goals. For example, IDLE could easily grow macros, RCS buttons,
templates and such, but it's design goal is to be a relatively simple
yet complete, portable editor/ide written in pure python -- this means
that grandiose ideas to transform it into emacs will likely not be accepted.
The presence of a feature in another language is neither cause for
acceptance or rejection. Just because Perl, PHP, VB, or Ruby does
something, it is not necessarily good or necessarily bad. It does
at least provide a proof-of-concept and real world experience with
the feature so that we can learn from its successes or failures. The
itertools module was designed to capture some of the successes
in Haskell and ML.
Raymond Hettinger
