| opendevreview | Merged openstack/election master: Create candidates/2024.2 placeholder directories https://review.opendev.org/c/openstack/election/+/909025 | 03:56 |
|---|---|---|
| opendevreview | Vladimir Kozhukalov proposed openstack/election master: Add Vladimir Kozhukalov candidacy for Openstack-Helm 2024.2 PTL https://review.opendev.org/c/openstack/election/+/909067 | 04:49 |
| opendevreview | Sylvain Bauza proposed openstack/election master: Sylvain Bauza candidacy for TC https://review.opendev.org/c/openstack/election/+/909076 | 09:35 |
| opendevreview | Michal Nasiadka proposed openstack/election master: [2024.2] Add mnasiadka candidacy for Kolla https://review.opendev.org/c/openstack/election/+/909078 | 10:09 |
| opendevreview | Andrey Kurilin proposed openstack/election master: Andriy Kurilin(andreykurilin) PTL Candidacy for Rally https://review.opendev.org/c/openstack/election/+/909079 | 10:17 |
| opendevreview | Andrey Kurilin proposed openstack/election master: Andriy Kurilin (andreykurilin) PTL Candidacy for Rally https://review.opendev.org/c/openstack/election/+/909079 | 10:17 |
| opendevreview | Jake Yip proposed openstack/governance master: Update jakeyip email https://review.opendev.org/c/openstack/governance/+/909080 | 10:17 |
| opendevreview | Amy Marrich proposed openstack/election master: Adding Amy Marrich candidacy for TC https://review.opendev.org/c/openstack/election/+/909112 | 13:17 |
| mnaser | JayF: i appreciate your thought / message of "do instead of ask to do" | 17:27 |
| JayF | mnaser: 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 |
| mnaser | JayF: i do think it is sometimes important to recognize sometimes in openstack "do" is also hard | 17:38 |
| mnaser | i think some rules like two cores merging / etc are making things slower to move /shrug | 17:39 |
| JayF | The 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 all | 17:40 |
| JayF | Setting 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 |
| JayF | The key of it being that one line in my email: getting people to agree on what direction forward is | 17:41 |
| JayF | For 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 vote | 17:42 |
| clarkb | its also worth noting that some projects have taken the initiative and are running mypy with type annotations in their codebase. nothing prevents this today | 17:43 |
| dansmith | yep, nova does | 17:43 |
| clarkb | Sure having broad acceptance would be an improvement, but you are already empowered to do so | 17:43 |
| mnaser | yeah i agree, if you want to do it, go ahead and do it, i don't think anyone will be unhappy about that | 17:44 |
| dansmith | it 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 it | 17:44 |
| mnaser | yeah, it does make things a little tougher i agree | 17:44 |
| dansmith | it'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 value | 17:44 |
| clarkb | I 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 |
| JayF | I like the idea of type annotations, in practice the tooling is very difficult especially for a non-greenfield project | 17:45 |
| dansmith | clarkb: yeah, it also really clutters up the code, IMHO | 17:45 |
| dansmith | it's nice that it helps with IDEs, but no actual checking except for an external tool makes it pretty meh for me | 17:45 |
| clarkb | that struggle with mypy is why i made a note of alternatives. I do wonder if some of the alternatives might be more flexible and pythonic | 17:46 |
| clarkb | but I have no idea | 17:46 |
| dansmith | well, type checking in itself is not pythonic, IMHO :) | 17:46 |
| fungi | i like the idea of typed variables in typed languages. i like python *for* its concept of duck-typing, not in spite of it | 17:48 |
| dansmith | yeah | 17:48 |
| fungi | i 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 norm | 17:49 |
| dansmith | even 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 testing | 17:49 |
| dansmith | fungi: yeah that's my argument exactly.. if you want to do that stuff, do it with a language that values it | 17:49 |
| fungi | i 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 cpython | 17:51 |
| fungi | maintainers don't consider integrated type annotations valuable, then that's a pretty bold statement | 17:51 |
| clarkb | this is neat pytype does type inference and can even emit .pyi files | 17:52 |
| clarkb | That mgiht be a lightweight way of getting what people want in IDEs without changing the code | 17:52 |
| dansmith | fungi: indeed | 17:52 |
| clarkb | pytype also claims to be lenient and not strict which might address my conditional import complaints | 17:53 |
| dansmith | right, because the best typing is non-strict typing... :P | 17:53 |
| clarkb | definitely seems like this could be useful particualrly for the IDE case | 17:53 |
| clarkb | and not impact codebases | 17:54 |
| dansmith | yeah, that's really all I care for, is the IDE hinting | 17:54 |
| dansmith | not sure if vscode supports it though | 17:54 |
| dansmith | I've love to rip out all the inline typing in nova for external files, but I suspect I'd lose that argument | 17:56 |
| dansmith | in part because it's also pushing us to a 500-char line width, which I also hate | 17:57 |
| fungi | a 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 turned | 17:58 |
| fungi | off 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 reasons | 17:58 |
| dansmith | nice | 17:59 |
| dansmith | mypy 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 stuff | 17:59 |
| fungi | i suppose the question is whether it caught problems that, e.g., pyflakes would have missed | 18:00 |
| fungi | (not that pyflakes is a barrel of fun either) | 18:00 |
| dansmith | yeah, idk.. they were things that I thought flake8 would have caught but didn't | 18:01 |
| dansmith | as in, they were in the realm of simple stuff that flake8 often finds | 18:01 |
| JayF | I know for pycharm, at least, it understands pydocs when you put types in the params | 18:16 |
| JayF | that's why I always have tried to encourage that in Ironic | 18:16 |
| clarkb | unfortunately 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-error | 18:22 |
| clarkb | which they indicate is likely a bug in pytype itself | 18:22 |
| clarkb | its type inference also seems to fail when you redefine things in stdlib | 18:25 |
| dansmith | yeah, most IDEs understand the old-school types-in-comments stuff | 18:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!