GeezerVison

Suggestion on wording: "...which validates the element or element tree names and values only contain allowed/escaped characters prior to serialization"

No, this is not good. Characters should not be escaped prior to serialization. Element tree has no names, I wrote "the element or element tree" because some methods/functions serialize an element, and others work with the element tree. We check not only for invalid characters, but for invalid sequences of characters, and some characters/sequences can only be invalid at the start or the end of the name or content.

I updated the entry according to description proposed by @ezio-melotti.

Similarly the other error messages could specify what is invalid.

We perhaps should also forbid the surrogate codes. They are not explicitly mentioned in the tokenizer definition, unlike to the null character, but they are invalid in all standard encodings, and using numeric references for them is also invalid (https://html.spec.whatwg.org/multipage/parsing.html#numeric-character-reference-end-state).

As for what invalid, it is not always easily accessible. xml.is_valid_name() and xml.is_valid_text() simply return a boolean.

We could include the name of the parent element, but this may complicate the code to handle special cases of undefined or None.

We perhaps should also forbid the surrogate codes. They are not explicitly mentioned in the tokenizer definition, unlike to the null character, but they are invalid in all standard encodings, and using numeric references for them is also invalid (https://html.spec.whatwg.org/multipage/parsing.html#numeric-character-reference-end-state).

As for what invalid, it is not always easily accessible. xml.is_valid_name() and xml.is_valid_text() simply return a boolean.

We could include the name of the parent element, but this may complicate the code to handle special cases of undefined or None.

Usually new parameters are added to the end, so the order gives an idea when a parameter was added. Why not putting it at the end? (It only matters for the documentation.)

If all parameters was keyword-only, I would place method and validate before other options, because they are more general and important. But keyword-or-positional parameters should keep their position, so I can only change order of validate and short_empty_elements.

Your arguments are also valid. I'll, change the order.

I don't understand method="text" case. Does it force validate to False? How is it different from the default behavior (validate=False)?

validate has no effect for method="text".

"invalid comment" error can be raised in 3 very different cases. Would it be possible to give the reason in the error message? For example: "invalid comment: illegal character U+0000". Same remark for _serialize_html().

We do not know what character is invalid. We need to reimplement is_valid_text and is_valid_name to get such information.

What is the purpose of + in [range]*+? Why not just writing [range]*?

Similar question on [range]++ below: re.fullmatch('[^\0\t\n\r\f />=\ud800-\udfff]++', k).

Microoptimization. It disables backtracking.

For for example, we check the name "a0123456789/". The RE engine first matches prefix "a0123456789", but this is not the entire string, it backtracks:

• prefix "a012345678" matches, is this the entire string?
• prefix "a01234567" matches, is this the entire string?
• prefix "a01234567" matches, is this the entire string?
• ...

We perhaps can make the RE engine smarter and automatically detect such pattern, but this is a separate issue.

Would it be possible to mention the first invalid character in the error message? Otherwise, it can be tricky to debug such issue.

To do this, we need to murder is_valid_text and pull his insides out.

Or have is_valid_text / new function validate_text raise the exception directly.

This can be done in a following issue, after we get more examples of its use.