[Biopython-dev] Fwd: New Biopython (sub)module?
David Cain
davidjosephcain at gmail.com
Mon Aug 19 17:18:48 EDT 2013
Hi, Cyrus! Before the constructive criticism, I just wanted to say your
module looks excellent and thank you for opening it up as free software!
I'm by no means a developer (just interested in Biopython's development),
but I noticed your code generally doesn't adhere to
PEP8<http://www.python.org/dev/peps/pep-0008/>.
If you're interested in getting feedback from others, it's quite valuable
to format your code by the standards. (Proper PEP 8 code has a look and
feel that's easier for the trained eye to view).
Key things that detract from your module's readability:
- CamelCase method, module, and field names (when a Python developer sees
these, they're prone to assuming the name is for a class). Of course,
Biopython doesn't provide the best example here, but there are reasons for
that<http://www.biopython.org/pipermail/biopython-dev/2012-September/009938.html>
(it'll
be fixed eventually). All-caps names are either refrained from use, or used
for constants (i.e. you may wish to rename your module `mosaic`).
- Very long line wrapping - you should really try to keep your lines to 79
characters
- Using integers as booleans (you should stick to True/False, e.g. `while
True` in lieu of `while 1`)
- module renamings: it's much easier to see `random.shuffle` over
`r.shuffle`, as one can assume `random` is the standard module, whereas `r`
might be completely different.
Also, your module should definitely remove usage of pdb if you wish to
publish it as part of an official Python package.
Would you be open to hosting a development branch of your code on GitHub or
a similar community-editable resource? Any acceptance to the official
Biopython distribution would of course be up to the main devs, but I'd be
more than happy to test your code and make suggestions, regardless of its
integration to a third-party package.
David
More information about the Biopython-dev
mailing list