Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Kevin Wolf]

Am 14.02.2023 um 21:52 hat Paolo Bonzini geschrieben:
> Il mar 14 feb 2023, 18:26 Kevin Wolf <kwolf@redhat.com> ha scritto:
> 
> > Am 14.02.2023 um 15:03 hat Paolo Bonzini geschrieben:
> > > In the case of Python the issue is not the interpreter per se, though
> > > there are a couple new feature in Python 3.7 that are quite nice (for
> > > example improved data classes[1] or context variables[2]). The main
> > > problem as far as I understood (and have seen in my experience) is
> > > linting tools. New versions fix bugs that caused false positives, but
> > > also become more strict at the same time. The newer versions at the
> > > same time are very quick at dropping support for old versions of
> > > Python; while older versions sometimes throw deprecation warnings on
> > > new versions of Python. This makes it very hard to support a single
> > > version of, say, mypy that works on all versions from RHEL8 and SLE15
> > > to Fedora 38 and Ubuntu 23.04.
> >
> > Why do we have to support a single version of mypy? What is wrong with
> > running an old mypy version with old Python version, and a newer mypy
> > with newer Python versions?
> >
> > Sure, they will complain about different things, but it doesn't feel
> > that different from supporting multiple C compilers in various versions.
> >
> 
> It's more like having to support only C++03 on RHEL 8 and only C++20 in
> Fedora 37, without even being able to use a preprocessor.
> 
> For example old versions might not understand some type annotations and
> will fail mypy altogether, therefore even with newer versions you can't
> annotate the whole source and have to fall back to non-strict mode.

Sure, using old versions restricts which features can be used. But I
suppose C++03 is (for the most part) a subset of C++20, and annotations
understood by old mypy are a subset of annotation understood by new
mypy? Which would make it something for the "shiny new feature"
department.

Don't get me wrong, I was among the first people advocating for using
mypy and I still think any improvement in type checking is something we
should take when we can. But while it may a very desirable new feature,
it still is one.

So I assume the real problem sits somewhere else? Or do we get lots of
places where new mypy requires something that old mypy complains about
and vice versa?

Kevin