Stop introspecting rawdata after Python 3.14.7 internal buffering added. - #168
Stop introspecting rawdata after Python 3.14.7 internal buffering added.#168ianjosephwilson wants to merge 2 commits into
Conversation
| raise ValueError( | ||
| "Parser expects more data, is the template valid html?" | ||
| ) | ||
| super().close() |
There was a problem hiding this comment.
An internal flush has to be forced here so super.close() is called at the top.
|
@davepeck I think I prefer this. We can start something up at python hq and see if there is an official mechanism that could be exposed and if that doesn't work out then we can bring back the other PR or something else. |
| raise ValueError( | ||
| "Parser expects more data, is the template valid html?" | ||
| ) | ||
| super().close() |
| def close(self) -> None: | ||
| if self.waiting_for_data(): | ||
| # We apply heuristics here to try to guess why the parser didn't finish. | ||
| if self.rawdata.count('"') % 2 == 1 or self.rawdata.count("'") % 2 == 1: |
There was a problem hiding this comment.
I don't mind losing this.
That said, if we wanted to restore this behavior, I suppose we could:
- Join our entire (with-placeholders) string and call
feed()exactly once, and remember its length - Before calling
close(), callgetpos()and see if there's still a bit of content left - Run something like this check on the remaining content
There was a problem hiding this comment.
The result is pretty confusing, especially something like html(t'''<div id='1"></div>''') == ''.
It also breaks our placeholder tracking. Kind of a bummer. Maybe it won't happen very often because most people will be using an editor that will highlight the asymmetry of the quotes. I think the fact we are parsing small fragments is a disadvantage in this situation though because it exacerbates this type of mistake. This catches that we didn't use the placeholder but the user probably doesn't understand why: html(t'''<div id='{True}">''') raises ValueError: Some placeholders were never resolved..
A short test of your idea and it seems to work(!) but we are still implicitly depending on the implementation because we assume the buffering doesn't take place until after the first feed. We know that... because it says so in the source! Although if the threshold was higher then it might not parse at all. Seems like a really big implementation change on the stdlib's part which makes me nervous. Maybe this will just have to be a "gotcha" for a while...
I wonder where a good place to bring this up would be, a feature request on the issue tracker seems like it would get put on ice forever. Maybe starting a discussion on discuss.python.org? I'm an optimist on Thursdays.
|
@ianjosephwilson agree this is the better approach. We should probably add a true regression test for 166: def test_issue_166():
template = t"<button disabled={True}>x</button><button disabled={True}>y</button>"
expected = "<button disabled>x</button><button disabled>y</button>"
assert html(template) == expectedOther than that, happy to merge this one (and vastly prefer it over #167 !) |
|
I realized that this doesn't actually update |
2 participants
We were introspecting
rawdatato try to detect at least this error:https://html.spec.whatwg.org/multipage/parsing.html#parse-error-eof-in-tag
Especially in the case of a dangling quote:
html(t'<div x="{1}></div>').This PR just cuts all that out and we lose some user experience but drop our dependency on
rawdata.