[Python-Dev] Smoothing the transition from Python 2 to 3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Jun 15 14:55:34 EDT 2016
- Previous message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Next message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Next message (by thread): [Python-Dev] Smoothing the transition from Python 2 to 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]