Walter D=F6rwald <walter@livinglogic.de> writes:
> So does escape_decode need an errors argument. AFAICT
> escape_decode is used only in the context of reading pickles.
> Will there ever be a need to call escape_decode with anything
> other than errors=3D"strict"?
It's a codec, so anybody is entitled to write
"foo".decode("string-escape", "replace")
if they chose to. If you are suggesting that this is not supported is
only acceptable if you also suggest how it should fail. Silently
ignoring the "replace" argument is not acceptable.
> > What does this have to do with Unicode?
>=20
> I expected that all codecs to unicode<->8bit coding/decoding
> "string-escape" seems to be an exception.
That was my original expectation as well. By now, I have accepted
things like
>>> "foo".encode("base64")
'Zm9v\n'
So codecs can do way more things than converting between
unicode<->byte strings. Whether it is a good thing that they are that
flexible is still open to debate, however, it was convenient for
string-escape.
> So it doesn't need the new PEP293 error handling?
Probably not - just supporting "strict", "replace", "ignore", and
failing for any other error handling would be sufficient. If you
manage to make it fail for anything but "strict", that would be
acceptable as well (IMO).
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4