search

ipython / ipython_genutils

Vestigial IPython utilities: DO NOT USE
Other
11 stars 22 forks source link

IronPython is neither fish nor fowl #5

Closed swn1 closed 8 years ago

swn1 commented 8 years ago

I am beating my head against the jupyter-in-IronPython brick wall. I've reached the point where jupyter_client is trying to json-encode a connection file and it's erroring out because bytes_to_str is a no-op.

IronPython 2.7.5 is almost exactly python 2.7 but one of the "almost" things is that str is unicode, to match the .NET type system. So for purposes of the unicode stuff in py3compat it is more like python 3 than 2.

I'm not at all sure how best to hack around this, if anybody more familiar with this code than I would like to make a suggestion I'm all ears. Failing that I'll submit something when I figure it out.

takluyver commented 8 years ago

I don't think we want it merged in, because if they're using the Python 3 model, it's not really the semantics of Python 2, but feel free to change it locally to use the Python 3 unicode handling on Python 2.

swn1 commented 8 years ago

If I am able to get the whole chain working some change somewhere will have to be made to bridge this gap. Are you saying the right place to bridge it would be outside ipython_genutils? jupyter_client/connect.py imports bytes_to_str explicitly from genutils and invokes it explicitly, so I'd either have to modify that code or change the (effective) import target, or maybe monkey patch it.

I will pull a fork and see where it ends up, if I can make a nice clean patch I'll run it by you again.

takluyver commented 8 years ago

I guess that if there's a clean way to detect IronPython, probably the cleanest way is to do that in py3compat. Still annoying, though.

takluyver commented 8 years ago

And I'm not sure how it works, because we're hoping not to have to make any more releases of this package - but there's no obvious alternative place for things like bytes_to_str, which is why this package exists. @minrk ?

swn1 commented 8 years ago

If I am successful in getting at least the client side of the jupyter protocol working there will be a need for a coordinated release with a few small patches in several repos. If I'm not successful it's moot, so we can all wait and see.

minrk commented 8 years ago

If bytes_to_str should have a different definition on IronPython, we can handle that in genutils while it still exists. In general, we want to wean most projects off of genutils to tools like six, etc., so that can be an avenue, depending on the nature of the fixes required.

I'm a bit surprised this is coming up now, because we've had this code for a few years, at least, and it's used in plain terminal IPython for all that time, as well. I guess nobody has tried to use IPython in IronPython in the past several years?

swn1 commented 8 years ago

Speaking for myself, it seemed that IronPython had become a zombie for quite a while. Recently interest has picked back up. I have a commercial need to get this working but it's pretty hard. There are three C# bindings for zmq, none of which expose either the pymq API or the "backend" interface that the pymq binding factors out. And while cffi is documented as having been designed to admit an IronPython implementation I've found no evidence it ever happened. Directly binding to a C library from IronPython is doable but primitive, tricky to get right for one call and impractical for a broad library API.

Frustratingly, the jupyter_client code uses bytes_to_str and str_to_bytes in one place and at least two other platform abstraction mechanisms for the same operation pair in other places. It's a soup sandwich.

I do not yet have it all working end-to-end but this particular patch strikes me as ready to merge, I'll submit a PR.