On Mon, Apr 14, 2014 at 9:32 AM, Steve Dower <steve.do...@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. _______________________________________________ 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
