On Sun, Jan 19, 2014 at 11:14 AM, Pawel Jasinski <pawel.jasin...@gmail.com> wrote: > hi, > > I have been playing with some cpython packages and tried to get them > to work under ironpython. > Ironpython, similar to jython, is a hybrid with true unicode strings > (as it is defined in 3.x) and arguments and returned values of > standard library and build-ins conforming to 2.x. > > Modules I have tried, have already provisions for 2->3 transition, > which means, that most of the str/unicode/byte differences are already > figured out. > After some try and error, I have chosen to configure existing > compatibility layer to run in 3.x mode and patch api entry/exit > points. As far as I can tell it works but ... > it appears to bit a bit inefficient. > > For example, socket.send is a call where 2.x expects str and 3.x bytes. > In my case, buffer to be used for socket.send is being constructed > using bytes, unicodes are encoded as they are appended. In case of > ironpython 2.7, before send can be called, it has to be converted into > string: whatever_bytes.decode('latin-1') > I also explored use of buffer, but internally I can see it performs > redundant string conversion as well.
Yeah, it's kind of a hack to just make things work. > > How about we expose, in addition to existing 2.x, extra 3.x argument happy > api? > For socket.send, in addition to: > > public int send(string data, [DefaultParameterValue(0)] int flags) { > > we would have > > public int send(byte[] data, [DefaultParameterValue(0)] int flags) { This is a better option, and it's needed for 3.x anyway. > > The additional 3.x-isch api could be an activated using option. > > Another question, what is the plan for 3.x? As far as I can tell, > entire unicode/api problematic would be gone. Moving to 3.x is my major goal for the year. I've just finished moving to Ireland (and my Windows box is still on a boat somewhere) so I haven't had much time to work on it lately, but a couple of people have contacted me about how to help on IP 3, which should hopefully make things go faster. My own thoughts from last year are at http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html. Figuring out which "native" APIs need bytes and string versions would be a huge help. There's also some other changes I'd like to make, but I'll start a new thread for those. - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users