-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
various cleanups for typing stuff #19270
various cleanups for typing stuff #19270
Conversation
The failure is tricky: we expect the In any case, that's not what I intended to do and it needs to be cleaned up. Yay for catching bugs? |
Indeed, the current behaviour of the Python bridge would cause problems with C peers, for example. |
7fc5ddf
to
e600ebb
Compare
@allisonkarlitskaya @jelly seems this was very close to landing, and then slipped through the cracks 😢 It's conflicty, and by now I suppose it will also conflict with #19668. Moving to draft. |
Start building a list of files in src/cockpit which are clean under `mypy --strict` to ensure that we don't regress. The end goal is to have all of `src/cockpit` strictly typed.
At one point we wanted to implement this as a BufferedProtocol, where a memoryview would have likely been advantageous. We went with our current "dumb" bytes-based approach instead, and haven't found any egregious performance problems there, so let's remove the code that could theoretically deal with memoryview. Maybe we'll do something more intelligent at some point in the future. We also lift a check on the value being non-empty to the loop in the calling function. This is not strictly required, but speeds things up in the EOF case.
e600ebb
to
ee953dc
Compare
This file is now clean under `mypy --strict`.
Since 747e7c2 we have the ability to send verbatim JSON objects as control messages, which we do when forwarding channel control messages to peers. Until now, we haven't applied the same handling for 'kill' messages because we haven't had access to the message object in order to be able to forward it. This means that we've been unintentionally breaking protocol: the current way we construct the control message from kwargs, we always send up sending both "host" and "group", even if one of them is `null`, which is a violation of protocol (these should either be strings, or absent). Let's wire the original message through and send it verbatim: this will help us in the next commit when we start enforcing type safety on kill message parameters.
Drop the manual error checking on 'init' messages and avoid the total lack of error checking for 'kill' and 'authorize' messages.
ee953dc
to
d4bfd9a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Mostly looks good. If you want to land this quickly, please do, but I'd appreciate a follow-up (no-test) to put back the comment.
# We know the length + newline is never more than 10 bytes, so just | ||
# slice that out and deal with it directly. We don't have .index() on | ||
# a memoryview, for example. | ||
# From a performance standpoint, hitting the exception case is going to | ||
# be very rare: we're going to receive more than the first few bytes of | ||
# the packet in the regular case. The more likely situation is where | ||
# we get "unlucky" and end up splitting the header between two read()s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That comment is still current, other than the "we don't have .index" bit. But it's useful to explain the magic number 10 below, as well as splitting reads in between a number.
This review is stale (requested changes already made)
This enables
mypy --strict
on a handful of files. This was all fairly straight-forward.In general, we need to proceed from the bottom of the dependency tree upwards. That means that the next targets are:
We're stuck on config because systemd_ctypes dbus stuff isn't
--strict
friendly. We're stuck on router because the 'freeze' mechanism is pretty evil from a types perspective and I kind of want to get rid of it anyway.Let's get these "easy" ones in now.