On 10 June 2016 at 16:36, Neil Schemenauer <n...@python.ca> wrote: > Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
