# Ansible supported Python version on \_target\_

**URL:** <https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863>\
**Category:** Project Discussions\
**Tags:** ansible, linux, ansible-core\
**Created:** [November 19, 2025, 3:31pm UTC](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863 "2025-11-19T15:31:23Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [November 19, 2025, 5:19pm UTC](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863/2 "2025-11-19T17:19:40Z")

</div>

I fully agree with you (and it’s one of the reason why I continue to hope for [“execution plugins” - or however they should be named -](https://forum.ansible.com/t/39973) which allow to support older Python versions without having to drop support for module\_utils etc.)

I think dropping support for older Python versions _on the controller_ is perfectly fine. It’s also perfectly fine for many collections that (mostly, or even exclusively) contain modules that are almost always run on the controller. But some things definitely should better keep compatible with old Pythons, especially all the low-level things.

(I’m thinking of whether it would make sense to create a new collection community.core for that, and migrate modules from other collections such as community.general to there. I really don’t want to support old Pythons and ansible-cores for community.general, but for a smaller, more specialized collection that’s perfectly fine IMO. But that still doesn’t solve the ansible-core problem, where a new enough ansible-core version effectively prevents execution of modules and module utils - even if they still support Python 2.6 - on older Python versions like Python 3.6.)

RH’s official answer to all this are execution environments, which are better than nothing, but IMO they are more like a band-aid than a proper solution. (And you really don’t want to split up playbooks into different playbooks that each needs a different EE… 😱)

* * *

There’s one thing in your post I’d like to clarify:

> [@Thulium-Drake](#):
>
> But, to get back to the point, the pattern I see is that every new release (which comes fast) seems to drop the lowest version of Python on the target compared to the previous version.

I’m assuming you mean a new ansible-core 2.x.0 release. (And not a new Python 3.y.0 release.)

It’s only every second release: basically once a new Python version is added (which happens once per year), an old Python is dropped. The ansible-core versions 2.15 - 2.18 were kind of outliers: there it looks like one version is dropped every release, i.e. every half a year. But that was mainly to reduce the number of supported Python versions to the current count (3 on controller, 6 on target) without dropping too much at once. (I’m not sure whether that was the official strategy, but it felt very much like that.)

---

_[View the full topic](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863)._