[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] qapi: Fix code generation with Python 3.5

From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
Date: Sat, 18 Jan 2020 09:29:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 1/17/20 8:41 PM, John Snow wrote:
On 1/17/20 2:07 AM, Markus Armbruster wrote:
John Snow <address@hidden> writes:

On 1/16/20 3:25 PM, Markus Armbruster wrote:
Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules"
modules" switched QAPISchema.visit() from

     for entity in self._entity_list:

effectively to

     for mod in self._module_dict.values():
         for entity in mod._entity_list:

Visits in the same order as long as .values() is in insertion order.
That's the case only for Python 3.6 and later.  Before, it's in some
arbitrary order, which results in broken generated code.

Fix by making self._module_dict an OrderedDict rather than a dict.

Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c
Signed-off-by: Markus Armbruster <address@hidden>
  scripts/qapi/schema.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
index 0bfc5256fb..5100110fa2 100644
--- a/scripts/qapi/schema.py
+++ b/scripts/qapi/schema.py
@@ -795,7 +795,7 @@ class QAPISchema(object):
          self.docs = parser.docs
          self._entity_list = []
          self._entity_dict = {}
-        self._module_dict = {}
+        self._module_dict = OrderedDict()
          self._schema_dir = os.path.dirname(fname)
          self._make_module(None) # built-ins

This problem has bitten me *many* times. I'm wondering if there's a
prescription that isn't just "Wait until we can stipulate 3.6+".

No clue.

3.5 EOL is scheduled for 2020-09-13.

We support 3.5 because we support Debian 9.

We'd normally drop support for Debian 9 two years after Debian 10,
i.e. July 2021.  Assuming Debian supports it that far.  Whether they can
truly support Python 3.5 after uptstream EOL seems doubtful.

We should decide whether we consider Debian LTS to be adequately
supported, yes-or-no.

We should use a rule of "two years after successor, or End-of-Support,
whichever comes first."

For Debian, is end of support three years after it comes out, or is it
when the LTS is EOL?

In this specific case, do we trust that Debian 9 LTS will continue to
patch Python3.5 all the way up until July 2021?

This broke 29 of the 32 Travis jobs we have:


Since we started to use Travis CI, it catched quite some bugs...

I think it is important to add in the equation we also depend of our CIs.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]