This message didn't get through the first time.
On Nov 5, 2007 9:40 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On Nov 5, 2007 9:27 PM, Russell Blau russblau@imapmail.org wrote:
"Merlijn van Deen" valhallasw@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