Use six or drop python2?

[freeboson]

Maybe this is an unpopular opinion, but there is a lot of complication in sopel by maintaining python2 and python3 compatibility, without using six. @elad661 added six type features by hand, but I don't see the point of not just using six (6.6) or dropping python2 (7.0).

[dgw]

Dropping py2 isn't likely to happen any time soon, I'll be up-front about that. Certainly not in 7.0, that's too soon. There's enough stuff planned for that release that I'd rather not also go through the code removing py2 compatibility shims during the development cycle.

I can't speak to why six wasn't used, but since all the manual shims are basically in place at this point it seems like switching would be mostly busywork and a new dependency. Add in the extra testing and code review that would have to go into each six patch (or one hypothetical giant commit/PR that replaces everything at once) and I'm not really into this. There's too much else going on.

For now, this will be closed, but the discussion can continue. It can be reopened if I change my mind.

[freeboson]

I hope the sopel version out in 2020 will not bother with python2 anymore. For that day I'll note that since the modules basically just do the following: query API -> format a string -> privmsg the string, combining the six-type boilerplate and all the str.format accounts for probably 20% of module source length which would disappear in pure stable python3.

[dgw]

I don't see how str.format would disappear in "pure stable python3". The values have to be interpolated into the strings no matter which version the code is written for, do they not?

A number of other Python projects I've looked at have some kind of internal compat layer that wraps things they need to do across Python versions or different OSes. Maybe Sopel should gain one of those…

[freeboson]

In pre 3.5, you have to do this:

def f(bot):
    a = blah
    # ...
    bot.say("a: {a} | b: {b} | c: {c} | ...".format(a=a, b=b, c=c,...)

The fact that you do this so much in sopel and its modules, f-strings are a godsend.

I.e., if much of the work in modules is generating interpolated strings, wouldn't it be nice to have sugary interpolated strings? :)

[dgw]

The fact that you do this so much in sopel and its modules

I have done almost none of it at all, having joined the project only a few months ago, but I know what you're saying. 😛

Sure, it would be nice. But that feature alone isn't worth dumping py2 support and bumping the minimum py3 version to 3.6 at the same time—especially since if it's really wanted, there's a module to get f-strings all the way back to py2.7 (the minimum Sopel currently supports).