Question, why not to upgrade to Python 3?

[nengxu]

Thanks for bringing us a promising tool. I'm primarily using Ruby now for work. However, Python remains one of my favorite languages. I use both Capistrano and Fabric, and don't need Chef or Puppet's complexity. So would like to try Ansible.

Although Python 3 has been live for a few years, it seems that Python community still has the inertia to stick with Python 2. For example, one cool boy called Dreampie, and of course Ansible and Fabric.

I'm using Arch Linux, where the default Python is 3. I have to change the system default link to Python 2 in order to make Ansible work, just like in here:
#205 (comment)

However, this will affect other Python 3 programs on Arch. So not a good nor convenient solution.

May I ask in the case of Ansible, why not to upgrade to Python 3?

Thanks.

[mpdehaan]

May I ask in the case of Ansible, why not to upgrade to Python 3?

Because I care much more about the ecosystem of users using RHEL and
CentOS, and it's still possible to use Python 2.6/7 on newer platforms
(including Arch) just fine. There's really nothing to be gained from
Python 3, nor do I think what Guido has decided to add address any real
world problems.
At some point, we'll probably explore Python 3 compatibility, but it's a
requirement that control code support python 2.6.

Moving code to Python 3 does a great disservice to all of our users at this
point in time.

[nengxu]

Thanks for your quick response. I'm not a fan of RHEL or CentOS (you
can guess that from my Arch Linux usage). But your reason of supporting
Python 2 is quite valid as long as some people prefer them.

It is interesting to know your thought about "what Guido
has decided to add address any real world problems".

On Mon, 22 Oct 2012 12:11:30 -0700
Michael DeHaan [email protected] wrote:

May I ask in the case of Ansible, why not to upgrade to Python 3?

Because I care much more about the ecosystem of users using RHEL and
CentOS, and it's still possible to use Python 2.6/7 on newer platforms
(including Arch) just fine. There's really nothing to be gained from
Python 3, nor do I think what Guido has decided to add address any
real world problems.
At some point, we'll probably explore Python 3 compatibility, but
it's a requirement that control code support python 2.6.

Moving code to Python 3 does a great disservice to all of our users
at this point in time.

---

Reply to this email directly or view it on GitHub:
#1409 (comment)

[mpdehaan]

Basically I haven't had any problems with Python 2.X

I think he's viewed some syntaxes as things he did not like, or wanted to
prevent certain classes of user errors
that he thought were important, but they weren't really important in
practice.

[nengxu]

Thanks for sharing your opinions. Do you know anyone who is working on
implementing Capistrano features in Ansible? In other words, using
Ansible to deploy Rails and other Ruby applications.

I noticed on one pull request you mentioned that all core modules in
Ansible should be in Python. How about Capistrano and other Ruby stuff?

On Tue, 23 Oct 2012 04:20:10 -0700
Michael DeHaan [email protected] wrote:

Basically I haven't had any problems with Python 2.X

I think he's viewed some syntaxes as things he did not like, or
wanted to prevent certain classes of user errors
that he thought were important, but they weren't really important in
practice.

---

Reply to this email directly or view it on GitHub:
#1409 (comment)

[yegle]

Writing forward compatible code to work in both 2.6/3.3 should be feasible.

[bcoca]

many clients come only with 2.4, which has already bitten us several time
and that is with just going up to 2.7

Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

[jirutka]

@bcoca So tell them to upgrade…?! Don’t take this in a wrong way, but this is really insane – Python 3 was released ~6 years ago, but you still bother with 2.4, about 10 years old mummy. On the other side, you’re telling us that we need to install Python 2.x on all of our nodes.

[bcoca]

I'll get right on it, right after I make them all move to perl 6.

[jirutka]

@webscientist And it’s also a good opportunity to improve tests and do some refactor. Ansible is indeed very good piece of software, but code quality and especially test coverage should be improved. For an example, look at TestRunner – this module scares me.

[bcoca]

Ansible like, most tools has a target market, currently that market has a
preponderance of python 2.4 (not even 2.7), at least it requires 2.6 on the
master (as you expect desktops to be a bit newer).

Until the installed base (not latest version of distributions) moves all to
python 3, it doesn't make sense to move Ansible to python 3 because it
would be cutting it's target market to a fraction of what it is now.

[bcoca]

FYI, I'm just a contributor, I don't represent the company or the main
author.

My view is that Ansible is a system tool, systems are normally conservative
and slow moving targets. The default python for most distributions is still
v2, a few have started including 2 & 3 and I'm only aware of one only using
3 and leaving 2 as a optional install.

The numbers of installed linux and versions do fluctuate, but not as much
as you think. Most sources seem to agree that by far it seems RHEL and
derivatives + Debian and derivatives hold most of the market, and all
current versions of these out there default to python 2. This is just for
Linux, you must also consider Solaris (and variants), BSDs and AIX, etc.

I understand the frustration of the Pyhton community wanting everyone to
move to 3 already, my previous crack about Perl6 is not a totally fair
comparison but it does have similarities to the problems faced (though
perl5 has been developing faster and more vibrantly than 6 which creates
problems for them python doesn't have). Python 2 might not get much love
from core maintainers but it is stable, known, predictable (stuff systems
people and distro maintainers like).

A preponderance of the libraries are still 2, I even see that many new ones
are still written for 2, some of the management libraries Ansible depends
on are only available in 2 (for example boto3 is still experimental, most
dev efforts seem to go to boto v2).

Yes, it is chicken and egg, but I don't see how Ansible can move to 3 w/o
alienating the vast majority of the installed base.

Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

[jirutka]

I totally agree with @webscientist!

What about writing the code to be compatible with both versions, when possible? Most of the incompatibilities can be relatively simply and nicely solved, can’t it? And for the rest of them (exceptions catching for an example *), the 2to3 script can be used.

* It’s actually possible to write catch to be compatible with both versions, but it’s ugly and non-idiomatic.

[bcoca]

I've had code rejected for using 2.7 semantics and last I looked it is not
that easy to write code 2.4 - 3 compatible (modules), for 2.6 (core) it
looks easier. I, for one, would welcome any pointers to do so, but I'm not
sure this is that attainable.

In the last 2 years I've migrated web apps from python 2.4 to 2.7 and that
itself was non-trivial, we even had a few unexpected side effects. None of
the devs (myself included) could make a good argument to go to v3 as it
didn't offer any feature worth the cost of porting, the main performance
issue was the GIL and that was much easier and cheaper to sidestep going to
multiprocess and preforking, specially since the gains with the GIL in 3
did not solve the concurrency issues (if they had eliminated it, we would
have probably been able to justify it).

In any case, the reasons Python2 is still alive and kicking as been
discussed to death by the Python community itself, much of it has to do
with how Python3 broke backwards compatibility. I don't think Ansible is a
good place to stage this battle, I recommend going to popular libraries and
frameworks, once all of those have moved, everyone else will follow.

Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

[jirutka]

Ah, I forgot about the requirement for an ancient 2.4. Well, that’s unsolvable. :(

BTW, why isn’t Ansible written in plain C? What about the mainframe people, they don’t even have Python! Sorry, I’m just allergic to keeping backward compatibility up the time of dinosaurs, because of some “enterprise” companies which don’t want to upgrade their systems… It’s just an awful brake on development.

However, I have Python 2 installed on my systems anyway, so it’s not such a problem for me as a user, it just annoys me as a developer.

[Russell-Jones]

Fair enough, though it would be useful for us to have a list of dependencies and 2/3 statuses here. It may also be useful to 1) have a python2and3 branch for those who want to work on that (kept in sync with master as far as possible) 2) make the inconsequential changes in master that help python3 support ( e.g. print -> print() ).

BTW, when is the EOL for the products that are stuck with-- er, support 2.4? Presumably it can't sensibly continue to be used after it stops getting security patches? What's your plan for when the requirements stop supporting 2.4 and 2.5?

[mpdehaan]

Gentlemen,

You are commenting an old ticket. We're not going to likely respond to this.

If you would like to start a discussion, I would recommend posting on the ansible-devel mailing list.

It is absolutely vital that we continue to support users on EL 5 and 6 platforms, as much of the world runs here. We are seeing much less usage of EL 5 but EL 6 is widely deployed.

It's still our position that Python 3 is a seperate language and we'll fight that battle when the time comes and there's no longer a Python 2 by default in everybody's Linux -- but it already is.

There is simply no benefit to using Python 3 in core code, though if you want to write your own modules that use Python 3, that already works -- though we won't accept them in core for compatibility reasons.

Once again, this is a bug tracker and not a discussion forum, so let's move this over to ansible-devel if you would like to continue.

[ariddell]

I'd like to see support for Python 3. It would be easier to use ansible with Arch Linux.

[nealmcb]

For the record, Red Hat Enterprise Linux 5 was released in 2007, shipped with Python 2.4, and will receive security patches until 31 March 2017. For an extra fee, customers can get security patches until 31 March 2020. RHEL 6 shipped with Python 2.6, and gets security patches for all thru 30 November 2020.

[jirutka]

@nealmcb So we should remain in the Stone Age just because RedHat sells an irrationally long support for the certain version of RHEL and some of their customers are too lazy to upgrade or install Python e.g. from https://iuscommunity.org? Sorry, but this is just stupid, 10 years is like a century in ICT. This excessive conservatism is just killing Python.

[jimi-c]

@jirutka, we appreciate your concerns regarding this, however there is a very large installed user base of RHEL/CentOS 5, and breaking backwards compatibility for those users would not be fair.

As such, I have now locked this dicsussion, and any further discussions regarding this topic should be directed towards the ansible-devel mailing list.

Thank you!

[abadger]

One update to this ticket: the ansible team is merging patches to make future ansible core (the piece that you run on your controlling machine to run ansible) python2.6, 2.7 and python3.4 compatible. We don't anticipate this to allow running ansible on python3 in the near future but we are not hostile to changes that help get us to this goal.

The modules are a tougher problem as they need to run on RHEL5/CentOS5 for now which means supporting python2.4 there. We don't currently have a good idea for supporting python-2.4 and python3 from the same codebase so we've deferred working on this until after the core is ported in hopes that we can think of something better.