I don’t think this support would be very hard to add, if this is the only stumbling block.
From: Andrés de la Peña <a.penya.gar...@gmail.com> Date: Wednesday, 26 January 2022 at 14:10 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: Have we considered static type checking for our python libs? Last time I ported dtests during the 4.0 quality test epic there wasn't support for virtual nodes in in-jvm dtests. We have many Python dtests depending on vnodes that can't be totally ported if we still don't have support for vnodes, I don't know if it's still the case. On Wed, 26 Jan 2022 at 14:02, Joshua McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> wrote: Could be a very fruitful source of LHF tickets to highlight in the biweekly email and would be pretty trivial to integrate this into the build lead role (getting an epic and jira tickets created to port tests over, etc). we can run our tests much more quickly, and debug failures much more easily. Please Yes. If we can get away from python upgrade tests I think all our lives would be improved. I like it. On Wed, Jan 26, 2022 at 8:42 AM bened...@apache.org<mailto:bened...@apache.org> <bened...@apache.org<mailto:bened...@apache.org>> wrote: We could set this as a broad goal of the project, and like the build lead role could each volunteer to adopt a test every X weeks. We would have migrated in no time, I expect, with this kind of concerted effort, and might not even notice a significant penalty to other ongoing work. Last time I ported a dtest it was a very easy thing to do. 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. From: Joshua McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> Date: Wednesday, 26 January 2022 at 13:40 To: dev <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> Subject: Re: Have we considered static type checking for our python libs? I have yet to encounter this class of problem in the dtests. It's more about development velocity and convenience than about preventing defects in our case, since we're not abusing duck-typing everywhere. Every time I have to work on python dtests (for instance, when doing build lead work and looking at flaky tests) it's a little irritating and I think of this. I would hate to expend loads of effort modernising them when the same effort could see them superseded by much better versions of the same test. I completely agree, however this is something someone would have to take on as an effort and I don't believe I've seen anybody step up yet. At the current rate we're going to be dragging along the python dtests into perpetuity. On Wed, Jan 26, 2022 at 8:16 AM bened...@apache.org<mailto:bened...@apache.org> <bened...@apache.org<mailto:bened...@apache.org>> wrote: I was sort of hoping we would retire the python dtests before long, at least in large part (probably not ever entirely, but 99%). I think many of them could be migrated to in-jvm dtests without much effort. I would hate to expend loads of effort modernising them when the same effort could see them superseded by much better versions of the same test. From: Joshua McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> Date: Wednesday, 26 January 2022 at 12:59 To: dev <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> Subject: Have we considered static type checking for our python libs? Relevant links: 1) Optional static typing for python: https://docs.python.org/3/library/typing.html 2) Mypy static type checker for python: https://github.com/python/mypy So the question - has anyone given any serious thought to introducing type hints and a static type checker in ccm and python dtests? A search on dev ponymail doesn't turn up anything. I've used it pretty extensively in the past and found it incredibly helpful combined with other linters in surfacing troublesome edge cases, and also found it accelerated development quite a bit. Any thoughts on the topic for or against? ~Josh
