pygccxml-development

[pygccxml-development] Bug in virtual function wrapping with pyplusplus

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

I think I have found a bug in the handling of virtual methods with 
pyplusplus.

I have attached a set of test classes and the generated bindings.

The problem seems to be that when you have 3 classes derived from each 
other as:

class Grandpa
class Father : public Grandpa
class Son : public Father

And Grandpa declares a pure virtual method that is defined in Father but 
just used in Son, the wrapper for Son still thinks it is a pure virtual 
and doesn't know to generate code with the default implementation in 
Father.  (See the attached code, it really makes more sense with an example)

-Allen

Re: [pygccxml-development] Unexpected headers files in generated code

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

On 5/23/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 5/23/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I am seeing some unexpected and undesirable system headers showing up =
in
> >> my generated bindings.  For example, with one library I am seeing thes=
e
> >> includes in the generated .cpp files.
> >>
> >> #include "/usr/include/c++/4.0.2/ext/mt_allocator.h"
> >> #include "/usr/include/c++/4.0.2/bits/stl_construct.h"
> >>
> >> Any idea why this would be happening?  Is anyone else seeing these
> >> problems?
> >>
> >> If it matters, I am generating bindings on Fedora Core 4 with gccxml
> >> 0.7.0.
> >
> >
> > May be you export something from those headers?
> > If not it seems to me that the right place to set break point is
> > module_builder.module_builder_t.__filter_by_location function.
> >
> > I tested indexing suite on Windows only, this evening I will test it
> > on Linux too.
> > May be I will find some bug.
>
> I am not exporting anything from these files, just standard classes
> exported from their own headers.
>
> This came in before the indexing suite.  I have been seeing this
> behavior for a week or so.  Unfortunately I don't have a nice small test
> case that replicates the problem. :(

Can you send me gccxml generated file and your script?
This should be enough to reproduce the problem.

Thanks


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

Re: [pygccxml-development] Re: Suggested debug output

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

On 5/22/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/22/06, Allen Bierbaum <al...@vr...> wrote:
> > I don't have the code anymore, I removed it once I found the bug.  I
> > think you could probably just add some output in the normalize_path
> > method (I think I remembered the name correctly).
>
> I will do this in a few days.

I completely forgot that this is already implemented, but has been disabled=
.
If you take a look on code_creators.instruction_t class, than you will
see silent property.
By default it is True. This means, that include_directories_t code
creator, will not
write into generated files additional include directories. I think,
that this was a mistake,
and may be I should turn it to false, by default.

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


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

Re: [pygccxml-development] Unexpected headers files in generated code

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

Roman Yakovenko wrote:

> On 5/23/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I am seeing some unexpected and undesirable system headers showing up in
>> my generated bindings.  For example, with one library I am seeing these
>> includes in the generated .cpp files.
>>
>> #include "/usr/include/c++/4.0.2/ext/mt_allocator.h"
>> #include "/usr/include/c++/4.0.2/bits/stl_construct.h"
>>
>> Any idea why this would be happening?  Is anyone else seeing these 
>> problems?
>>
>> If it matters, I am generating bindings on Fedora Core 4 with gccxml 
>> 0.7.0.
>
>
> May be you export something from those headers?
> If not it seems to me that the right place to set break point is
> module_builder.module_builder_t.__filter_by_location function.
>
> I tested indexing suite on Windows only, this evening I will test it
> on Linux too.
> May be I will find some bug.

I am not exporting anything from these files, just standard classes 
exported from their own headers.

This came in before the indexing suite.  I have been seeing this 
behavior for a week or so.  Unfortunately I don't have a nice small test 
case that replicates the problem. :(

-Allen

Re: [pygccxml-development] Unexpected headers files in generated code

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

On 5/23/06, Allen Bierbaum <al...@vr...> wrote:
> I am seeing some unexpected and undesirable system headers showing up in
> my generated bindings.  For example, with one library I am seeing these
> includes in the generated .cpp files.
>
> #include "/usr/include/c++/4.0.2/ext/mt_allocator.h"
> #include "/usr/include/c++/4.0.2/bits/stl_construct.h"
>
> Any idea why this would be happening?  Is anyone else seeing these proble=
ms?
>
> If it matters, I am generating bindings on Fedora Core 4 with gccxml 0.7.=
0.

May be you export something from those headers?
If not it seems to me that the right place to set break point is
module_builder.module_builder_t.__filter_by_location function.

I tested indexing suite on Windows only, this evening I will test it
on Linux too.
May be I will find some bug.

> Thanks,
> Allen

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

[pygccxml-development] Unexpected headers files in generated code

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

I am seeing some unexpected and undesirable system headers showing up in 
my generated bindings.  For example, with one library I am seeing these 
includes in the generated .cpp files.

#include "/usr/include/c++/4.0.2/ext/mt_allocator.h"
#include "/usr/include/c++/4.0.2/bits/stl_construct.h"

Any idea why this would be happening?  Is anyone else seeing these problems?

If it matters, I am generating bindings on Fedora Core 4 with gccxml 0.7.0.

Thanks,
Allen

Re: [pygccxml-development] Using pyplusplus with indexing suite

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

On 5/23/06, Allen Bierbaum <al...@vr...> wrote:
> Any update on this.  Is it still something you think can be automated?

:-). Basically, I prepare pygccxml and pyplusplus for next release.
This means that
source code is almost freeze and the main task is to write
documentation. I think
I will make a release next week. I do not want to implement complete soluti=
on
for the problem. Under complete solution, I mean that py++
automatically finds out
for which classes and what indexing suite should be registered. So I
implemented partial
solution, that I hope will make your life easier:

mb =3D module_builder_t( ... )
item_cls =3D mb.class_( 'item_t' )
item_cls.indexing_suites.append(
module_builder.vector_indexing_suite_t( 'items_t' ) )

I don't promise, that the last line will stay as is in the future( =3D=3D
when I implement full
support for indexing suite ). But don't worry, I will let you know
before I will commit
the changes.

I know, that you are going to take a look on the code, I wrote, am I right?
If so can you add few doc strings and commit? ( Yes, you have SVN access ).

Thanks.

P.S. vector_indexing_suite requires operators =3D=3D and !=3D.

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

Re: [pygccxml-development] Using pyplusplus with indexing suite

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

>
>
> 2. I will accept the patch. Now when I think about it, it should be
> fairly simple.
>    1.  There is a need for vector_indexing_suite_ code creator.
>    2.  After this small modification should be done to types_database_t.
>         It should recognize, that data type is vector or map.
>         pygccxml.declarations.templates parser will do the job easier
>    3.  Modify module_creator.creator_t class
>
> I am running out of time, otherwise I would implement the patch by 
> myself.
> I think it should take like 3-5 hours.
>
Any update on this.  Is it still something you think can be automated?

-Allen

Re: [pygccxml-development] Re: Suggested debug output

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

On 5/22/06, Allen Bierbaum <al...@vr...> wrote:
> I don't have the code anymore, I removed it once I found the bug.  I
> think you could probably just add some output in the normalize_path
> method (I think I remembered the name correctly).

I will do this in a few days.

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

Re: [pygccxml-development] Re: Suggested debug output

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

Roman Yakovenko wrote:

> On 5/22/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman:
>>
>> I just ran into a strange issue where all the generated code has a
>> hard-coded path in my user directory.  It took me a while to track down,
>> but I finally fixed it.  (I just needed another path in my user include
>> directories)
>>
>> But in the process I added print output in a number of places
>> (include_t, include_directories_t) so I could see the process that the
>> headers were going through to get the final name.  I got to thinking
>> about this and I think this would be useful debug output to send to the
>> logger so users can see how the paths are being normalized and get some
>> insight into what they need to change.
>>
>> Could you add some debug loggin to the header normalization process so
>> people can debug similar problems?  (I found it helpful to have the
>> original header name, the final normalized name, and a current list of
>> include directories used to normalize it)
>>
>> Thanks,
>> Allen
>>
>> PS. I would give you my changes, but they are just hacked up print
>> statements and probably nothing close to where you would really want to
>> put this type of output.
>>
>
> I am fine with those changes. Can you send me the code you hacked?
> Thus I will have better idea and understanding, what you did and what 
> help
> you to fix it.
>
I don't have the code anymore, I removed it once I found the bug.  I 
think you could probably just add some output in the normalize_path 
method (I think I remembered the name correctly).

-Allen

> Thanks
>

[pygccxml-development] Re: Suggested debug output

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

On 5/22/06, Allen Bierbaum <al...@vr...> wrote:
> Roman:
>
> I just ran into a strange issue where all the generated code has a
> hard-coded path in my user directory.  It took me a while to track down,
> but I finally fixed it.  (I just needed another path in my user include
> directories)
>
> But in the process I added print output in a number of places
> (include_t, include_directories_t) so I could see the process that the
> headers were going through to get the final name.  I got to thinking
> about this and I think this would be useful debug output to send to the
> logger so users can see how the paths are being normalized and get some
> insight into what they need to change.
>
> Could you add some debug loggin to the header normalization process so
> people can debug similar problems?  (I found it helpful to have the
> original header name, the final normalized name, and a current list of
> include directories used to normalize it)
>
> Thanks,
> Allen
>
> PS. I would give you my changes, but they are just hacked up print
> statements and probably nothing close to where you would really want to
> put this type of output.
>

I am fine with those changes. Can you send me the code you hacked?
Thus I will have better idea and understanding, what you did and what help
you to fix it.

Thanks

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

[pygccxml-development] =?WINDOWS-1252?Q?Re:_[pygccxml-development]_error:_cannot_?= =?WINDOWS-1252?Q?create_pointer_to_reference_member_=91B::a=92?=

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

On 5/22/06, Neal Becker <ndb...@gm...> wrote:
> hello_world.hpp:
> --------------
> struct A {};
>
> struct B {
>   A& a;
> };
>
> --------------
>
> run through pygccxml produces:
> // This file has been generated by pyplusplus.
>
> #include "boost/python.hpp"
>
> #include "/home/nbecker/tmp/hello_world.hpp"
>
> namespace bp =3D boost::python;
>
> BOOST_PYTHON_MODULE(hw){
>     bp::class_< B, boost::noncopyable >( "B", bp::no_init )
>         .def_readonly( "a", &B::a );
>
>     bp::class_< A >( "A" );
> }
>
> But this doesn't compile:
> g++ -I /usr/include/python2.4 -I /usr/local/src/boost.cvs hello_world.py.=
cpp
> hello_world.py.cpp: In function 'void init_module_hw()':
> hello_world.py.cpp:11: error: cannot create pointer to reference member '=
B::a'

I will fix it in a day or too. I will let you know, okay?
Thanks for bug reporting.

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

Re: [pygccxml-development] Patch to let gccxml work

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

On 5/22/06, Allen Bierbaum <al...@vr...> wrote:
> I have had a patch sitting around in my pygccxml code for a while to
> actually allow gccxml to work on my code base.
>
> You see, some of the code I use and wrap causes gccxml to output warning
> messages during execution.  The current pygccxml code makes the
> assumption that if there is any output then there was error compiling
> the code.  This prevents it from working for me.
>
> I have attached a patch that fixed the problem for me by judging
> successful completion by wether or not gccxml actually generates an
> output file.  This may not be the best way to do this, but it works for m=
e.

I remember this patch. Also I remember it does not work for me. I will
check it one
more time. If it works I will commit it. If it will not work, I have
another idea how we
can fix it.

> -Allen


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

[pygccxml-development] error: cannot create pointer to reference member =?utf-8?q?=E2=80=98B=3A=3Aa=E2=80=99?=

[Neal B. <ndb...@gm...>]

hello_world.hpp:
=2D-------------
struct A {};

struct B {
  A& a;
};
=2D-------------

run through pygccxml produces:
// This file has been generated by pyplusplus.

#include "boost/python.hpp"

#include "/home/nbecker/tmp/hello_world.hpp"

namespace bp =3D boost::python;

BOOST_PYTHON_MODULE(hw){
    bp::class_< B, boost::noncopyable >( "B", bp::no_init )   =20
        .def_readonly( "a", &B::a );

    bp::class_< A >( "A" );
}

But this doesn't compile:
g++ -I /usr/include/python2.4 -I /usr/local/src/boost.cvs hello_world.py.cp=
p=20
hello_world.py.cpp: In function =E2=80=98void init_module_hw()=E2=80=99:
hello_world.py.cpp:11: error: cannot create pointer to reference member =E2=
=80=98B::a=E2=80=99

[pygccxml-development] Patch to let gccxml work

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

I have had a patch sitting around in my pygccxml code for a while to 
actually allow gccxml to work on my code base.

You see, some of the code I use and wrap causes gccxml to output warning 
messages during execution.  The current pygccxml code makes the 
assumption that if there is any output then there was error compiling 
the code.  This prevents it from working for me.

I have attached a patch that fixed the problem for me by judging 
successful completion by wether or not gccxml actually generates an 
output file.  This may not be the best way to do this, but it works for me.

-Allen

Re: [pygccxml-development] Bug fix for noncopyable objects that are copyable

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

On 5/18/06, Allen Bierbaum <al...@vr...> wrote:
>
> I have attached a patch that fixes a bug I ran into in pyplusplus.
>
> The problem was that I have something that looks like this.
>
> class Base
> {
> protected:
>    Base(Base& r);
>    Base();
> }
>
> class Derived : public Base
> {
> public:
>    Derived();
>    Derived(Derived& r);
> }
>
> As you can see in the code, the base class has a protected constructor.
> In my case this is fine because it is a pure virtual base class.  The
> problem was that when I tried to wrap Derived, pyplusplus thought is was
> noncopyable because Base didn't have a trivial copy (ie. public).  This
> led pyplusplus to introduce boost::noncopyable into the exposer
> generated.  This was a bug because as you can see the Derived class is
> actually quite copyable.
>
> The patch fixes the is_noncopyable method in type_traits to understand
> that the base classes can have either a public or protected copy
> constructor.
>
> I regenerated bindings for a couple of libraries using this code and it
> seems to work fine.

Thank you. This is a right patch. I checked it on few libraries also
and it works.
Committed
--=20
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Bug fix for noncopyable objects that are copyable

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

I have attached a patch that fixes a bug I ran into in pyplusplus.

The problem was that I have something that looks like this.

class Base
{
protected:
   Base(Base& r);
   Base();
}

class Derived : public Base
{
public:
   Derived();
   Derived(Derived& r);
}

As you can see in the code, the base class has a protected constructor.  
In my case this is fine because it is a pure virtual base class.  The 
problem was that when I tried to wrap Derived, pyplusplus thought is was 
noncopyable because Base didn't have a trivial copy (ie. public).  This 
led pyplusplus to introduce boost::noncopyable into the exposer 
generated.  This was a bug because as you can see the Derived class is 
actually quite copyable.

The patch fixes the is_noncopyable method in type_traits to understand 
that the base classes can have either a public or protected copy 
constructor.

I regenerated bindings for a couple of libraries using this code and it 
seems to work fine.

-Allen

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>
> >
> > The bottom line: if you don't mind I would like to exclude __getattr__
> > part of the
> > patch. If you feel, that this part is so good, then I will insert it,
> > but user will
> > have to turn this feature on. I will try to find how to do this.
> >
> I am fine without it.  I just liked it because it allowed pyplusplus to
> feel a lot more like the Pyste interface.  This could help with user
> adoption and porting.

I understand all those advantages, but I think that the price it too high.
Anyway thanks.

> -Allen
>
>


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

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

>
> The bottom line: if you don't mind I would like to exclude __getattr__
> part of the
> patch. If you feel, that this part is so good, then I will insert it,
> but user will
> have to turn this feature on. I will try to find how to do this.
>
I am fine without it.  I just liked it because it allowed pyplusplus to 
feel a lot more like the Pyste interface.  This could help with user 
adoption and porting.

-Allen

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
> Yes, I don't see anyway around this.  That is why this syntax is a
> little dangerous.  It is nice when it works but there are certain
> reserved words that it is not going to work with.

My main problem with this part, is that user can run into the problem.
I try to explain my self. When he misspelled some reserved word, he don't h=
ave
to know that there is __getattr__ function that does some work.

> Personally I don't think this is enough reason to not use the API, but
> it does mean that users need to be careful when they do (or atleast they
> need to be warned about the potential problems in the documentation).

In most cases, this part of documentation will be skiped.

> It would have to be considered an advanced feature unless someone can
> think of a way around this problem.

The bottom line: if you don't mind I would like to exclude __getattr__
part of the
patch. If you feel, that this part is so good, then I will insert it,
but user will
have to turn this feature on. I will try to find how to do this.

> -Allen
>
>


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

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

Roman Yakovenko wrote:

> On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>> >> > ns.MyClass.exclude()
>> >> > class_a = ns.ClassA
>> >> > class_a.doSomething.include()
>> >
>> >
>> > This one I like less. If user made some mistake and spelled wrong
>> > property name
>> > of the class_t or namespace_t and there is a declaration with that 
>> name,
>> > then .... I prefer to apply the patch without __getattr__ part.
>> >
>> > Thoughts?
>>
>> I assume you mean something like:
>>
>> MyClass.someMethod.call_policies = ....
>>
>> so what if they spell it 'call_pooicies', it that case it will raise the
>> exception that python would normal raise and just throw and 
>> AttributeError.
>
>
> I don't have a problem with exceptions you raise. I have a problem
> when exception
> is not raised. User wrote MyClass.named, when he meant MyClass.name and
> MyClass has named variable.
>
> Almost same example, different view:
> class X{
> string name;
> };
>
> User can not use X.name syntax, because name is the property of every
> declaration.
>
> So he is forced to switch to alternative syntax: X["name"].
>
> I don't like this.

Yes, I don't see anyway around this.  That is why this syntax is a 
little dangerous.  It is nice when it works but there are certain 
reserved words that it is not going to work with.

Personally I don't think this is enough reason to not use the API, but 
it does mean that users need to be careful when they do (or atleast they 
need to be warned about the potential problems in the documentation).

It would have to be considered an advanced feature unless someone can 
think of a way around this problem.

-Allen

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
> >> > ns.MyClass.exclude()
> >> > class_a =3D ns.ClassA
> >> > class_a.doSomething.include()
> >
> >
> > This one I like less. If user made some mistake and spelled wrong
> > property name
> > of the class_t or namespace_t and there is a declaration with that name=
,
> > then .... I prefer to apply the patch without __getattr__ part.
> >
> > Thoughts?
>
> I assume you mean something like:
>
> MyClass.someMethod.call_policies =3D ....
>
> so what if they spell it 'call_pooicies', it that case it will raise the
> exception that python would normal raise and just throw and AttributeErro=
r.

I don't have a problem with exceptions you raise. I have a problem
when exception
is not raised. User wrote MyClass.named, when he meant MyClass.name and
MyClass has named variable.

Almost same example, different view:
class X{
string name;
};

User can not use X.name syntax, because name is the property of every
declaration.

So he is forced to switch to alternative syntax: X["name"].

I don't like this.
>
> -Allen
>


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

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

Roman Yakovenko wrote:

> On 5/17/06, Roman Yakovenko <rom...@gm...> wrote:
>
>> On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>> > I have included a patch that I find useful for simplifying decl lookup
>> > in pyplusplus.
>> >
>> > It allows code like the following to be written using the __getitem__
>> > interface.
>> >
>> > ns = mb.global_ns.namespace( 'my_ns',)
>> > ns["MyClass"].exclude()
>> > class_a = ns["ClassA"]
>> > class_a["doSomething"].include()
>
>
> I like this part of the patch
>
>> > It also allows an attribute interface (similar to Pyste).
>> >
>> > ns.MyClass.exclude()
>> > class_a = ns.ClassA
>> > class_a.doSomething.include()
>
>
> This one I like less. If user made some mistake and spelled wrong 
> property name
> of the class_t or namespace_t and there is a declaration with that name,
> then .... I prefer to apply the patch without __getattr__ part.
>
> Thoughts?

I assume you mean something like:

MyClass.someMethod.call_policies = ....

so what if they spell it 'call_pooicies', it that case it will raise the 
exception that python would normal raise and just throw and AttributeError.

In the case of trying to look up a decl and spelling that decl wrong, 
for example:

MyClass.someMethod_bad

it still throws an AttributeError because that is the standard way to 
deal with a python attribute lookup problem.  It would be nice if the 
exception included the name that failed, but I don't see a way to do this.

I thought about just allowing a failed find to throw the pyplusplus 
RuntimeError exception for a failed lookup, but this would make all the 
decl classes behave dramatically different then they way python would 
expect them to work normally.  For example in a previous e-mail I talk 
about how there are some failed attemtps to look up '__newstate__'.  The 
code that is failing with this lookups is able to work correctly (I 
would guess) because it catches the AttributeError exception to detect 
that the lookup failed.  If we changed it so the classes didn't throw 
this exception anymore, this code would fail because it would not be 
expecting a RuntimeError.

So, it is not a perfect solution, but it seems like a reasonable one 
since it makes the attribute lookup keep behaving as standard python 
lookups would.

-Allen

Re: [pygccxml-development] Finalizing a class?

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

On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> This seems like something that should be made easier for the user.
> >>
> >> Perhaps something like:
> >>
> >> my_ns.class_("ClassA").finalize()
> >>
> >> class_a.member_function("my_method").finalize()
> >>
> >> Is there any reason pyplusplus can't provide a more simple interface
> >> like this for the user?
> >
> >
> > What should do pyplusplus if the only way to export declaration is to
> > create some
> > wrapper for it? For example class with pure virtual function:
> >   raise an error?
> >   create wrapper?
> >   try to export without wrapper and let to the user to understand
> > what he did
> >   wrong?
>
> I think it should raise an error and explain to the user why pyplusplus
> can't honor their request.
>
> If it is ever possible to detect that they user is doing something that
> is invalid and can be detected, then the system should tell the user and
> ask them to correct it.

It is not convinient, I think we should have next functionality:
finalize if possible

>  For example I would like the option to turn on
> a warning or even error message for cases where pyplusplus knows the
> user should specify a calling policy but hasn't.  The system already
> puts a comment in the code to that effect, it may as well warn the user
> as well.

I will print a message to log.

> -Allen
>
>


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

Re: [pygccxml-development] Patch to add a little syntactic sugar

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

Roman Yakovenko wrote:

> On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I have included a patch that I find useful for simplifying decl lookup
>> in pyplusplus.
>>
>> It allows code like the following to be written using the __getitem__
>> interface.
>>
>> ns = mb.global_ns.namespace( 'my_ns',)
>> ns["MyClass"].exclude()
>> class_a = ns["ClassA"]
>> class_a["doSomething"].include()
>>
>> It also allows an attribute interface (similar to Pyste).
>>
>> ns.MyClass.exclude()
>> class_a = ns.ClassA
>> class_a.doSomething.include()
>>
>> These both can be used to dramatically reduce the amount of clutter
>> (redundant code calls) using in a script to generate bindings. Although
>> the second one could be seen as a little dangerous because of potential
>> name conflicts, I think the interface of Pyste has proven that people
>> like an interface like this because it allows something that feels like
>> a very tight domain specific langauge for creating bindings.
>>
>> I know that neither of these methods is anything more then syntactic
>> sugar, but IMHO it is pretty sweet sugar. :)
>
>
> Thanks. I will apply the patch. There is only one question:
> Why not to implement the __getattr__ next way:
>        found_decls = self.decls(name=name, allow_empty=True)
>        if found_decls:
>            return found_decls
>        else:
>            raise AttributeError
> Why do you need treatment for '__' ?

I didn't originally have it but without it I was seeing a lot of 
searches for '__getnewargs__' and '__getstate__'.  I don't know why they 
were happening but I didn't think it was a good idea to spend time 
searching for decls that we know are not there.  It was more of an 
optimization then anything.

-Allen

>
>
>> -Allen
>
>
> Thanks.
>
>