[Bf-committers] Freestyle branch status report May 2012

[Tamito KAJIYAMA]

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>


-----Original Message----- 
From: Dan Eicher 
Sent: Friday, May 25, 2012 2:06 AM 
To: bf-blender developers 
Subject: Re: [Bf-committers] Freestyle branch status report May 2012 

On Wed, May 23, 2012 at 11:43 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> @Tamito, I figured auto generation wasn't really an option here so
> didn't mention it - of course if it was practical it would be a nice
> time saver.

I wouldn't be too much trouble to come up with some pybindgen scripts
to auto-generate the py-api, from what I've seen in the current python
bindings there doesn't seem to be any gotchas.

The pros:
* automagic sub-classing support of C++ classes
* can convert C++ getter/setter methods to py-attributes
* easily rename C++ methods to make them more pythonic
* much simpler to do stuff like __call__ <--> operator() mapping,
well...automatic really.

The cons:
* time -- mostly it's just a bunch of grunt work to cleanup the output
from the header file scanner tbh
* Yet Another Build Dependency
* py3k support isn't in the main repo, only in my branch
* need to remove python stuff from C++ classes (in the long run this
is probably a 'Pro')
* need to change base class methods to pure virtual for the python
sub-classing to work correctly (ie, not let you create an instance of
a pure virtual base class)
* tp_iter & tp_iternext support is lacking -- could probably be made
to work with a little hacking though

All in all time is the biggest issue, I can't guarantee to have this
done in a timely manner since I'll be taking off the middle of next
week for my sister's graduation and to help her move then when I get
back I have to bust-ass to make my rent.

I do think with a little careful planning it's possible to make a 100%
drop in replacement for the current hand-written bindings with some
'free' stuff thrown in like pythreads support and more robust
sub-classing plus all the benefits of auto-generation.

Dan