[Python-Dev] Smoothing the transition from Python 2 to 3

[Nick Coghlan]

On 10 June 2016 at 16:36, Neil Schemenauer <neil at python.ca> wrote:
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> It could be very interesting to add an "ascii-warn" codec to Python
>> 2.7, and then set that as the default encoding when the -3 flag is
>> set.
>
> I don't think that can work.  The library code in Python would spew
> out warnings even in the cases when nothing is wrong with the
> application code.  I think warnings have to be added to a Python
> where str and bytes have been properly separated.  Without extreme
> backporting efforts, that means 3.x.
>
> We don't want to saddle 3.x with a bunch of backwards compatibility
> cruft.  Maybe some of my runtime warning changes could be merged
> using a command line flag to enable them.  It would be nice to have
> the stepping stone version just be normal 3.x with a command line
> option.  However, for the sanity of people maintaining 3.x, I think
> perhaps we don't want to do it.

Right, my initial negative reactions were mainly to the idea of having
these kinds of capabilities in the mainline 3.x codebase (where we'd
then have to support them for everyone, not just the folks that
genuinely need them to help in migration from Python 2).

The standard porting instructions currently assume code bases that are
*mostly* bytes/unicode clean, with perhaps a few oversights where
Python 3 rejects ambiguity that Python 2 tolerates. In that context,
"run your test suite, address the test failures" should generally be
sufficient, without needing to use a custom Python build.

However, there are a couple of cases those standard instructions still
don't cover:

- if there's no test suite, exploratory discovery is problematic when
the app falls over at the first type ambiguity
- even if there is a test suite, sufficiently pervasive type ambiguity
may make it difficult to use for fault isolation

That's where I now agree your proposal for a variant build
specifically aimed at compatibility testing is potentially
interesting:

- the tool would become an escalation path for folks that aren't in a
position to use their own test suite to isolate type ambiguity
problems under Python 3
- using Python 3 as a basis means you get a clean standard library
that shouldn't emit any false alarms
- the necessary feature set is defined by the common subset of Python
2.7 and a chosen minimum Python 3 version, not any future 3.x release,
so you should be able to maintain the changes as a stable patch set
without needing to chase CPython trunk (with the attendant risk of
merge conflicts)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia