qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH v3 6/8] iotests: Test driver whitel


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v3 6/8] iotests: Test driver whitelisting in 093
Date: Tue, 17 Sep 2019 09:44:24 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


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.

Oh well.

I have a patch that replaces the configure checks, but there are a few
places in docker and the EDK2 build where we require python2 still, so I
have a few threads to chase down before proposing a patch.

Stay tuned, I guess.

--js



reply via email to

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