On Tue, Oct 16, 2018 at 10:58 AM Zane Bitter <zbit...@redhat.com> wrote:
> On 15/10/18 8:00 PM, Monty Taylor wrote: > > On 10/15/2018 06:39 PM, Zane Bitter wrote: > >> > >> In fact, as far as we know the version we have to support in CentOS > >> may actually be 3.5, which seems like a good reason to keep it working > >> for long enough that we can find out for sure one way or the other. > > > > I certainly hope this is not what ends up happening, but seeing as how I > > actually do not know - I agree, I cannot discount the possibility that > > such a thing would happen. > > I'm right there with ya. > > > That said - until such a time as we get to actually drop python2, I > > don't see it as an actual issue. The reason being - if we test with 2.7 > > and 3.7 - the things in 3.6 that would break 3.5 get gated by the > > existence of 2.7 for our codebase. > > > > Case in point- the instant 3.6 is our min, I'm going to start replacing > > every instance of: > > > > "foo {bar}".format(bar=bar) > > > > in any code I spend time in with: > > > > f"foo {bar}" > > > > It TOTALLY won't parse on 3.5 ... but it also won't parse on 2.7. > > > > 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. > > Yeah, that is a good point. There are only a couple of edge-case > scenarios where that might not prove to be the case. One is where we > install a different (or a different version of a) 3rd-party library on > py2 vs. py3. The other would be where you have some code like: > > if six.PY3: > some_std_lib_function_added_in_3_6() > else: > py2_code() > > It may well be that we can say this is niche enough that we don't care. > > In theory the same thing could happen between versions of python3 (e.g. > if we only tested on 3.5 & 3.7, and not 3.6). There certainly exist > places where we check the minor version.* However, that's so much less > likely again that it definitely seems negligible. > > * e.g. > > https://git.openstack.org/cgit/openstack/oslo.service/tree/oslo_service/service.py#n207 > > > The day we decide we can drop 2.7 - if we've been testing 3.7 for > > python3 and it turns out RHEL/CentOS 8 ship with python 3.5, then > > instead of just deleting all of the openstack-tox-py27 jobs, we'd > > probably just need to replace them with openstack-tox-py35 jobs, as that > > would be our new low-water mark. > > > > Now, maybe we'll get lucky and RHEL/CentOS 8 will be a future-looking > > release and will ship with python 3.7 AND so will the corresponding > > Ubuntu LTS - and we'll get to only care about one release of python for > > a minute. :) > > > > Come on - I can dream, right? > > Sure, but let's not get complacent - 3.8 is right around the corner :) > > Btw I confirmed this morning that the plan for 20.04 LTS is to have 3.8, so it really is around the corner. Thanks, Corey cheers, > Zane. > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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