Re: [Modeling-users] Request for testers: dynamic creation of classes from a model

[Sebastien B. <sbi...@us...>]

        Hi,

Mario Ruggier <ma...@ru...> wrote:
> sorry i did not do this earlier, but i finally managed to give some time
> to it. I did as instructed, installing NF 0.6, and the dynamic patch over
> the latest installation of the framework, and ran thru the tests as instr=
ucted.
> I am testing with a Postgresql server. The log of each test is below.
> Note there is also a problem with the general test run.py, which I am
> placing first...

  True, the tests/run.py testsuite was not updated and fails. I'll soon
  send an update for that.

> The following tests have been run on an OSX box, python 2.2=20
> ((#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on=20
> darwin), with Modeling 0.9-pre-15 plus this patch.
[...]
> % python ./test_EditingContext_Global.py -r -c
> [Model.searchModel] Trying ./pymodel_AuthorBooks.py
> Traceback (most recent call last):
[...]
> ".../Modeling/dynamic.py", line 39, in instance_method
>      meth=3Dnew.instancemethod(func, None, aClass)
> TypeError: instancemethod() argument 3 must be class, not type

I think you need to upgrade your python version. There is a bug in 2.2
final, fixed from 2.2.1c1, that makes new.instancemethod() fail for new
style classes. See:
  http://sf.net/tracker/index.php?func=3Ddetail&aid=3D503091&group_id=3D547=
0&atid=3D105470
  http://www.python.org/2.2.2/NEWS.txt

> Anyway, I am not sure I understand all the benefits of this intriguing
> new feature, but does this also mean (in particular in option 3 (metaclas=
s)
> that one can just manually define "CustomObject" classes by specifying
> only the custom python code for that class, and never have to worry
> about merging with the regenerated modules after model changes?

The first reason to make this is that various people asked if there was
an alternative to code generation; this demonstrates that we're not
tightly bound to code-generation. In fact, this also makes it clearer
what requirements need to be fulfilled for CustomObject classes --this
will eventually enhance the user's guide too.

  And yes, this means that you can:

1. directly experiment your models without the code-generation phase,

2. design your classes so that they inherit from the generated modules
   or use the metaclass; you'll put there any other methods, such as
   validation methods, and in this case, __init__() and attributes'/
   relationships' setters and getters will be automatically in sync with
   the model --no need to update the source anymore.

> Also, why 3 ways? Experimental? Will you pick what is the better of
> the 3, and stick with that one?

The answer to your last question is still not clear to me. Now on the
three ways:

  - "classic" [-c / dynamic.build()]: because we're supporting py2.1, we
    need the generation of classic-style classes. Now if you use this w/
    py2.2, you'll get new-style classes just because CustomObject is a
    new-style class. In fact, this dynamic.build() is really equivalent
    to what you get when generating the code.

  - metaclass [-M, -m / dynamic.build_with_metaclass()]: this is an
    alternate method, using metaclass ;)

Last, the difference between -M and -m is just properties; this could
also be done with the "classic" build. I realized that most people
prefer to write book.title=3D"my title" rather than
book.setTitle("mytitle"), that's why I added properties.

It's also not clear whether the metaclass way is appropriate. You can
make your own idea by e.g. reading those two articles (referenced some
time ago by the excellent daily-python http://www.pythonware.com/daily):

  "Metaclasses are evil" by Hans Nowak
    http://zephyrfalcon.org/weblog/arch_d7_2003_09_06.html#e337

  and the sequel: "Metaclasses, reprise"
    http://zephyrfalcon.org/weblog/arch_d7_2003_09_13.html#e342

This is my first metaclass, so it's highly possible that I fall into the
experimenting-and-learning category ;)


-- S=E9bastien.