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

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 dependend 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...".