-
Notifications
You must be signed in to change notification settings - Fork 12
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
Refactor element declarations. #39
Conversation
Sorry but can somebody please explain why that pre-commit is failing? It says ruff "Found 1 error" but it does not say what the error is?! Also, the mypy/pyright errors seem to be something else? |
1. The void_elements were identically defined in two different files. This PR moves them to 1 file. 2. Better to define the element names in a table and loop over that table to create the elements (exploiting globals()) rather than use explicit code per element.
Ran pre-commit, then ruff, locally and found error was:
I copied that comment from the original Later edit: OK, E501 inhibits the line length check which was not applicable to me new lines because I wrapped them. Have force-pushed to fix this. Would be good if somebody fixed the CI though so users can see the error messages. |
The mypy and pyright tests are failing because they can not determine def test_void_element() -> None:
element = input(name="foo")
assert_type(element, VoidElement)
assert isinstance(element, VoidElement) mypy and pyright fail on the static |
Hey @bulletmark , thanks for the PR! assert_type is used to ensure that the static types as seen by mypy/pyright aligns with the run-time types. That is why both checks are performed. Static type checkers cannot understand To avoid the duplication of the _void_elements in html2htpy, something like this could be used: _void_elements = {
element._name for element in htpy.__dict__.values() if isinstance(element, htpy.VoidElement)
} I am skeptical of that too though since it makes it harder to read the code for a small win in DRYness. The HTML elements does not change that often that this is a big burden to update the list in two places. Are there other ways these changes improves the code? |
@pelme , note the type checkers are not a problem here. Both Seems a shame though that keeping that constraint means you have to duplicate that |
You PR does make it more DRY and avoids some duplication. I have however put quite some effort into getting htpy to play nicely with types, that is a big reason for its existence, so I do not want to compromise on the types in this case. The difference between VoidElement and Element is that VoidElement does not implement getitem but it is still a difference that I want to keep. In 2f3ca97, I removed the hard coded void element names, so they are not duplicated anymore and there is no possibility of forgetting to updated them in two places whenever there is a new HTML void element. Thanks for your PR and desire to improve htpy but I will close this PR for now. 🙏 |
@pelme regarding your statement "I removed the hard coded void element names, so they are not duplicated anymore and there is no possibility of forgetting to updated them in two places whenever there is a new HTML void element" - note that both changes I did here were simply about making the code look better. I don't consider it likely at all that somebody would forget to add a new element in both places. It is just that replicated data structures, and multi-replicated code lines in the other change, are quite ugly. Code is not just about function, but also about style and aesthetics. That change you did looks much better though and I am completely fine that you chose to close this PR. |
The void_elements were identically defined in two different files. This PR moves them to 1 file.
Better to define the element names in a table and loop over that table to create the elements (exploiting globals()) rather than use explicit code per element.