Thread: [pygccxml-development] Future of pypp_api...
Brought to you by:
mbaas,
roman_yakovenko
Menu
▾
▴
pygccxml-development
|
From: Allen B. <al...@vr...> - 2006-08-19 18:32:03
|
What are the future plans of the pypp_api? I am in a very frustrating position because I am very happy with the capabilities and code generation abilities of pyplusplus, I have ported all my projects over to using it and am actively promoting it to others. But I am not at all happy with the pyplusplus builder interface. I have become frustrated enough with the pyplusplus builder API that I am starting to port my generation scripts over to using the pypp_api. This API is definitely designed to be much more of a user API that just allows people to get work done. I would highly suggest that anyone that wants to use pyplusplus to create bindings should be using this API. It is simple and direct. I am willing and interested in contributing more to it, but first I wanted to make sure it is going to continue to exist. Matthias: Do you think development will continue on this API or do you only need it for a single project? Roman: Will you ever move over to using this API or recommending it as the user-level API that people should use? If you don't, then I am not sure how much use this wonderful API will ever get. The short of it is: Will this API continue to be supported and maintained as pyplusplus continues to evolve? 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. Is this just going to get worse if I use pypp_api? -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-19 18:52:17
|
On 8/19/06, Allen Bierbaum <al...@vr...> wrote:
> What are the future plans of the pypp_api?
>
> I am in a very frustrating position because I am very happy with the
> capabilities and code generation abilities of pyplusplus, I have ported
> all my projects over to using it and am actively promoting it to
> others. But I am not at all happy with the pyplusplus builder
> interface. I have become frustrated enough with the pyplusplus builder
> API that I am starting to port my generation scripts over to using the
> pypp_api. This API is definitely designed to be much more of a user API
> that just allows people to get work done. I would highly suggest that
> anyone that wants to use pyplusplus to create bindings should be using
> this API. It is simple and direct. I am willing and interested in
> contributing more to it, but first I wanted to make sure it is going to
> continue to exist.
1. It is an open source project with very open license
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.
> 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?
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-08-19 21:55:14
|
Roman Yakovenko wrote: > On 8/19/06, Allen Bierbaum <al...@vr...> wrote: > >> What are the future plans of the pypp_api? >> >> I am in a very frustrating position because I am very happy with the >> capabilities and code generation abilities of pyplusplus, I have ported >> all my projects over to using it and am actively promoting it to >> others. But I am not at all happy with the pyplusplus builder >> interface. I have become frustrated enough with the pyplusplus builder >> API that I am starting to port my generation scripts over to using the >> pypp_api. This API is definitely designed to be much more of a user API >> that just allows people to get work done. I would highly suggest that >> anyone that wants to use pyplusplus to create bindings should be using >> this API. It is simple and direct. I am willing and interested in >> contributing more to it, but first I wanted to make sure it is going to >> continue to exist. > > > 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. > > 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 As you have said, your vision for pyplusplus is to be an API for writing code generators. That is a fine goal, but what I want to use and what I want to provide for users is a domain specific language that makes it easy to create bindings. >> 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. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 04:52:11
|
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 > > > > 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 > >> 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. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-20 20:07:52
|
Roman Yakovenko wrote: > On 8/20/06, Allen Bierbaum <al...@vr...> wrote: > >> I am hesitant to make any changes like this because I don't want to >> offend you or change something in a way that you don't want. > > > :-) This is not the changes I will not like. If you think, that these > change will improve > user experience please do it. Please write what classes you want to be > imported > directly from module_builder package. I will add them tomorrow. > Part of the reason this discussion has very few details is that this isn't something I can easily make a list of for you. It is much more something that I would need to do "on the fly" while working on a project. If it is okay with you, what I suggest is that I will use the Py++ API over the next couple of days. As I find something annoying or that I think could be better I will either: a) fix it in a way that won't break existing code or b) note it and let you know. I have been thinking that one way I could do this is to make an adapter interface that modifies the existing interfaces at run-time to create a new interface that implements the ideas that I have. The idea would be to make it possible for someone to import a single module (or package which is really the same thing) and then have a DSL for them to use. Things I know I would be looking into: - Importing everything that users may need for most cases - Simplified naming convention (so it doesn't look likes classes or interfaces) - Template support by default - Some helper functions that I have found useful and may be helpful for others. - Adding methods to some existing interfaces to make some things simpler I think I can do this in a way that you can take some things into the core if you want to and leave other things out if you want to. The way I would implement this is something like: ---------- module: user_interface.py ----------------- from module_builder import module_builder, <other stuff> from pygccxml.declarations.type_traits import <things> # customize it ModuleBuilder = module_builder def mb_newmethod(self, arg): pass ModuleBuilder.newMethod = mb_newmethod ------------------------------------------------------------ I think you can get the idea. Basically make an interface that adapts the current stuff. Then this interface can keep adapting and changing while still being based on the same code base. And if you choose to pull things on over to core, then we just change the adapter a little bit. I think this would make it so the efforts don't diverge as much. I just don't have the time or energy to spend wasted effort. I need to focus on getting my work done. :) Thoughts? Now to help this get going, Roman, could you comment on the questions I asked on the template page on the wiki today? https://realityforge.vrsource.org/view/PyppApi/TemplateSupport I still don't understand the method you are suggesting could work. I put some comments in there and asked new questions. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 20:42:30
|
On 8/20/06, Allen Bierbaum <al...@vr...> wrote:
> Part of the reason this discussion has very few details is that this
> isn't something I can easily make a list of for you. It is much more
> something that I would need to do "on the fly" while working on a project.
I could be wrong, but I usually response in a day or two.
> If it is okay with you, what I suggest is that I will use the Py++ API
> over the next couple of days. As I find something annoying or that I
> think could be better I will either: a) fix it in a way that won't
> break existing code or b) note it and let you know.
If you don't mind I prefer "and". May be the functionality you are looking for
already exists, so I will just point you to it. Or better I will write
documentation
for it.
> I have been thinking that one way I could do this is to make an adapter
> interface that modifies the existing interfaces at run-time to create a
> new interface that implements the ideas that I have. The idea would be
> to make it possible for someone to import a single module (or package
> which is really the same thing) and then have a DSL for them to use.
>
> Things I know I would be looking into:
> - Importing everything that users may need for most cases
In this case, you can add the code to the module_builder/__init__.py file
directly without even asking me.
> - Simplified naming convention (so it doesn't look likes classes or
> interfaces)
What do you mean? Can you post some example? Also, you can, and it seems
is what you want, is to introduce the aliases:
class yyy_t:
def yyyyyyyyyyy( ):
...
y = yyyyyyyyyyy
Yyy = yyy_t
I understand, that not every one like my convention. Also I don't see how it
will move us closer to DSL or will significant improve user experience.
> - Template support by default
We are still working on the document.
https://python-ogre.python-hosting.com/file/trunk/python-ogre/ogre_generate_code.py?rev=13
Please take a look on generate_instantiations_string function and its usage.
It is possible to make this code much user friendly.
> - Some helper functions that I have found useful and may be helpful for
> others.
> - Adding methods to some existing interfaces to make some things simpler
I think I know what you mean: functions that creates "def" and similar
code, right?
That what cause use to know very little about boost.python, right?
If so, I have a problem with them: they don't work in all cases. For example
exception translator registration function from pypp_api, will
generate wrong code,
if exception class is template instantiation.
Also, in this specific case, I think user should mark class as
"exception" and add
"translation" code. Py++ should do the rest.
You will also need to write unit tests.
> I think I can do this in a way that you can take some things into the
> core if you want to and leave other things out if you want to.
>
> The way I would implement this is something like:
>
> ---------- module: user_interface.py -----------------
Can you propose another module name?
> from module_builder import module_builder, <other stuff>
> from pygccxml.declarations.type_traits import <things>
>
> # customize it
> ModuleBuilder = module_builder
>
> def mb_newmethod(self, arg):
> pass
>
> ModuleBuilder.newMethod = mb_newmethod
I think about next name: goodies, adapters, convinience_methods
( or something like this )
This module will sit under module_builder package, and will expose
one function - install_[goodies|adapters|...]. It will add all your methods to
module_builder_t and other classes.
For the time being, until I release this version, can you put this code under
"contrib" directory?
This is basically your idea, right? I have nothing against it. It
could be nice, if you
can stick to the "small letters and underscore" convention.
> I think you can get the idea. Basically make an interface that adapts
> the current stuff. Then this interface can keep adapting and changing
> while still being based on the same code base. And if you choose to
> pull things on over to core, then we just change the adapter a little
> bit. I think this would make it so the efforts don't diverge as much.
> I just don't have the time or energy to spend wasted effort.
You are not alone.
> I need to focus on getting my work done. :)
Me too. The source code is ready for release, but documentation still needs
some work.
> Now to help this get going, Roman, could you comment on the questions I
> asked on the template page on the wiki today?
> https://realityforge.vrsource.org/view/PyppApi/TemplateSupport
>
> I still don't understand the method you are suggesting could work. I
> put some comments in there and asked new questions.
See "template support by default". If it still will not be clear, I
will write a document.
And may be skeleton of implementation.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-08-20 13:08:05
|
Allen Bierbaum wrote: > Matthias: Do you think development will continue on this API or do you > only need it for a single project? Currently, I'm only using it for one project. But that doesn't mean that I don't want to continue with pypp_api, it's rather the opposite, as long as I'm using it I'm definitely interested in keeping it up-to-date and even improving it. As the documentation and feature set of the official Py++ API evolves, I'll check from time to time if it would allow me to create the bindings just as easily, but as I'm rather pleased with pypp_api and the Py++ API doesn't have all the features of pypp_api yet it seems that I will stick with pypp_api for another a while. > 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. Is this just going > to get worse if I use pypp_api? I don't think so. So far, whenever there have been API changes in py++ that broke something, they broke something in pypp_api and not in my main driver script. So in those cases we only have to fix pypp_api and all projects using it will continue to work. Roman Yakovenko wrote: >>> 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. The last modification that broke pypp_api was the transfer of the "write_main" parameter from multiple_files_t.write() to the constructor. We already had a few similar changes before. Then, I think it was the call policy objects that have been moved to a different module so that they had to be imported from somewhere else. And so on... Well, these changes are no big deal (especially as py++ still hasn't reached v1.0) and for me, all those modifications were "shielded" by pypp_api and I never had to update my main script so far, so I don't really complain about this... (but as you were asking)... ;) But I think it's also a requirement for a high-level API that it remains relatively stable and protects the user from noticing internal interface modifications. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 13:34:38
|
On 8/20/06, Matthias Baas <ba...@ir...> wrote: > The last modification that broke pypp_api was the transfer of the > "write_main" parameter from multiple_files_t.write() to the constructor. The person who added( me ) this flag to the "write" method completely missed the fact, that method "write" should be implemented as is, without adding additional arguments. Otherwise, it does not implements "file_writer" interface. Everyone who uses Py++ module_builder_t class had nothing to do with this change. > We already had a few similar changes before. > Then, I think it was the call policy objects that have been moved to a > different module so that they had to be imported from somewhere else. That happened, when we just started to work on high level API, so this does not count. Also, in ALL cases, Py++ and pygccxml packages have __init__.py file, that contains\\introduce all references to the functionality provided by package. > Well, these changes are no big deal (especially as py++ still hasn't > reached v1.0) and for me, all those modifications were "shielded" by > pypp_api and I never had to update my main script so far, so I don't > really complain about this... (but as you were asking)... ;) This is good. Users of module_builder_t API are also protected from some kind of changes, exactly as in your case. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-20 13:18:56
|
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 |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 13:58:22
|
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/
|
|
From: Allen B. <al...@vr...> - 2006-08-21 00:27:10
|
Roman Yakovenko wrote: > On 8/20/06, Allen Bierbaum <al...@vr...> wrote: > >> Part of the reason this discussion has very few details is that this >> isn't something I can easily make a list of for you. It is much more >> something that I would need to do "on the fly" while working on a >> project. > > > I could be wrong, but I usually response in a day or two. true, but "on the fly" for me is much more of a "I have to wrap this right now" type thing. I need to solve it instantly or I see an annoyance right then. I just need a place to dump the solution so I can continue working. I think the adapter idea could work well for this. >> If it is okay with you, what I suggest is that I will use the Py++ API >> over the next couple of days. As I find something annoying or that I >> think could be better I will either: a) fix it in a way that won't >> break existing code or b) note it and let you know. > > > If you don't mind I prefer "and". May be the functionality you are > looking for > already exists, so I will just point you to it. Or better I will write > documentation > for it. Agreed. doing a) effectively means that I am noting it since I will be writing code that addresses it. As far as documentation, I would still really like to see the documentation move to more of a group effort on the wiki so the docs are always live and up-to-date for anyone to contribute to. But that is a separate topic for another e-mail... >> I have been thinking that one way I could do this is to make an adapter >> interface that modifies the existing interfaces at run-time to create a >> new interface that implements the ideas that I have. The idea would be >> to make it possible for someone to import a single module (or package >> which is really the same thing) and then have a DSL for them to use. >> >> Things I know I would be looking into: >> - Importing everything that users may need for most cases > > > In this case, you can add the code to the module_builder/__init__.py > file > directly without even asking me. True, but the adapter would give me a way to test it out and let you review the idea. We can see how it goes though. >> - Simplified naming convention (so it doesn't look likes classes or >> interfaces) > > > What do you mean? Can you post some example? Also, you can, and it seems > is what you want, is to introduce the aliases: > > class yyy_t: > def yyyyyyyyyyy( ): > ... > y = yyyyyyyyyyy > > Yyy = yyy_t > > I understand, that not every one like my convention. Also I don't see > how it > will move us closer to DSL or will significant improve user experience. The cases I would do this are where I think it may make it seem more like a DSL. For example scons does this very well by masking the fact that when you call what looks like a method what is actually happening is that a class is being created behind the scene. That said, I don't think I would do this much and once again where I do it the change will not be permanent. Just something for you to review. >> - Template support by default > > > We are still working on the document. > > https://python-ogre.python-hosting.com/file/trunk/python-ogre/ogre_generate_code.py?rev=13 > > > Please take a look on generate_instantiations_string function and its > usage. > It is possible to make this code much user friendly. Yes. This code looks pretty similar in spirit to the TemplateBuilder stuff I did for pyOpenSG. I just want to take it that step further and make it very user friendly so the don't have to know all the ugly details happening behind the scenes to allow this to work. I think it can be done and I will do it. >> - Some helper functions that I have found useful and may be helpful for >> others. >> - Adding methods to some existing interfaces to make some things simpler > > > I think I know what you mean: functions that creates "def" and similar > code, right? No. I was meaning add methods to existing class interfaces or modules that py++ defines. > That what cause use to know very little about boost.python, right? > > If so, I have a problem with them: they don't work in all cases. For > example > exception translator registration function from pypp_api, will > generate wrong code, > if exception class is template instantiation. > > Also, in this specific case, I think user should mark class as > "exception" and add > "translation" code. Py++ should do the rest. > > You will also need to write unit tests. > >> I think I can do this in a way that you can take some things into the >> core if you want to and leave other things out if you want to. >> >> The way I would implement this is something like: >> >> ---------- module: user_interface.py ----------------- > > > Can you propose another module name? adapters, goodies, whatever. It doesn't really matter to much since we can always move the file in svn. > >> from module_builder import module_builder, <other stuff> >> from pygccxml.declarations.type_traits import <things> >> >> # customize it >> ModuleBuilder = module_builder >> >> def mb_newmethod(self, arg): >> pass >> >> ModuleBuilder.newMethod = mb_newmethod > > > I think about next name: goodies, adapters, convinience_methods > ( or something like this ) > This module will sit under module_builder package, and will expose > one function - install_[goodies|adapters|...]. It will add all your > methods to > module_builder_t and other classes. I was thinking of just making it even simplier. Just make it so if you do: from adapter import * Then you get the entire DSL or whatever API it defines. > > For the time being, until I release this version, can you put this > code under > "contrib" directory? Sure. > > This is basically your idea, right? I have nothing against it. It > could be nice, if you > can stick to the "small letters and underscore" convention. Not a problem. > >> I think you can get the idea. Basically make an interface that adapts >> the current stuff. Then this interface can keep adapting and changing >> while still being based on the same code base. And if you choose to >> pull things on over to core, then we just change the adapter a little >> bit. I think this would make it so the efforts don't diverge as much. >> I just don't have the time or energy to spend wasted effort. > > > You are not alone. > >> I need to focus on getting my work done. :) > > > Me too. The source code is ready for release, but documentation still > needs > some work. > >> Now to help this get going, Roman, could you comment on the questions I >> asked on the template page on the wiki today? >> https://realityforge.vrsource.org/view/PyppApi/TemplateSupport >> >> I still don't understand the method you are suggesting could work. I >> put some comments in there and asked new questions. > > > See "template support by default". If it still will not be clear, I > will write a document. > And may be skeleton of implementation. What I need to see is the places that you said "no, you can do this", I need to see what you are saying can be done and how. Because as I see it right now there is always going to be a two phase process where a template header has to be created behind the scenes before the parsing. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-21 05:05:02
|
On 8/21/06, Allen Bierbaum <al...@vr...> wrote: > The cases I would do this are where I think it may make it seem more > like a DSL. For example scons does this very well by masking the fact > that when you call what looks like a method what is actually happening > is that a class is being created behind the scene. You don't have to go to provide an example: str, list, dict, set > That said, I don't think I would do this much and once again where I do > it the change will not be permanent. Just something for you to review. > > >> - Template support by default > > > > > > We are still working on the document. > > > > https://python-ogre.python-hosting.com/file/trunk/python-ogre/ogre_generate_code.py?rev=13 > > > > > > Please take a look on generate_instantiations_string function and its > > usage. > > It is possible to make this code much user friendly. > > Yes. This code looks pretty similar in spirit to the TemplateBuilder > stuff I did for pyOpenSG. I just want to take it that step further and > make it very user friendly so the don't have to know all the ugly > details happening behind the scenes to allow this to work. I think it > can be done and I will do it. :-) Now you are talking! > >> - Some helper functions that I have found useful and may be helpful for > >> others. > >> - Adding methods to some existing interfaces to make some things simpler > > > > > > I think I know what you mean: functions that creates "def" and similar > > code, right? > > No. I was meaning add methods to existing class interfaces or modules > that py++ defines. Would you mind to provide few examples? > > I was thinking of just making it even simplier. Just make it so if you do: > > from adapter import * > > Then you get the entire DSL or whatever API it defines. >>> import this See item 2. But it is your decision. > > What I need to see is the places that you said "no, you can do this", I > need to see what you are saying can be done and how. Because as I see > it right now there is always going to be a two phase process where a > template header has to be created behind the scenes before the parsing. I will write some document -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-20 15:45:36
|
Roman Yakovenko wrote: > 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? Easier to use, easier to approach, more modular. Better meets the goal of a domain specific language. > >> 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! Pyste failed to allow the power needed to do advanced things. Py++ has that power but in the process has thrown out the one good thing that Pyste had going for it. Namely a very simple and easy to use API/domain specific language. > >> > 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. The specifics in this case are not going to help much because there is a bigger question which has to be answered in order to evaluate the specifics. That question is what is Py++ going to provide for a *user* api (note: not the developer API)? Will it be: a) A set of classes and interfaces to write code generators or b) A simple and complete domain specific language that makes the simple things simple and the hard things possible (by using the class interfaces behind the scenes) The reason I am not giving specifics is because they don't matter if what you want is A and what I want is B. To me pypp_api is a better solution for providing b. It has shortcomings but those can be eliminated. >> 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. I am not talking about the time to run the script. I am talking about the time from when the user decided they want to wrap a library to the time that they have a working script. In other words the learning curve and the effort it takes to be successful. > >> * 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. We have gone farther then writing a paper, we have written two APIs. The original pypp_api I wrote and the current one that Matthias is maintaining. > >> * 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. A minimal, inclusive, small API. The user should not have to learn about classes from all over pyplusplus and pygccxml. In other words they should not have to understand the code under the covers, but just the API itself. A prime example of this is boost.python. I don't know anyone but David that understands all the internal details. But users are able to use it because they use the high-level API, the domain specific language if you will, that is documented for exposing code. They don't need to know the details of how it works internally just to use it. > > 2. This will never work. He should know at least what is declarations > and declarations > tree ( pygccxml.declarations package ) But why should he have to look into pygccxml.declarations and scopedef_t and type_traits and matcher and so on. Why can't he just look at the API provided in a single package called for example "pypp_api" or "user" or whatever? Why should we require users to import anything except a single package the brings in a the domain specific language for them to use? Why should have have to use class types at all (for example module_builder_t vs. ModuleBuilder) instead of just making it look like a custom language for exposing APIs. This may really be the core of my difference of opinion. I don't think a user should have to understand the entire pyplusplus and pygccxml system. They should only have to understand a single package to do 90% of the things they want to. And most users should never have to understand anything outside of there. That package should provide an interface that is not the class interface mirroring the internals of pyplusplus but is exposing a language for making wrappers with boost.python. >> * 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 ) ? No, what I mean is that as I said above the user should only have to understand the full details of the pyplusplus and pygccxml packages unless they want to do something advanced. In other words the low-level power is there, but they don't need to know about it unless they want to go do something outside of the normal. > >> * 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++. This is true, but again you are jumping to an advanded use case. It is possible to provide an interface (like pypp_api and Pyste) that lets the user express what they want to do without knowing more then the boost.python tutorial. >> 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. What do you mean? I think you are talking about adding custom code in many places. While this is good, this really just makes advanced use cases easier. > 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. - Anywhere that they have to import or use a symbol that does not come in through the module_builder import. - Anywhere that they have to grab an attribute of anything beyond a decl. >> 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. The best document for it may be the pypp_api interface. It is simple and self contained. It has it's limits so I would need to extend it (for example to support Templates better) but I think the idea is a good one. I want a domain specific language that is as easy as Pyste but allows the power of the internals of pyplusplus. All this said, does anyone else agree with me? -Allen |
|
From: Brian O. <bob...@ya...> - 2006-08-20 16:15:16
|
I wish the make process was easier on the mac. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 18:32:12
|
On 8/20/06, Brian OBrien <bob...@ya...> wrote: > I wish the make process was easier on the mac. Setup environment is one of the biggest problems with Py++. I am aware to it and I hope I will be able to adress it in the next version. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Lakin W. <lak...@gm...> - 2006-08-20 16:56:14
|
On 8/20/06, Allen Bierbaum <al...@vr...> wrote: > > Roman Yakovenko wrote: > > That is what I am asking you for. Py++ solves real problems and > > exports real projects. > > Please be specific. > > The specifics in this case are not going to help much because there is a > bigger question which has to be answered in order to evaluate the > specifics. That question is what is Py++ going to provide for a *user* > api (note: not the developer API)? > > Will it be: > a) A set of classes and interfaces to write code generators > or > b) A simple and complete domain specific language that makes the > simple things simple and the hard things possible (by using the class > interfaces behind the scenes) > > The reason I am not giving specifics is because they don't matter if > what you want is A and what I want is B. To me pypp_api is a better > solution for providing b. It has shortcomings but those can be > eliminated. I don't think that these options are mutually exclusive. You also make it sound like the second option is the only option which can provide simplicity. I disagree. There are plenty of situations where the first option can "make the simple things simple and the hard things possible." So why is it that you think providing a domain specific language is the only way to provide a simple solution to user's problems? As per my previous email, I think specifics here are essential. What is it about the py++ api that makes simple things _not_ simple? Given a concrete set of issues, Roman, you, Matthias and the rest of us can work towards addressing these issues. I think that Roman would agree that he wants to provide a solution which is as simple as possible for simple things, and still makes the hard things possible. In order to do this, he needs to know what is wrong with the current situation. Lakin |
|
From: Matthias B. <ba...@ir...> - 2006-08-20 15:45:52
|
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? While we're at it, could I also ask you to do the same thing in the opposite direction? Which are the areas where you think the Py++ API is better than pypp_api? And what were the reasons to start a new API instead of working on pypp_api (considering that the Py++ API borrowed a lot of concepts from pypp_api)? >> 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. I think that's what Allen meant when he said that he (or rather, we) and you have different goals. > Pyste failed to solve real world problems. The projects that use Pyste do not exist! I don't think these statements are true. In my case, I know another guy who also did Python bindings for Maya and who was/is using Pyste. His project isn't public but it is used internally at the company he's working for. So Pyste was definitely used for a "real world problem". Just because those people might not read the c++-sig mailing list regularly or have no time to respond to messages doesn't mean that Pyste is not used. Of course, I do agree that creating bindings using py++ can be done faster and more "complete" (would I be using it otherwise?). But the reason why Pyste fails in this respect is *not* because its API concept cannot deal with those things, it's rather that its backend is not as powerful as py++. I think its API concept is pretty easy to grasp and more intuitive and easier to use than py++. So the ideal solution for me (and I suppose for Allen as well) is having the API concept from Pyste in combination with py++ as its backend. Basically, this is what pypp_api is trying to accomplish (and so far, I'm quite pleased with it). >> * 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. Oops, as I was the one who added the above point to the wiki, I have to clarify something here as I now notice that the point got misunderstood! I was not referring to the time it takes the *computer* to run the script, I was referring to the time it takes the *user* to write the script in the first place (which not only involves the API itself, but also documentation, warning/error messages, etc.). >> * 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. As pypp_api was created by Allen and me, I guess you can simply have a look at it to see our "suggestions". >> * 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. I consider the functionality from pypp_api (or in your case module_builder_t + related classes) to be the high level API. > 2. This will never work. He should know at least what is declarations > and declarations tree ( pygccxml.declarations package ) He only has to understand the concept, but not the details (how to traverse the tree, the exact types of the nodes, etc.). The high level API already provides an interface to deal with that tree. >> * 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 ) ? No, for example in the case of pypp_api you can obtain the declaration_t objects that belong to a particular query result. In most cases you don't need them because you can use the API provided by pypp_api, but should there be a case where this API is not sufficient, you have the option to "go down" and work directly on the py++ declaration objects. Another example is the code creator tree. Usually a user doesn't need this tree and doesn't even have to know that this tree exists, but should there be a case where a user has to inject his own code creators he can do so by intercepting the code creator tree generation and do his own modifications to it (using the "low level" py++ interface) before pypp_api proceeds with writing the files. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 18:30:40
|
On 8/20/06, Matthias Baas <ba...@ir...> wrote:
> > I did not created another Pyste, Py++ will never be another Pyste.
>
> I think that's what Allen meant when he said that he (or rather, we) and
> you have different goals.
I am one of the biggest user of Py++. I have same goal as you.
> Of course, I do agree that creating bindings using py++ can be done
> faster and more "complete" (would I be using it otherwise?).
> But the reason why Pyste fails in this respect is *not* because its API
> concept cannot deal with those things, it's rather that its backend is
> not as powerful as py++.
I don't agree with you. Pyste always works with single header file.
I am almost sure, that is not possible to extend Pyste API to work on whole
project.
> I think its API concept is pretty easy to grasp
> and more intuitive and easier to use than py++. So the ideal solution
> for me (and I suppose for Allen as well) is having the API concept from
> Pyste in combination with py++ as its backend. Basically, this is what
> pypp_api is trying to accomplish (and so far, I'm quite pleased with it).
Your situation is not different from my. I am not pleased with pypp_api,
but I do pleased with Py++. But still I am willing to work on this.
>
> As pypp_api was created by Allen and me, I guess you can simply have a
> look at it to see our "suggestions".
May be I missed something, but Py++ contains all non problematic functionality
found in pypp_api.
> I consider the functionality from pypp_api (or in your case
> module_builder_t + related classes) to be the high level API.
related classes are: decl_wrappers + pygccxml.declarations, right?
> > 2. This will never work. He should know at least what is declarations
> > and declarations tree ( pygccxml.declarations package )
>
> He only has to understand the concept, but not the details (how to
> traverse the tree, the exact types of the nodes, etc.). The high level
> API already provides an interface to deal with that tree.
May be I miss something, but ( I am not arguing here but ask you to point me
to the mistakes )
1. Where I force him to know how to traverse the tree?
2. Why do you think that user should not understand on what declaration set
he is working on?
> >> * 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 ) ?
>
> No, for example in the case of pypp_api you can obtain the declaration_t
> objects that belong to a particular query result. In most cases you
> don't need them because you can use the API provided by pypp_api, but
> should there be a case where this API is not sufficient, you have the
> option to "go down" and work directly on the py++ declaration objects.
Can you point me to the user code, I want to be sure I understand you right.
> Another example is the code creator tree. Usually a user doesn't need
> this tree and doesn't even have to know that this tree exists, but
> should there be a case where a user has to inject his own code creators
> he can do so by intercepting the code creator tree generation and do his
> own modifications to it (using the "low level" py++ interface) before
> pypp_api proceeds with writing the files.
It is not completely true. User should understand, that after some
point he can not
work on declarations. pyplusplus.module_builder_t class explicitly defines this
point.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Lakin W. <lak...@gm...> - 2006-08-20 16:30:09
|
On 8/20/06, Matthias Baas <ba...@ir...> wrote: > > > >> * 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. > > As pypp_api was created by Allen and me, I guess you can simply have a > look at it to see our "suggestions". I've had a look at the pypp wiki a few times now, although I have not read through it in great detail. From looking at the wiki, I still don't understand what it is that pypp does. If you want to convince me that pypp is an easier better api to use, then you're going to have to create some concrete examples of how this new API saves me time. Put it in the wiki and link to it. I've been following this conversation and I still have no idea what it is that you guys dislike so much about the py++ high level API. I know that you think it's not efficient. I know that you think pypp does a better job. but I've not yet seen any concrete examples to back it up. In my opinion this issue is fundamental to this conversation. Without this sort of document, it's going to be hard to convince users to switch from one to the other. So users will stick with whichever they've started to use first. Without this document, Roman can't understand what it is that is difficult about the py++api. my 2c. Lakin |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 18:09:24
|
On 8/20/06, Allen Bierbaum <al...@vr...> wrote: > The specifics in this case are not going to help much because there is a > bigger question which has to be answered in order to evaluate the > specifics. That question is what is Py++ going to provide for a *user* > api (note: not the developer API)? > > Will it be: > a) A set of classes and interfaces to write code generators > or > b) A simple and complete domain specific language that makes the > simple things simple and the hard things possible (by using the class > interfaces behind the scenes) Both. I hope, that at the end of this discussion you will be able to define DSL to show where Py++ user interface could be improved. > I am not talking about the time to run the script. I am talking about > the time from when the user decided they want to wrap a library to the > time that they have a working script. In other words the learning curve > and the effort it takes to be successful. In my opinion it takes only few hours. For this release I worked a lot on documentation. A lot of topics have been covered. > > > >> * 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. > > We have gone farther then writing a paper, we have written two APIs. Here is a mistake. It is not the same, it may be give you an understanding of what and how things should be done, but it did not promote the project as a whole. Matthias wrote a paper, now we have better understanding about the problem we deal with. We can discuss different API and different solution. I am sure we will come to one solution and we will implement it only once. > The original pypp_api I wrote and the current one that Matthias is > maintaining. The API contains few problems and mixes few concepts. I can write it's full review, but I hate to do this. > > 1. Please define high level API. I don't know what you mean. > > A minimal, inclusive, small API. The user should not have to learn > about classes from all over pyplusplus and pygccxml. In other words > they should not have to understand the code under the covers, but just > the API itself. Still, I am missing the use cases. Py++ exports "hello world" cases using just GUI. > A prime example of this is boost.python. I don't know anyone but David > that understands all the internal details. But users are able to use it > because they use the high-level API, the domain specific language if you > will, that is documented for exposing code. They don't need to know the > details of how it works internally just to use it. As much as I like Boost.Python, I must tell you that this is not true. Consider: * compilation errors few kB long * almost anything, that is not covered in tutorials is not as trivial as you expect > Why can't he just look at the > API provided in a single package called for example "pypp_api" or "user" > or whatever? Why should we require users to import anything except a > single package the brings in a the domain specific language for them to > use? Why should have have to use class types at all (for example > module_builder_t vs. ModuleBuilder) instead of just making it look like > a custom language for exposing APIs. Because it makes a lot of sense for me. I did not see any non trivial package, that from one module imports functionality of all other packages. But I am open for suggestion. Also this specific problem very easy to solve. I don't remember, I said no when you asked me to add shortcut to something. > This may really be the core of my difference of opinion. I don't think > a user should have to understand the entire pyplusplus and pygccxml > system. This is the case today. He should understand only pygccxml.declarations package, pyplusplus.module_builder and pyplusplus.decl_wrappers package. Now, where do I make a mistake? > And most users should never have to > understand anything outside of there. As I said "hello world" example could be done using GUI and GUI generated ( Py++ ) code. > That package should provide an > interface that is not the class interface mirroring the internals of > pyplusplus but is exposing a language for making wrappers with boost.python. I need your constructive comments and not just critic. > No, what I mean is that as I said above the user should only have to > understand the full details of the pyplusplus and pygccxml packages > unless they want to do something advanced. In other words the low-level > power is there, but they don't need to know about it unless they want to > go do something outside of the normal. Please, use cases. > This is true, but again you are jumping to an advanded use case. It is > possible to provide an interface (like pypp_api and Pyste) that lets the > user express what they want to do without knowing more then the > boost.python tutorial. Please, use cases. > What do you mean? I think you are talking about adding custom code in > many places. While this is good, this really just makes advanced use > cases easier. No. I am talking about this: http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/documentation/inserting_code.rest?view=markup > > What are they. Please describe them. > > - Anywhere that they have to import or use a symbol that does not come > in through the module_builder import. Very easy to fix. You have commit permissions, why you just don't fix this? > - Anywhere that they have to grab an attribute of anything beyond a decl. Please, be more specific here. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-20 19:43:21
|
>> > What are they. Please describe them. >> >> - Anywhere that they have to import or use a symbol that does not come >> in through the module_builder import. > > > Very easy to fix. You have commit permissions, why you just don't fix > this? I am hesitant to make any changes like this because I don't want to offend you or change something in a way that you don't want. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-20 19:51:58
|
On 8/20/06, Allen Bierbaum <al...@vr...> wrote: > I am hesitant to make any changes like this because I don't want to > offend you or change something in a way that you don't want. :-) This is not the changes I will not like. If you think, that these change will improve user experience please do it. Please write what classes you want to be imported directly from module_builder package. I will add them tomorrow. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-08-22 15:04:26
|
Lakin Wecker wrote: > I've had a look at the pypp wiki a few times now, although I have not > read through it in great detail. From looking at the wiki, I still > don't understand what it is that pypp does. > > If you want to convince me that pypp is an easier better api to use, > then you're going to have to create some concrete examples of how this > new API saves me time. Just to clarify, compared to the Py++ high-level API pypp_api is not a *new* API. pypp_api was created by Allen and me because we were not satisfied with the way py++ had to be used at that time (there hasn't been any high-level API at all). Obviously the general concepts from our experimental prototype did convince Roman and so he implemented his own version of a high-level API which is based on the ideas from pypp_api but which does some things differently. To me it was just another "prototype" to try out alternative ways. But as it is integrated into the pyplusplus code base it has become the official API. Anyway, this explains why there are a lot of similarities between the two APIs. Meanwhile I'm the only one who is using pypp_api and who's keeping it alive. But instead of sticking it into the repository for my own project I decided to put it into the pyplusplus contrib directory so that 1) others who are interested have the chance to try it out as well and 2) I don't have to duplicate code when I want to use the API for another project. As for documentation/examples, now that we have a wiki I did write a short quick start tutorial and I've just started some user guide documentation. So if anyone is interested in giving pypp_api a try then keep an eye on the following pages: https://realityforge.vrsource.org/view/PyppApi/PyppTutorial https://realityforge.vrsource.org/view/PyppApi/PyppUserGuide and run the script contrib/pypp_api/generate_docs.py to create an epydoc reference manual. If you want a full example you could have a look at pypp_setup.py in here: http://svn.sourceforge.net/viewvc/cgkit/maya/trunk/maya_wrapper/ This is how I create Python bindings for the Maya SDK (Maya is a commercial 3D application from Autodesk (formerly from Alias)). But on the other hand, if you're entirely happy with the current Py++ API and you already have the bindings you wanted to have, then there's absolutely no reason to waste your time with pypp_api. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-08-22 17:38:11
|
On 8/22/06, Matthias Baas <ba...@ir...> wrote: > > Just to clarify, compared to the Py++ high-level API pypp_api is not a > *new* API. pypp_api was created by Allen and me because we were not > satisfied with the way py++ had to be used at that time (there hasn't > been any high-level API at all). Obviously the general concepts from our > experimental prototype did convince Roman and so he implemented his own > version of a high-level API which is based on the ideas from pypp_api > but which does some things differently. To me it was just another > "prototype" to try out alternative ways. But as it is integrated into > the pyplusplus code base it has become the official API. > Anyway, this explains why there are a lot of similarities between the > two APIs. Matthias is right. The pypp_api is not new. The main problem is that it takes time to learn to work in "open source" team. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X