1410
Comment:
|
2972
|
Deletions are marked like this. | Additions are marked like this. |
Line 8: | Line 8: |
I am new to hg, so take this with a grain of salt: | I am new to hg, so take this with a grain of salt. I am willing to do some of that stuff listed below, but I hesitate to do bigger refactorings / src code reformatting as long as I don't know if this is wanted by core developer(s). == general stuff == |
Line 25: | Line 27: |
This stuff could be put into some _header.py so one can easily use it when starting a new file. | This stuff could be put into some _template.py so one can easily use it when starting a new file. * Avoid putting longer license texts ONLY into the header of src files - nothing is more boring and annyoing when you try to find out what some file does. I personally like to reference licenses ''by reference'' (see above), that's shorter and leaves more space for useful "what this does" comments. I am not a lawyer... |
Line 27: | Line 30: |
* use epydoc docstrings and generate docs using epydoc tool | * use more epydoc docstrings and generate docs using epydoc tool, put the html output somewhere online * maybe try to use `from xy import *` less than now == optimizing for portability == hg is optimized for speed mostly. With Python it uses a highly portable language, though. In some applications (like making a hg moin 2.0 backend some time in the future), extremely high speed is less important, but if one demands a C compiler for installation, this can cause trouble for installation. Even if you compile it before and offer platform-dependent packages, it loads the developers and maintainers with the burden to make such platform dependent packages. As this only affects mpatch.c and bdiff.c, I would be glad so see some python equivalents of them and import code similar to: {{{ try: import c_bdiff as bdiff except ImportError: import bdiff }}} I didn't try what setup.py install does right now when there is no C compiler, but as soon as we have the py implementations it should only emit some warning "No C compiler found, using py implementations...". |
I am a MoinMoin wiki developer (also in Python) and Linux user.
See ThomasWaldmann and ThomasWaldmann.
We currently use GNU Arch for our MoinMoin repository, but after some playing with mercurial and having a working converter, who knows... - I like good Python programs.
How to improve Mercurial
I am new to hg, so take this with a grain of salt. I am willing to do some of that stuff listed below, but I hesitate to do bigger refactorings / src code reformatting as long as I don't know if this is wanted by core developer(s).
general stuff
- run pychecker more often - although it might give some false alarms, it often points out strange places in the src and sometimes even severe errors.
- read and follow pep-0008 and maybe put multiple statements on multiple lines (even for single line blocks under some "if"), makes it more readable
- make sure every py src code file begins like:
# -*- coding: iso-8859-1 -*- (or ascii or utf-8, just to make things clear) """ What this file does in a single line. What this file does in some more detailed description... @license: GNU GPL, see COPYING for details. @copyright: 2005 Firstname Lastname <email> @copyright: 2005 more authors... """
This stuff could be put into some _template.py so one can easily use it when starting a new file. Avoid putting longer license texts ONLY into the header of src files - nothing is more boring and annyoing when you try to find out what some file does. I personally like to reference licenses by reference (see above), that's shorter and leaves more space for useful "what this does" comments. I am not a lawyer...
- make sure your src code files end with an empty line (makes it easier for diff, avoids "missing end of line at eof warnings")
- use more epydoc docstrings and generate docs using epydoc tool, put the html output somewhere online
maybe try to use from xy import * less than now
optimizing for portability
hg is optimized for speed mostly. With Python it uses a highly portable language, though.
In some applications (like making a hg moin 2.0 backend some time in the future), extremely high speed is less important, but if one demands a C compiler for installation, this can cause trouble for installation. Even if you compile it before and offer platform-dependent packages, it loads the developers and maintainers with the burden to make such platform dependent packages.
As this only affects mpatch.c and bdiff.c, I would be glad so see some python equivalents of them and import code similar to:
try: import c_bdiff as bdiff except ImportError: import bdiff
I didn't try what setup.py install does right now when there is no C compiler, but as soon as we have the py implementations it should only emit some warning "No C compiler found, using py implementations...".