[C++-sig] pyplusplus tutorials & GUI wizard

[Matthias Baas]

Roman Yakovenko wrote:
> On 1/24/06, Matthias Baas <baas at ira.uka.de> wrote:
>> It's good to see a more or less introductory tutorial as I couldn't
>> extract enough information from the previous pages to get started with
>> pyplusplus.
> 
> What information is missing?

Well, for example, the information from the new tutorial was missing. 
Before the tutorial it was not obvious to me how the tool actually works 
and what steps are required from the user.

>> so why
>> does this have to be provided by the user and why isn't it put under the
>> hood of pyplusplus instead?
> 
> What do you mean. If you mean parsing\reading C++ then the answer is simple:
> pyplusplus does not care from where you read declarations. And I thing
> that keeping this separation is important.

That's not really what I meant. I have absolutely no objections of your 
design to keep parsing the sources and creating the output separate 
processes. I second that design and I don't argue that you should change 
that. But why not adding some additional layer above this design that 
hides this implementation detail if not otherwise specified. I think 
most if not all users will use pygccxml to parse the sources (what other 
choice do they have?), so why not make that the default procedure?

Step 1 of the tutorial consists of 12 lines of code where there are only 
two things that I really had to specify: the name of the input header 
file and a filtering rule (whereas gccxml is on my path, so I didn't 
need to specify that in the driver file. And as long as pyplusplus 
cleans up its temporary files, I don't really care where it puts them 
(don't get me wrong, it's absolutely ok to be able to change these 
things but I shouldn't be forced to set them)). Now to pass these two 
pieces of data to pyplusplus I had to import several modules, create a 
class and call some functions. Maybe I'm wrong, but these things looked 
as if they were not from a public interface but actually from the 
internals of the program. Exposing that much stuff from inside the 
program has the disadvantage that my driver file becomes dependent on 
them. Should you ever choose to change some of these things for whatever 
reasons, these changes will break all driver scripts out there which 
would be a very bad thing. Such dependencies could be reduced if the 
public interface would be kept more slim and rather be of a descriptive 
nature as it is the case with Pyste (another example would be SCons, 
www.scons.org). Access to the internal API could also be provided but it 
should only be necessary for special cases.

>> Personally I'd prefer the "signal-to-noise
>> ratio" in the config/driver file to be as high as possible, i.e. the
>> file should only contain information that really must be provided by the
>> user and that pyplusplus cannot know itself. In the tutorial this would
>> be the input file name and maybe the output module name (which could
>> even be deduced from the input file name by default). I would say Pyste
>> performs much better in this respect as its "hello world" example only
>> requires a single line.
> 
> Here I don't agree with you. The complexity on start with pyplusplus is higher,
> you are right. But the point is that this complexity will grow only a
> little with pyplusplus.

Granted, but in my experience there have been cases where I really could 
get away with short *.pyste files and there was no need to do complex 
stuff. Currently, this would be prohibited with pyplusplus as there is 
only a relatively complex way to describe the wrappers.
Actually, you wouldn't have to change anything in your package but only 
add an additional layer on top of what is currently there so that for 
easy cases, the descriptions of the wrappers can be as concise as those 
from Pyste.

>> So at the end, this round went to Pyste, but I'm eagerly awaiting the
>> next rounds... :)
> 
> I don't think so, but I am not objective.

Of course, the above was from my point of view. :) The current state of 
the documentation and the tool just couldn't convince me yet to switch 
from Pyste to pyplusplus, which was for the previously mentioned reasons 
(well, maybe the main reason was that I couldn't get it to work with 
that SDK I'm currently wrapping). But as I said, it kept me enough 
interested to provide some feedback (hoping that this will contribute to 
the improvement of pyplusplus) and to try future versions again.
Your work is still appreciated, my criticism is not meant to bash the 
tool but rather to be an incentive to improve it.

- Matthias -