Re: [pygccxml-development] argument policies

[Roman Y. <rom...@gm...>]

On 5/3/06, Matthias Baas <ba...@ir...> wrote:
> ok, of course a design document can be postponed until the actual
> problem is better understood... :)

-:)

> One thing that might be useful for me at the moment would be the
> possibility for an arg policy to actually spawn another wrapper so that
> there'll be two wrappers with different signatures.

I think a little bit different. I think that pyplusplus should
generate only 1 wrapper
for the function. But it should be fully functional. All other
customization/conveniences should be done from Python.

For example "return status as exception" arg policies could be solved in Py=
thon.
This will also improve compilation time.

> For example, I have
> C++ methods that look like this:
>
>    void get(double*)
>
> They just return an array of a predefined size. With my current arg
> policies I can turn that into a Python method that takes no arguments
> and returns a list of floats. But meanwhile I'm also toying with the
> idea to provide an additional version of the method that takes a list as
> argument and that will fill that list with the return values. This will
> be less "Pythonic" but it's closer to the original C++ API.
> I don't know if it should really be the arg policy that creates the
> additional wrapper or if it should be done by the user. For example, I
> could also imagine a way where the user can "clone" a declaration and
> then just apply a different arg policy to the clone.

This will never work ( reliably ). py++ assumes that code is 100% correct.
Another way to solve this is to parse files, generate C++ wrapper for
the functions,
and then to parse again with generated functions wrappers.

> > Yes. If you don't mind I'd like next structure of the directory:
> > contrib
> > |----your name
>
> Do you really insist on this? What name would that be? The experimental
> stuff is not by myself alone, it's also by Allen. Personally, I would
> much prefer a directory name that's chosen after the *functionality* of
> its contents and not after its initial author(s). The latter would
> rather look as if the directory contains my private stuff, but of
> course, the directory is open to anyone and people should rather be
> encouraged to contribute to it (would we then have to rename the
> directory? ;) The authors can be mentioned in a file inside the
> directory, then it will also be clear that you are not responsible for
> that code and the list of authors can be extended if necessary.

I don't insist on this at all. I saw this structure in docutils
project. If you have
something different in mind, that is perfectly okay with me.

> - Matthias -


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/