Martin v. Loewis wrote:
> Walter Dörwald <walter@livinglogic.de> writes:
>
>
>>A recent checkin added a function PyString_DecodeEscape()
>>to stringobject.c. To make this function PEP293 compatible
>>it would need access to unicode_decode_call_errorhandler
>>which is defined static in unicodeobject.c. Does
>>PyString_DecodeEscape() really need an errors argument?
>
>
> What do you mean, "really need"? The callers of this function pass the
> argument, in particular escape_decode. Is that "real"?
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="strict"?
>>If yes, we could either move it to unicodeobject.c
>
>
> No. It has to do little with Unicode.
>
>
>>or make unicode_decode_call_errorhandler externally visible.
>
>
> I don't know this function.
It's a static function in unicodeobject.c in the PEP293 patch
that does the complete error handling for decoding.
> What does this have to do with Unicode?
I expected that all codecs to unicode<->8bit coding/decoding
"string-escape" seems to be an exception.
>>Another problem that I noticed is that string-escape can't
>>be used for encoding Unicode objects:
>
>
> That is a feature. string-escape has nothing to do with Unicode.
So it doesn't need the new PEP293 error handling?
Bye,
Walter Dörwald
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