First of all, if you haven't already read it, read the PEP 8
Style Guide for Python Code which, if in doubt, serves as
the default coding-style for the py lib.
generally we want to drive and interweave coding of
documentation, tests and real code as much as possible.
Without good documentation others may never know about
your latest and greatest feature.
adding features requires adding appropriate tests.
bug fixes should be encoded in a test before being fixed.
write telling log messages because several people
will read your diffs, and we plan to have a search facility
over the py lib's subversion repository.
if you add .txt or .py files to the repository then
please make sure you have svn:eol-style set to native.
which allows checkin/checkout in native line-ending format.
Tests are the insurance that your code will be maintained
further and survives major releases.
Try to put the tests close to the tested code, don't
overload directories with names.
If you think of exporting new py lib APIs, discuss it first on the
py-dev mailing list and possibly write a chapter in our
future_ book. Communication is considered a key here to make
sure that the py lib develops in a consistent way.