From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: Python 3 bindings Date: Wed, 22 Feb 2017 12:52:21 +0100 Message-ID: <20170222115221.GS1146@mail-itl> References: <20170217123601.GF12171@mail-itl> <20170220171844.ifeumcygyk4hglb6@citrix.com> <20170221130300.GF1146@mail-itl> <20170222113416.rwt26rsxrftpi3ba@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4791308389465623271==" Return-path: In-Reply-To: <20170222113416.rwt26rsxrftpi3ba@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu Cc: Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org --===============4791308389465623271== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hSZb4FHl1C2xfsUy" Content-Disposition: inline --hSZb4FHl1C2xfsUy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2017 at 11:34:16AM +0000, Wei Liu wrote: > On Tue, Feb 21, 2017 at 02:03:00PM +0100, Marek Marczykowski-G=C3=B3recki= wrote: > > On Mon, Feb 20, 2017 at 05:18:44PM +0000, Wei Liu wrote: > > > On Fri, Feb 17, 2017 at 01:36:01PM +0100, Marek Marczykowski-G=C3=B3r= ecki wrote: > > > > Hi, > > > >=20 > > > > I'm adjusting python bindings to work on python3 too. This will req= uire > > > > 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: > > > >=20 > > > > 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 > > >=20 > > > Could you be more specific? Like, provide a code snippet? > >=20 > > Here is compile tested only version: > > https://github.com/marmarek/xen/tree/python3 > >=20 > > It uses PyLong_* only for python3, here is how it looks in code (I've > > skipped s/PyInt_/PyLongOrInt_/ for readability): > >=20 > > -----8<----- > > --- a/tools/python/xen/lowlevel/xc/xc.c > > +++ b/tools/python/xen/lowlevel/xc/xc.c > > @@ -34,6 +34,17 @@ > > =20 > > #define FLASK_CTX_LEN 1024 > > =20 > > +/* Python 2 compatibility */ > > +#if PY_VERSION_HEX >=3D 0x03000000 > > +#define PyLongOrInt_FromLong PyLong_FromLong > > +#define PyLongOrInt_Check PyLong_Check > > +#define PyLongOrInt_AsLong PyLong_AsLong > > +#else > > +#define PyLongOrInt_FromLong PyInt_FromLong > > +#define PyLongOrInt_Check PyInt_Check > > +#define PyLongOrInt_AsLong PyInt_AsLong > > +#endif > > + > > static PyObject *xc_error_obj, *zero; > > =20 > > typedef struct { > > --- a/tools/python/xen/lowlevel/xs/xs.c > > +++ b/tools/python/xen/lowlevel/xs/xs.c > > @@ -43,6 +43,14 @@ > > #define PKG "xen.lowlevel.xs" > > #define CLS "xs" > > =20 > > +#if PY_VERSION_HEX < 0x03000000 > > +/* Python 2 compatibility */ > > +#define PyLong_FromLong PyInt_FromLong > > +#undef PyLong_Check > > +#define PyLong_Check PyInt_Check > > +#define PyLong_AsLong PyInt_AsLong > > +#endif > > + > > static PyObject *xs_error; > > =20 >=20 > If this is the recommended practice, then that's fine. I can't seem to > find such practice in https://docs.python.org/3/howto/cporting.html but > I'm no python binding expert. "In the C-API, PyInt_* functions are replaced by their PyLong_* equivalents." > BTW, I went through your python3 branch. It seems that some patches can > be submitted independently. Yes, I've tried to separate cleanup commits from actual python3 support. > > /** Python wrapper round an xs handle. > > -----8<----- > >=20 > > >=20 > > > >=20 > > > > 2. Python3 has no longer separate 'str' and 'unicode' type, new 'st= r' is > > > > the same as 'unicode' (PyUnicode_* at C-API level). For things not > > > > really unicode-aware, 'bytes' type should be used. On the other han= d, 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 pa= ths - > > > > those should also be 'bytes', or maybe 'unicode' (which is implicit= ly > > > > using 'utf-8' encoding)? I think the only reason to use 'unicode' is > > >=20 > > > According to docs/txt/misc/xenstore.txt, paths should be ASCII > > > alphanumerics plus four punctuation characters. Not sure if this is > > > relevant to what you describe. > >=20 > > It's easy to make function accept both 'bytes' and 'unicode'. The > > question is what should be return type (read_watch, ls etc) - given > > limited character set used there, I'm in favor of 'unicode' - easier to > > handle, but we shouldn't hit any unicode decoding problems. > > Maybe the same should apply to path arguments (use 'unicode')? Most > > file-handling methods in python3 use 'unicode' for paths, if that > > matters. > >=20 >=20 > OK. Using unicode makes sense to me. Again, I'm no python expert and I > trust what you said. :-) Ok, I'll adjust patches to return unicode paths. Then test them and actually send here :) --=20 Best Regards, Marek Marczykowski-G=C3=B3recki 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? --hSZb4FHl1C2xfsUy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYrXt1AAoJENuP0xzK19csmikH/ArlJlo+H6KugrzsUVzA1nD0 hWXgWZv+xtkP/poG3P4yLf8wFl1zo9lBUMbGn6gyyraRgiV6g+5WVETWLADDW8DM 0ywJ5WNbnLAvB12hS2lltycjCFIIeeAWP+dAqKeR2JMsf9AFH2ocXhu9FSwnxqiB oQPD3j6Q5Zn1rZH6pWh70o8WF6IkS4m2N9o/rr6+J9bzJGAHZkskZyMTfcw/ylmV Oxmtx4Qi6qpc8vR/RY+L57IWPbehAJFQPdWxipsKXHuni9yiZ4Knak5pVwa4pJhB x0wBdn3Usx6ehlOqSwqBrQnjX+mirDcm3P4s4/TkShcWDt3dFbX50ZJ24mXqLho= =dA0t -----END PGP SIGNATURE----- --hSZb4FHl1C2xfsUy-- --===============4791308389465623271== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4791308389465623271==--