Mark all packets as final #53
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ItsDrike
added
t: bug
ItsDrike
force-pushed
the
make-packets-final
branch
from
f6c044e
to
5e731a3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The packet classes weren't marked with
typing.final, which meant the existence of abstract methods wasn't enforced, as a type checker couldn't know whether this wasn't just an extension for the ABC, that's still abstract.By explicitly marking these with the
@finaldecorator, these packets will now be treated as the final (concrete) classes, and implementation of all abstract methods will be enforced.Marking these packets as final will also prevent subclassing them (type-wise), meaning any subclassing will need
# type: ignore. This does make sense, no matter what decision will be made in #45, as subclassing older packet classes from different versions, to avoid code repetition is LSP breaking, and so a need for a type ignore would be justified there anyway.