The ElementTree module (xml.etree) avoids the XML declaration for "utf-8" and "us-ascii" codecs, but not for the "ascii" encoding.

Attached patch avoids the XML declaration for the "ascii" codec since it's a subset of UTF-8 and UTF-8 is the default encoding of XML.

The patch also normalizes the encoding name to handle aliases like "utf8" (UTF-8) or "us_ascii" (ASCII).

The patch adds unit tests.

--

By the way, I'm surprised that the special encoding "unicode" relies on the *current* locale encoding when the XML declaration is requested. Why not alway susing UTF-8 for *unicode* instead of the locale encoding?

My unit test tests different locale encodings.

Note: I found the "us-ascii" special case when reviewing the issue #27915 which proposed to replace "us-ascii" with "ascii" in the xml.etree module to use the Python fast-path for performance.

> By the way, I'm surprised that the special encoding "unicode" relies on the *current* locale encoding when the XML declaration is requested. Why not alway susing UTF-8 for *unicode* instead of the locale encoding?

Because it is usually outputs to sys.stdout or a file opened with default encoding. Agreed, the current locale encoding is not the best choice. It would be better to look at the encoding attribute of the file and fallback to utf-8 or ascii.

> By the way, I'm surprised that the special encoding "unicode" relies on the *current* locale encoding when the XML declaration is requested.

That seems a weird choice. Since it serialises to a Unicode string, it shouldn't have any XML declaration at all, if only to make it easy for users to add one themselves if they feel like it.

I guess it's too late to change that now, though...

New patch:

* Avoid codecs.lookup() for method != "xml"
* More unit tests

I lost track of this change. I'm not sure why I proposed it, and I don't feel confortable to change the ElementTree code :-/ I fear a regression, so I prefer to abandon my change.