This message didn't get through the first time.
On Nov 5, 2007 9:40 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:
On Nov 5, 2007 9:27 PM, Russell Blau
<russblau(a)imapmail.org> wrote:
"Merlijn van Deen"
<valhallasw(a)arctus.nl> wrote:
Although I appreciate your efforts, I still want
to ask you to wait with
any other rewrite commits until you have read, understood, and reacted to
this (fairly long) email.
All of the points in your email (which I won't quote at length) are very
good ones. I think it would be very helpful for all interested participants
to agree on style and approach before coding. (My commit this morning,
incidentally, was code that I had already written for my own use, which fit
in nicely with what Misza had already done. And there's more where that
came from, but I'll wait...)
For the coding style, I propose the following:
* As base: PEP 8 [1].
Misza will be disappointed; PEP 8 says to use lowercase with underscores for
function and method names. ;)
Endorse PEP 8 ;)
One
module per class
I'd make an exception to this one to allow including
subclasses in the same
module, such as Page, ImagePage, and Category.
I agree with russblau. Additionally, one module per class might give
problems with cross importing of modules.
thirdly: point c.
This really is not a seperate point, but it is important. I think we
should use the API where possible, but having a fallback to the monobook
html parser.
Absolutely. The API doesn't do everything that you can do with HTML (yet),
and if we want backwards compatibility we have to remember that the API has
changed a lot between MW versions.
Branching is the key. The trunk should always be in sync with the
trunk of MediaWiki. Additionally each time a MediaWiki version is
released, the trunk should be forked into a compatible branch.
I also don't see the point of providing a fall back to HTML scraping,
except when absolutely necessary.
On unit testing -- it may be difficult to write
unit tests for methods that
access the wiki, because the value returned will depend on the contents of
the wiki at any given time. Maybe if we have a dedicated test wiki with at
least some pages that are locked, so that they give predictable values, that
would be a way around the problem.
Or an auto-reseted wiki or something like that.
Bryan