Python 3 cleanups #824
Python 3 cleanups #824
Conversation
Ironically, for a package that was intended to provide portability between python2 and python3, it is broken with python 3.12. A better library to use in all cases is "six". However, mythtv requires python 3.8 for a while now. Using "future.standard_library" is a no-op other than costing a pointless import and being troublesome to actually install. The hacky copy of six.with_metaclass included in "future" is rewritten to use the pure python3 form of a metaclass.
Drop ancient and outdated backwards compatibility code designed to
support python2, which is no longer supported anymore.
Performed using the command:
```
find . -name '*.py' -exec pyupgrade --py3-only --keep-percent-format {} +
```
and committing the results.
Mostly, this changes:
- remove coding cookies
- drop no-op imports of `__future__` or `builtins`
- classes don't need to inherit object anymore
- simpler `super()`
- drop the no-op string prefix u''
- drop some code under `sys.version_info == 2`. This never worked
because it didn't compare to .major, but if it did work it would not
be needed anymore on python 3.
The bulk of this is to just manually unroll custom is_py3 checks and switch to the canonical python3 naming. If this had just used six, then this would be trivially automated...
|
Yes, python 3.12 removes the |
|
'from future import standard_library' enabled to run Py3 code under Py2. Totally unnecessary now. |
|
@eli-schwartz Thank you for providing these patches! My suggestions for separate pull requests:
I would consider above PRs as necessary for the upcoming
Rationale: Some of above modules are not functional
My rationale for this separation is to |
|
My original interest in this is as a Linux distro packager, not a mythtv user -- this is a QA blocker for marking all packages as 3.12 compatible and eventually phasing out 3.10 and 3.11 support -- so I lack the familiarity to be aware in advance of that module maintainer split. Your explanation does make a ton of sense, and I'd be more than delighted to accommodate it. It makes a great change from having my careful patches squash-merged. :P Question: for the automatic tool-powered changes, do you want me to apply one autofix type per commit? It's somewhat easier to review that way but either approach isn't hard, so I'm not sure which you prefer. |
|
I really appreciate Your help in this topic! |
|
I submitted 2 PRs containing the broken-out commits for simplejson and future. |
First parts committed, thank you for help! |
Roughly divided into two changes:
futurePyPI package, which is broken on python 3.12 and unneeded in python 3 entirely.The first part is critical to allow running on modern versions of python. The second part I did just because I can, so why not.