[openstack-dev] [python3] Enabling py37 unit tests

Monty Taylor mordred at inaugust.com
Tue Oct 16 12:53:34 UTC 2018

On 10/15/2018 08:24 PM, Tim Burke wrote:
>> On Oct 15, 2018, at 5:00 PM, Monty Taylor <mordred at inaugust.com 
>> <mailto:mordred at inaugust.com>> wrote:
>> If we decide as a community to shift our testing of python3 to be 3.6 
>> - or even 3.7 - as long as we still are testing 2.7, I'd argue we're 
>> adequately covered for 3.5.
> That's not enough for me to be willing to declare support. I'll grant 
> that we'd catch the obvious SyntaxErrors, but that could be achieved 
> just as easily (and probably more cheaply, resource-wise) with multiple 
> linter jobs. The reason you want unit tests to actually run is to catch 
> the not-so-obvious bugs.
> For example: there are a bunch of places in Swift's proxy-server where 
> we get a JSON response from a backend server, loads() it up, and do some 
> work based on it. As I've been trying to get the proxy ported to py3, I 
> keep writing json.loads(rest.body.decode()). I'll sometimes get pushback 
> from reviewers saying this shouldn't be necessary, and then I need to 
> point out that while json.loads() is happy to accept either bytes or 
> unicode on both py27 and py36, bytes will cause a TypeError on py35. And 
> since https://bugs.python.org/issue17909 was termed an enhancement and 
> not a regression (I guess the contract is str-or-unicode, for whatever 
> str is?), I'm not expecting a backport.
> TLDR; if we want to say that something works, best to actually test that 
> it works. I might be willing to believe that py35 and py37 working 
> implies that py36 will work, but py27 -> py3x tells me little about 
> whether py3w works for any w < x.

Fair point - you've convinced me!

More information about the OpenStack-dev mailing list