qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	tamiko@43-1.org, qemu-devel@nongnu.org, arfrever.fta@gmail.com
Subject: Re: [Qemu-devel] [PATCH v4 1/2] qapi: Open files with encoding='utf-8'
Date: Tue, 19 Jun 2018 13:05:10 +0100	[thread overview]
Message-ID: <20180619120510.GS20929@redhat.com> (raw)
In-Reply-To: <20180619105032.GO7451@localhost.localdomain>

On Tue, Jun 19, 2018 at 07:50:32AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 19, 2018 at 08:28:08AM +0200, Markus Armbruster wrote:
> > Eduardo Habkost <ehabkost@redhat.com> writes:
> > 
> > > On Mon, Jun 18, 2018 at 07:59:57PM +0200, Markus Armbruster wrote:
> > >> Python 2 happily reads UTF-8 files in text mode, but Python 3 requires
> > >> either UTF-8 locale or an explicit encoding passed to open().  Commit
> > >> d4e5ec877ca fixed this by setting the en_US.UTF-8 locale.  Falls apart
> > >> when the locale isn't be available.
> > >> 
> > >> Matthias Maier and Arfrever Frehtes Taifersar Arahesis proposed to use
> > >> binary mode instead, with manual conversion from bytes to str.  Works,
> > >> but opening with an explicit encoding is simpler, so do that.
> > >> 
> > >> Since Python 2's open() doesn't support the encoding parameter, we
> > >> need to suppress it with a version check.
> > >> 
> > >> Reported-by: Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com>
> > >> Reported-by: Matthias Maier <tamiko@43-1.org>
> > >> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> > >> ---
> > >>  scripts/qapi/common.py | 17 ++++++++++++++---
> > >>  1 file changed, 14 insertions(+), 3 deletions(-)
> > >> 
> > >> diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
> > >> index 2462fc0291..832f11438a 100644
> > >> --- a/scripts/qapi/common.py
> > >> +++ b/scripts/qapi/common.py
> > >> @@ -16,6 +16,7 @@ import errno
> > >>  import os
> > >>  import re
> > >>  import string
> > >> +import sys
> > >>  from collections import OrderedDict
> > >>  
> > >>  builtin_types = {
> > >> @@ -340,7 +341,10 @@ class QAPISchemaParser(object):
> > >>              return None
> > >>  
> > >>          try:
> > >> -            fobj = open(incl_fname, 'r')
> > >> +            if sys.version_info[0] >= 3:
> > >> +                fobj = open(incl_fname, 'r', encoding='utf-8')
> > >> +            else:
> > >> +                fobj = open(incl_fname, 'r')
> > >
> > > I dislike the Python version check, but getting rid of it would
> > > require rewriting the QAPI modules to not use the Python 2 str
> > > type (that has different semantics from Python 3 str type).
> > 
> > The version check is ugly, but it has a property I rather like: when we
> > drop support for Python 2, the conditional becomes True, and partial
> > evaluation results in the Python 3 code we actually want.
> > 
> > > The python-future package would help us write code for a single
> > > file/string API instead of two different APIs, but it's not a
> > > QEMU build dependency (yet?), so this patch is good enough for
> > > now.
> > 
> > Please do not invest more than absolutely necessary in Python 2 support.
> > All such investment will turn into technical debt in less than two
> > years.  If you must invest, pick a solution that will result in less
> > technical debt.  We can accept local ugliness for that.
> > 
> > In my personal opinion, dumb ideas like supporting Python 2 this close
> > to its EOL ought to look ugly.
> 
> That's the whole point: python-future allows us to not worry
> about Python 2 support in the code anymore because it exposes the
> Python 3 string API (and others) even if we're running Python 2.
> 
> After we stop supporting Python 2, we can simply delete the "from
> __future__ import .*" and "from builtins import .*" lines.
> 
> Anyway, I will send a RFC series demonstrating that, and then we
> can discuss if it's worth it.  My main worry is not the extra
> imports in Python code, but the introduction of a new build
> dependency only for a few (one?) releases.

Using __future__ doesn't add an build dependancy AFAIK. __future__ is
bundled with core python library rather than being an addon module.

> > > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > > Acked-by: Eduardo Habkost <ehabkost@redhat.com>
> > 
> > Uh, what does "Acked-by" add over "Reviewed-by"?
> 
> It was supposed to indicate that I agree it can be merged through
> other maintainers.  But it looks like this is not part of the
> original definition of "Acked-by"?

Yeah that's what I always thought it meant too.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  parent reply	other threads:[~2018-06-19 12:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 17:59 [Qemu-devel] [PATCH v4 0/2] Fix compilation with python-3 if en_US.UTF-8 is unavailable Markus Armbruster
2018-06-18 17:59 ` [Qemu-devel] [PATCH v4 1/2] qapi: Open files with encoding='utf-8' Markus Armbruster
2018-06-18 21:35   ` Eduardo Habkost
2018-06-19  6:28     ` Markus Armbruster
2018-06-19 10:50       ` Eduardo Habkost
2018-06-19 11:52         ` Markus Armbruster
2018-06-19 12:05         ` Daniel P. Berrangé [this message]
2018-06-19 13:06           ` Eduardo Habkost
2018-06-19 11:02   ` Eric Blake
2018-06-18 17:59 ` [Qemu-devel] [PATCH v4 2/2] Revert commit d4e5ec877ca Markus Armbruster
2018-06-18 21:35   ` Eduardo Habkost
2018-06-19 11:03   ` Eric Blake
2018-06-19 11:46     ` Markus Armbruster
2018-06-19 11:59   ` Markus Armbruster

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=20180619120510.GS20929@redhat.com \
    --to=berrange@redhat.com \
    --cc=arfrever.fta@gmail.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tamiko@43-1.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).