Proposition: Drop support for Python 2

[eSoares]

Proposition: Drop support for Python 2

[hugovk]

I've split the commits, 4448a8d is a 2.6 -> 2.7 upgrade, and f0a2d2e is 2.7 -> 3.4+.

[hugovk]

See https://python3statement.org for a list of projects which have pledged to drop support for Python 2 on or before it's EOL on 2020-01-01.

And pyupgrade is a useful tool to help upgrade Python syntax for newer language versions.

[llimllib]

Thankfully, the syntax is already compatible with python 3; this would be a matter of dropping support for python 2. It would indeed be very nice to switch to f-strings, but I don't think there's a whole lot to gain otherwise?

Addition of typing that could easy the coding of plugins and new functionality;

I do think we could stand to add some type notes for sure, but we could do that in a python 2.7 compatible way if we wanted to. (I think? I just kind of vaguely recall that either 2.7 supports the syntax, or is it that you have to use a weird comment-type syntax?)

Maybe asyncio can also improve somethings?

I've actually played around with an asyncio branch, and I found asyncio to be a confusing mess.

It actually kind of makes me want to convert limbo to go tbh, but I'm much too lazy to do that.

If somebody else wants to make an asyncio branch that works, I'm all ears.

Maybe other niceties that I have forgot (iterators everywhere, Enums,...)

This is the crux of the matter, I think; it's not much pain to support both python 2.7 and python 3 ATM.

So I'm open to it but don't feel like python 2.7 support is really dragging me down? Mostly it makes me use ugly format strings.

That said, I'm python 3 all the way, so if you can convince me that there's real value to be gained I'll be happy to mark a revision as the last one that supports python 2.7 and move forward with 3 only.

[StewPoll]

Ultimately, you'll want/need to drop python 2.7 eventually. With Django and other larger frameworks already having dropped support, it will hasten the rest of the community to do so as well.

Why not get it done now? All it really should need is simply removing python 2.7 from travis, and telling people to run it in python 3 instead.

[llimllib]

I will want to drop python 2.7 eventually for sure, I don't see who I benefit by dropping it today, you know?

[hugovk]

Just as an example, here's what it could look like after removing a few things manually (like 2.7 Travis) and then running pyupgrade:

• master...hugovk:rm-2.7

[llimllib]

right, it changes the things I expected (I put in all the things that keep it compatible, so it's no surprise haha). Basically f-strings would be nicer plus it removes the one utility function that does python2/3 string handling, and I can remove the makefile switch.

Still doesn't seem like that big a win to me?

[llimllib]

All the {0}s btw are because I used to support python 2.6, because it was the standard RH python for a long time, now that was a PITA I dropped as soon as possible

[eSoares]

I will want to drop python 2.7 eventually for sure, I don't see who I benefit by dropping it today, you know?

We could argue this till 2.7 reaches EOL, but do we really want to keep being stuck in 2.7?

I do think we could stand to add some type notes for sure, but we could do that in a python 2.7 compatible way if we wanted to. (I think? I just kind of vaguely recall that either 2.7 supports the syntax, or is it that you have to use a weird comment-type syntax?)

We could add some weird comment syntax yes, but I think some tools will maybe miss it or not work as good as typings from python 3.

Let's do a modest proposal and wait a couple of weeks to see if anyone manifests interest?
In order to increase the reachability of this matter to limbo users, maybe merge this warning: eSoares@b755e9d

[eSoares]

Closed by #186