Thursday, 2024-02-15

opendevreviewMerged openstack/election master: Create candidates/2024.2 placeholder directories  https://review.opendev.org/c/openstack/election/+/90902503:56
opendevreviewVladimir Kozhukalov proposed openstack/election master: Add Vladimir Kozhukalov candidacy for Openstack-Helm 2024.2 PTL  https://review.opendev.org/c/openstack/election/+/90906704:49
opendevreviewSylvain Bauza proposed openstack/election master: Sylvain Bauza candidacy for TC  https://review.opendev.org/c/openstack/election/+/90907609:35
opendevreviewMichal Nasiadka proposed openstack/election master: [2024.2] Add mnasiadka candidacy for Kolla  https://review.opendev.org/c/openstack/election/+/90907810:09
opendevreviewAndrey Kurilin proposed openstack/election master: Andriy Kurilin(andreykurilin) PTL Candidacy for Rally  https://review.opendev.org/c/openstack/election/+/90907910:17
opendevreviewAndrey Kurilin proposed openstack/election master: Andriy Kurilin (andreykurilin) PTL Candidacy for Rally  https://review.opendev.org/c/openstack/election/+/90907910:17
opendevreviewJake Yip proposed openstack/governance master: Update jakeyip email  https://review.opendev.org/c/openstack/governance/+/90908010:17
opendevreviewAmy Marrich proposed openstack/election master: Adding Amy Marrich candidacy for TC  https://review.opendev.org/c/openstack/election/+/90911213:17
mnaserJayF: i appreciate your thought / message of "do instead of ask to do"17:27
JayFmnaser: I read the reply from fungi and it struck me as incredibly correct and so I took his idea and wrote more words about it 17:38
mnaserJayF: i do think it is sometimes important to recognize sometimes in openstack "do" is also hard17:38
mnaseri think some rules like two cores merging / etc are making things slower to move /shrug17:39
JayFThe correct "do" to solve that problem is to become more active in governance and push for the solutions that you think are the best. I'll note that we've only recently begun having TC elections that had any opposition at all17:40
JayFSetting policies that reflect the current state of our project instead of the state it was in 5 years ago is maybe more difficult IME than any technical problem I've tried to tackle.17:41
JayFThe key of it being that one line in my email: getting people to agree on what direction forward is17:41
JayFFor instance, just like one might push a patch to a bug, if you think there's a problem with an existing policy, I think some of the best way to encourage actionable debate about it is to propose a change and put it up for debate and a vote17:42
clarkbits also worth noting that some projects have taken the initiative and are running mypy with type annotations in their codebase. nothing prevents this today17:43
dansmithyep, nova does17:43
clarkbSure having broad acceptance would be an improvement, but you are already empowered to do so17:43
mnaseryeah i agree, if you want to do it, go ahead and do it, i don't think anyone will be unhappy about that17:44
dansmithit finds some useful stuff, but it also makes it really difficult to do things that are totally fine and normal in python, but has to be expressed verbosely to get mypy to allow it17:44
mnaseryeah, it does make things a little tougher i agree17:44
dansmithit's so counter to the spirit of python (IMHO) that I surely don't want to make it an expectation, but let people do it if they want/see value17:44
clarkbI gave up on mypy when it wouldn't let me conditionally use the c yaml classes without turning off type checking. So I turned it off :)17:44
JayFI like the idea of type annotations, in practice the tooling is very difficult especially for a non-greenfield project17:45
dansmithclarkb: yeah, it also really clutters up the code, IMHO17:45
dansmithit's nice that it helps with IDEs, but no actual checking except for an external tool makes it pretty meh for me17:45
clarkbthat struggle with mypy is why i made a note of alternatives. I do wonder if some of the alternatives might be more flexible and pythonic17:46
clarkbbut I have no idea17:46
dansmithwell, type checking in itself is not pythonic, IMHO :)17:46
fungii like the idea of typed variables in typed languages. i like python *for* its concept of duck-typing, not in spite of it17:48
dansmithyeah17:48
fungii feel like some of the people who have pushed hard to more deeply adopt typing in python would rather be using a different programming language where that is the norm17:49
dansmitheven in languages where it's a core feature/requirement, nowadays I find myself fighting against it and using "void *" for things that are trivially easy in python.. *especially* when it comes to testing17:49
dansmithfungi: yeah that's my argument exactly.. if you want to do that stuff, do it with a language that values it17:49
fungii also think it's worth noting that for the cpython stdlib, type annotations are not maintained in the source code by the core devs, but instead are relegated to a separate "typeshed" maintained by another set of people who want to have it. any time merging type annotations into the cpython stdlib comes up, there is substantial pushback from the core devs. if a majority of the cpython17:51
fungimaintainers don't consider integrated type annotations valuable, then that's a pretty bold statement17:51
clarkbthis is neat pytype does type inference and can even emit .pyi files17:52
clarkbThat mgiht be a lightweight way of getting what people want in IDEs without changing the code17:52
dansmithfungi: indeed17:52
clarkbpytype also claims to be lenient and not strict which might address my conditional import complaints17:53
dansmithright, because the best typing is non-strict typing... :P17:53
clarkbdefinitely seems like this could be useful particualrly for the IDE case17:53
clarkband not impact codebases17:54
dansmithyeah, that's really all I care for, is the IDE hinting17:54
dansmithnot sure if vscode supports it though17:54
dansmithI've love to rip out all the inline typing in nova for external files, but I suspect I'd lose that argument17:56
dansmithin part because it's also pushing us to a 500-char line width, which I also hate17:57
fungia few years back, folks interested in type annotations started trying to add them to zuul's codebase. the maintainers accepted the offer as an experiment, but the experience was that we spent more time fighting the type checker than we saved identifying latent bugs, and the resulting code was far less readable as well. i doubt we reached even 20% coverage of the codebase before we turned17:58
fungioff mypy jobs in frustration, declared the experiment failed, and instituted a policy of cleaning up any existing annotations whenever an already annotated block of code was touched for other reasons17:58
dansmithnice17:59
dansmithmypy has found a few issues for me in various places (not nova) but rarely type related and more just because it has some more solid static analysis stuff17:59
fungii suppose the question is whether it caught problems that, e.g., pyflakes would have missed18:00
fungi(not that pyflakes is a barrel of fun either)18:00
dansmithyeah, idk.. they were things that I thought flake8 would have caught but didn't18:01
dansmithas in, they were in the realm of simple stuff that flake8 often finds18:01
JayFI know for pycharm, at least, it understands pydocs when you put types in the params18:16
JayFthat's why I always have tried to encourage that in Ironic18:16
clarkbunfortunately trying to run pytype against zuul produces a number of these errors in the generated pyi files https://google.github.io/pytype/errors.html#pyi-error18:22
clarkbwhich they indicate is likely a bug in pytype itself18:22
clarkbits type inference also seems to fail when you redefine things in stdlib18:25
dansmithyeah, most IDEs understand the old-school types-in-comments stuff18:38

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!