Re: [pygccxml-development] Re: recent changes to pygccxml\pyplusplus

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

On 3/2/06, Matthias Baas <ba...@ir...> wrote:
> However, apart from that I was implementing a new cache class as
> mentioned in another mail. It's not yet finished because of that "dict
> vs list" bug in the handling of the "included_files" parameter. This
> first needs to be resolved before I can finish the class (so is
> source_reader_t.__parse_gccxml_created_file() supposed to return the
> files as a dictionary or as a list?)

May be I missed something, but what cache do you implement?
Any way the answer: list, I already fixed this bug.

> >> currently breaks my "driver" script for creating my bindings (that's
> >> what I meant the other day on the c++-sig list when I was against
> >> exposing the entire internal API as public API because the chances a
> >> future pyplusplus version will break a user's script are much higher
> >> then. And here we are... ;)
> >
> > :-(. I tested my changes. They should work as is without any changes
> > from user code.
> > It seems that I introduce a bug.
>
> It seems that for your tests you're using pyplusplus right from the
> source tree (instead of building/installing them using distutils), is
> this correct? You added some new sub packages to pyplusplus but forgot
> to add them to the setup script (decl_wrappers, module_builder). So
> anybody who's installing the package will miss those sub package and
> then, of course, pyplusplus will raise an exception right at import time
> (btw, obviously the cyclic thing I mentioned in the mailing list was not
> the source of the exception)

1. I think I found and kill the bug. When I switched to decl_wrapper's
classes I
started to return wrong "alias"es, so this bug has been fixed

2. I updated setup file before release, when I have something like
"feature freeze" period.
    I suppose, that every one who use CVS will be able to use it
without setup. I could be
    wrong, but right now I prefer to concentrate my attention on something =
else

> And the things that broke my script were:
>
> 1. call_policies.py was moved to a different location (so my import and
> usage was failing).

I can not change the history, I learned the lesson. Next time we will need =
to
do some changes I hope you will be not surprised. Sorry.

> 2. The recursive flag was removed from the module_creator.creator_t()
> constructor which broke my instantiation of that class.

:-(

> I fixed those in my script so it wasn't a big deal, especially when
> considering that pyplusplus is still under devlopment (but it sort of
> confirmed my previous concerns... ;)

Guilty :-)

> But even after fixing all of the above, there still seems to be a
> genuine bug which still prevents me from generating the bindings. When
> executing my script, I get the following traceback:
>
>    File "pyplusplus/module_creator/creator.py", line 54, in __init__
>      self.__decls =3D self._filter_decls( self._reorder_decls(
> self._prepare_decls( decls ) ) )
>    File "pyplusplus/module_creator/creator.py", line 68, in _prepare_decl=
s
>      decls =3D filter( lambda x: not x.ignore, decls )
>    File "pyplusplus/module_creator/creator.py", line 68, in <lambda>
>      decls =3D filter( lambda x: not x.ignore, decls )
> AttributeError: 'class_t' object has no attribute 'ignore'

I hope that until end of this week we will have some stable interface.
At least I
will try to work hard to do it.

> > Also I would like to explain them:
> > We decided on next concepts, correct me if I wrong:
> >
> > declarations tree is used to configure code creators
>
> Exactly.

This change had broken your scripts.

> >> And while I'm all for consistent coding guidelines I currently find it
> >> quite confusing to have several different classes with the same name (=
I
> >> spotted at least three different classes called "class_t"). For me, th=
is
> >> doesn't really help understanding the code.
> >
> > I know, this should be fixed. Can you propose naming scheme for
> > pyplusplus code creators
> > and declarations wrappers/decorators ?
>
> Well, you could fill in some extra words (such as class_wrapper_t) but
> as Python already organizes code in a hierarchy I guess it would be a
> better idea to use decl_wrapper.class_t explicitly instead of importing
> the classes into the namespace of another module. Then it's also clear
> to the reader which class is being referred to.

So, basically you would like to stay with name I proposed,  but user
is forced to
use "fully qualified" names, am I right?


>
> > Matthias, I think you should stop to use latest CVS in production envir=
onment,
> > until we stabilize interface. That's said.
>
> That's ok. I mean, I do want to be able to take advantage of the latest
> features, so it's ok that this might lead to some inconveniences first.
> And the sooner someone notices bugs, the sooner they can be fixed. :)
>
> - Matthias -
>


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