Thanks for starting a discussion about the (Python) stack as a whole and
not just making this about using Python 3.9 vs. 3.12....

OpenStack is a well established cloud software stack and just like the
Python interpreter and whole ecosystem is relies on,
it should embrace new capabilities and not just move if there is an
unavoidable breaking change.

Subjectively there has been quite some developer drain or let's say the
amount of patches by new developers seems
lower than years ago. Quite a few projects died with not replacement.
The community has been very capable if an external change (Death of
Python 2.7, SQLAlchemy 2.x, eventlet EoL, ....)
forced some reaction or adaption. But does it really require some
external force for some kind of modernization?
Why is OpenStack is not pushing ahead in and out of itself? For the sake
of one's own quality standards, but also
to ensure the whole ecosystem remains vital and and attractive to new
new developers?



On 13.02.24 13:27, Niklas Schwarz wrote:
> A modern and up to date static code analysis:
> Currently flake8 and pylint are used both of which are modern analysis
> tools. But their configuration is in my opinion
> not up to date. Lets have a look at the configuration of the
> neutron-lib [6]. As seen a lot of rules are disabled
> by the configuration and are needed at the current moment at the state
> of the project. In addition some rules
> need to be adjusted such as the line length (80 characters is a very
> aggressive limit and on most modern
> displays a line length of 100 to 120 can fit without any problems,
> personal opinion).
> The adjustment of the static code analysis besides opinionated rules
> will lead me to my third point to modernize
> the Python stack used
> Introduce type annotations
> [...]
> The type hints can and in in my experience will reduce the
> introduction of
> bugs (accessing members or calling methods, no logical bugs) and will
> shorten the time to develop a new
> feature or fix a logical bug and do not run in runtime exceptions.



I can only second Niklas' reference to the PEP 484 ([2]) and its rationale:

> This PEP aims to provide a standard syntax for type annotations,
> opening up Python code to easier static analysis and refactoring,
> potential runtime type checking, and (perhaps, in some contexts) code
> generation utilizing type information.
> Of these goals, static analysis is the most important. This includes
> support for off-line type checkers such as mypy, as well as providing
> a standard notation that can be used by IDEs for code completion and
> refactoring.
>
an this is from 2014, so about 10 years ago.

While unit and functional tests allow people to move faster in writing
their code,
be it a bugfix or feature as they quickly see if their code breaks
stuff. But having static code analysis as a first line of defense is a must.
Continuing to allow more un-typed variables, references and interfaces
limits the good those kind of tools can do.



If I may quote an reply to an old post to the ML ( [1]) about the
introduction of "black" formatter:

On 18.4.19 19:04, Clint Byrum wrote: :

> The main value is that using an automatic formatter will ultimately lead
> to less wasted test runs, less wasted developer time, and better diffs
> with less conflicts later.
>
> So while I appreciate the desire to not rock the boat, it might be that
> the boat would go faster after some dead weight is dropped overboard,
> and that new energy is applied to forward progress instead of "darn it,
> now I have to think about how to fit this into 80 chars and parenthesis
> and ..."
>
> Basically, weigh the one time cost vs. the ongoing savings, rather than
> considering them separately.


Agreeing on a set of rules then set in stone (or rather the config of
formatter, linters and static code analysis tools)
increases the quality of the code, makes it more approachable to new
devs and allows reviewers to focus more on the
logic and functional part of submitted code. And what's the downside of
moving into this direction really?

* A big initial reformatting commit that makes it harder to then
backport changes to older releases?
* Introducing types to older code and identifying issues this way?
* Static code analysis throwing lots of warnings?

Regards

Christian



[1]
https://lists.openstack.org/pipermail/openstack-discuss/2019-April/005364.html
[2] https://peps.python.org/pep-0484/#rationale-and-goals