All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Cleber Rosa <crosa@redhat.com>, John Snow <jsnow@redhat.com>
Subject: Re: Python 3.5 EOL; when can require 3.6?
Date: Wed, 16 Sep 2020 15:30:01 +0200	[thread overview]
Message-ID: <878sd9luhy.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA8q8J1n2UqsNbHgNwEedA8pZ6fNA7obCR1REN-33nvmkg@mail.gmail.com> (Peter Maydell's message of "Wed, 16 Sep 2020 13:30:49 +0100")

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>> We require Python 3.5.  It will reach its "end of life" at the end of
>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>> already does for its Python parts.
>
> I think these things really ought to start with the converse question:
> what is the important new thing that 3.6 brings to the table that
> makes it worth moving our minimum requirement forward ?

I'm chiefly after PEP 526 "Syntax for Variable Annotations" for much
saner type hints.  John's "[PATCH 00/37] qapi: static typing conversion
pt1" already uses it, because not using it results in illegible code.

Nice to have: PEP 498 "Literal String Interpolation" may let us improve
QAPI code geneator readability.  I haven't tried, yet.

<https://www.python.org/dev/peps/pep-0494/#features-for-3-6> has the
full list of new features.

> If our code still works on 3.5 and there's nothing we really want to
> do to the code that would be awkward to do without insisting on
> 3.6, why should we irritate users by arbitrarily bumping the version
> requirement ?
>
> Also as Dan notes upstream's EOL policies aren't very relevant,
> because our policy is based on what distros ship.
>
> My broader point of view: C does not have any kind of infrastructure
> like Rust's cargo or node's npm that makes it easy for a project to
> say "we depend on these versions of these other packages" and
> have them be satisified in a fairly painless-to-the-end-user/distro
> way. So I prefer to take the approach of being as conservative as
> possible about what we depend on, because the alternative tends
> to be either pain for the person trying to compile QEMU (when they
> have to scrabble around finding and building dependencies they
> don't have conveniently to hand) or pain for us (when we have
> to ship a dependency as a submodule). The default should be
> "leave the version dependency where it is", not "bump the version
> dependency as soon as we can".

Understood.

Anyone writing Python code in QEMU has paid a price for this policy.  I
certainly did.  I'm okay with that as long as it helps more than it
hurts.

Lack of sane type hints is hurting QAPI developement.

I believe requiring 3.6 will hurt QEMU less than hobbled QAPI
development.



  reply	other threads:[~2020-09-16 13:32 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  7:43 Python 3.5 EOL; when can require 3.6? Markus Armbruster
2020-09-16  7:53 ` Philippe Mathieu-Daudé
2020-09-16  8:02   ` Thomas Huth
2020-09-16  8:16     ` Philippe Mathieu-Daudé
2020-09-16 13:53     ` Alex Bennée
2020-09-16 13:57       ` Daniel P. Berrangé
2020-09-17 14:53         ` Eduardo Habkost
2020-09-16  8:22   ` Andrea Bolognani
2020-09-16 15:09   ` Eduardo Habkost
2020-09-16  7:54 ` Thomas Huth
2020-09-16  8:33   ` Daniel P. Berrangé
2020-09-16  9:50     ` Thomas Huth
2020-09-16  9:54       ` Daniel P. Berrangé
2020-09-16  9:55         ` Thomas Huth
2020-09-16  8:31 ` Daniel P. Berrangé
2020-09-16 12:30 ` Peter Maydell
2020-09-16 13:30   ` Markus Armbruster [this message]
2020-09-16 14:00   ` Thomas Huth
2020-09-16 14:05     ` Daniel P. Berrangé
2020-09-16 14:57     ` John Snow
2020-09-17 14:10     ` Thomas Huth
2020-09-17 14:55       ` Daniel P. Berrangé
2020-09-17 15:24         ` Thomas Huth
2020-09-17 15:39           ` Daniel P. Berrangé
2020-09-17 15:41             ` Thomas Huth
2020-09-17 15:30       ` Markus Armbruster
2020-09-17 15:39         ` Thomas Huth
2020-09-17 15:42         ` Warner Losh
2020-09-17 16:07         ` Andrea Bolognani
2020-09-17 16:35           ` Daniel P. Berrangé
2020-09-17 17:02             ` Andrea Bolognani
2020-09-17 16:19     ` Eduardo Habkost
2020-09-17 16:33       ` Daniel P. Berrangé
2020-09-17 16:50         ` Eduardo Habkost

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=878sd9luhy.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.