the Gravity of Python 2

[Chris Angelico]

On Tue, Jan 7, 2014 at 2:12 PM, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
> Doing a flag like that that enables a backwards incompatible change
> does in fact address that issue you were worried about originally, so
> that's something. And feature-by-feature moves are, like the OP said,
> still lower cost than a wholesale move.
>
> In the end a gradual transition can still be done with the polyglot
> approach, but I'm not happy that there's no way to enforce/test a
> polyglot conversion until it is complete. Any kind of granularity
> would have helped. :(

Yeah, feature-by-feature is possible; but it doesn't help with one of
the big (and common) complaints, that a library can't migrate without
the application migrating. The way I see it, polyglot coding should be
considered a superset of 2.7 coding, at which point there should
hopefully be some perceived value in boasting "Requires 2.7 *OR
3.3*!", and ideally that value should be greater than the cost of
supporting both. There are two ways to achieve that: Increase the
perceived value, and decrease the cost. Making 3.3 (or 3.4, or
whatever) look better is simply a matter of there being more
applications (or potential applications) written for that, and that's
going to be largely circular, and it's completely not in the hands of
Python development, so the focus has to be on decreasing the cost.

Hence the question: What are the breakages between 2.7 and 3.3, and
which ones can be solved per-module? If the solution to the breakage
has to be done per-application, that's a problem, even if it is
feature-by-feature. But stuff that can be changed per-module can
entirely eliminate the cost of polyglot code (for that feature), as
it'll simply be written in the Py3 way, with one little future
directive at the top.

ChrisA