[Next 2020-09] Drop support for Python 2.7, Python 3.4 and Python 3.5

[Natim]

I guess it would allow us to cleanup the code, switch to f-strings, remove __future__ hacks and get a clearer code base.

However it sends a good signal that Python 2 EOL is near and that it is time to switch to Python 3.

---

(addition by @brunobord to the original post)

Planning summary:

EOL Date	Python Version to drop	Workalendar release
2019-03-16	3.4	6.0.0
2020-01-01	2.7	8.0.0
2020-09-13	3.5	12.0.0

[Natim]

[Natim]

@brunobord any opinion on this?

[brunobord]

If I'm following this Status of Python branches:

• Python 3.4 EOL is scheduled for 2019-03-16
• Python 3.5 EOL is scheduled for 2020-09-13
• and more importantly, Python 2.7 will be terminated on 2020-01-01

At the moment, there are projects that would still need PY2-compatible workalendar lib, and removing its availability is a touchy topic, this should be carefully driven.

I see the point of switching to a "Python 3" only code, although the "f-string" may not be the NUMBER 1 argument for workalendar. I'm almost sure there's not a lot of formatted strings, and they don't require to be f-stringified :o)
The problem with using f-strings is that you're blocking any use in Python 3.5, which is the default in numerous distributions, and not all the system administrators would make the switch towards 3.6 without a serious reason.

But I don't see the point in rushing here: our codebase compatibility is as wide as necessary, from 2.7 to 3.7.

I think that the next milestone would happen after Python 3.4 EOL, in March. We'll probably make a major release with its support dropped.
Then, later this year, we'll schedule the deprecation of Python 2.7 and would keep workalendar as widely compatible as possible (and yes, that'd mean we won't be using 3.6 "f-strings" and others, because there will still be a long way towards 3.5 support drop)

I hope you still think I'm your friend ;o)

[Natim]

It makes a lot of sense and I like the reasoning and the fact that we have a path forward regarding this.

[brunobord]

version 5.0.0 was released, with drop of Python 3.4 support. Next stop is Python 3.5 in september.

[ShaheedHaque]

When support for Python2.7 is dropped, it would be nice to change all the places with an absolute import of workalendar itself with a relative import.

[brunobord]

@ShaheedHaque Adding this to my TODO list ;o)

[brunobord]

Starting the "drop Python 2 branch" right now.

[brunobord]

Currently working on dropping support for Python 3.5

[brunobord]

Then we'll just need to make a release to close this

[brunobord]

one small thing to add. Since we now have Python3.5-incompatible code (due to the introduction of math.tau), I'll add a python_requires option.

[brunobord]

... and we're done.
Next step will be Python 3.9, which is due next week. The Github issue is already here: #557, all we need to wait is support through Travis.