Hello all,
A while ago, a discussion was started about the rewrite project, bug
was left unfinished. In order to help it reach a consensus, I'm
summarizing the discussion up to here, with the hope that you'll read
this rather long email and comment about the uncertainities left.
Merlijn proposed thees four to be taken into account prior to starting
the rewrite project:
a) to restructure the framework
b) to have consistent formatting (including coding style) and documentation
c) to move to the API
d) to add i18n support
He suggested PEP 8 for coding style, while X other people commented in
favor of camelCase. He also suggested using u'' for all strings,
Epydoc for inline documentation and __version__ in every file; no one
argued against any of these.
Not much discussion took place about items c and d. (Having read all
that, I'm still not sure if we reached an agreement about moving to
API totally -- and solely -- or not, though).
Item a, on the other hand, seems to be approached differently by
different persons. Merlijn suggested use of unit testing, which was
supported by some others. He also suggested a one-module-per-class
style, keeping it thread safe. Some people depicted disadvantages of
(and ambiguities of) one-module-per-class style, and I see no final
decission.
Bryan took a different approach and proposed separation of the code to
different levels as such:
* High-level
* Middleware
* Lowware or core
He also proposed some connections between each part of the current
code, and the desired "level" in the above classification.
Bryan later shared some thoughts about the GZip module. He also
suggested having a code name for our rewrite project (rather than, for
example, "pywikipedia 2.0" which was perhaps coined by Misza).
That's all. It's your comments which can drive it more ahead.
I'm not a professional programmer, nor can I call myself an expert in
Python. So please excuse me if I misunderstood something and reflected
it incorrectly in the above.
Cheers,
Hojjat (aka Huji)
Show replies by date