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-k...@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-k...@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-k...@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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
