[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] A python bridge between versions
From:       Nick Coghlan <ncoghlan () gmail ! com>
Date:       2014-02-28 13:18:31
Message-ID: CADiSq7e2sU4xXv9tTcE4BhswwP3w_bBvxdjpSNYtURSxXr7M0A () mail ! gmail ! com
[Download RAW message or body]

On 28 February 2014 18:30, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Feb 28, 2014 at 5:03 PM, ian o <ian.team.python@gmail.com> wrote:
>> Yes it is not easy. Especially if you wish to make use of python2 modules
>> painless.
>
> It's fundamentally not going to be painless. You can either try to
> move the pain into the thunking module, or keep it in the application,
> but using a Py2 module is not painless. And I'm not sure it's even
> possible to move all the pain into the thunker - most Py2 code simply
> doesn't concern itself with the difference between text and bytes, so
> there's no automated way to create that difference. (And if the module
> already does care, then chances are it's easy to port it and
> officially support Py3, which will be far FAR easier than using the
> shim - way higher performance too.)
>
>> And I agree wholeheartedly that serious thought is needed on the 'could it
>> work so well that it actually slow the migration of library modules?'.
>>
>> This is an important debate to have.  I suggest if the answer to 'can a
>> specification be created that will significantly accelerate migration?',
>> then it is worth the effort to deliver this.
>>
>> But could it accelerate migration to python 3?
>
> At best, it'll accelerate migration of applications, while slowing
> migration of libraries.

And we don't actually mind all that much if applications don't migrate
in the near term - Python 2 will have commercial support available
well past 2020. (The developers of *those applications* might mind,
though, just as anyone maintaining Python 2.4 compatibility for the
benefit of RHEL/CentOS 5 typically isn't happy about it)

By far the path of least resistance if developers would like to write
Python 3 code, but are relying on some legacy Python 2 modules, is to
instead write "Python 3 like" code in Python 2. Most of the
interesting new Python 3 standard library modules (even asyncio) have
Python 2 backports available on PyPI, and python-future
(http://python-future.org/index.html) provides backports of the core
data types that otherwise don't have Python 2 counterparts.

This isn't *as* nice as actually running under Python 3 (you miss out
on exception chaining for one thing, as well as the improvements to
error messages in various parts of the standard library, and the
infrastructure work that has gone into improving the core
interpreter), but it's still a pretty nice environment to work in
(heck, Python 2.*6* is still a pretty nice language to work in,
although it definitely relies on more external library support than
3.x, or even 2.7).

The group we *do* really care about supporting is authors of existing
Python *libraries*, and "2in3" and "3in2" approaches don't really help
them at all, since library and framework authors with users on both
Python 2 and Python 3 will likely face demand to support both versions
natively anyway. That's where various Python 3 changes like restoring
Unicode string prefixes, restoring the binary transform codecs, and
(for 3.5 in 2015) likely restoring binary interpolation support come
in - by making the common subset of Python 2 and Python 3 larger, we
make it easier for library authors to support Python 3 without
breaking things for their existing Python 2 users.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]