qemu-devel
[Top][All Lists]
Advanced

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

Re: Python 3.5 EOL; when can require 3.6?


From: Markus Armbruster
Subject: Re: Python 3.5 EOL; when can require 3.6?
Date: Wed, 16 Sep 2020 15:30:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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 via email to

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