Dynamically Changing the Base Class

[Adam C.]

We have a situation where we want a Swig-generated Python class to
have a different base (not object). It doesn't appear that we can
coerce Swig into generating the class we want at present (but we are
still enquiring).

Is it possible to dynamically change the base class to something else?
Initial experiments appear to show it is not:
-------------------------------- snip --------------------------------

>>class Foo(object):

pass

>>class Foozle(object):

pass

>>Foozle.__base s__ = (Foo,)

Traceback (most recent call last):
File "<pyshell#6 >", line 1, in <module>
Foozle.__bases_ _ = (Foo,)
TypeError: __bases__ assignment: 'Foo' deallocator differs from
'object'
-------------------------------- snip --------------------------------

Is there a solution I am missing?

Thanks in advance.

[George Sakkis]

On Jul 7, 9:31*am, "Adam C." <adam...@gmail. comwrote:

We have a situation where we want a Swig-generated Python class to
have a different base (not object). It doesn't appear that we can
coerce Swig into generating the class we want at present (but we are
still enquiring).

Is it possible to dynamically change the base class to something else?
Initial experiments appear to show it is not:
-------------------------------- snip -------------------------------->>>class Foo(object):

* * * * pass

>class Foozle(object):

* * * * pass

>Foozle.__bases __ = (Foo,)

Traceback (most recent call last):
* File "<pyshell#6 >", line 1, in <module>
* * Foozle.__bases_ _ = (Foo,)
TypeError: __bases__ assignment: 'Foo' deallocator differs from
'object'
-------------------------------- snip --------------------------------

Is there a solution I am missing?

Thanks in advance.

Supposedly it should (usually) work, there's a 6 year old patch for
this (http://bugs.python.org/issue635933). Check if Swig can generate
old-style classes (i.e. not inheriting from object) since __bases__
assignment works for them.

HTH,
George

[Adam C.]

On Jul 7, 9:11*am, George Sakkis <george.sak...@ gmail.comwrote:

On Jul 7, 9:31*am, "Adam C." <adam...@gmail. comwrote:

We have a situation where we want a Swig-generated Python class to
have a different base (not object). It doesn't appear that we can
coerce Swig into generating the class we want at present (but we are
still enquiring).

Is it possible to dynamically change the base class to something else?
Initial experiments appear to show it is not:
-------------------------------- snip -------------------------------->>class Foo(object):

* * * * pass

>>class Foozle(object):

* * * * pass

>>Foozle.__base s__ = (Foo,)

Traceback (most recent call last):
* File "<pyshell#6 >", line 1, in <module>
* * Foozle.__bases_ _ = (Foo,)
TypeError: __bases__ assignment: 'Foo' deallocator differs from
'object'
-------------------------------- snip --------------------------------

Is there a solution I am missing?

Thanks in advance.

Supposedly it should (usually) work, there's a 6 year old patch for
this (http://bugs.python.org/issue635933). Check if Swig can generate
old-style classes (i.e. not inheriting from object) since __bases__
assignment works for them.

HTH,
George

Thanks. I think we would want new-style classes, and 6-year-old
patches strike me as maybe a little out of the desired path... so this
really just doesn't work in modern Python?

[Carl Banks]

On Jul 7, 9:31 am, "Adam C." <adam...@gmail. comwrote:

We have a situation where we want a Swig-generated Python class to
have a different base (not object). It doesn't appear that we can
coerce Swig into generating the class we want at present (but we are
still enquiring).

Is it possible to dynamically change the base class to something else?
Initial experiments appear to show it is not:
-------------------------------- snip -------------------------------->>class Foo(object):

pass

>class Foozle(object):

pass

>Foozle.__bases __ = (Foo,)

Traceback (most recent call last):
File "<pyshell#6 >", line 1, in <module>
Foozle.__bases_ _ = (Foo,)
TypeError: __bases__ assignment: 'Foo' deallocator differs from
'object'
-------------------------------- snip --------------------------------

Is there a solution I am missing?

Thanks in advance.

You get the same effect as subclassing by using multiple inheritance.
Suppose your SWIG class called Foo to have a base class of Base. You
could instead call the SWIG class _Foo, and define Foo as a Python
class like this:

class Foo(_Foo,Base): pass

If you do that, the resulting class will behave exactly as if _Foo
were a subclass of base (apart from some introspection methods and
edge cases). You can see that this is so if you look at the MRO:

Foo, _Foo, Base, object

Which is the same MRO that would occur if _Foo derived from Base
directly.

The drawback (which is also a drawback to the hypothetical base
reassignment) is that Foo's __init__ method won't call Base's. The
only way you can make SWIG __init__ call it's superclass's __init__ is
apparently a patch.
Carl Banks

[Michele Simionato]

On Jul 7, 8:08*pm, "Adam C." <adam...@gmail. comwrote:

Thanks. I think we would want new-style classes, and 6-year-old
patches strike me as maybe a little out of the desired path... so this
really just doesn't work in modern Python?

Can you use (multiple) inheritance instead of changing the bases?
Alternatively, try using an old-style class, changing the bases
and subclassing it inheriting from object too:

class NewStyle(OldSty le, object):
pass

[Adam C.]

On Jul 7, 4:04*pm, Carl Banks <pavlovevide... @gmail.comwrote :

On Jul 7, 9:31 am, "Adam C." <adam...@gmail. comwrote:

We have a situation where we want a Swig-generated Python class to
have a different base (not object). It doesn't appear that we can
coerce Swig into generating the class we want at present (but we are
still enquiring).

Is it possible to dynamically change the base class to something else?
Initial experiments appear to show it is not:
-------------------------------- snip -------------------------------->>class Foo(object):

* * * * pass

>>class Foozle(object):

* * * * pass

>>Foozle.__base s__ = (Foo,)

Traceback (most recent call last):
* File "<pyshell#6 >", line 1, in <module>
* * Foozle.__bases_ _ = (Foo,)
TypeError: __bases__ assignment: 'Foo' deallocator differs from
'object'
-------------------------------- snip --------------------------------

Is there a solution I am missing?

Thanks in advance.

You get the same effect as subclassing by using multiple inheritance.
Suppose your SWIG class called Foo to have a base class of Base. *You
could instead call the SWIG class _Foo, and define Foo as a Python
class like this:

class Foo(_Foo,Base): pass

If you do that, the resulting class will behave exactly as if _Foo
were a subclass of base (apart from some introspection methods and
edge cases). *You can see that this is so if you look at the MRO:

Foo, _Foo, Base, object

Which is the same MRO that would occur if _Foo derived from Base
directly.

The drawback (which is also a drawback to the hypothetical base
reassignment) is that Foo's __init__ method won't call Base's. *The
only way you can make SWIG __init__ call it's superclass's __init__ is
apparently a patch.

Carl Banks

Thanks. Looks like I will just write a patch step and hook it into the
makefile.

[Adam C.]

On Jul 7, 10:44*pm, Michele Simionato <michele.simion [e-mail]>
wrote:

On Jul 7, 8:08*pm, "Adam C." <adam...@gmail. comwrote:

Thanks. I think we would want new-style classes, and 6-year-old
patches strike me as maybe a little out of the desired path... so this
really just doesn't work in modern Python?

Can you use (multiple) inheritance instead of changing the bases?
Alternatively, try using an old-style class, changing the bases
and subclassing it inheriting from object too:

class NewStyle(OldSty le, object):
* pass

Definitely don't want old-style classes. We could probably use
multiple inheritance, but it feels like a horrible hack to me; I'd
just go with duck typing and alternate implementations over that.