On 05/04/2010 03:06 AM, Samuel Williams wrote:
Dear Rouslan,
It looks interesting. I say go for it. You will learn something and might make
some improvements on existing ideas.
I recommend putting the code on www.github.com
Kind regards,
Samuel
Thanks for the suggestion. I think I'll do just that. The "social"
aspect sounds interesting, since up until now, this project has been a
solitary exercise.
On 05/04/2010 01:51 AM, Stefan Behnel wrote:
> Last I heard, that was basically what PyBindGen does (and probably some
> other existing binding generators). You should take a look at them
> before investing too much time into a duplicated effort.
>
> Also, if you're interested in performance, you should take a look at
> Cython, which is an optimising compiler for (basically) Python code that
> can talk to C, C++ and Fortran code. It's been used a lot for writing
> performance critical library wrappers.
>
> Stefan
>
I took a brief look at PyBindGen. I noticed a couple of things in the
generated code of a test module. The PyObject definitions held a pointer
to the contained datatype, which is one of the things I was trying to
steer away from. It would generate a std::map for each new type,
apparently to allow the contained type to be matched back to the
PyObject when needed. I intend to use the same method that Boost.Python
uses, sneak the pointer into the destruct functor of a shared_ptr.
And when parsing arguments from an overloaded set, PyBindGen appears to
generate complete separate functions for each overload and then try one
after the other. The reason mine doesn't support overloaded named
arguments is because it instead uses a bunch of nested if-statements to
match the overload with as few checks as possible. Mine also orders the
checks so that a base-class is never checked before a derived-class and
that numeric types and string types are matched to their best fit (given
func(double x) and func(int x), a python float value will always call
func(double)). I'm not certain that PyBindGen doesn't generate code that
takes this into consideration I haven't studied its code.
I'll definitely take a look at how Cython handles arguments some time.
It's also interesting to note that while PyBindGen will parse C++ types
itself, to interpret arguments and return types, mine uses gccxml to do
all the work. When given a specific overload, it will generate a dummy
function with the same set of arguments in the file given to gccxml,
along with typedefs for all built-in types. That way, you can specify
types either explicitly, or with typedefs regardless of how the
interface you want to expose does it, and my code doesn't have to do any
extra work.
The only question I have now is what about licensing? Is that something
I need to worry about? Should I go with LGPL, MIT, or something else?
And should the license be mentioned in the code or be in a single
separate file at the top-level directory?
--
http://mail.python.org/mailman/listinfo/python-list
