General cleanup of code

[MattHag]

Information

• Solaar version: 1.11rc (latest master)

Is your feature request related to a problem? Please describe.

• Although, setup.py mentions compatibility for Python 3.7 and above, there are still some additional code pieces to support Python 2. A cleanup should remove these workarounds.
• Upgrade the code style to favor double quotes " for strings over single quotes ' to prepare for usage of f-strings with dictionaries.
• Use Python 3 features, such as well-readable f-strings introduced in Python 3.6.
• Remove all assertion from non-test code (Can be tackled along rewrites) not so easy
• Type hint functions, methods, parameters ...
• Replace NamedInt, NamedInts with built-in Enums, which supports type checking and auto-completion
• Let functions raise a dedicated error, instead of return None - in the error case
• Remove humongous number of code lines in an init py

[pfps]

Yeah, the question is identifying what should be removed.

[MattHag]

At least the code pieces commented with Python 2, which I already removed and pushed.

Maybe 'Upgrade code to Python 3 style' is a better title, in order to upgrade strings to f-strings with pyupgrade as well and upgrade remaining strings manually.

pip install pyupgrade
pyupgrade --py37-plus `find lib/. -name "*.py" -type f`
pyupgrade --py37-plus `find lib/. -name "*.py" -type f`

[MattHag]

In addition to that, I also suggest a switch to double-quoted strings "" instead of '', and an upgrade to the insanely fast ruff, which replaces isort, yapf and flake8. This tool is also quite handy as very quick 'on save' auto formatter.

#2295

[pfps]

These seem reasonable, but let's defer this until after 1.11.1 goes out, which should be in a week. Then I have a bunch of changes to improve the imports loops, except for the big one of calling the UI from logitech_receiver.

[MattHag]

I think the mentioned issues have already been implemented.

However, when adapting the title to clean up, it could target

• Remove empty hashtag lines #2515
• Remove any commented out code
• Replace all import ... as _... statements and favor loading the module.
• Update license notice at the beginning of longstanding files and update license file, if necessary. Keep in mind, that sometimes comments are put after that legal part, where they are poorly visible.

[pfps]

The advice I have received is that the license notice should be at the top of each file. It's probably overkill but that is what I have been told.

[MattHag]

Yes, it is and it is not beneficial for development and leads to some irritation for me.

It is obvious, that there's no real plan for maintaining them, since most of the years date back to 2012-2013. This needs a plan and the best is to remove unnecessary duplication and ambiguous years from the individual files.

• Which name should be there?
  • If it is Solaar developers, is that even something good or does that refer to anyone contributing something. Could this have a weakening effect on the legal side?
• What does the year refer to? 2013 is certainly not the year of the latest changes, but also not the introduction of the module.

[pfps]

The important part of this section is the license. The code is Solaar uses the GPL and this can't be changed and should be prominently mentioned in each file.

It is true that the copyright line has not been updated. I'm now putting new information in for the files that I am touching.

[MattHag]

Good, then a cleanup and unification would be to replace all existing ones with that timeless message, as 90% of them are dated.
And furthermore reformat the module level descriptions, which are sometimes appended in the same style as the copyright notice. They use a # instead of a Multiline comment „““, which would be easy to distinguish.

[MattHag]

It is true that the copyright line has not been updated. I'm now putting new information in for the files that I am touching.

This needs a pre-commit hook then, otherwise it will never be up-to-date.

[pfps]

The copyright lines are the least important part of the license block, or so I understand. Having them be out of date is not ideal but doesn't invalidate the license.

[MattHag]

Sure, but there's certainly a nice handy tool to maintain it. Or, I would not even add a date at all anymore.

[rloutrel]

Hi. I wish I could help for this task, since it is a good way to discover the project and step up.

I am a pretty good soldier, but I do not know the battlefield and the HQ-objectives, so I should be instructed.

I was thinking, that the point:

• Remove all assertion from non-test code

Would be feasible without a deep knowledge of the project. (The Namedint to Enum could also be a good candidate)

I understand, that the point is to replace with "try ... except ... " the "assert" assertions in the productive code, since it is meant to be testing purpose. Is this correct?
Could i have a simple example of the expectations before / after ?

My dev/test environments will be:

• OS: Fedora Plasma (KDE) | Ubuntu Gnome
• Mouses: MX Anywhere 2S / MX Anywhere 3 / Mx Master
• Keyboards: MX Keys / Mx 400+ (for the record: the white one)
• No copilot, so I will fight alone on this

[MattHag]

Hi, you actually picked the hardest task of these. I meant to rewrite the code in a way that it does not rely on a humongoues amount of availability checks. I wouldn't recommend to start with this. They need more like a good overview of the wgole project and a solid plan.

The remaining tasks are easier to get started and can be done in smaller iterations. Any change should be covered by a small unit test. It is often helpful to split some parts of a huge function into smaller ones, that are testable on their own.

[rloutrel]

Ok. Then I will do the [NamedInt, NamedInts, UnsortedNamedInts] part.

About the tests, I have 28 from the 470 tests that are failing. Is this something, that I can first ignore (some of the tests seems quite recent and maybe not stable yet / in development)

Is the fact that the existing following test still passes: logitech_receiver/test_setting_templates.py::test_key_template[test0] not a test?

or is another purpose to increase the test coverage?

[rloutrel]

I am thinking about starting with the class _SettingWithValueUI from diversion_rules.py and the list of settings.

But I am a bit clueless about the tests to create. I will think about it.

Or:

# tree model columns
_COLUMN = NamedInts(PATH=0, NUMBER=1, ACTIVE=2, NAME=3, ICON=4, STATUS_TEXT=5, STATUS_ICON=6, DEVICE=7)
_COLUMN_TYPES = (str, int, bool, str, str, str, str, TYPE_PYOBJECT)
_TREE_SEPATATOR = (None, 0, False, None, None, None, None, None)
assert len(_TREE_SEPATATOR) == len(_COLUMN_TYPES)
assert len(_COLUMN_TYPES) == `len(_COLUMN)

seems to be another good candidate (like by creating a class instead of those 3 consts)?

[MattHag]

The tree model stuff likely needs to change for GTK 4.0, so I'd not touch it right now.

About the tests, I have 28 from the 470 tests that are failing. Is this something, that I can first ignore (some of the tests seems quite recent and maybe not stable yet / in development)

Starting from my latest pull request #2626 all tests should pass. I think the hidpp constants contain many NamedInts, which seem doable to replace, especially the ones without fallback value. Some modules like diversion/rules at not teddy for testing yet, but if a function is well testable on its own a test helps.

[rloutrel]

I saw the diff of your PR. I will wait for the merge before any modifications 😃

I can not work on it before this weekend.

Do you have WIP on hidapi (I saw #2480 is in progress), which would conflict with hidpp (not sure about it, I did not check the code about this part): to avoid conflicts, I would use your branch.

[MattHag]

No, there's nothing else to consider. This is the latest version and already includes many hidapi abstraction improvements.

[rloutrel]

Is this:
master...rloutrel:Solaar:master

What you are expecting for the testing, before I start with the refactoring?

[MattHag]

Yes, that looks good