> 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.
Tim
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
