Ok now. As I am a complete lamer when it comes to team coding, coding standards etc., I'll take your words for it, but have nonetheless several lame questions.
The purpose of the rewrite was
a) to restructure the framework
b) to have consistent formatting and documentation
c) to move to the API
and possibly
d) to add i18n support
First of all: point b.
Before any new code is written, we should agree on a fixed coding style.
The current framework has several coding styles used throughout the
framework - and even sometimes in one class: in the Page class, we have
got Page.urlname, Page.isAutoTitle and Page.put_async... - I think we
should use one style for the entire framework.
For the coding style, I propose the following:
* As base: PEP 8 [1].
* UTF8 encoding for all files (and using u'' for all strings), with UTF8 BOM
* Docstrings mandatory, using Epydoc [2] for describing parameters and
return value. Defining the function in this way almost automatically
defines unit tests for that function.
One module per class
Note that all code should be written thread safe: we want to use
persistent HTTP connections and this means we will be sharing a connection
throughout several page objects. If we want to be able to put in a thread,
we really need to make sure code is thread safe.
Secondly: point a.
<snip>
Because adding structure afterwards is much harder, I think we first
should decide on what modules/classes we want, then defining what
functions we want and what these functions should do. After that, we can
start writing unit tests and functions.
On a compatibility note; even though we are changing the way the framework
works, it should be possible to create a layer that maps functions in the
old framework to the new framework.
thirdly: point c.
finally: point d.
This is not a very important point, but it's kinda interesting. With the
new framework, it's easier to restructure existing functions, making
translations easier.
I'm sorry for the long email, and I repeat: I really appreciate your
efforts, but I really think we should address these issues before starting
at - even the most basic - code.