[Ironpython-users] porting things to ironpython

Jeff Hardy jdhardy at gmail.com
Mon Jan 20 09:50:53 CET 2014


On Sun, Jan 19, 2014 at 11:14 AM, Pawel Jasinski
<pawel.jasinski at 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


More information about the Ironpython-users mailing list