Re: [pygccxml-development] Future of pypp_api...

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 8/20/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>> > 1. It is an open source project with very open license
>>
>> Agreed.  This isn't an issue though.  The question comes down to one of
>> will people be using and supporting the pypp_api or are the module
>> builder interface and the classes of pyplusplus going to be promoted as
>> the user-level API.
>
>
> Py++ API is going to be promoted as the user-level API

IMHO this is a shame because the pypp_api much better addresses the 
needs of keeping things simple and making Py++ approachable for new 
users and users porting over from Pyste.

>> >
>> > 2. I would like to get a list what you think is really bad in current
>> > API and what
>> >    is really good with pypp_api.
>>
>> We have discussed it before, but the goals for pypp_api really sum it up
>> well for me.
>>
>> https://realityforge.vrsource.org/view/PyppApi/PyppGoals
>
>
> In order to get results from this discussion, please right few reasons
> why Py++ API is
> bad and why pypp_api is good

There was a pretty big discussion of this in mid-July in the "pyplusplus 
status" thread, but here is my summary of the highlights.  Note I am not 
talking about specific features that can just be implemented.  I am 
talking about the differences in philosophy about what the API is for 
and how it would be used.

First the goals of pypp_api

    * Optimize the time it takes to create the final bindings for a
      given C++ library.
    * Provide simple, usable interface for wraping C++ code with
      boost.python.
          o the outcome of a statement should not differ from what the
            user expects.
    * Provide domain specific language so users can focus on their code
    * Do not require the user to know anything outside of the high-level
      API to accomplish most tasks.
    * Provide access to all the power of pypluplus and pygccxml *if* the
      user wants it
    * User background
          o Detailed knowledge of boost.python should not be required
          o More extensive knowledge may be required for advanced features.

In my opinion the Py++ API fails on all of these points.  To use the 
words of one of my developers that I convinced to use the Py++ API, "it 
is cryptic" and it requires knowing internal details of the pyplusplus 
and pygccxml modules.

My biggest complaint about Py++ center on one area.

1) 90% of users should never have to delve beyond the "easy API" (never 
need to know about creators). The current API is close to this, but 
there are still some times when IMHO users have to suddenly delve very 
deep into the internal code.

I know that you have said:  "This will never happen :-( . py++ knows to 
export only limited subset of C++."  but I don't buy into this.  It has 
nothing to do with the subset of C++ that py++ knows about.  It has to 
do with how a user-level API or domain specific language is presented.  
At the current time I don't see a user-level API, I see a bunch of 
classes that can be used to create a code generator and the user has to 
write python code to instantiate and use those classes.  This is much 
more difficult then something like Pyste and hurts clarity and I think 
it will hurt adoption.

But I think we are just going to have to agree to disagree here.  We 
want different things.  You want a library and I want a domain specific 
language.

This is why I was asking about the future of pypp_api because if it was 
going to be supported going forward I would work on it and try to make 
it better.  If it is not going to be supported I will just deal with the 
py++ API and get my scripts working.

>> >> I have already run into
>> >> cases where changes to pyplusplus have broken my generation 
>> scripts and
>> >> that is when I was using the pyplusplus builder API.
>> >
>> >
>> > In most case, when I break API I have good reason. What is your case,
>> > may be this
>> > is a bug?
>>
>> I don't think it is a bug, it is just a changing API.
>
>
> What is it?
>
> Allen, please I need details without details this discussion is
> meaningless. Sorry.

I have already fixed it.  Some arguments disappeared in the API.  I just 
had to change my code.

-Allen