|
Size: 2521
Comment:
|
Size: 284
Comment: Add CategoryHomepage.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| 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. :) | We used CVS and GNU Arch for our MoinMoin repository, but switched to Mercurial because it is so nice and fast (and mostly in Python). |
| Line 7: | Line 7: |
| = How to improve Mercurial = I am new to hg, so take this with a grain of salt: == 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: {{{ #!/usr/bin/env python (optional, for tools) # -*- 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 or annyoing when you try to find out what this 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 }}} |
CategoryHomepage |
I am a MoinMoin wiki developer (also in Python) and Linux user.
See ThomasWaldmann and ThomasWaldmann.
We used CVS and GNU Arch for our MoinMoin repository, but switched to Mercurial because it is so nice and fast (and mostly in Python).