Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
python3 str to std::string conversion is not automatic #2819
I have a python2 project where the pyx files contain the following directive:
In the process of converting to python3, I am finding that even with these directive, the conversion from a python3
In python3, this results in the following exception:
I have tested this behaviour both in cython 0.28.5 as well as master, using all available language level values.
My expected results would be that given the directives, any implicit assignment/conversion to
My current workaround in dealing with the ton of locations where a python string is assigned to a
This has been error prone since I keep overlooking hard to spot type conversions. It would be amazing for the behaviour in Cython to be updated to support automatic conversions based on my directives.
Just guessing, but it might be the setting of
Could you try changing
added a commit
Feb 3, 2019
On Fri, Feb 1, 2019 at 8:08 PM Stefan Behnel ***@***.***> wrote: Just guessing, but it might be the setting of __PYX_DEFAULT_STRING_ENCODING_IS_DEFAULT in the generated code. For the c_string_encoding names UTF-8/utf8/…, it should be true in Py3, where the default encoding is always utf8. Could you try changing __PYX_DEFAULT_STRING_ENCODING_IS_DEFAULT to 1 (it should be 0 now) in the generated C file and try that directly under Py3, without running Cython again?
Sorry for the delay. I've just tested this and it does seem to fix the problem. The python string to std::string happens automatically. Looking forward to seeing a patch release!…
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2819 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARPxubHW5XviStNGJ8yEWVGAo1GS7Isks5vI-figaJpZM4adT6x> .
I think it's on the edge. It sort-of falls into the "new feature" bucket, and I find it a bit difficult to decide whether it's safe to throw at users in a point release, since it changes the behaviour of existing code in a potentially unexpected way. There might be code out there that deals with this use case in its own way already, and I do not know what such code would do with the new auto-conversion.
I can see from my current approach of manually handling this problem that I am preventing the
If it's a 3.0.0 thing, then I just have to manually handle my dependency against a commit. My company is behind a proxy and we request local packaging from 3rd party releases that track a semver.