qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 6/8] iotests: Test driver whitelisting in 093


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v3 6/8] iotests: Test driver whitelisting in 093
Date: Tue, 17 Sep 2019 16:05:36 +0200
User-agent: Mutt/1.12.1 (2019-06-15)

Am 17.09.2019 um 15:44 hat John Snow geschrieben:
> 
> 
> On 9/17/19 9:42 AM, Kevin Wolf wrote:
> > Am 17.09.2019 um 15:09 hat John Snow geschrieben:
> >> On 9/17/19 7:22 AM, Kevin Wolf wrote:
> >>> Am 17.09.2019 um 13:07 hat Max Reitz geschrieben:
> >>>> On 17.09.19 10:40, Kevin Wolf wrote:
> >>>>> Am 17.09.2019 um 10:18 hat Max Reitz geschrieben:
> >>>>>> On 13.09.19 20:30, John Snow wrote:
> >>>>>>> I'd still like to define func_wrapper with a nod to the type 
> >>>>>>> constraint
> >>>>>>> it has:
> >>>>>>>
> >>>>>>> def func_wrapper(instance: iotests.QMPTestCase, *args, **kwargs):
> >>>>>>>     [...]
> >>>>>>>
> >>>>>>>
> >>>>>>> Then, you'd write:
> >>>>>>>
> >>>>>>> if callable(required_formats):
> >>>>>>>     fmts = required_formats(instance)
> >>>>>>> else:
> >>>>>>>     fmts = required_formats
> >>>>>>
> >>>>>> Yep, that anyway.  (Although I didn’t know about the “param: type”
> >>>>>> syntax and put that constraint in a comment instead.  Thanks again :-))
> >>>>>
> >>>>> Note that function annotations are Python 3 only, so we can't use that
> >>>>> syntax yet anyway. If you want to use type hints that are understood by
> >>>>> tools (like mypy) and compatible with Python 2, you have to use
> >>>>> something like this (feel free to be more specific than Any):
> >>>>
> >>>> Do we really feel like staying compatible with Python 2, though?
> >>>
> >>> Feel like it? No.
> >>>
> >>> It's more that we are compelled to do so because we only deprecated it
> >>> in 4.1.
> >>
> >> Sorry for the impromptu lesson on type hints in 3.5! I added that in to
> >> my suggestion as a demonstrative example and didn't mean for you to use
> >> it as-is, sorry for not making that clear.
> >>
> >> I'm confused about the Python3 deprecation timeline. Normally we'd
> >> follow our standard approach, but it does hit EOL at the end of this
> >> year, so do we drop support then, too? I have the memory of a goldfish I
> >> suppose, and can't quite remember our conclusions, if any, of previous
> >> discussions on this subject.
> > 
> > It shouldn't make a difference actually because deprecation in 4.1 means
> > that 4.2 (in December) will be the last release that must still support
> > Python 2, and we can switch to Python 3 for 5.0.
> > 
> >> If we do drop python2 though, the new minimum version appears to be 3.5
> >> because that's what ships in EPEL. That'd give us standardized type
> >> hints that we can use for static analysis tools.
> > 
> > Actually I seem to remember I suggested that we should make 3.5 the
> > minimum Python 3 version, and I thought a patch to this effect had been
> > merged, but now I can't find any such check in configure. Maybe I should
> > find the old thread again to see if there was any reason not to do this.
> > 
> > Personally, I would have preferred 3.6 because it brings in variable
> > annotations, but I think last time the conclusion was that it would be
> > 3.5 indeed.
> > 
> 
> And with variable annotations you get data classes too, I believe, which
> are quite handy.

I didn't know these. Looks convenient, only in 3.7, though. We might be
there in five years.

Kevin



reply via email to

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