pygccxml-development Mailing List for C++ Python language bindings (Page 69)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Matthias, it seems that you are watching too match TV :-). You don't
have to keep me/us under presure.

Please commit your changes, as they are. I want to contribute too :-)

Thanks

On 3/14/06, Allen Bierbaum <al...@vr...> wrote:
>
> >Good. It was important to me to get your agreement. Now I also can work
> >on high level API.
> >
> >Allen if you don't have some strong arguments against s/m select interfa=
ces
> >I am going to implement that interfaces.
> >
> >
> I like the s/m select interfaces.

Good. One step to having better interface

> -Allen

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

Matthias Baas wrote:

> Hi,
>
> I implemented some stuff today that mainly deals with the selection of 
> declarations (all additions are beneath the experimental directory, 
> but I didn't commit anything yet). It's not finished but I just wanted 
> to keep you informed about what I'm currently doing.

Great.  I was feeling guilty that I got tied up with work this weekend 
and hadn't been able to get to this.  I am glad someone is making 
progress. :)

>
> What I did:
>
> - I implemented an alternative version of the 
> DeclWrapper/MultiDeclWrapper classes
>
> - To prevent chaos I didn't actually change anything in pypp_api but 
> implemented the new DeclWrapper in a separate module and replaced the 
> DeclWrapper in pypp_api at runtime
>
If you go ahead and check this in I don't think there will be chaos.  I 
think in fact that it would help us to better understand what we need to do.

On question I have related to this implementation though:

 From our discussion the other day I think it sounds like we don't need 
a DeclWrapper/MultiDeclWrapper class but instead should maybe be 
modifying/extending/renaming/etc the decl_wrapper that are being created 
by the pyplusplus code creator now.

I think this may be the direction to move because:

- It seems like this is what Roman wants
- The interface for everything but the query methods in *DeclWrapper 
will just call straight through to the pyplusplus _wrappers
- Using the pyplusplus wrappers could give us better type safety in the 
form of errors when the user calls something that doesn't make sense for 
the currently wrapped decl type.

Doing this would move a great deal of the high-level API into the 
pyplusplus decl_wrappers but it just seems like a good move right now.

Thoughts?

> - I only dealt with the selection so far, so the decoration still 
> works as before. The heart of the selection is a single function 
> select() that takes as input the root of the pygccml declaration tree 
> and a single filter "function" and returns a list of declarations that 
> matched the filter. Conceptually, the search is always done 
> recursively. The filter function is actually a special object which 
> itself can be a tree of filter functions (think of it as the tree 
> representation of a boolean expression). The nodes of the tree are the 
> functions AND, OR, NOT and the leaves are the actual filters similar 
> to what I had before or to Roman's matcher objects. Filters can be 
> concatenated using the regular &, | and ~ operators. This select() 
> function is supposed to be the most generic selection function that 
> all specialized selection functions can be based on.

Sounds very interesting.  I can't wait to see it. :)

>
> - Based on the above select() function there are the query methods 
> (still using the naming convention from pypp_api):
>
>   * Class / Classes
>   * Method / Methods
>   * Function / Functions
>   * ...etc...
>
> The first version will always reference exactly 1 declaration whereas 
> the second version may reference an arbitrary number of declarations 
> (if desired the user can still add an assert_count argument).
> There is a global option that controls whether queries producing no 
> results should be considered an error or not (for both cases). By 
> default, empty queries are considered an error.
> What I still have to do is make the above queries only work on the 
> direct children of the parent node by default. I think this can again 
> be done by a global option as default value which can be overridden by 
> a local recursive argument.

Sounds good.  Once this is all in there I think we can really start 
pushing the API and finding areas that we want to extend further.

>
> There's no special treatment of overloaded methods yet. This is still 
> an unresolved issue.
>
> I hope that this version meets most (if not all) of the requirements 
> we had so far. By default, the queries are local and the "1-result" 
> version guarantees that you will get exactly one declaration. This is 
> what a new user will see first. Then, when he feels bold enough he can 
> use the "n-result" queries and can opt to enable global searches. If 
> desired he can also turn off the checks for empty results.
> In any case, the decoration interface is the same, so when the 
> beginner gets advanced he doesn't have to learn a new interface.
>
Sounds great.  Thanks for working so hard on this.

-Allen

>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

>Good. It was important to me to get your agreement. Now I also can work
>on high level API.
>
>Allen if you don't have some strong arguments against s/m select interfaces
>I am going to implement that interfaces.
>  
>
I like the s/m select interfaces.

-Allen

>  
>
>>The only problematic case is the presence of overloaded methods. Maybe I
>>like the above exception best (i.e. to treat them as one single
>>declaration).
>>    
>>
>
>After we will have some initial version we can try to implement
>different solution.
>
>  
>
>>- Matthias -
>>
>>    
>>
>
>Thanks for comments.
>
>--
>Roman Yakovenko
>C++ Python language binding
>http://www.language-binding.net/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
>_______________________________________________
>pygccxml-development mailing list
>pyg...@li...
>https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>
>  
>

On 3/13/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I implemented some stuff today that mainly deals with the selection of
> declarations (all additions are beneath the experimental directory, but
> I didn't commit anything yet). It's not finished but I just wanted to
> keep you informed about what I'm currently doing.

I am a little bit surprised. I struggle with my self for 3 or more
weeks not to write
high level api. But this is okay. I have something like 10 hours in a
week to work on
py++. It would be nice to know how many hours do you have to work on
it, so we could
plan features. Also until end of this week I should have Internet
connection at home.
It will be easier to discuss our efforts.

Can you commit your changes? I would like to analyze your code, as I
did with Allen one. I am sure I can find some piece of code that
should be placed in an other place :-).

> What I did:
>
> - I implemented an alternative version of the
> DeclWrapper/MultiDeclWrapper classes
>
> - To prevent chaos I didn't actually change anything in pypp_api but
> implemented the new DeclWrapper in a separate module and replaced the
> DeclWrapper in pypp_api at runtime

I hope you read my post about adding some teaching/guiding functionality to
decl_wrappers. Did you created DeclWrapper base on my work or you wrote
something new? Also what is wrong with mdecl_wrapper_t class?

> - I only dealt with the selection so far, so the decoration still works
> as before. The heart of the selection is a single function select() that
> takes as input the root of the pygccml declaration tree and a single
> filter "function" and returns a list of declarations that matched the
> filter. Conceptually, the search is always done recursively.

What is wrong with pygccxml.declarations.matcher? Even if you say that
search is always done recursively you still can use it. Am I wrong?

>The filter
> function is actually a special object which itself can be a tree of
> filter functions (think of it as the tree representation of a boolean
> expression). The nodes of the tree are the functions AND, OR, NOT and
> the leaves are the actual filters similar to what I had before or to
> Roman's matcher objects. Filters can be concatenated using the regular
> &, | and ~ operators. This select() function is supposed to be the most
> generic selection function that all specialized selection functions can
> be based on.

First of all I like you idea about using and\or\not for
matchers\select function.
Why did not you modify matchers? This is exactly how things should work.
I thought that the user will use lambda. But this is a great idea,
lets port that piece of
code to pygccxml.declaration.matchers object. I think I have an idea
how to do it
in single place. If you want we can discuss this in separate thread.

> - Based on the above select() function there are the query methods
> (still using the naming convention from pypp_api):
>
>    * Class / Classes
>    * Method / Methods
>    * Function / Functions
>    * ...etc...

Good.

> The first version will always reference exactly 1 declaration whereas
> the second version may reference an arbitrary number of declarations (if
> desired the user can still add an assert_count argument).

Good.

> There is a global option that controls whether queries producing no
> results should be considered an error or not (for both cases). By
> default, empty queries are considered an error.

Global variables? -brrr :-). Can I propose solution for this? Can you
add all those
global variables as class members? No global variables + all instances will
behave the same.

> What I still have to do is make the above queries only work on the
> direct children of the parent node by default. I think this can again be
> done by a global option as default value which can be overridden by a
> local recursive argument.

If you would use my decl_wrapper class hierarchy you could put those
select functions on scope/namespace/class wrappers.

> There's no special treatment of overloaded methods yet. This is still an
> unresolved issue.

This is okay, We need something to comment/try.

> I hope that this version meets most (if not all) of the requirements we
> had so far. By default, the queries are local and the "1-result" version
> guarantees that you will get exactly one declaration. This is what a new
> user will see first. Then, when he feels bold enough he can use the
> "n-result" queries and can opt to enable global searches. If desired he
> can also turn off the checks for empty results.
> In any case, the decoration interface is the same, so when the beginner
> gets advanced he doesn't have to learn a new interface.
>
> - Matthias -
>

Please commit your changes. Do not forget license. People should know
who is guilty :-).
I will try it with boost.date_time library.

Thanks

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

Hi,

I implemented some stuff today that mainly deals with the selection of 
declarations (all additions are beneath the experimental directory, but 
I didn't commit anything yet). It's not finished but I just wanted to 
keep you informed about what I'm currently doing.

What I did:

- I implemented an alternative version of the 
DeclWrapper/MultiDeclWrapper classes

- To prevent chaos I didn't actually change anything in pypp_api but 
implemented the new DeclWrapper in a separate module and replaced the 
DeclWrapper in pypp_api at runtime

- I only dealt with the selection so far, so the decoration still works 
as before. The heart of the selection is a single function select() that 
takes as input the root of the pygccml declaration tree and a single 
filter "function" and returns a list of declarations that matched the 
filter. Conceptually, the search is always done recursively. The filter 
function is actually a special object which itself can be a tree of 
filter functions (think of it as the tree representation of a boolean 
expression). The nodes of the tree are the functions AND, OR, NOT and 
the leaves are the actual filters similar to what I had before or to 
Roman's matcher objects. Filters can be concatenated using the regular 
&, | and ~ operators. This select() function is supposed to be the most 
generic selection function that all specialized selection functions can 
be based on.

- Based on the above select() function there are the query methods 
(still using the naming convention from pypp_api):

   * Class / Classes
   * Method / Methods
   * Function / Functions
   * ...etc...

The first version will always reference exactly 1 declaration whereas 
the second version may reference an arbitrary number of declarations (if 
desired the user can still add an assert_count argument).
There is a global option that controls whether queries producing no 
results should be considered an error or not (for both cases). By 
default, empty queries are considered an error.
What I still have to do is make the above queries only work on the 
direct children of the parent node by default. I think this can again be 
done by a global option as default value which can be overridden by a 
local recursive argument.

There's no special treatment of overloaded methods yet. This is still an 
unresolved issue.

I hope that this version meets most (if not all) of the requirements we 
had so far. By default, the queries are local and the "1-result" version 
guarantees that you will get exactly one declaration. This is what a new 
user will see first. Then, when he feels bold enough he can use the 
"n-result" queries and can opt to enable global searches. If desired he 
can also turn off the checks for empty results.
In any case, the decoration interface is the same, so when the beginner 
gets advanced he doesn't have to learn a new interface.

- Matthias -

On 3/13/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 1) In [1] function name is member_function, while in [2] it is member_f=
unctions.
> > I think that "s" is essential. First time when an user starts to use th=
is API
> > it could be confusing. I think he will expect one m.f. but will get som=
e other
> > class instance.
>
> I agree that distinguishing between a "1-result" and a "n-result" query
> has its merits. It's a much shorter form of the assert_count argument
> which enables the query function to perform a check on the number of
> declarations found.

Good.

> > 3) Lets see some ( =3D=3D my :-) ) patterns that an user has, while exp=
orting C++
> > library:
> > [...]
> >         If I will use [1] approach, I always will be forced to add a
> > "num_expected" argument.
>
> Why are you "forced" to do so? In my practical experience with my API
> this has not been the case and I was using the explicit assertion only
> in one single place.

May be because I want to track changes. Or may be, I want to be sure that
this is special case and it was applied only on single declaration.

> When you do queries for anything else than methods, then the cases where
> the user could be confused are rather rare. Suppose the user queries one
> particular class in some namespace:
>
> ns.Class("Foo")
>
> I believe your concerns so far have been that this might confuse a user
> when the result actually references more than one class. But when can
> that happen at all? C++ doesn't allow several classes with the same name
> in one namespace, so the undesired extra class must come from a
> namespace that lies within the ns namespace.
> In my case, I knew already in advance that all Maya classes are located
> in the standard namespace and there are no children namespaces that
> carry classes with the same name, so a line like the above could *never*
> reference more than 1 class and that's why I didn't need to add the
> assert_count argument to my queries.

So you do know the library you wrap :-). Also, while reading this code user
should remember that "recursive" flag value. In single select he does not n=
eed -
module builder will do the job.

> Don't get me wrong, I'm not arguing against the single/multiple
> interface. In fact, in a case like the above I agree that it is even
> superior because pyplusplus has more information about what the user
> actually intends (and it gets this information with very little effort
> from the user).

:-) We are talking about high level API, so I do want to argue a little :-)=
.
Also it was my filling, that you do not want to provide single API, because
you can achieve same effect using multi select version.

> I just wanted to point out that in most cases my version of the API is
> not as confusing as you make it sound sometimes. ;-)

Sorry, I tried to build a disscussion based on facts only, but it is
too difficult :-).

> However, it does make a difference when selecting methods (more on that
> below).

> > 5) How can an user rename all overloaded functions?
> >    mfs =3D module_builder.member_functions( .... )
> >    mfs.rename( "......" )
> >    In both solutions it simple
>
> Now that's the area where my concerns have actually been.
> In the above example the user *must* know in advance that he's dealing
> with a set of overloaded methods, and I think it could happen that he
> isn't really aware of the fact that a method has overloads.
>
> What if we treat a set of overloaded methods like one single method? I
> might argue that conceptually they already are one single method and
> it's only a syntax peculiarity of C++ that they have to be defined as
> separate methods (whereas on the Python side they will be combined to
> one single method again).

There are few possible solutions to the problem, but I prefer to solve
them next week,
after we will have some high level api that actually work.

> > 6) An other problem that I see in [1] approach. We want multi_decl_wrap=
per_t
> > to behave, as it is an instance of some declaration decorator/wrapper. =
We can
> > implement such behaviour only for "set" properties and functions that u=
ser
> > does not care about their return values. "get" properties could not be
> > implemented at all.
>
> I was always using the result of a query for decorating the
> declarations, so there was no case where I had to read attributes.
> But this could still be handled as follows: If all declarations return
> the same value for a particular attribute then this value is returned,
> otherwise None is returned or an exception is thrown.

Well, now we don't have to define the behaviour :-)

> Basically, I'm in favor of the single/multiple result distinction
> because it provides additional information to pyplusplus which can be
> used for checks.

Good. It was important to me to get your agreement. Now I also can work
on high level API.

Allen if you don't have some strong arguments against s/m select interfaces
I am going to implement that interfaces.

> The only problematic case is the presence of overloaded methods. Maybe I
> like the above exception best (i.e. to treat them as one single
> declaration).

After we will have some initial version we can try to implement
different solution.

> - Matthias -
>

Thanks for comments.

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

Roman Yakovenko wrote:
> 1) In [1] function name is member_function, while in [2] it is member_functions.
> I think that "s" is essential. First time when an user starts to use this API
> it could be confusing. I think he will expect one m.f. but will get some other
> class instance.

I agree that distinguishing between a "1-result" and a "n-result" query 
has its merits. It's a much shorter form of the assert_count argument 
which enables the query function to perform a check on the number of 
declarations found.

> 2) Return type of functions depends on num_expected argument. This one
> could also confuse.

I think this is only a weak point. In my opinion, the exact type of the 
result is an implementation detail that should be of no interest to the 
user. The only important thing is what *interface* the resulting 
object(s) provide. And here, I'm in favor of keeping the interface 
identical (at least as far as decoration is concerned) no matter if the 
result references one single object or several objects.

> 3) Lets see some ( == my :-) ) patterns that an user has, while exporting C++
> library:
> [...]
>         If I will use [1] approach, I always will be forced to add a
> "num_expected" argument.

Why are you "forced" to do so? In my practical experience with my API 
this has not been the case and I was using the explicit assertion only 
in one single place.
When you do queries for anything else than methods, then the cases where 
the user could be confused are rather rare. Suppose the user queries one 
particular class in some namespace:

ns.Class("Foo")

I believe your concerns so far have been that this might confuse a user 
when the result actually references more than one class. But when can 
that happen at all? C++ doesn't allow several classes with the same name 
in one namespace, so the undesired extra class must come from a 
namespace that lies within the ns namespace.
In my case, I knew already in advance that all Maya classes are located 
in the standard namespace and there are no children namespaces that 
carry classes with the same name, so a line like the above could *never* 
reference more than 1 class and that's why I didn't need to add the 
assert_count argument to my queries.

Don't get me wrong, I'm not arguing against the single/multiple 
interface. In fact, in a case like the above I agree that it is even 
superior because pyplusplus has more information about what the user 
actually intends (and it gets this information with very little effort 
from the user).
I just wanted to point out that in most cases my version of the API is 
not as confusing as you make it sound sometimes. ;-)
However, it does make a difference when selecting methods (more on that 
below).

> 4) Small plus that I see for [1] approach is number of API user should
> see/learn.
> But I don't think that this is makes big difference.

Agreed. This is only a minor (or even irrelevant) point.

> 5) How can an user rename all overloaded functions?
>    mfs = module_builder.member_functions( .... )
>    mfs.rename( "......" )
>    In both solutions it simple

Now that's the area where my concerns have actually been.
In the above example the user *must* know in advance that he's dealing 
with a set of overloaded methods, and I think it could happen that he 
isn't really aware of the fact that a method has overloads.

What if we treat a set of overloaded methods like one single method? I 
might argue that conceptually they already are one single method and 
it's only a syntax peculiarity of C++ that they have to be defined as 
separate methods (whereas on the Python side they will be combined to 
one single method again).

> 6) An other problem that I see in [1] approach. We want multi_decl_wrapper_t
> to behave, as it is an instance of some declaration decorator/wrapper. We can
> implement such behaviour only for "set" properties and functions that user
> does not care about their return values. "get" properties could not be
> implemented at all.

I was always using the result of a query for decorating the 
declarations, so there was no case where I had to read attributes.
But this could still be handled as follows: If all declarations return 
the same value for a particular attribute then this value is returned, 
otherwise None is returned or an exception is thrown.

Basically, I'm in favor of the single/multiple result distinction 
because it provides additional information to pyplusplus which can be 
used for checks.
The only problematic case is the presence of overloaded methods. Maybe I 
like the above exception best (i.e. to treat them as one single 
declaration).

- Matthias -

Hi. I did not had much time this weekend to work( write ) some
conclusions from our
conversation :-). I reviewed documentation you wrote - perfect. I like
the work you did.
Thanks.

Also, after my conversation with Matthias I think, that I fully
understand the issue.
The main question is: does class module_builder_t ( mb ) should have 2
different sets of
select functions:

    the first one for selecting single instance of declaration
    the second one for selection multiple instances of declarations

or
    should it have only second one ( multi-select )?

Here is discussion that I hope will guide us to the right answer.

    First of all, I think that this is obvious, that an user can use only s=
econd
approach to select 1 instance of declaration and to work on it. The
main Matthias
point, please correct me if I wrong, is that the user does not have to know=
 on
how many instances he works.

Here is some possible implementation of Matthias API:

[1]
class module_builder_t:
    def member_function( self, ..., num_expected=3DNone ):
        mfs =3D some magic code that according to criteria will return list=
 of
              all member functions.

        if None is num_expected:
            return multi_decl_wrapper_t( mfs )

        if num_expected !=3D len( mfs ):
            raise RuntimeError( "unexpected number of mem functions,
that match criteria: ...." )

        if num_expected =3D=3D 1:
            return mfs[0] #In this case we also can return
multi_decl_wrapper_t( mfs )
                          #that will behave as an instance of the class
                          #but this is also tricky and dirty to implement i=
t.

        return multi_decl_wrapper_t( mfs )

Here is some possible implementation of s/m select interface:

[2]
class module_builder_t:
    def member_function( self, ... ):
        mf =3D some magic code that according to criteria will return
single instance
              of matched member function or exception will be raised
        return mf

    def member_functions( self, ..., num_expected=3DNone ):
        mfs =3D some magic code that according to criteria will return list=
 of
              all member functions.

        if None is num_expected or num_expected =3D=3D len( mfs ):
            return multi_decl_wrapper_t( mfs )
        else:
            raise RuntimeError("unexpected number of mem functions,
that match criteria: ...." )

Now I am going to compare 2 approaches from an user point of view.

1) In [1] function name is member_function, while in [2] it is member_funct=
ions.
I think that "s" is essential. First time when an user starts to use this A=
PI
it could be confusing. I think he will expect one m.f. but will get some ot=
her
class instance.

2) Return type of functions depends on num_expected argument. This one
could also
confuse.

3) Lets see some ( =3D=3D my :-) ) patterns that an user has, while exporti=
ng C++
library:
    3.1 There are a lot of cases, where I need to work on whole library and=
 I
        don't care on how many instances I work. For example: exclude
all functions
        that takes as second argument pointer to X. In this case I want to =
use
        multi decl select

        mfs =3D module_builder.member_functions( .... )
        mfs.exclude()

    3.1 There are also a lot of special cases. May be in future we will hav=
e
        less of them, but right now they do exists. So single select is ver=
y
        useful here:

        mf =3D module_builder.member_function( .... )
        mf.arguments[3].default_value=3D"std::string()"

        If I will use [1] approach, I always will be forced to add a
"num_expected"
        argument.
The main point in this example is that I do want to know the number of
instances: 1 or many. I think that setting explicit number of expected
instances is annoying. I am not against "num_expected" argument, I
think that Matthias has some use case, where he needs this. ( By the
way I'd like to see it :-) ). So we actually can add it.

4) Small plus that I see for [1] approach is number of API user should
see/learn.
But I don't think that this is makes big difference.

5) How can an user rename all overloaded functions?
   mfs =3D module_builder.member_functions( .... )
   mfs.rename( "......" )
   In both solutions it simple

6) An other problem that I see in [1] approach. We want multi_decl_wrapper_=
t
to behave, as it is an instance of some declaration decorator/wrapper. We c=
an
implement such behaviour only for "set" properties and functions that user
does not care about their return values. "get" properties could not be
implemented
at all.

So, as you can guess I am for different interfaces for single and
multiple selects.
Also, I understand, that I could be wrong and more over I do not get
right an user
desire/needs. I am asking you to try to understand my points. Also, it woul=
d be
nice to see where I am wrong.

Thought, comments?

Thanks

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

On 3/9/06, Allen Bierbaum <al...@vr...> wrote:
>
> >
> >Don't you think, that after documentation this is  a second reason why
> >people don't use
> >pyplusplus?
> >
> >
> Yes, in my opinion this is definitely a reason that people may not want
> to use pyplusplus.  The current design is very good but there are parts
> of the interface that look complex and this can scare people away.

So as you can see you pointed to the big problem.

> Before making too many changes in this regard though I think we should
> all agree to what the goal is for the changes.  Perhaps agree to some
> rough coding standards or coding idioms to use.

Yes. I will read Python coding guide-lines. May be will will change somethi=
ng
for this release may be not. Anyway if you have some ideas - please share t=
hem.

> -Allen

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

>
>Don't you think, that after documentation this is  a second reason why
>people don't use
>pyplusplus?
>  
>
Yes, in my opinion this is definitely a reason that people may not want 
to use pyplusplus.  The current design is very good but there are parts 
of the interface that look complex and this can scare people away.

Before making too many changes in this regard though I think we should 
all agree to what the goal is for the changes.  Perhaps agree to some 
rough coding standards or coding idioms to use.

-Allen

On 3/9/06, Allen Bierbaum <al...@vr...> wrote:
> I agree with you that there is an overuse of properties that often makes
> the code more complex without gaining anything.  I had hesitated to
> mention it earlier because it seemed like a little bit of nit picking. :(

No, no, no. If [I, we] want the project to be successful I need to
hear such critic.
Take it, as it is your responsibility to critic me.

> I was talking to one of my co-workers yesterday and describing the
> pygccxml and pyplusplus codebase to him.  After describing the issues I
> was having understanding the codebase he pointed out something I had not
> thought about before.  Namely it seems that some parts of the code are
> using non-Pythonic idioms.

You don't even know how much he is right!!!! I make my living from coding
pretty big system in C++. I had few reasons, when I started to develop
pyplusplus.
One of them is was to get an experience with coding in Python.
( The main reason is that I believe in multi language development
environment, and
this is a tiny thing I can do in order to promote this approach )
If you take an abstract look on the code you will see C++ there:
1. all members are private
2. there is accessor ( get,set ) for every member
3. coding convention
4. I almost don't use Python dynamism
5 I am sure you can fill the list

>For example in python the only time you
> normally would use properties is to make something read-only or to
> trigger code (such as validation) when a value is change.  On the other
> hand with javabeans the properties with getters/setters are used for
> everything.  There are other areas in the code base that use metaphors I
> have not seen widely used in Python.  For example: the class naming
> convention seems more like C code then python,

I explained this

>filters

I like stl algorithms as an approach to solve the problems.

>and flattening
> are used quite often and in ways that look to be copying and iterating
> more then necessary.

You are right. There is only one reason: get the job done in shorter time.
I don't like to write complex code, but may be by using the full power of
Python, I still can get an expressiveness and simplicity. You will
need to teach me.

Also, this specific critic is right, in general, it lacks the numbers.
I did profiling
and I am satisfied with the numbers. I never saw in profiler I am paying fo=
r
copying and iterating. Lets say that if new approach will improve speed by =
20%
we will commit it.

> To be clear, I am not saying the code is wrong or should change I am
> just trying to point out that I have seen some strange things in the
> code as well.

Because this is a C++ code using Python :-). You and Allen have commit
permissions, \
right? Go ahead and fix it, please, please, please.

I think we should not even discuss such things. The only things we
need a discussion
is design and interface. I want to believe, that design is right. If
you think different,
please say it. I am sure it will be an interesting conversation :-).

> None of these are critical.

Don't you think, that after documentation this is  a second reason why
people don't use
pyplusplus?

> The important thing is that the code works
> and works well right now.  I would rather have working code that
> confuses me then clear code that fails. :)

You are 100% right.

> -Allen

Thank you and Matthias for raising those points.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

On 3/8/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I was just going over the config_t class to add some more doc strings
> when I noticed a few things I would just like to mention.
>
> When I wanted to document the "gccxml_path" argument of the config_t
> constructor I had a look at the code to find out what exactly it is
> supposed to contain and what values are valid. The first thing that
> surprised me was that the actual code that checks this argument is not
> in config_t but in source_reader_t.__raise_on_wrong_settings(). So the
> data and the related code is separated (even into different source
> files) which seems to be against the object-oriented programming
> principles.

:-). Please critic me as much as you can. I like this kind of arguments.
You are right.

> Then, the class uses properties to "shield" its attributes, but actually
> this is only exploited for about half of the attributes to make them
> read-only. The other attributes are read/write and *any* value is
> allowed. So why are they implemented as properties at all? There is no
> advantage in doing so if the values are simply passed through, you could
> just have used regular attributes which would have made the code smaller
> and easier to read. Especially as you have explicitly decided to do
> validity checks outside the class.

And you are right here

> The advantage of properties is that they can invoke actions and values
> can be checked and possibly rejected or corrected. This is exactly what
> __raise_on_wrong_settings() is doing. So in my opinion, a better place
> for that code would have been the __set_gccxml_path() method right in
> config_t. This way, config_t would be a "smart" container and other
> parts of the code could rely on the parameters always holding valid
> values which don't have to be checked again.

Hmm. I am not sure how I should implement this. From the one side I don't
want to force user to give all arguments in constructor. I think that next
coding style should be supported, but I could be wrong.

cfg =3D config_t()
cfg.gccxml_path =3D ...
cfg.... =3D ....

Do I need to support it? If now it is pretty clear to me how to fix this cl=
ass.

> Apart from that, I also noticed some flaws in the way the gccxml_path
> check is done. For example, when I specify a file and this file doesn't
> exist (maybe because of a typo or because some directory isn't mounted),
> then the source_reader just switches back to using "gccxml", entirely
> ignoring the fact that the user explicitly specified another version of
> gccxml to use. In such cases, I expect a program to use a default value
> only when the user did not specify any value at all. But if the user did
> specify a value and this value is invalid for some reason, the program
> should create an error (or at least issue a warning that the user's
> value is not used and the program switches back to its default behavior).

This analisys should be moved to config_t.gccxml_path property, right?

> The above cases are not really serious things, but I wanted to mention
> them anyway as I think they show what I would consider to be basic flaws
> in the design which could be improved in the future.

Please answer my question and I will improve it in a near future.
( You can do it also :-) )

> - Matthias -

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

On 3/8/06, Allen Bierbaum <al...@vr...> wrote:
> Matthias Baas wrote:
>
> > Allen Bierbaum wrote:
> >
> >> Sort of right.  I do have time to get the current API working once I
> >> understand how to get at the wrappers.
> >
> >
> > Well, it works for me (using the unmodified pypp_api module as it is
> > stored in cvs in the experimental directory).
> > When I print "parsed_decls" in parse() I get:
> >
> > [<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at
> > 0xb75f50cc>]
> >
> > Just make sure you don't load an old declaration tree from any cache
> > that is still lying around.
> >
> > But a few lines later I get an exception because
> > code_creators.decl_decorator_t doesn't exist. This was a class from
> > your patch, right?
>
> Yes.  That is the part I want to fix up.
>
> Good suggestion on the cache.  I will check that tonight (in about 5
> hours).  If that is the problem I should be able to get most of the API
> back up and working tonight.

Allen if you don't have time this is okey. I do have some. I can
create module builder.
Obviously I will do it wrong  and you will have to fix it. I will be
able to commit it 12/03 morning. What do you think?

> -Allen
>
> >
> > - Matthias -
> >
> >

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

On 3/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> ok, at least the script runs without errors again. But I do get an err=
or
> >> during compilation but that's another thing now that I first have to
> >> investigate...(it seems my call policies don't get assigned anymore, b=
ut
> >> that's ok for now).
> >
> > The only thing that I can say is that "it works fine for me". Could
> > you investigate the
> > problem. If this is a problem in pyplusplus you can commit the fix.
>
> ok (but I think this could just as well be a problem in my old API which
> just has to be updated to the new version of pyplusplus. So far, I'm
> happy that I don't get an exception anymore. :)
>
> >> I think now that pyplusplus relies on seeing its own declaration
> >> classes, it would be useful to introduce a parse() function in
> >> pyplusplus (which would use the dwfactory_t class as default instead o=
f
> >> the factory from pygccxml). At the moment, *every* user of pyplusplus
> >> would have to pass dwfactory_t explicitly whereas this is rather an
> >> implementation detail.
> >
> > Yes and this is exactly the details that will be hidden in Allen class =
:-)
>
> Oh, ok, but just because we will have a high level API doesn't mean we
> should be "sloppy" and introduce awkward things into the low level API.
> In my opinion, the low level API should still be kept clean and logical
> and also as "easy to use" as possible (without having to introduce new
> concepts that the high level API might already do). Maybe there are
> cases where users have to go back to the low level API for whatever
> reasons...

Like your :-). If you can commit the fix go ahead. If you don't I will
do it next week

> - Matthias -

Thanks

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

Matthias Baas wrote:

> Hi,
>
> I was just going over the config_t class to add some more doc strings 
> when I noticed a few things I would just like to mention.
>
> When I wanted to document the "gccxml_path" argument of the config_t 
> constructor I had a look at the code to find out what exactly it is 
> supposed to contain and what values are valid. The first thing that 
> surprised me was that the actual code that checks this argument is not 
> in config_t but in source_reader_t.__raise_on_wrong_settings(). So the 
> data and the related code is separated (even into different source 
> files) which seems to be against the object-oriented programming 
> principles.
> Then, the class uses properties to "shield" its attributes, but 
> actually this is only exploited for about half of the attributes to 
> make them read-only. The other attributes are read/write and *any* 
> value is allowed. So why are they implemented as properties at all? 
> There is no advantage in doing so if the values are simply passed 
> through, you could just have used regular attributes which would have 
> made the code smaller and easier to read. Especially as you have 
> explicitly decided to do validity checks outside the class.
> The advantage of properties is that they can invoke actions and values 
> can be checked and possibly rejected or corrected. This is exactly 
> what __raise_on_wrong_settings() is doing. So in my opinion, a better 
> place for that code would have been the __set_gccxml_path() method 
> right in config_t. This way, config_t would be a "smart" container and 
> other parts of the code could rely on the parameters always holding 
> valid values which don't have to be checked again.

I agree with you that there is an overuse of properties that often makes 
the code more complex without gaining anything.  I had hesitated to 
mention it earlier because it seemed like a little bit of nit picking. :(

I was talking to one of my co-workers yesterday and describing the 
pygccxml and pyplusplus codebase to him.  After describing the issues I 
was having understanding the codebase he pointed out something I had not 
thought about before.  Namely it seems that some parts of the code are 
using non-Pythonic idioms.  For example in python the only time you 
normally would use properties is to make something read-only or to 
trigger code (such as validation) when a value is change.  On the other 
hand with javabeans the properties with getters/setters are used for 
everything.  There are other areas in the code base that use metaphors I 
have not seen widely used in Python.  For example: the class naming 
convention seems more like C code then python, filters and flattening 
are used quite often and in ways that look to be copying and iterating 
more then necessary.

To be clear, I am not saying the code is wrong or should change I am 
just trying to point out that I have seen some strange things in the 
code as well. 

None of these are critical.  The important thing is that the code works 
and works well right now.  I would rather have working code that 
confuses me then clear code that fails. :)

-Allen

>
> Apart from that, I also noticed some flaws in the way the gccxml_path 
> check is done. For example, when I specify a file and this file 
> doesn't exist (maybe because of a typo or because some directory isn't 
> mounted), then the source_reader just switches back to using "gccxml", 
> entirely ignoring the fact that the user explicitly specified another 
> version of gccxml to use. In such cases, I expect a program to use a 
> default value only when the user did not specify any value at all. But 
> if the user did specify a value and this value is invalid for some 
> reason, the program should create an error (or at least issue a 
> warning that the user's value is not used and the program switches 
> back to its default behavior).
>
> The above cases are not really serious things, but I wanted to mention 
> them anyway as I think they show what I would consider to be basic 
> flaws in the design which could be improved in the future.
>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Matthias Baas wrote:

> Allen Bierbaum wrote:
>
>> Sort of right.  I do have time to get the current API working once I 
>> understand how to get at the wrappers.  
>
>
> Well, it works for me (using the unmodified pypp_api module as it is 
> stored in cvs in the experimental directory).
> When I print "parsed_decls" in parse() I get:
>
> [<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at 
> 0xb75f50cc>]
>
> Just make sure you don't load an old declaration tree from any cache 
> that is still lying around.
>
> But a few lines later I get an exception because 
> code_creators.decl_decorator_t doesn't exist. This was a class from 
> your patch, right?

Yes.  That is the part I want to fix up.

Good suggestion on the cache.  I will check that tonight (in about 5 
hours).  If that is the problem I should be able to get most of the API 
back up and working tonight.

-Allen

>
> - Matthias -
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Allen Bierbaum wrote:
> Sort of right.  I do have time to get the current API working once I 
> understand how to get at the wrappers.  

Well, it works for me (using the unmodified pypp_api module as it is 
stored in cvs in the experimental directory).
When I print "parsed_decls" in parse() I get:

[<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at 
0xb75f50cc>]

Just make sure you don't load an old declaration tree from any cache 
that is still lying around.

But a few lines later I get an exception because 
code_creators.decl_decorator_t doesn't exist. This was a class from your 
patch, right?

- Matthias -

Matthias Baas wrote:

> Allen Bierbaum wrote:
>
>> Roman:  How do I get to the decl wrappers.
>
>
> I had a look at pypp_api.py and saw that you're already doing what I 
> thought is required....(passing the dwfactory_t object to the 
> project_reader)
> Do you have you caching enabled? Then you must remove the cache file 
> because otherwise you get the old cache content which uses the 
> pygccxml declaration objects.
>
> By the way, did I get that right that you won't have the time to work 
> on the pypp_api before the weekend? So is the current cvs version also 
> the up-to-date version or do you have already a newer version? As one 
> of the next things I wanted to have a closer look at it and maybe I 
> can also do some modifications to get it to work again....

Sort of right.  I do have time to get the current API working once I 
understand how to get at the wrappers.  I just won't have time to sit 
down and work for more then an hour or two.  I "should" be able to 
dedicate a day to the effort this weekend though.

-Allen

>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Allen Bierbaum wrote:
> Roman:  How do I get to the decl wrappers.

I had a look at pypp_api.py and saw that you're already doing what I 
thought is required....(passing the dwfactory_t object to the 
project_reader)
Do you have you caching enabled? Then you must remove the cache file 
because otherwise you get the old cache content which uses the pygccxml 
declaration objects.

By the way, did I get that right that you won't have the time to work on 
the pypp_api before the weekend? So is the current cvs version also the 
up-to-date version or do you have already a newer version? As one of the 
next things I wanted to have a closer look at it and maybe I can also do 
some modifications to get it to work again....

- Matthias -

Hi,

I was just going over the config_t class to add some more doc strings 
when I noticed a few things I would just like to mention.

When I wanted to document the "gccxml_path" argument of the config_t 
constructor I had a look at the code to find out what exactly it is 
supposed to contain and what values are valid. The first thing that 
surprised me was that the actual code that checks this argument is not 
in config_t but in source_reader_t.__raise_on_wrong_settings(). So the 
data and the related code is separated (even into different source 
files) which seems to be against the object-oriented programming 
principles.
Then, the class uses properties to "shield" its attributes, but actually 
this is only exploited for about half of the attributes to make them 
read-only. The other attributes are read/write and *any* value is 
allowed. So why are they implemented as properties at all? There is no 
advantage in doing so if the values are simply passed through, you could 
just have used regular attributes which would have made the code smaller 
and easier to read. Especially as you have explicitly decided to do 
validity checks outside the class.
The advantage of properties is that they can invoke actions and values 
can be checked and possibly rejected or corrected. This is exactly what 
__raise_on_wrong_settings() is doing. So in my opinion, a better place 
for that code would have been the __set_gccxml_path() method right in 
config_t. This way, config_t would be a "smart" container and other 
parts of the code could rely on the parameters always holding valid 
values which don't have to be checked again.

Apart from that, I also noticed some flaws in the way the gccxml_path 
check is done. For example, when I specify a file and this file doesn't 
exist (maybe because of a typo or because some directory isn't mounted), 
then the source_reader just switches back to using "gccxml", entirely 
ignoring the fact that the user explicitly specified another version of 
gccxml to use. In such cases, I expect a program to use a default value 
only when the user did not specify any value at all. But if the user did 
specify a value and this value is invalid for some reason, the program 
should create an error (or at least issue a warning that the user's 
value is not used and the program switches back to its default behavior).

The above cases are not really serious things, but I wanted to mention 
them anyway as I think they show what I would consider to be basic flaws 
in the design which could be improved in the future.

- Matthias -

Matthias Baas wrote:

> Hi,
>
> some of the recent discussion has become somewhat "theoretical" for me 
> as I'm still in a state where I cannot create my bindings. So my 
> short-term goal is still to get either my own or Allen's API to a 
> state where it's at least partially functional again. In my own 
> version I still get that exception I once posted. After the 
> discoveries from yesterday I thought the problem might be that I don't 
> provide a decl_factory to create decl_wrappers and pyplusplus might 
> depend on them. But when I created a factory class that returns 
> decl_wrappers then even the parse() step fails with an assertion error 
> in source_reader.py (btw, shouldn't such a factory object be part of 
> pyplusplus?).
> And Allen's version still seems to rely on his patched version of 
> pyplusplus.
> I'm not sure if Allen is in the same situation or not, but at least 
> for me it would be great if I could somehow get any API to work with 
> the current cvs version of pyplusplus again.
> Roman, can you provide a small "porting guide" and outline what has to 
> be changed so that a script that was working with pyplusplus from 1 or 
> 2 weeks ago will work again with the current version?
> I'd like to get "back on the road" again as quickly as possible so 
> that I can actually move on... ;)

I would like to get back to a working API as well.  I tried to do this 
last weekend but ran into problems when I couldn't figure out how to get 
back the decl_wrappers with the new interface.  The current problem in 
my API is that when the pygccxml parse returns (after being called with 
the decl_wrapper factory) it does not return a decl_wrapper.  Until I 
find out how to get to the decl wrappers I am at a standstill.

Roman:  How do I get to the decl wrappers.

-Allen

>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Roman Yakovenko wrote:
>> ok, at least the script runs without errors again. But I do get an error
>> during compilation but that's another thing now that I first have to
>> investigate...(it seems my call policies don't get assigned anymore, but
>> that's ok for now).
> 
> The only thing that I can say is that "it works fine for me". Could
> you investigate the
> problem. If this is a problem in pyplusplus you can commit the fix.

ok (but I think this could just as well be a problem in my old API which 
just has to be updated to the new version of pyplusplus. So far, I'm 
happy that I don't get an exception anymore. :)

>> I think now that pyplusplus relies on seeing its own declaration
>> classes, it would be useful to introduce a parse() function in
>> pyplusplus (which would use the dwfactory_t class as default instead of
>> the factory from pygccxml). At the moment, *every* user of pyplusplus
>> would have to pass dwfactory_t explicitly whereas this is rather an
>> implementation detail.
> 
> Yes and this is exactly the details that will be hidden in Allen class :-)

Oh, ok, but just because we will have a high level API doesn't mean we 
should be "sloppy" and introduce awkward things into the low level API. 
In my opinion, the low level API should still be kept clean and logical 
and also as "easy to use" as possible (without having to introduce new 
concepts that the high level API might already do). Maybe there are 
cases where users have to go back to the low level API for whatever 
reasons...

- Matthias -

Roman Yakovenko wrote:
> reader = parser.project_reader_t( config, None, decl_wrappers.dwfactory_t() )

Ah! I hadn't found the dwfactory_t class. I was only searching for a 
file name with "factory" in its name, I didn't expect it to be "hidden" 
in the __init__ module... ;)
When I also used that factory class, it worked again (which is somewhat 
weird because my own factory class was almost the same, the only 
difference was that I didn't derive from decl_factory_t).

ok, at least the script runs without errors again. But I do get an error 
during compilation but that's another thing now that I first have to 
investigate...(it seems my call policies don't get assigned anymore, but 
that's ok for now).

I think now that pyplusplus relies on seeing its own declaration 
classes, it would be useful to introduce a parse() function in 
pyplusplus (which would use the dwfactory_t class as default instead of 
the factory from pygccxml). At the moment, *every* user of pyplusplus 
would have to pass dwfactory_t explicitly whereas this is rather an 
implementation detail.

- Matthias -

On 3/8/06, Roman Yakovenko <rom...@gm...> wrote:
I will try to help you to use low level api

config =3D parser.config_t( gccxml_path=3Dgccxml_path)

reader =3D parser.project_reader_t( config, None, decl_wrappers.dwfactory_t=
() )
decls =3D reader.read_files( self.__files )
#directly customize decls, by the way decls will contains decl wrappers
#You can use your own filters with declarations.matcher class.

module_creator =3D module_creator.creator_t( decls, module_name, .... )
#directly customize module creator

use file writers

This should work well.

Did this help?
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

2006	Jan	Feb (6)	Mar (160)	Apr (96)	May (152)	Jun (72)	Jul (99)	Aug (189)	Sep (161)	Oct (110)	Nov (9)	Dec (3)
2007	Jan (13)	Feb (48)	Mar (35)	Apr (7)	May (37)	Jun (8)	Jul (15)	Aug (8)	Sep (2)	Oct (1)	Nov (2)	Dec (38)
2008	Jan (11)	Feb (29)	Mar (17)	Apr (3)	May	Jun (64)	Jul (49)	Aug (51)	Sep (18)	Oct (22)	Nov (9)	Dec (9)
2009	Jan (28)	Feb (15)	Mar (2)	Apr (11)	May (6)	Jun (2)	Jul (3)	Aug (34)	Sep (5)	Oct (7)	Nov (13)	Dec (14)
2010	Jan (39)	Feb (3)	Mar (3)	Apr (14)	May (11)	Jun (8)	Jul (9)	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar (7)	Apr	May	Jun (3)	Jul (3)	Aug (3)	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (2)
2016	Jan (1)	Feb (1)	Mar	Apr (1)	May	Jun	Jul (1)	Aug (1)	Sep	Oct	Nov (1)	Dec
2019	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2021	Jan (1)	Feb (1)	Mar	Apr	May (1)	Jun	Jul	Aug	Sep (1)	Oct (1)	Nov	Dec