All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.