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

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

On 8/20/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
> IMHO this is a shame because the pypp_api much better addresses the
------------------------^^^^^^^^^^^^^^^^^^^^^^^

I don't think so. Please define "much better", what do you  mean?

> needs of keeping things simple and making Py++ approachable for new
> users and users porting over from Pyste.

I did not created another Pyste, Py++ will never be another Pyste. Pyste failed
to solve real world problems. The projects that use Pyste do not exist!

> > 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.

That is what I am asking you for. Py++ solves real problems and
exports real projects.
Please be specific.


> First the goals of pypp_api
>
>     * Optimize the time it takes to create the final bindings for a
>       given C++ library.

I asked you to provide me with profiling information. All projects I
has run under 3 minutes
and generates more or less 1000 files.

>     * 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.

I consider this to be a bug. Please report it. What is the case your
are talking about.

>     * Provide domain specific language so users can focus on their code

I am open for suggestions. Please write the paper, like Matthias did.
Thus we will work
together on it and I promise you after we get to agreement I will implement it.

>     * Do not require the user to know anything outside of the high-level
>       API to accomplish most tasks.

1. Please define high level API. I don't know what you mean.

2. This will never work. He should know at least what is declarations
and declarations
    tree ( pygccxml.declarations package )

>     * Provide access to all the power of pypluplus and pygccxml *if* the
>       user wants it

What do you mean? To introduce 3 module builders ( beginner,
intermediate and power
user ) ?

>     * User background
>           o Detailed knowledge of boost.python should not be required

This will never work: call polices. If you mean to provide simple interface for
generating "def" and similar, than the code you are going to write will not work
( and does not ) in all cases. That is why is still outside of Py++.

> In my opinion the Py++ API fails on all of these points.

Obviously, my opinion is different. But I'd like you to be happy with Py++.
So, please, now when we have wiki: select subject(s) you want to improve,
right the document and we will work on it together. I am very pleased how it
works with "argument policies".

> 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.

And I asked you to be more specific and did not get the answer.

> 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 latest addition of "user code everywhere" should eliminate this knowledge.
Please, specify use-case, that you think simple and require knowledge
of internal
details. Please, please, please.

> 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.

What are they. Please describe them.

> 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.

Allen, please describe what you want, create document that we can discuss it.



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