[Bf-committers] Freestyle branch status report May 2012

[Tamito KAJIYAMA]

Dan,

The use of C++-like iterators in the Freestyle Python API is a right thing and
not something that needs to be addressed.  I thought it was a SWIG/C++
dependency and tried to replace it with a better Pythonic syntax [1].  This
attempt was not successful for the following reason, and now I think it is an
integral part of the API design.

Two main abstract classes of the Freestyle API are 0D and 1D elements.  The
former is a point, and the latter is a polyline made of a series of 0D elements.

The API has several base functor classes for 0D and 1D elements, such as
function functors (Function0D and Function1D) and unary predicate functors
(PredicateU0D and PredicateU1D).

A 0D functor takes an iterator over 0D elements and performs computations
on the 0D element pointed by the given iterator.  This allows the 0D functor
to perform the computation based on not only the given 0D element but also
any other 0D elements before and after the 0D element.  Suppose that we
approximately compute the tangent of a curve at a point.  We need to refer to
the point as well as its previous and next points.  Passing an iterator indicating
the point is an elegant way of allowing you to access the three points.

[1] http://freestyleintegration.wordpress.com/2010/05/23/weekly-update-may-10-23/

> 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.

Yes, I took this opportunity to look at the present Python API design from a
different perspective (i.e., from the viewpoint of API auto-generation).  I really
appreciate all the discussions on this matter.

I will proceed with the finalization of Freestyle Python API improvements.

Thank you,

-- 
KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>


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

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