Drop python 3.4 compat

[xrotwang]

Python 3.4's EOL was more than one year ago, so I'd argue we can drop py 3.4 compatibility now. Since py 3.5 also reached EOL recently, the question arises whether we should also drop 3.5 compat because new features in 3.6 would be worth this step? I assume only f-strings could be this feature - but I don't think that's very relevant here, right?

[xrotwang]

@SimonGreenhill @chrzyki @xflr6 @stschiff thoughts?

[xrotwang]

@xflr6 somewhat related: We have the mock_use_standalone_module setting in most of our packages. I think I copied that from you. Is there a good reason for this? Currently - since mock>=4.0 requires python 3.6 - this breaks compatibility with py 3.5.

[LinguList]

I do not like the f-strings, since they are hard to read. So I would not use them anyway. 3.5 is still standard on some ubuntu systems. What is used on a mac now?

[xrotwang]

I agree regarding readability of f-strings, in particular when they are long and concatenated. I also think hiding full expressions in strings is a recipe for disaster.

[xflr6]

We have the mock_use_standalone_module setting in most of our packages. I think I copied that from you.

I often found myself trying newer mock features stumbling on versions and so I preferred to use the module everywhere (and at that time Python 2 needed the package anyway, IIRC). I guess I would just pin the version of mock to the last one that still supports all versions so we can use all mock features until this version (in general, I think adding/changing dependencies for tests is usually less of an issue).

I do like to use f-strings (when I can) but I also see the concerns. With rising code editor support (syntax highlighting), I think they can be quite helpful, but one should probably avoid complex formatting e.g. joins and nested strings.

Maybe the CI plays a role in maintenance costs (just an idea)? With 3.6+, we can bump it up to focal (latest LTS, assuming that is closer to user's environments).

[xrotwang]

I guess, I'm often the slowest of all users when it comes to upgrading :) And I like the idea of supporting all python versions that are reasonably used. Considering that EOL means the latest patch has just been released, trying to support this for about another year seems nice.

So what I understand is that dropping the mock_use_standalone_module setting is ok if the test suite still passes. So for simplcity's sake, I'd propose we reverse the default: Only add mock_use_standalone_module when a new mock feature is actually used.

[SimonGreenhill]

Does anyone know how to find out what versions of python are in e.g. Ubuntu LTS releases? (I can't after a quick google). Something like ubuntu 18.04 LTS might still be on py3.5?

This is the only reason I can see for keeping backwards compat.

& yes, removing un-needed dependencies (mock) is good if we can.

[xrotwang]

Ubuntu 18.04 has py3.6. I'm still on 16.04 and that has py 3.5 - and one more year of support.

[SimonGreenhill]

Ok, makes sense to drop 3.4, but keep 3.5?

On 15/09/2020, at 08:14, Robert Forkel notifications@github.com wrote:

 Ubuntu 18.04 has py3.6. I'm still on 16.04 and that has py 3.5 - and one more year of support.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[stschiff]

I think the default on Mac is still 2.7 😂

Anyway I personally never hesitate to drop support for old versions, so definitely go from my side!

[xrotwang]

I'll merge #42 then.

[xflr6]

Thanks. Re dropping mock_use_standalone_module: fine with me.