[Python-Dev] PEP 414

[Vinay Sajip]

Terry Reedy <tjreedy <at> udel.edu> writes:

> > An installation hook means that you need to install the package
> > before running the tests.  Which is fine for CI but horrible during
> > development.  "python3 run-tests.py" beats "make venv; install
> > library; run testsuite" anytime in terms of development speed.
> 
> That I can appreciate. It makes programming more fun. I presume you are 
> saying that you would run the 'Python 3' tests quickly with 3.3 in your 
> normal development cycle. Then, if you want your library to also run 
> under 3.1/2, only occasionally (daily?) check that they also run under a 
> 3.1/2 installation. That *does* make sense to me.

Right, but Armin, while arguing against an installation hook for 2to3, is ISTM
arguing for an analogous hook for use with 3.2 (and earlier 3.x), which does a
smaller amount of work than 2to3 but is the same kind of beast.

The "programming fun" part is really an argument about a single codebase, which
I am completely in agreement with. But (summarising for my own benefit, but
someone please tell me if I've missed or misunderstood something) there are (at
least) three ways to get there:

1. Support only 2.6+ code, use from __future__ import unicode_literals, do away
with u'xxx' in favour of 'xxx'. This has been opposed because of
action-at-a-distance, but can be mitigated by strongly applied discipline on a
given project (so that everyone knows that all string literals are Unicode,
period). Of course, the same discipline needs to be applied to depended-upon
projects, too.

2. Support 2.5 or earlier, where you would have to use u('xxx') in place of
u'xxx', unless PEP 414 is accepted - but you would still have the exception
syntax hacks to upset you. This has been opposed because of performance and
productivity concerns, but I don't think these are yet proven in practice (for
performance, microbenchmarks notwithstanding - there's no data on more
representative workloads. For productivity I call shenanigans, since if we can
trust 2to3 to work automatically, we should be able to trust a 2to3 fixer to do
the work on u'xxx' -> u('xxx') or u('xxx') -> 'xxx' automatically).

3. Do one of the above, but approve this PEP and keep u'xxx' literals around for
some yet-to-be-determined time, but perhaps the life of Python 3. This has been
called a retrograde step, and one can see why; ISTM the main reason for
accepting this path is that some fairly vocal and respected developers don't
want to (as opposed to can't) take one of the other paths, and are basically
saying they're not porting their work to 3.x unless this path is taken. They're
saying between the lines that their views are representative of a fair number of
other less vocal developers, who are also not porting their code for the same
reason. (ISTM they're glossing over the other issues which come up in a 2.x ->
3.x port, which require more time to diagnose and fix than problems caused by
string literals.) But never mind that - if we're worried about the pace of the
2.x -> 3.x transition, we can appease these views fairly easily, so why not do
it? And while we're at it, we can perhaps also look at those pesky exception
clauses and see if we can't get 3.x to support 2.x exception syntax, to make
that porting job even easier ;-)

Regards,

Vinay Sajip