> Minor nit about this idea: it makes decoding repr() style
> strings harder for external tools and it could cause breakage
> (e.g. if "\n" is usedby the encoding for some other purpose).
Such a tool would be broken. If it accepts string literals it should
accept all forms of escapes.
> BTW, since there are a gazillion ways to encode strings into
> 7-bit ASCII, why not use the new codec design to add additional
> output schemes for 8-bit strings ?!
>
> Strings have an .encode() method as well...
Good idea! This could also be used to "hexify" a string, for which
currently one of the quickest ways is still the hack
"%02x"*len(s) % tuple(s)
--Guido van Rossum (home page: http://www.python.org/~guido/)
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