[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Python 3 bindings
Hi, I'm adjusting python bindings to work on python3 too. This will require few #if in the code (to compile for both python2 and python3), but it isn't that bad. But there are some major changes in python3, which require some decision about the bindings API: 1. Python3 has no longer separate 'int' and 'long' type - old 'long' type was renamed to 'int' (but on C-API level, it uses PyLong_*). I see two options: - switch to PyLong_* everywhere, including python2 bindings - this makes the code much cleaner, but it is an API change in python2 - switch to PyLong_* only for python3 - this will introduce some #ifdefs, but python2 API will be unchanged 2. Python3 has no longer separate 'str' and 'unicode' type, new 'str' is the same as 'unicode' (PyUnicode_* at C-API level). For things not really unicode-aware, 'bytes' type should be used. On the other hand, in python2 'bytes' type was the same as 'str'. This affects various places, where in most cases 'bytes' type is appropriate (for example cpuid). But I'm not sure about xenstore paths - those should also be 'bytes', or maybe 'unicode' (which is implicitly using 'utf-8' encoding)? I think the only reason to use 'unicode' is convenience for API users - in python3 if you write 'some string' it will be unicode type, to create bytes data you need to write b'some string'. As for python2, it should definitely be still 'str'/'bytes' type. There is one more little detail - build process. Here I'm going to follow popular standard - use $(PYTHON) variable - if that points to python3, build for python3. Actually this means no change in the current makefile. If someone want to build for both python2 and python3, will need to call the build twice - at packaging level. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our