> So far, noone has commented on this idea. > > I would like to go ahead and check in patch which passes through > Unicode objects to the file-object's .write() method while leaving > the standard str() call for all other objects in place. > I'm behind this in principle. Here's an example of why: >>> tokyo_utf8 = "??" # the kanji for Tokyo, trust me... >>> print tokyo_utf8 # this is 8-bit and prints fine æ±äº¬ >>> tokyo_uni = codecs.utf_8_decode(tokyo_utf8)[0] >>> print tokyo_uni # try to print the kanji Traceback (innermost last): File "<interactive input>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) >>> Let's say I am generating HTML pages and working with Unicode strings containing data > 127. It is far more natural to write a lot of print statements than to have to (a) concatenate all my strings or (b) do this on every line that prints something: print tokyo_utf8.encode(my_encoding) We could trivially make a file object which knows to convert the output to, say, Shift-JIS, or even redirect sys.stdout to such an object. Then we could just print Unicode strings to it. Effectively, the decision on whether a string is printable is deferred to the printing device. I think this is a good pattern which encourages people to work in Unicode. I know nothing of the Python internals and cannot help weigh up how serious the breakage is, but it would be a logical feature to add. - Andy Robinson
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