[Ironpython-users] porting things to ironpython
Pawel Jasinski
pawel.jasinski at gmail.com
Sun Jan 19 12:14:22 CET 2014
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.
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) {
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.
--pawel
More information about the Ironpython-users
mailing list