Code quality tools #571

juliusz-t · 2025-04-23T17:01:12Z

PR related to issue #570

There are other issues regarding code quality and typing. It may be worth reviewing existing PRs and adding them to master before this change is accepted.

juliusz-t · 2025-04-23T18:45:34Z

I pushed the proposed tool configuration and the effect of their use. Please let me know if any changes have been made that are not acceptable to maintainers or parties using the project. The change is quite invasive from a code merge perspective. If I get the green light I can help implement compatible fixes in PRs that are waiting for approval.

acolomb · 2025-04-23T21:09:47Z

I'll need some time to judge this. And to be fair, actual feature work is still waiting in several PRs, so those should get attention first.

acolomb

I skimmed over the changes now and must say sorry, I'm not happy with the result and the current settings.

Tried to add individual comments on some changes, to give you a feel for what is likely to be accepted and what is not.

In general, I think the classes of changes should be discussed and handled separately. This "all things fixed (or silenced)" approach would take very long to review thoroughly, and discussion will be painful because it touches on so many opinionated subjects.

I'm open for code style improvements in general. But rather by applying a consistent style to newly added code and stuff that's touched anyway as part of feature work. As it stands, this PR will waste a lot of time for very little benefit, which can be better spent looking at the open feature PRs. Sorry.

acolomb · 2025-04-27T20:52:21Z

canopen/emcy.py

@@ -6,7 +6,6 @@

 import canopen.network

-


Definitely not. Which tool would suggest that? Separating the whole imports block(s) from the rest of the code is certainly worth an additional newline.

acolomb · 2025-04-27T20:56:05Z

canopen/emcy.py

-    def wait(
-        self, emcy_code: Optional[int] = None, timeout: float = 10
-    ) -> "EmcyError":
+    def wait(self, emcy_code: Optional[int] = None, timeout: float = 10) -> "EmcyError":


Keeping in mind the different Python versions supported by this library, this could be improved by using from __future__ import annotations. We already have it in other modules.

In general, when touching some line of code just for prettifying or reformatting, at least it should modernize things we haven't consistently brought up to date yet.

acolomb · 2025-04-27T20:56:32Z

canopen/emcy.py

-        (0xFF00, 0xFF00, "Device Specific")
+        (0xFF00, 0xFF00, "Device Specific"),


acolomb · 2025-04-27T20:59:56Z

canopen/lss.py

-CS_IDENTIFY_REMOTE_SLAVE_VENDOR_ID = 0x46               # m -> s
-CS_IDENTIFY_REMOTE_SLAVE_PRODUCT_CODE = 0x47            # m -> s
-CS_IDENTIFY_REMOTE_SLAVE_REVISION_NUMBER_LOW = 0x48     # m -> s
-CS_IDENTIFY_REMOTE_SLAVE_REVISION_NUMBER_HIGH = 0x49    # m -> s
-CS_IDENTIFY_REMOTE_SLAVE_SERIAL_NUMBER_LOW = 0x4A       # m -> s
-CS_IDENTIFY_REMOTE_SLAVE_SERIAL_NUMBER_HIGH = 0x4B      # m -> s
-CS_IDENTIFY_NON_CONFIGURED_REMOTE_SLAVE = 0x4C          # m -> s
-CS_IDENTIFY_SLAVE = 0x4F                                # s -> m
-CS_IDENTIFY_NON_CONFIGURED_SLAVE = 0x50                 # s -> m
-CS_FAST_SCAN = 0x51                                     # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_VENDOR_ID = 0x46  # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_PRODUCT_CODE = 0x47  # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_REVISION_NUMBER_LOW = 0x48  # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_REVISION_NUMBER_HIGH = 0x49  # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_SERIAL_NUMBER_LOW = 0x4A  # m -> s
+CS_IDENTIFY_REMOTE_SLAVE_SERIAL_NUMBER_HIGH = 0x4B  # m -> s
+CS_IDENTIFY_NON_CONFIGURED_REMOTE_SLAVE = 0x4C  # m -> s
+CS_IDENTIFY_SLAVE = 0x4F  # s -> m
+CS_IDENTIFY_NON_CONFIGURED_SLAVE = 0x50  # s -> m
+CS_FAST_SCAN = 0x51  # m -> s


Do you find this more readable? I don't. That's a case where I disagree with Black. In fact, I'd even align the equal signs to have the numbers always on the same column. For example Golang (go fmt) uses this style and keeps it automatically updated when some new, longer identifier gets added into the list.

So yes, this is not consistent with Black's stringent rules, but it's a case where the "standardization" change is detrimental. And we shouldn't waste time on such changes just because the tools are available. Time can be better spent on more important (functional) changes.

acolomb · 2025-04-27T21:00:08Z

canopen/lss.py

-ERROR_VENDOR_SPECIFIC = 0xff
+ERROR_VENDOR_SPECIFIC = 0xFF


acolomb · 2025-04-27T21:03:27Z

canopen/lss.py

-            return True
-
-        return False
+        return cs == CS_SWITCH_STATE_SELECTIVE_RESPONSE


acolomb · 2025-04-27T21:04:28Z

canopen/lss.py

@@ -197,19 +198,22 @@ def activate_bit_timing(self, switch_delay_ms):
        message = bytearray(8)

        message[0] = CS_ACTIVATE_BIT_TIMING
-        message[1:3] = struct.pack('<H', switch_delay_ms)
+        message[1:3] = struct.pack("<H", switch_delay_ms)


We shouldn't get started with this, it has potential for endless discussions and no real benefit. I actually configure Black with skip-string-normalization = true locally, to avoid such noise.

acolomb · 2025-04-27T21:07:03Z

canopen/lss.py

        self.__send_command(message)

    def store_configuration(self):
-        """Store node id and baud rate.
-        """
+        """Store node id and baud rate."""


Nice. PEP8 if I remember correctly? I use flake8 to help me with such things.

acolomb · 2025-04-27T21:08:44Z

canopen/network.py

-        self.subscribers: Dict[int, List[Callback]] = {}
+        self.notifier: can.Notifier | None = None
+        self.nodes: dict[int, RemoteNode | LocalNode] = {}
+        self.subscribers: dict[int, list[Callback]] = {}


What Python version is the minimum to support this? We shouldn't break compatibility because of such minor changes.

acolomb · 2025-04-27T21:11:34Z

pyproject.toml

+[tool.ruff.lint.per-file-ignores]
+# temporal ignores, to be removed once we figure out how to refactor code
+"canopen/objectdictionary/__init__.py" = [
+    "F403",  # unable to detect undefined names
+    "F405",  # variable defined from star imports
+    "SIM115",  # context manager for opening files
+]
+"canopen/objectdictionary/eds.py" = [
+    "SIM115",  # context manager for opening files
+]
+"canopen/sdo/client.py" = [
+    "F403",  # unable to detect undefined names
+    "F405",  # variable defined from star imports
+    "SIM102",  # nested `if` statements
+]
+"canopen/sdo/server.py" = [
+    "F403",  # unable to detect undefined names
+    "F405",  # variable defined from star imports
+]
+"test/test_eds.py" = [
+    "SIM117",  # nested with statements
+]
+"test/test_local.py" = [
+    "SIM117",  # nested with statements
+]


Definitely don't get started collecting exemptions like this. Either fix it or accept that a warning will pop up unless somebody steps up to cleanly refactor and get rid of the root cause.

acolomb · 2025-04-27T21:21:00Z

One more general comment: Things like git bisect and git blame are very useful tools. Littering the code history with formatting changes makes those unnecessarily hard. That's one of the main reasons why I'm sceptical of large-scale changes like this. Always keep in mind the cost / benefit ratio.

sveinse · 2025-04-27T21:25:13Z

In @juliusz-t defense, most of these code changes are result of using black. And black is a) very opinionated on formatting, and b) has become the defacto standard in many projects. We should definitely take a stand if we want that in this project.

acolomb · 2025-04-28T07:29:44Z

No need for defense, it's all being done in good faith and I hope that my reactions are not taken as an offense :-)

I definitely think that opting into rigorous "black" code styling is too much. There are various reasons why deviating from it makes sense, such as the aligned comments I pointed out above. It's certainly useful to consider what python -m black --diff suggests, and that is usually the best choice. But I reject throwing away different but sensible formatting that was chosen consciously for good reasons.

On that ground, blindly applying all changes that black would make will not happen. And I'm also reluctant to add specific silencing options just to make it shut up (except for the quotes thing which is just very noisy). Take the tool as a tool, which can help finding decisions, but not as the single source of truth what's best for the project :-)

juliuszt added 4 commits April 22, 2025 17:35

Add and configure code quality tools

2067f82

Reformat code with black

7612061

Format and group imports

7b9f8c8

Update ruff lint rules, format comments

b7ddf3f

juliusz-t changed the title ~~Code quality tools (#570)~~ Code quality tools Apr 23, 2025

juliusz-t mentioned this pull request Apr 23, 2025

Integrate code quality tools (black, isort, ruff) #570

Open

juliusz-t force-pushed the code-quality-tools branch from aa563df to 6a4c129 Compare April 23, 2025 18:26

Autofix ruff issues, ignore those requiring refactoring

cf06f72

juliusz-t force-pushed the code-quality-tools branch from 6a4c129 to cf06f72 Compare April 23, 2025 18:32

Autofix tests ruff issues

a72c122

acolomb requested changes Apr 27, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Code quality tools #571

Code quality tools #571

juliusz-t commented Apr 23, 2025

juliusz-t commented Apr 23, 2025 •

edited

Loading

acolomb commented Apr 23, 2025

acolomb left a comment

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb Apr 27, 2025

acolomb commented Apr 27, 2025

sveinse commented Apr 27, 2025

acolomb commented Apr 28, 2025

		(0xFF00, 0xFF00, "Device Specific")
		(0xFF00, 0xFF00, "Device Specific"),

		ERROR_VENDOR_SPECIFIC = 0xff
		ERROR_VENDOR_SPECIFIC = 0xFF

Code quality tools #571

Are you sure you want to change the base?

Code quality tools #571

Conversation

juliusz-t commented Apr 23, 2025

juliusz-t commented Apr 23, 2025 • edited Loading

acolomb commented Apr 23, 2025

acolomb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acolomb commented Apr 27, 2025

sveinse commented Apr 27, 2025

acolomb commented Apr 28, 2025

juliusz-t commented Apr 23, 2025 •

edited

Loading