> On Oct 15, 2018, at 5:00 PM, Monty Taylor <mord...@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 <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.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to