Ka-Ping Yee wrote: > > On Fri, 19 May 2000, Guido van Rossum wrote: > > The email below suggests a simple solution to a problem that > > e.g. Fran\347ois Pinard brought up long ago; repr() of a string turns > > all non-ASCII chars into \oct escapes. Jyrki's solution: use > > isprint(), which makes it locale-dependent. I can live with this. > > Changing the behaviour of repr() (a function that internally > converts data into data) based on a fixed global system parameter > makes me uncomfortable. Wouldn't it make more sense for the > locale business to be a property of the stream that the string > is being printed on? Umm, Jyrki's patch does *not* affect repr(): it's a patch to the string_print API which is used for the tp_print slot, so the only effect to be seen is when printing a string to a real file object (tp_print is only used by PyObject_Print() and that API is only used for writing to real PyFileObjects -- all other stream get the output of str() or repr()). Perhaps we should drop tp_print for strings altogether and let str() and repr() to decide what to do... (this is what Unicode objects do). The only good reason for implementing tp_print is to write huge amounts of data to a stream without creating intermediate objects -- not really needed for strings, since these *are* the intermediate object usually created for just this purpose ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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