Tristan Croll added the comment:
I've cross-posted the following to the SWIG bug tracker. Hopefully someone can
find an answer, because I'm getting nowhere.
If I have two classes Foo and Bar (where Bar has a function get_foo() that
returns a Foo object) defined in the SWIG-generat
Tristan Croll added the comment:
I don't agree that it should be closed yet. I still have the issue that an
approach that was perfectly legal in Python 3.5 now no longer works in Python
3.6, and I don't know why. The description in msg289281 stands, and is a real
problem. Nothing h
Tristan Croll added the comment:
Sorry - ignore that. Brain-fart at the end of a (very) long day.
--
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue29
Tristan Croll added the comment:
Nope - belay that. Checking through the SWIG-generated Python code, all the
classes correctly inherit from object, which negates that issue.
--
___
Python tracker
<http://bugs.python.org/issue29
Tristan Croll added the comment:
OK, this seems to narrow down the problem. The following was legal in Python
3.5.1, but in 3.5.3 and 3.6.1rc1 returns:
'TypeError: must be type, not classobj'
class Foo_Base:
pass
class Bar_Base:
def get_foo(self):
f
Tristan Croll added the comment:
OK, a further clue. First, a little more detail on how my project is arranged
(to re-iterate, this works without complaint in Python 3.5):
Rather than use my SWIG output directly, I've created a further wrapper layer
in Python to add functions/syntactic
New submission from Tristan Croll:
Possibly related to http://bugs.python.org/issue29327 - yields the same error
message:
Objects/tupleobject.c:81: bad argument to internal function
I have a large SWIG project which was previously working well in Python 3.5.
After migrating to Python 3.6.0
