> > I'm unable to think of an instance where typing in python could have > helped me,
Discoverability, IDE integration, more primitives to describe your intent in your code to other maintainers, and shifting a certain class of runtime errors to being "merge-time" errors all come to mind. There's a significant implication to the "rigorous vs. fast and loose" continuum with code you write using something like type hints and mypy vs. classic python, and we have an admitted problem with rigor in that codebase at this point. Admittedly, changes w/regards to typing and such aren't going to do much to address the deeper problems of non-deterministic execution, leaning heavily on sleeps for timing in tests, etc On Wed, Jan 26, 2022 at 11:41 AM bened...@apache.org <bened...@apache.org> wrote: > Python execution is obviously not a bottleneck, but cluster > startup/shutdown and lengthy waits due to lack of visibility to state > changes in the tests quite probably are. The python tests are also IME > quite rudimentary compared to their java equivalents, and more brittle, due > to worse tooling for e.g. data generation, interfering with message > delivery etc. > > > > They are also comparatively poorly maintained, due to most on the project > not wanting to touch them beyond what is necessary. It would be hugely > beneficial to migrate to a platform the majority uses, and that can produce > more powerful tests that are also able to execute faster (for reasons of > integration, not language). > > > > > > *From: *Brandon Williams <dri...@gmail.com> > *Date: *Wednesday, 26 January 2022 at 16:09 > *To: *dev <dev@cassandra.apache.org> > *Subject: *Re: Have we considered static type checking for our python > libs? > > On Wed, Jan 26, 2022 at 7:43 AM bened...@apache.org <bened...@apache.org> > wrote: > > I might even venture to predict that it might payoff with lower > development overhead, as we can run our tests much more quickly, and debug > failures much more easily. > > I don't think in practice these will happen at all, let alone 'much > more.' Python execution is nowhere near the bottleneck, not that > either of these would speed it up significantly. I'm unable to think > of an instance where typing in python could have helped me, at least > in the dtest tickets I've worked on. Maybe someone with more > experience has a different estimation? >
