Conversation
|
@pelme Haven't had a chance to work on this further, but does this seem like a reasonable approach? We end up with a pretty gigantic file, but it seems like that's what's necessary for best class autocomplete/static analysis. |
|
Still plan to look at this some more when I get the time. Seems like maybe https://html.spec.whatwg.org/ is a better source to scrape elements/attributes from. MDN doesn't seem to be as up to date. |
|
If we go this route, maybe we should use pyi files for typing and get rid of typing from the .py files altogether. Making a bunch of subclasses/overloading call may cause performance problems. In the beginning of htpy I had separate .pyi and .py files but it was easier to just keep them the same: c3afb62 Then we would be certain that these huge files would not affect import times or runtime performance. Btw, the "typing council" recommends to accept PEP 728: python/typing-council#22 (comment) so hopefully there will be some movement there. But that will earliest land in Python 3.15 so there will be years before everyone can use it anyways. |
|
I was starting to wonder if this could be better handled with ide plugins that could delegate to the HTML completer. I'm doing some experimentation, but that is further out of my wheelhouse so we'll see how it goes. |
|
it would be nice to solve it at the python level, maintaining plugins for all sorts of IDEs seems very annoying at best 🙂 but maybe that could provide richer HTML completion than type hints can provide |
This is a very messy, and unfinished, implementation for #122 to allow some initial discussion
Goals:
I did a couple parts here:
Things are very messy at the moment, just wanted to put initial work up for discussion.
TODO:
__call__method of subclasses of Element don't match the base class. Is this a real problem? What to do?