xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: Python 3 bindings
Date: Fri, 17 Feb 2017 13:36:01 +0100	[thread overview]
Message-ID: <20170217123601.GF12171@mail-itl> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1962 bytes --]

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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

             reply	other threads:[~2017-02-17 12:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 12:36 Marek Marczykowski-Górecki [this message]
2017-02-20 17:18 ` Python 3 bindings Wei Liu
2017-02-21 13:03   ` Marek Marczykowski-Górecki
2017-02-22 11:34     ` Wei Liu
2017-02-22 11:52       ` Marek Marczykowski-Górecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170217123601.GF12171@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).