Differences between revisions 2 and 5 (spanning 3 versions)
Revision 2 as of 2005-11-16 11:10:52
Size: 1410
Comment:
Revision 5 as of 2005-11-16 11:29:12
Size: 2972
Comment:
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...".

ThomasWaldmann (last edited 2009-05-19 19:31:03 by localhost)