Le mer. 14 févr. 2024 à 11:26, Christian Rohmann < christian.rohmann@inovex.de> a écrit :
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?
FWIW, those three reasons are the main reasons why at least every cycle during the PTG, I'm very conservative for new formatting features in the Nova project. That's it for me, we already discussed this in the nova project during the last Caracal PTG and we had no consensus.
Regards
Christian
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2019-April/005364.ht... [2] https://peps.python.org/pep-0484/#rationale-and-goals