[Python-Dev] Python "2migr8"

[Eric Snow]

On Mon, Apr 14, 2014 at 9:32 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
[snip]
> The two important components of Python 2migr8 would be the ability to disable 2.7-only features, and to do so on a module-by-module basis.

This should be doable with an import hook.  For that matter it would
be pretty straight-forward to provide a script around the Python
binary that installs the import hook.  All this could be bundled up
and distributed through the cheeseshop.

-eric

>
> My best idea so far would be to have a magic comment (to ensure 2.7 compatibility better than a "from __future__ ...") near the top of the file that marks that file as "must straddle 2.7 and 3.3". Adding this comment causes (for example) the parser to treat "except x, y" as a syntax error in this file, forces "from __future__ import ...", hides "dict.iterkeys", undefines "basestring", etc., but only for this file. (I haven't thought through all the possibilities or implications - Eric Snow said he was going to sprint on this today/tomorrow, so he'll soon have a better idea just what can be done.)
>
> In effect, 2migr8 would be the version that *only* supports "single-source" files. This allows large code bases to progressively migrate modules from 2.x to single-source while continuing to run against Python 2.7. As files are updated, they are marked as being single-source. When all files have this marker, it should be possible to flip the switch and run with Python 3.3 or later.
>
> You could also think of this as enabling "-3 --warnings-as-errors" for individual modules, though since the user has already opted in to 2migr8, it isn't unreasonable to make more significant changes, like having dict.keys returning a list that warns if it is mutated. This sort of warning can only really be done by changing the interpreter - static analysis just can't catch everything - and only when users accept a potential performance hit and low probability of breakage when they move to 2migr8 (followed by a not-quite-as-low probability of breaking when they eventually move from 2migr8 to 3.x, but it's still better than guaranteed breakage).
>
> As a fork, it would also be possible to bundle the modules that have been backported, and possibly also to disallow importing deprecated stdlib modules when 2.7 functionality is disabled. As I said, I haven't thought through all the possibilities, but the general idea is to take 2.7 and *remove* features so it becomes easier to migrate.
[snip]
> I'm not pretending to have a full plan on how this will work. I was privileged to have some private conversations during PyCon that are directly relevant, so I'm bringing it here to promote the discussion. Thanks to everyone I had a chance to chat to, and to everyone generally for a great PyCon.