[C++-sig] Patches and complete pyste replacement prototype for pyplusplus

[Allen Bierbaum]

On 2/25/06, Matthias Baas <baas at ira.uka.de> wrote:
> Allen Bierbaum wrote:
> > On 2/25/06, Roman Yakovenko <roman.yakovenko at gmail.com> wrote:
> >> Allen and Matthias many thanks to you for your work. Meanwhile I have been
> >> working on my own version. I still a little bit busy, I will review
> >> every version and I promise to
> >> take the best parts from all 3 proposals. It will take some time.
> >
> > Would you and Matthias be interested in collaborating on the review
> > and "taking the best parts" from the 3 proprosals?
>
> Sure (aren't we doing that already to some degree? ;)...

Yes, but I think we are getting to a point where closer collaboration
could be helfpul to get something finalized.

> Roman, I'd also like to hear how your version will differ from ours. Is
> it based on the same concepts than ours or is it something new? Now that
> we already have two separate implementations I think before creating a
> third one, it would be useful to discuss the pros and cons of the things
> we have and then create an improved API.
> I suppose eventually it would be more productive if we would all work on
> the same code instead of having three separate "branches".

Agreed.  It would already be nice to have a shared source code area
under revision control.

>
> > For example I
> > could volunteer the wiki that I have been using a a place to
> > collaborate on a unified API description.
>
> Any "documentation tool" is fine with me as long as there actually *is*
> any documentation. As you might have noticed, I was using doxygen which
> has the advantage that the doc strings can be used for the final
> implementation (which I did *after* writing the documentation) and you
> don't have to copy the stuff out of the wiki. But of course, it's not as
> open to the public as a wiki is...

I wasn't thinking of wiki for documentation.  I was thinking of using
it to discuss and refine the API.  I guess the outcome of this could
serve as the basis for the tutorial or guide documentation but I whole
heartedly agree with you that the code itself should be highly
documented.  You may have noticed that I tried to add a good deal of
documentation as well.  I thought about using doxygen, but I know that
is rather non-standard for python code and I saw that Roman is using
restructured text.  In the end I just used plain text but I would like
to rework this into something more structured once the API is
stabalized.

> > I read through Matthias's reply to my posting and have gotten a much
> > better understanding of where our efforts differ.  I like many of
> > Matthias's ideas and I would like to integrate some of them into the
> > API I have been using for my bindings.  There are a few things I have
> > questions about, but that is exactly what the collaboration could help
> > to iron out.
>
> So let's hear your comments and questions and what ideas you do (and do
> not) like to integrate.

See my other e-mail.  Sorry it took so long to get back.  I just
didn't have the time on Friday night to take an indepth look.

>
> > On a related topic: Roman, what did you think of the patches to
> > pygccxml/pyplusplus?  If we were able to work through getting some of
> > those things accepted I think it would enable many variations on the
> > public API since they could all use the same features on the backend
> > to interface with pyplusplus.
>
> I haven't looked at Allen's patch, but I agree that a stable internal
> pyplusplus/pygccxml interface would definitely be useful to prevent our
> individual efforts from diverging too much.

Yes.  After looking at your code I see that you are introducing flags
very similar to the ones I am using.  A standard way to do this would
be very helpful.

>
> Roman Yakovenko wrote:
>  >> Would you and Matthias be interested in collaborating on the review
>  >> and "taking the best parts" from the 3 proprosals?  For example I
>  >> could volunteer the wiki that I have been using a a place to
>  >> collaborate on a unified API description.
>  >
>  > Definitly. I think, that the main test should be usability. Can you
> setup some
>  > C++ project? After this everyone will create Python bindings with his
>  > proposed API.
>
> I think each of us already has a C++ project which we're using to test
> pyplusplus and the respective API. Allen uses it for wrapping OpenSG and
> I'm using it for wrapping the Maya SDK (which is a commercial 3D
> package). I think this is a far better test than coming up with a dummy
> project (where chances are pretty good that we would miss a lot of things).

True.  Once we progress a little further I have several other projects
I could try out that are currently using a combination of Pyste and
manual intervention.

>  > Thus, we will be able to compare and critic every API.
>
> That's what I did in my previous mail. And actually, as I tried to
> emphasize, Allen's and my version are pretty close. The basic concept is
> the same, I'd say we were just focusing on different areas. You could
> simply take one version and extend it with the stuff from the other
> version and both of us would be happy. :) So I don't see them as two
> competing proposals where you have to decide either for one or for the
> other.

Agreed.  As I said in my other e-mail I think that right now I could
migrate the expressive queries from Matthias's API to my proposal and
have something that could do everything that either API can do
individually.  The only thing keeping me from doing it tonight is that
I would like to get feedback first to make sure that 1) everyone is
okay with this path and 2) that it wouldn't be wasted effort if Roman
has a different idea of how to move forward.


Thanks,
Allen

> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>