At 03:08 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
Barry Warsaw writes:
> Would it make sense to have "encoding-carrying" bytes and str
> types?
I think the answer is "no", though, because (1) it would constitute an
attractive nuisance (the default would be abused, it would work fine
in Kansas, and all hell would break loose in Kagoshima, simply
delaying the pain and/or passing it on to third parties),
You have the proposal exactly backwards, actually.
In Kagoshima, you'd use pass in an ebytes with your encoding to a
stdlib API, and *get back an ebytes with the right encoding*, rather
than an (incorrect and useless) unicode object which has lost data you need.
Why limit that to bytes and str? Why not have all objects carry their
serializer/deserializer around with them?
Because it's not a serialization or deserialization. Your conceptual
framework here implies that unicode objects are the real thing, and
that bytes are "just" a way of transporting unicode around.
But this is not the case at all, for use cases where "no, really, you
*have to* work with bytes-encoded text streams". The mere release of
Python 3.x will not cause all the world's applications, libraries,
and protocols to suddenly work with unicode, where they did not before.
Being explicit about the encoding of the bytes you're flinging around
is actually an *increase* in specificity, explicitness, robustness,
and error-checking ability over the status quo for either 2.x *or*
3.x... *and* it improves these qualities for essentially *all*
string-handling code, without requiring that code to be rewritten to do so.
It's like getting to use the time machine, really.
and (2) you
really want this under control of higher level objects that have
access to some knowledge of the environment, rather than the lowest
level.
This proposal actually has such a higher-level object: an
ebytes. And it passes that information *through* the lowest level,
in such a way as to permit the stringlike operations to be fully
polymorphic, without the information being lost inside somebody else's API.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
