Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Nick Coghlan]

On 13 December 2014 at 16:28, Chris Angelico  wrote:
> On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft  wrote:
>> First of all, it's essentially the route that Python itself took and the side
>> effects of that is essentially what is making things less-fun for me to write
>> Python. Doing the same to the users of the things I write would make me feel
>> bad that I was forcing them to either do all the work to port their stuff
>> (and any dependencies) just so they can use a newer version of my library.
>
> Ultimately, those programs WILL have to be migrated, or they will have
> to remain on an unsupported system. You have the choice of either
> continuing to do what you find un-fun (cross-compatibility code) until
> 2020 and maybe beyond, or stopping support for 2.7 sooner than that.
> All you're doing is changing *when* the inevitable migration happens.

One of the biggest blockers has been the lack of ready access to
Python 3 on RHEL & CentOS (just as a lot of folks waited until RHEL 7
and CentOS 7 were out before they started dropping Python 2.6
support). It's perfectly sensible for folks in that ecosystem to wait
for the appropriate tools to be provided at the platform layer to make
it easier for them to switch, but that unfortunately has consequences
for upstream library and framework developers who have to continue to
support those users.

The initial release of Software Collections (softwarecollections.org
and the associated Red Hat downstream product) was the first step in
providing easier access to Python 3 within the RHEL/CentOS ecosystem
(as far back as RHEL 6 and CentOS 6), and that approach is still our
long term preference for getting user applications out of the system
Python (so upstream isn't stuck supporting legacy Python versions for
years just because Red Hat is still supporting them for the base RHEL
platform). Unfortunately, the usage model for software collections is
sufficiently different from running directly in the system Python that
a lot of folks currently still prefer to stick with the system version
(and that's the case even for the much lower barrier of using the
Python 2.7 SCL instead of the system 2.6 installation on RHEL 6).

Containerisation is another technology that aims to make it easier to
run end user applications and services under newer language runtimes
without interfering with the system Python installation. As with
software collections, though, the environments that are reluctant to
upgrade to newer versions of Python also tend to be reluctant to
upgrade to newer deployment technologies, so it will take time for the
full impact of the shift to containerisation to make itself felt.

Finally, in addition to the existing work on getting Fedora 22 (due
mid next year) to only ship Python 3 on the LiveCD and other similarly
minimalist installations, Slavek (the lead Python maintainer for
Fedora & RHEL) is now also actively working on getting Python 3 into
EPEL 7: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

Between the work that is being done to migrate the platform layer in
the Fedora/RHEL/CentOS ecosystem, the work by Brett Cannon and others
to improve the tooling around lower risk Python 3 migrations, the
inclusion of pip in Python 2.7 to improve the availability of
migration tools and backported modules, and the return of printf-style
binary interpolation support in Python 3.5, several of the concrete
challenges that make migration harder than it needs to be are being
addressed.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Barry Warsaw]

On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:

>For what it’s worth, I almost exclusively write 2/3 compatible code (and
>that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so
>does make the language far less fun for me than when I was writing 2.x only
>code.

For myself, the way I'd put it is:

With the libraries I maintain, I generally write Python 2/3 compatible code,
targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses,
although I will not contort too much to support those older versions.  Doing
so does make the language far less fun for me than when I am writing 3.x only
code.  All applications I write in pure Python 3, targeting Python 3.4, unless
my dependencies are not all available in Python 3, or I haven't yet had the
cycles/resources to port to Python 3.  Writing and maintaining applications in
Python 2 is far less fun than doing so in Python 3.

Cheers,
-Barry
___
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Donald Stufft]

> On Dec 13, 2014, at 10:17 AM, Barry Warsaw  wrote:
> 
> On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
> 
>> For what it’s worth, I almost exclusively write 2/3 compatible code (and
>> that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so
>> does make the language far less fun for me than when I was writing 2.x only
>> code.
> 
> For myself, the way I'd put it is:
> 
> With the libraries I maintain, I generally write Python 2/3 compatible code,
> targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses,
> although I will not contort too much to support those older versions.  Doing
> so does make the language far less fun for me than when I am writing 3.x only
> code.  All applications I write in pure Python 3, targeting Python 3.4, unless
> my dependencies are not all available in Python 3, or I haven't yet had the
> cycles/resources to port to Python 3.  Writing and maintaining applications in
> Python 2 is far less fun than doing so in Python 3.
> 

Yea that’s not unlike me in that. I don’t write many applications where I have
a choice of runtime. Most of what I write tends to be libraries or applications
for work where we’re using 2.7 or pip itself where if we dropped 2.7 or 2.6
support people would be after us with pitchforks.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Steve Dower]

This is also my approach, and the one that I'm encouraging throughout Microsoft 
as we start putting out more Python packages for stuff.

Top-posted from my Windows Phone

From: Barry Warsaw
Sent: ‎12/‎13/‎2014 7:19
To: python-dev@python.org
Subject: Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:

>For what it’s worth, I almost exclusively write 2/3 compatible code (and
>that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so
>does make the language far less fun for me than when I was writing 2.x only
>code.

For myself, the way I'd put it is:

With the libraries I maintain, I generally write Python 2/3 compatible code,
targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses,
although I will not contort too much to support those older versions.  Doing
so does make the language far less fun for me than when I am writing 3.x only
code.  All applications I write in pure Python 3, targeting Python 3.4, unless
my dependencies are not all available in Python 3, or I haven't yet had the
cycles/resources to port to Python 3.  Writing and maintaining applications in
Python 2 is far less fun than doing so in Python 3.

Cheers,
-Barry
___
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/steve.dower%40microsoft.com
___
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[R. David Murray]

On Sat, 13 Dec 2014 10:17:59 -0500, Barry Warsaw  wrote:
> On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
> 
> >For what it’s worth, I almost exclusively write 2/3 compatible code (and
> >that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and 
> >doing so
> >does make the language far less fun for me than when I was writing 2.x only
> >code.
> 
> For myself, the way I'd put it is:
> 
> With the libraries I maintain, I generally write Python 2/3 compatible code,
> targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses,
> although I will not contort too much to support those older versions.  Doing
> so does make the language far less fun for me than when I am writing 3.x only
> code.  All applications I write in pure Python 3, targeting Python 3.4, unless
> my dependencies are not all available in Python 3, or I haven't yet had the
> cycles/resources to port to Python 3.  Writing and maintaining applications in
> Python 2 is far less fun than doing so in Python 3.

I think this is an important distinction.  The considerations are very
different for library maintainers than they are for application
maintainers.  Most of my work is in (customer) applications, and except
for one customer who insists on using an old version of RedHat, I've
been on "latest" python3 for those for quite a while now.  I suspect we
hear less here from people in that situation than would be proportional
to their absolute numbers.

--David
___
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

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Nick Coghlan]

On 13 Dec 2014 05:19, "Petr Viktorin"  wrote:
>
> Also keep in mind that not all Python libraries are on PyPI.
> For non-Python projects with Python bindings (think video players,
> OpenCV, systemd, Samba), distribution via PyPI doesn't make much
> sense. And since the Python bindings are usually second-class
> citizens, the porting doesn't have a high priority.
>
> If anyone is wondering why their favorite Linux distribution is stuck
> with Python 2 – well, I can only speak for Fedora, but nowadays most
> of what's left are CPython bindings.
> No pylint --py3k or 2to3 will help there...

That's a good point. I actually think
https://docs.python.org/3/howto/cporting.html#cporting-howto is actually in
a worse state than the state the Python level porting guide was in until
Brett's latest round of updates, as it covers the underlying technical
details of the incompatibilities moreso than the available tools and
recommended processes for *executing* a migration.

For example, replacing a handcrafted Python extension with a normal C
library plus cffi, Cython or SWIG generated Python bindings can deliver
both an easier to maintain extension *and* Python 3 compatibility.

Similarly, converting an extension from C to Cython outright (without a
separate C library) can provide both benefits.

It's mainly when converting to one of those isn't desirable and/or feasible
that you really need to worry about C API level porting.

For that, tools like Dave Malcolm's static CPython extension analyser for
gcc could potentially be helpful (as pylint was to Brett's update to the
Python level guide), and Lennart also provides some more detailed practical
suggestions in http://python3porting.com/cextensions.html

I'm sure there are other useful techniques that can be employed, but aren't
necessarily well known outside the folks that have been busy implementing
these migrations.

Barry, Petr, any of the other folks working on distro level C extension
ports, perhaps one of you would be willing to consider an update to the C
extension porting guide to be more in line with Brett's latest version of
the Python level porting guide?

Regards,
Nick.
___
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