[Python-Dev] Allowing u.encode() to return non-strings

[Chermside, Michael]

> When looking for near-C speed, type inferencing is most important
> for a relatively small set of particularly efficiently manipulable
> types: most notably, smallish integers. Being able to prove that
> something is a Unicode object just isn't all that useful for
> efficiency, because most of the things you can do to Unicode
> objects aren't all that cheap relative to the cost of finding out
> what they are. Likewise, though perhaps a bit less so, for being
> able to prove that something is a string.

I think you may be missing an important special case here...
machines for which "unicode" is a machine-native type. Like the
JVM or .NET runtime. These machines are increasingly important,
and one of the two major implementations of Python runs on such
a machine. (I can't say "2 out of 3" because IronPython doesn't
count until it's released publicly.)

Of course, I *still* don't think that it makes all that much
difference. I agree with the folks who are saying that the
"functions generally return a known type" rule is useful not so
much because of optimization as because it helps the readability
of code. (And that's why obvious exceptions like construction
factories don't bother anybody.)

-- Michael Chermside


This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.