Martin von Loewis wrote:
>
> > is there any reason why "print" cannot pass unicode
> > strings on to the underlying write method?
>
> Mostly because there is no guarantee that every .write method will
> support Unicode objects. I see two options: either a stream might
> declare itself as supporting unicode on output (by, say, providing a
> unicode attribute), or all streams are required by BDFL pronouncement
> to accept Unicode objects.
I think the latter option would go a long way: many file-like
objects are written in C and will use the C parser markers. These
can handle Unicode without problem (issuing an exception in case
the conversion to ASCII fails).
The only notable exception is
the cStringIO module -- but this could probably be changed to
be buffer interface compliant too.
> BTW, your wrapper example can be rewritten as
>
> import sys,codecs
> sys.stdout = codecs.lookup("iso-8859-1")[3](sys.stdout)
>
> I wish codecs.lookup returned a record with named fields, instead of a
> list, so I could write
>
> sys.stdout = codecs.lookup("iso-8859-1").writer(sys.stdout)
>
> (the other field names would be encode,decode, and reader).
Why don't you write a small helper function for the codecs.py
module ?!
E.g. codecs.info("iso-8859-1") could provide an alternative interface
which returns a CodecInfo instance with attributes instead of
tuple entries.
Note that the tuple interface was chosen for sake of speed and
better handling at C level (tuples can be cached and are easily
parseable in C).
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: 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