undefined | Better HN

0 pointsmikepurvis6y ago0 comments

The author's suggestion of permitting a certain set of "from __past__" imports seems especially astute. This would have made it much more possible much earlier to have a single large codebase running natively on the Python 3 interpreter, but with modules (especially leaf modules) at varying degrees of ported-ness.

In contrast, the original porting guidance for module authors was actually to maintain the Python 2 source as the master copy, and use 2to3 to transform it for running tests or cutting a Python 3 release. How is a transition ever supposed to happen if the new hotness is perpetually a second class citizen?

0 comments

2 comments · 1 top-level

masklinn6y ago· 1 in thread

> The author's suggestion of permitting a certain set of "from __past__" imports seems especially astute.

Hell that's essentially what ended up happening over time, as past features got reintroduced (the `u` prefix, bytes.__mod__, `callable` being reintroduced, `range` being improved, …), as well as the serious Python3-ification of the Python2 branch that was 2.7.

mikepurvisOP6y ago

I feel like "from __past__" would have allowed projects to get to the point where they were "on Python 3" much sooner, though.

The mentality would have been "we're on Python 3, and we have a long tail of cleanup to do excising from-past out of our codebase" rather than "we and our users are all still on Python 2 but we thiiiiink our code is mostly using constructs that are Python 3 safe. We get a green CI checkmark, anyway, but who really knows."

j / k navigate · click thread line to collapse