On Sun, Aug 21, 2016 at 1:36 AM, Ian Henriksen <insertinterestingnamehere@gmail.com> wrote:

Remember - cython is "the way" that comes up for how to glue C/C++ into python these days, not just the program in cish python frontend for speed.

There's some truth to the issues you raise, but there are a lot of nasty details
behind the scenes. Do you have some more concrete details for what you're
proposing? In particular, Cython mangles all of its variable and function names.
How do you want to work around that? How should exception forwarding and
throwing work?

Recall I'm not one of the Cython devs :-) I think it is reasonable without knowing detail to the internals of Cython that if mangling must be done, there can be an opt-out specifier to the mangling done on cdef'd functions and variables. Variables are where the meat is at for me but there could be some benefit to functions as well if there's no reason they couldn't come along for the ride if they don't add significant complication.

I think for exception forwarding and throwing, the responsibility would lay to the wrapped code to guarantee either no thrown exceptions (you see this in multithreaded software all the time) or they must code the exception support in themselves. However easier user-handled translations patterns apply to make this a bit easier - set a cdef'd flag and a message and check that flag after the eval'd portion - then decode and possibly raise an exception.