limit docstrings and comments to 79 characters (#207)

This project has followed the following convention from the start:
- code limited to 88 characters (Black code style)
- Docstrings and comments limited to 79 characters.

Enforce this by adding the rule W505 for ruff.

Thoughts
--------
Although the *exact* numbers (79 and 88) could also be something else
and still offer a good developer (and code reading) experience, those
numbers are pretty close to optimal. The reason for this is that I,
among many others develop on small screen (laptop). I also use a large
font / small resolution (which makes font larger) to make it easier for
my eyes. As it's pretty common to need to have code side by side, the
roughly 88 characters starts to be absolute maximum so one does not need
to do horizontal scrolling.

There must be some reason people like to have shorter docstrings than
the actual code.
- PEP8: 72 for comments, 79 for code
- Django code style: 79 for comments, 88 for code.

Could perhaps some day use same line length for code and comments, but
even with the 79 char limit the experience has been quite good and the
code looks easy to read in my opinion.

Refs:
https://peps.python.org/pep-0008/
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style

pyproject.toml

@@ -115,8 +115,13 @@ exclude = [
 # Allow unused variables when underscore-prefixed.
 dummy-variable-rgx = "^(_+|(_+[a-zA-Z0-9_]*[a-zA-Z0-9]+?))$"
 # Enable pycodestyle (`E`) and Pyflakes (`F`) codes by default.
-select = ["E", "F"]
+# W505: doc-line-too-long. Ref: https://docs.astral.sh/ruff/rules/doc-line-too-long/
+select = ["E", "F", "W505"]
 ignore = []
 # Allow autofix for all enabled rules (when `--fix`) is provided.
 fixable = ["ALL"]
 unfixable = []
+
+[tool.ruff.lint.pycodestyle]
+# limits docstring and comments to 79 characters.
+max-doc-length = 79

wakepy/core/activation.py

@@ -375,10 +375,10 @@ def check_methods_priority(
 def _iterate_methods_priority(
     methods_priority: Optional[MethodsPriorityOrder],
 ) -> typing.Iterator[Tuple[str, bool]]:
-    """Provides an iterator over the items in methods_priority. The items in the
-    iterator are (method_name, in_set) 2-tuples, where the method_name is the
-    method name (str) and the in_set is a boolean which is True if the returned
-    method_name is part of a set and False otherwise."""
+    """Provides an iterator over the items in methods_priority. The items in
+    the iterator are (method_name, in_set) 2-tuples, where the method_name is
+    the method name (str) and the in_set is a boolean which is True if the
+    returned method_name is part of a set and False otherwise."""
 
     if not methods_priority:
         return
@@ -423,7 +423,10 @@ def get_prioritized_methods_groups(
     with names "A", "B", "C", "D", "E", "F":
 
     >>> methods = [MethodA, MethodB, MethodC, MethodD, MethodE, MethodF]
-    >>> get_prioritized_methods_groups(methods, methods_priority=["A", "F", "*"])
+    >>> get_prioritized_methods_groups(
+            methods,
+            methods_priority=["A", "F", "*"]
+        )
     [
         {MethodA},
         {MethodF},
@@ -486,9 +489,9 @@ def get_prioritized_methods(
     methods_priority: Optional[MethodsPriorityOrder] = None,
 ) -> List[MethodCls]:
     """Take an unordered list of Methods and sort them by priority using the
-    methods_priority and automatic ordering. The methods_priority is used to define
-    groups of priority (sets of methods). The automatic ordering part is used
-    to order the methods *within* each priority group. In particular, all
+    methods_priority and automatic ordering. The methods_priority is used to
+    define groups of priority (sets of methods). The automatic ordering part is
+    used to order the methods *within* each priority group. In particular, all
     methods supported by the current platform are placed first, and all
     supported methods are then ordered alphabetically (ignoring case).
 
@@ -843,19 +846,20 @@ class WakepyFakeSuccess(Method):
     def enter_mode(self):
         """Function which says if fake success should be enabled
 
-        Fake success is controlled via WAKEPY_FAKE_SUCCESS environment variable.
-        If that variable is set to a truthy value,fake success is activated.
+        Fake success is controlled via WAKEPY_FAKE_SUCCESS environment
+        variable. If that variable is set to a truthy value,fake success is
+        activated.
 
         Falsy values: '0', 'no', 'false' (case ignored)
         Truthy values: everything else
 
         Motivation:
         -----------
-        When running on CI system, wakepy might fail to acquire an inhibitor lock
-        just because there is no Desktop Environment running. In these cases, it
-        might be useful to just tell with an environment variable that wakepy
-        should fake the successful inhibition anyway. Faking the success is done
-        after every other method is tried (and failed).
+        When running on CI system, wakepy might fail to acquire an inhibitor
+        lock just because there is no Desktop Environment running. In these
+        cases, it might be useful to just tell with an environment variable
+        that wakepy should fake the successful inhibition anyway. Faking the
+        success is done after every other method is tried (and failed).
         """
         # The os.environ seems to be populated when os is imported -> delay the
         # import until here.

wakepy/core/dbus.py

@@ -91,8 +91,8 @@ class DBusMethod(NamedTuple):
         UINT64	t (116)	Unsigned 64-bit integer
         DOUBLE	d (100)	IEEE 754 double-precision floating point
         UNIX_FD	h (104)	Unsigned 32-bit integer representing an index into an
-                        out-of-band array of file descriptors, transferred via some
-                        platform-specific mechanism
+                        out-of-band array of file descriptors, transferred via
+                        some platform-specific mechanism
         STRING  s (115) String
 
     Ref: `dbus-specification <https://dbus.freedesktop.org/doc/dbus-specification.html>`_

wakepy/core/method.py

@@ -151,11 +151,12 @@ def caniuse(
 
         # Examples
         # --------
-        # - Test that system is running KDE using DBusMethodCalls to some service
-        #   that should be running on KDE. Could also test that the version of
-        #   KDE is something that is needed.
+        # - Test that system is running KDE using DBusMethodCalls to some
+        #   service that should be running on KDE. Could also test that the
+        #   version of KDE is something that is needed.
         # - If a Method depends on availability of certain software on PATH,
-        #   could test that it exist on PATH. (and that the version is suitable)
+        #   could test that it exist on PATH. (and that the version is
+        #   suitable)
 
     def enter_mode(self):
         """Enter to a Mode using this Method. Pair with a `exit_mode`.

wakepy/core/mode.py

@@ -147,8 +147,9 @@ class Mode(ABC):
         information about the activation process.
     dbus_adapter:
         For using a custom dbus-adapter. Optional. If not given, the
-        default dbus adapter is used, which is :class:`~wakepy.dbus_adapters.jeepney.JeepneyDBusAdapter`
-    """  # noqa: E501
+        default dbus adapter is used, which is :class:`~wakepy.dbus_adapters.\\
+        jeepney.JeepneyDBusAdapter`
+    """
 
     method_classes: list[Type[Method]]
     """The list of methods associated for this mode as given when creating the
@@ -178,7 +179,8 @@ class Mode(ABC):
     """
 
     dbus_adapter: DBusAdapter | None
-    r"""The DBus adapter used with ``Method``\ s which require DBus (if any)."""
+    r"""The DBus adapter used with ``Method``\ s which require DBus (if any).
+    """
 
     _controller_class: Type[ModeController] = ModeController
 

wakepy/methods/__init__.py

@@ -15,8 +15,8 @@
 (1) If a method needs D-Bus and GNOME, it is listed in gnome.py since GNOME is
     a desktop environment.
 (2) If a method needs a hypothetical (not well known) programX and systemd and
-    D-Bus, it is listed under programx.py, because programX is the "most specific"
-    or "least widespread" software.
+    D-Bus, it is listed under programx.py, because programX is the "most
+    specific" or "least widespread" software.
 (3) If a method needs systemd and D-Bus, it is listed under systemd, as D-Bus
     is more widespread than systemd, and you may have D-Bus without systemd
     but not vice versa.