[issue29758] Previously-working SWIG code fails in Python 3.6

Brett Cannon added the comment: Please keep this issue closed until you hear back from the SWIG team. Just because your code worked under Python 3.5 doesn't mean SWIG didn't accidentally emit something that breaks under Python 3.6 because we started being more stringent about something. Basica

[issue29758] Previously-working SWIG code fails in Python 3.6

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-generated library fo

[issue29758] Previously-working SWIG code fails in Python 3.6

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 has changed i

[issue29758] Previously-working SWIG code fails in Python 3.6

Brett Cannon added the comment: Since it sounds like everything on the Python side is fine I'm closing this. -- nosy: +brett.cannon resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue29758] Previously-working SWIG code fails in Python 3.6

Tristan Croll added the comment: Sorry - ignore that. Brain-fart at the end of a (very) long day. -- versions: -Python 3.5 ___ Python tracker ___ ___

[issue29758] Previously-working SWIG code fails in Python 3.6

STINNER Victor added the comment: "Nope - belay that. Checking through the SWIG-generated Python code, all the classes correctly inherit from object, which negates that issue." I don't understand your comment, on Python 3, any class inherit from object be default. There is no more old and new

[issue29758] Previously-working SWIG code fails in Python 3.6

STINNER Victor added the comment: The code in msg289314 doesn't emit any warning. I tested 3.5, 3.6 and master development branches and system Python 3.5.2. -- ___ Python tracker __

[issue29758] Previously-working SWIG code fails in Python 3.6

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 _

[issue29758] Previously-working SWIG code fails in Python 3.6

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 = Foo_Base() return

[issue29758] Previously-working SWIG code fails in Python 3.6

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 sugar t

[issue29758] Previously-working SWIG code fails in Python 3.6

STINNER Victor added the comment: Which function raises this exception? Add the traceback place. It may be a bug in your code. -- ___ Python tracker ___ _

[issue29758] Previously-working SWIG code fails in Python 3.6

Changes by Xiang Zhang : -- nosy: +haypo, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue29758] Previously-working SWIG code fails in Python 3.6

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, I