[C++-sig] PyCode_New and new.code() functions

[anders langlands]

Sorry, I assumed it was clear since I know exactly what I mean!

All the derived types do indeed define many additional methods that I want
to use. By type() constructor, do you mean doing:

b = getDerivedObjectAsBasePointer
# This would fail as doSomeDerivedFunction is only defined for Derived, but
python thinks b is a Base*
# b.doSomeDerivedFunction()
d = Derived( b )
d.doSomeDerivedFunction()

This is basically what I want to do, but I want that to be hidden from the
user. I want to do the type-checking and construction automatically. So I'd
wrap getDerivedObjectAsBasePointer with a pure python function,
getDerivedObject, defined in my module's __init__.py.

I'd like to generate the code for this python function automatically from
C++ at module initialization time, since I know the typenames of all my
classes then, and each of them has to register itself anyway, so *if* I can
get access to the globals, I can define the dict which defines the functions
for doing run-time type() constructors on my base class pointers.

Does this make it any clearer? This doesn't gain me anything over doing the
type() constructors manually in python, but I'd like to save users this
extra leg work. It'll make the resulting scripts easier to read as well.

A

On 9/12/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> anders langlands wrote:
> > Thanks stefan, that does indeed look pretty simple!
> >
> > However, is there any way I can do this with having my own interpreter?
> >
> > The problem I am trying to solve is this:
> >
> > I have a large class library I want to bind to python. Everything in the
> > library (Derived) is derived ultimately from a single class, Base. Now I
> > have functions to serialize and deserialize objects to disk. The
> > deserialize
> > function returns a Derived object as a Base*. When this Base* is passed
> > back
> > to python, python doesn't know that it's actually a Derived object, and
> it
> > would be nice if it did. I basically want to be able to automatically
> cast
> > the Base object to whichever flavour of Derived object it actually is in
> > python.
> >
> > No all my objects support the functions typeId() and typename() to get
> > information about what they are. So the solution I've come up with is
> this.
> > I just store a big dict or list in the globals which maps typeId's to
> > functions. These functions do the conversion of the base type to the
> > derived
> > type and the whole thing looks something like this:
>
> I'm not sure I understand the purpose of your downcasting. Those derived
> python classes don't offer any additional attributes over what 'Base'
> already has, or do they ?
> If not, what advantage do you get from having the type names differ,
> instead of using your own type system (provided by 'typeId()' and
> 'typename()' ?
>
> If you really want to generate python types for the many C++ classes,
> and you can do the conversion at runtime (as opposed to compile-time),
> you may consider doing all of this from within a python module, by means
> of the 'type()' constructor.
>
> But again, I don't yet understand what you are aiming at, since that
> won't give you anything you couldn't get by directly querying an object's
> typeId().
>
> Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20060912/e5a62518/attachment.htm>