pass .py code over pyupgrade --py38

[kloczek]

Upgrade code to py38 syntax and remove six module dependencies.

Summary of changes

Closes

Pull Request Checklist

• Changes have tests
• Authors have been added to AUTHORS.md
• News fragment added in changelog.d. See CONTRIBUTING.md for details

[kloczek]

May I ask for some comment about why it has been refused? 🤔

[eli-schwartz]

May I ask for some comment about why it has been refused? 🤔

Because there are many tickets about it, and several proposals to fix this correctly without a blind pass that breaks the world.

And because you previously submitted:
#1206
#1220
#1258

... without checking the bugtracker and without even checking whether you yourself previously opened tickets about it.

In fact, once upon a time you were aware of the issue because you commented on #1130 (comment) but appear to have somehow forgotten that it's a blocker for removing python2 support.

Frankly, it's not even obvious why upgrading the syntax is desirable at all. It would be useful only after the minimum required python version is bumped. But "be able to run pyupgrade" is not itself a reason to bump the minimum required python version...

[kloczek]

Look .. python 2.x support has been EOSed FOUR YEARS AGO!!
Do you see around any still supported any OS distro which still uses python 2.x?
So how long you want to keep python 2.x support on master?
Why not just remove that support from master and inform all around that exact version is last version which will has such support and it could be branched only if someone will find some critical issue?
All to keep on master clean and up-to-date code .. 🤔

Please read pyupgrade documentation where is precisely documented why it should be used (like remove no longer needed imports, use standard modules, use faster syntax etc).

So no technical reasons. Just because of me .. and fact that I'm working on OS distribution and I'm opening on daily bases multiple tickets, and I sometimes do not remember what I exactly wrote half year or thee years ago. Do you remember such details? 🤔
Thx to let me know that PR has been refused because I've been pointing to many times what can be updated/improved 😞
BTW are you aware of fact that dateutil is one of the only few remaining quite often used modules which still uses six? 🤔
EOT .. will try to keep in mind to not bother you any more about that topic.
PS. FYI I'll keep forked repo if you will change your mind.

[hugovk]

You were told the plan in November: #1130 (comment). Step 3 is next.

Things are moving forward. Please be patient and keep it civil. The maintainers are well aware of the EOL and will remove support when they are ready.

[kloczek]

From https://endoflife.date/python:

• 3.7 EOS is 27 Jun 2023 (already is EOSed)
• 3.8 EOS is 31 Oct 2024

So that step 3 should be for 3.8.

[eli-schwartz]

Look .. python 2.x support has been EOSed FOUR YEARS AGO!! Do you see around any still supported any OS distro which still uses python 2.x? So how long you want to keep python 2.x support on master? Why not just remove that support from master and inform all around that exact version is last version which will has such support and it could be branched only if someone will find some critical issue? All to keep on master clean and up-to-date code .. 🤔

Please read pyupgrade documentation where is precisely documented why it should be used (like remove no longer needed imports, use standard modules, use faster syntax etc).

All of those are good reasons for an upstream project to theorize about whether it's a good idea to drop support for older python.

None of them are good reasons for a downstream vendor, such as a linux distro, to have any stake whatsoever in the matter.

It doesn't matter to dateutil users, whether the code is "clean and up to date".

This is why no other OS distribution people go around submitting these... odd... bug reports and pull requests that you do.

So no technical reasons. Just because of me .. and fact that I'm working on OS distribution and I'm opening on daily bases multiple tickets, and I sometimes do not remember what I exactly wrote half year or thee years ago. Do you remember such details? 🤔

Well, no, in fact I don't actually tend to remember what I wrote three years ago. But it's quite irrelevant whether I remember.

This is why search exists. If you're going to propose removing six, the least you can do is perform a search to see if someone else has submitted a PR to do it first. If nothing else, your PR should say Fixes #<existing bug number>.

If you'd performed a simple search in issues + PRs for the word "six", you'd have prominently noticed your three bug reports. You'd also have noticed a bunch more tickets:

#653
#1085
#1202
#1203
#1291
#1304
#1345

BTW are you aware of fact that dateutil is one of the only few remaining quite often used modules which still uses six? 🤔

Yeah but I also don't particularly care because six isn't an urgent problem to remove. I would be happy to remove it as unneeded for modules which have already dropped python2 support, since it's a useful cleanup and results in fewer installed OS distribution packages, but it's a mere "guess it would be kinda nice, I suppose" and not actually important.

It is certainly not important enough to stoop to harassing dozens of projects about it only for most of them to close the PRs as undesirable. I try not to submit PRs when upstream considers those PRs to be an unhappy burden that they have to triage and close and explain "yet again" why they don't want the change and have been intentionally and knowingly refusing to do so for a long time.

[a-detiste]

Well said. In my PR I only propose to remove Py2 support when I can find some proof that it is already broken anyway (like presence of Py3 annotations, ....)