Drop python 2.6 support

[jaimeMF]

REHL 7 ships with python 2.7 since June 2014 and the same for CentOS 7, so I think that all the current releases for main Linux distributions have stopped shipping python 2.6 only, OS X includes 2.7 for a few releases and on *BSDs 2.7 can be easily installed from the ports. Therefore all users with updated software could continue to use it.

Some of the problems with python 2.6:

• It won't get any security updates, so it can be dangerous.
• We have to workaround around some features missing in the standard library. For example some assert* methods are not available in unittest and the xml module doesn't support xpath attributes queries or namespaces. One of the most annoying thing that is missing is the need to explicitly set the index for the .format method. That's also true to some degree for 2.7 vs 3.x, but 2.7 is currently widely deploy so dropping it would mean that a lot of users would stop using youtube-dl.

If someone is using outdated software it would unfortunately stop to work. This can annoy some users, for example those using a PPC Mac where youtube-dl can be the only option for viewing videos from the Internet; although they can probably manually build python 2.7 (I think I managed to compile python 3.{something} in OS X 10.4) or use something like Tigerbrew.

Some interesting read about the problem with supporting python 2.6 is this post by Nick Coghlan and this one from Alex Gaynor.

[yan12125]

Are we going to remove python 2.6-specific workarounds? Or just change the policy to "Python 2.6 series is not officially supported" and declare it in documents? The latter option brings less annoyance to users.

[jaimeMF]

I would first say that we only support 2.7+ and then start removing the workarounds, additionally for any new code that is added we wouldn't check if it works on 2.6 and we would assume that all the features in 2.7 are available.
I don't think that keeping the workarounds is useful, I would say a big part of dropping support for 2.6 is getting rid of them, and eventually users will get annoyed when some change we made is incompatible.

[dstftw]

According to #2396 (comment) it is probably reasonable to support python 2.6 while RHEL6 and CentOS6 do (namely 2024 and November 30th, 2020 correspondingly). As of workarounds, in case of dropping 2.6 support there would still remain lots of workarounds for python 2.7.

[jaimeMF]

From the Nick Coghlan's post:

Since September 2013, Red Hat Enterprise Linux subscriptions have included access to an additional component called Red Hat Software Collections. You can think of Software Collections roughly as "virtualenv for the system package manager", providing access to newer language runtimes (including Python 2.7 and 3.3), database runtimes, and web server runtimes, all without interfering with the versions of those integrated with (and used by) the operating system layer itself.

This model (and the fact they're included with the base Red Hat Enterprise Linux subscription) means that Red Hat subscribers are able to install and use these newer runtimes without needing to upgrade the entire operating system.

So they should be able to easily install a copy of python 2.7 without interfering with the system version. If they are installing youtube-dl, which is constantly getting updated, I don't think that installing software provided by Red Hat.

If some of the core contributors use 2.6 regularly I may understand wanting to support it. But if none of us use it, then we may miss issues and it's a unneeded burden (especially if we consider that we don't get that many reports from people using 2.6).

As of workarounds, in case of dropping 2.6 support there would still remain lots of workarounds for python 2.7.

Apart from the unicode issues and different module names, I don't think there too much of them. At least we would get access to the features in 2.7.

[jaimeMF]

For making transition easier and doing a survey on how many users would be affected, we could add a warning on python 2.6:

You are using python 2.6 and we're considering dropping support for it near the end of 2015. We recommend you to upgrade to python 2.7 or higher. If you can't or don't want to upgrade we ask you to share your reasons at https://github.com/rg3/youtube-dl/issues/<some-new-issue> and we may continue to support it for more time.

If you don't want to see this message again you can export the environment variable YOUTUBE_DL_NO_PY26_WARNING.

Would you accept this approach? If we get a lot of reasonable complains we could continue to support it, but if most of python 2.6 users upgrade it we could drop the support.

[yan12125]

There's a little trick: not all youtube-dl users have a github account. Is it neccessary to force a github account for a survey? Requiring registering an account can reduce the willingness of sharing ideas.

[jaimeMF]

There's a little trick: not all youtube-dl users have a github account. Is it neccessary to force a github account for a survey? Requiring registering an account can reduce the willingness of sharing ideas.

You are quite right. I know that Google Docs allows you to create a survey with the results publicly available (which I think we should try to do), maybe you prefer another service?
(I don't know if I'll be able to spend too much time setting it up in the next two months, so If someone wants to help I would appreciate)

[yan12125]

Just a reminder: Python 3.2.5, 3.3.6, 3.4.3 and 2.7.10 support SSL SubjectAltName, while 2.6.9 not. See #1589.

And I think Google Docs is a good choice if you're going to have a survey.

EDIT: Sorry I forgot Python < 2.7.9 does not check certificates. The problem is irrelevant with dropping python 2.6 support.

[alphapapa]

Another reason to move to 2.7+ is the addition of helpful modules to the standard library, like OrderedDict.

[videonerd]

Dear devs, I would be really grateful if you can look into this issue, which impacts us windows users of youtube-dl. Thank you!

[jaimeMF]

@videonerd I'm assuming you are talking about #7091, it has nothing to do with using python 2.6. The problem is that the exe is build with python 2.7, it could be fixed if it used python 3.x, see #5094 for more info.

[videonerd]

@jaimeMF thank you for the explanation. If the issue is as simple as building the windows exe using python 3.x, then can we please have the official windows exe built using python 3.x?

Thank you.

[expenses]

As it is the middle of 2016, can I ask that we drop support for Python 2.6, so that we can switch to using argparse instead of optparse (see #583), as well as fixing other issues?

[dstftw]

Switching to argparse is not a priority at all.

[yan12125]

As a side note: there are still some commits on optparse.py in CPython. I guess it's not completely abandoned.

$ hg log --template '{node|short} | {date|isodatesec} | {desc|strip|firstline}\n' --limit 10 Lib/optparse.py
dfb61cd916e3 | 2016-06-03 16:22:33 -0700 | final final step in backout of bad default->3.5 merge d085b4f779af: null merge 3.5->default
8f395bdff416 | 2016-06-03 15:20:13 -0700 | final step in backout of bad default->3.5 merge d085b4f779af. merge 3.5 heads
ac236f1e8fd4 | 2016-04-19 04:03:41 +0000 | Fix spelling (inital), grammar (may translates) in documentation, comments
33e571b14b7e | 2016-04-19 23:23:16 +0000 | Merge doc and comment fixes from 3.5
a54f6e207b22 | 2016-04-19 04:03:41 +0000 | Fix spelling (inital), grammar (may translates) in documentation, comments
932b330e22d8 | 2016-04-17 09:39:28 +0300 | Issue #26778: Fixed "a/an/and" typos in code comment, documentation and error
bbcde8db4dc4 | 2016-04-17 09:37:36 +0300 | Issue #26778: Fixed "a/an/and" typos in code comment and documentation.
395dd5630e6c | 2016-04-17 08:32:47 +0300 | Issue #26778: Fixed "a/an/and" typos in code comment and documentation.
78d67bdc1142 | 2015-11-14 12:46:42 +0000 | Issue #23883: Add missing APIs to __all__; patch by Jacek Kołodziej
ede054eb3dc1 | 2014-01-20 21:35:06 +0200 | Issue #20315: Removed support for backward compatibility with early 2.x versions.

[hugovk]

+1

27 months after this issue was opened, here's some current reasons for dropping 2.6:

• Unsupported since 2013-10-29
• Current pip 9 deprecates Python 2.6 support, pip 10 won't support it
• https://snarky.ca/stop-using-python-2-6/
• http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
  (Drop support for Python 2.6? pypa/pip#3955)
• Not much PyPI traffic (June 2016) Deprecate/Drop Support for Python 3.3? pypa/pip#3796
• http://www.python3statement.org

---

(Related issue: Drop Python 3.2 support #9751)

[Zocker1999NET]

61 months after this issue was opened, here are more reasons for dropping 2(.6):

• Python 2 was officially deprecated at January 1st, 2020

A few follow up questions 2,5 years later:
How about drop the Python 2.6 support? Is there still a reason to support this or could we just drop it?
Also the same question about Python 2.7 (a new issue feels unnecessary for now), are there users who still only can use youtube-dl together with Python 2 instead of Python 3?

[septatrix]

As pip itself (which is probably where most users install youtube-dl from) drops python 2 support january 2021 dropping python 2.6 seems long overdue. Keep in mind that this is only relevant for people not using the exe as it bundles python. People not using the exe will be mostly MacOS and Linux users who have up to date python versions in general. The only exceptions seem to be very old enterprise linux distributions whose set of users I assume have no overlap with the users of youtube-dl.

[stefnotch]

It seems like Python 2.7 is not officially supported by pip anymore. At this point it should be reasonable to drop Python 2.7 support. After a few versions, removing Python 2.7 workarounds from the code base could be investigated.

Python 2 Support
pip 20.3 was the last version of pip that supported Python 2. Bugs reported with pip which only occur on Python 2.7 will likely be closed as “won’t fix” issues by pip’s maintainers.
-- https://pip.pypa.io/en/latest/development/release-process/#python-2-support

[jcmdln]

This issue can likely be closed, as youtube-dl has new maintainers who committed to supporting Python 2.6 #30568 (comment)

[hugovk]

From #30568 (comment):

For people concerned that Python 2 is a couple of years beyond EOL, one case that I support could survive until 2038, or the end of DVB-T2 broadcasting if that comes sooner. That's the timescale of deployed embedded applications, a very different world from 'What version is Chrome today?' on your personal computing device.

Python 2.7 has ben EOL for a couple of years, but 2.6 is a couple of years off a decade EOL (2013-10-29).

https://devguide.python.org/devcycle/#end-of-life-branches

Is 2.6 still used in those cases?

[septatrix]

Is 2.6 still used in those cases?

An argument which often seem to be forgot is that old version of the library will still work. If you do not upgrade youtube-dl there is nothing to worry about. And if you can update youtube-dl on an embedded device it is usually also possible to update the interpreter

[dirkf]

From "How is Python 2 supported in RHEL after 2020?":

Just because the PSF consider Python 2 "unsupported" does not mean that Python 2 is "unsupported" within RHEL.

s/RHEL/youtube-dl/

However, it's now 2024, which AFAIK is the year when support for Python 2 expires in Ubuntu 16.04 ESR and RHEL8, and RHEL6 with Python 2.6 reaches End of Maintenance.

Python 2.7 support is a feature of the project that will be continued. However, if no Python 2.6 die-hards complain or provide examples of environments where Python 2.6 is required, or maybe even if they do, it's likely that the policy suggested above will start to be applied.

These look like the only 2.6-specific issues in the last few years: #31600, #32544.

The rationale for this is essentially stated in the second bullet point of the original post. See also compat_kwargs() in utils.py.