[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.
- Re: Python 3.5 EOL; when can require 3.6?, (continued)
Re: Python 3.5 EOL; when can require 3.6?, Daniel P . Berrangé, 2020/09/16
Re: Python 3.5 EOL; when can require 3.6?, Peter Maydell, 2020/09/16
- Re: Python 3.5 EOL; when can require 3.6?,
Markus Armbruster <=
- Re: Python 3.5 EOL; when can require 3.6?, Thomas Huth, 2020/09/16
- Re: Python 3.5 EOL; when can require 3.6?, Daniel P . Berrangé, 2020/09/16
- Re: Python 3.5 EOL; when can require 3.6?, John Snow, 2020/09/16
- Re: Python 3.5 EOL; when can require 3.6?, Thomas Huth, 2020/09/17
- Re: Python 3.5 EOL; when can require 3.6?, Daniel P . Berrangé, 2020/09/17
- Re: Python 3.5 EOL; when can require 3.6?, Thomas Huth, 2020/09/17
- Re: Python 3.5 EOL; when can require 3.6?, Daniel P . Berrangé, 2020/09/17
- Re: Python 3.5 EOL; when can require 3.6?, Thomas Huth, 2020/09/17
Re: Python 3.5 EOL; when can require 3.6?, Markus Armbruster, 2020/09/17
Re: Python 3.5 EOL; when can require 3.6?, Thomas Huth, 2020/09/17