generic to python, not pyjamas]
On Tue, Jun 7, 2011 at 4:38 PM, Alexander Tsepkov wrote:
I'm working on a python-based side project where I want to be able to
generate multiple variations of the program and I really like the way
pyjamas handles this same problem with the browsers by pulling in variations
from __safari__, __ie6__, etc. It seems very elegant to just define the
actual functions that change rather than copy-pasting entire code and having
to maintain the same class in multiple places. One way I was thinking of
dealing with this is to use regular expressions to scan these functions and
classes, but I feel like there would be too many special cases with
indentations that I would need to address. I'm trying to understand the
mechanism by which pyjamas does this so I can apply something similar to my
python code.
ok, then just use pyjd/imputil.py. it's a modified - bug-fixed -I'm working on a python-based side project where I want to be able to
generate multiple variations of the program and I really like the way
pyjamas handles this same problem with the browsers by pulling in variations
from __safari__, __ie6__, etc. It seems very elegant to just define the
actual functions that change rather than copy-pasting entire code and having
to maintain the same class in multiple places. One way I was thinking of
dealing with this is to use regular expressions to scan these functions and
classes, but I feel like there would be too many special cases with
indentations that I would need to address. I'm trying to understand the
mechanism by which pyjamas does this so I can apply something similar to my
python code.
version of the "standard" version of the python imputil.py which has
then been modified to include the "platform overrides" concept, as
well.
the problem(s) with the "standard" version of imputil.py include that
it failed to perform the correct import operations as compared to
standard built-in (c-code) python import behaviour. one of the very
first things i had to do was to fix the bugs and broken behaviour in
imputil.py
the second important thing that i had to do was, to instead of
looking up just the cached .pyc pre-compiled byte code file, but also
look up the platform override pre-compiled byte code file... *and*
also make sure that, if there existed a platform override .py file
*and* the "original" / "base" .py file, the platform override bytecode
was thrown away.
i.e. it's a leetle more complex than just "let's look at the
timestamp on the .pyc file, compare it to the timestamp of the .py
file".
for those people on python-list who may not be familiar with the
platform overrides system in pyjamas, it's a fantastic concept where,
instead of doing ridiculous amounts of "if platform == 'win32' do xyz
elif platform == 'cygwin' do abc elif elif elif elif elif elif
elif...." [i'm sure you get the idea] you just have one "base" file
e.g. compiler.py and then you have "overrides" compiler.win32.py or
compiler.cygwin.py etc. etc.
in these "overrides", you have classes with methods with the *exact*
same name as in the "base" file, and the [heavily-modified] imputil.py
performs an AST-level "merge" prior to byte-code compilation.
the technique forces a clean and clear separation of an API from the
functionality behind the API, with these overrides providing
Object-Orientated design methodology at a base "system" level.
l.