[Bf-committers] Freestyle branch status report May 2012

[Dan Eicher]

On Thu, May 24, 2012 at 7:01 PM, Tamito KAJIYAMA
<rd6t-kjym at asahi-net.or.jp> wrote:
> Dan,
>
> Auto-generation of the Freestyle Python API would be great if that is
> feasible and practical.  There are about 150 Python wrappers of C++ classes,
> and maintaining them manually has been a kinda painful excercise.
>
> Just for your information, I send you a link to a blog post that summarizes
> problems and implemented solutions for improving the Freestyle Python API:
> http://freestyleintegration.wordpress.com/2009/08/04/recent-commits-on-the-freestyle-python-api/
> I forward this to you, since there were several subtle issues that needed to
> be addressed carefully.  Honestly speaking, for this reason I am a bit reluctant
> to do a major revision of the present Python API implementation.
>
> As implicitly mentioned in the blog post, the C++ class system is quite static
> (i.e., user extensions of the present class hierarchy are very unlikely).  There
> are a limited number of C++ classes and their methods that are supposed to
> be subclassed/overriden by Python subclasses (see Section 3.4 of the blog
> article).  Exploiting these characteristics of the C++ class system might help
> you simplify the Python API auto-generation.
>
> Regards,
>
> --
> KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>
>

Looking over that blog post, freestyle code and pybindgen (which can
indeed do iterators, who knew?) the only thing that would really need
to change for it all to work would be adding methods like
Interface1D.getVertices() which could be wrapped in python as
Interface1D.vertices but would need to return the collection instead
of the actual iterator. Then python would do the right thing if one
were to write:

for vert in i1D.vertices:
    do_stuff(vert)

For the borrowed/owned reference stuff, pybindgen throws an exception
if you don't specify that on function args and return values that are
pointers or references so either way you have to tell it if it's owned
or borrowed, no choice.

Finally, for python sub-classing, that Just Works. Python can call C++
(non-pure virtual) base class methods, C++ can call overridden
py-methods, everyone's happy.

I'm not suggesting you stop work on the current py-api and wait on my
slow ass or anything, just seeing if there's any interest in this
before starting any work on it.

Dan