Pyhon 2.x or 3.x, which is faster?

Chris Angelico rosuav at gmail.com
Wed Mar 9 20:28:55 EST 2016


On Thu, Mar 10, 2016 at 11:58 AM, BartC <bc at freeuk.com> wrote:
>>> I'm not much interested in Unicode at the minute. I'll pass.
>
>
>> Your final comment sums up perfectly your knowledge of computing in
>> 2016.
>
>
> You're utterly determined to belittle everything I do aren't you!
>
> But, yeah, I was writing international applications decades ago. I'm not
> working for anyone now and don't need to bother.
>
> From what I've seen, a lot of software can't get it right anyway.

That would be because a lot of software is written by people who don't
understand Unicode. "But other people get it wrong too!" wasn't a
valid excuse when I was in grade school, and it still isn't in
real-world work. [1] If you are writing code in 2016 that assumes that
a byte is the same thing as a character, and speak as if this is
alright, then yes, we WILL belittle you for it. It's on par with
thinking that an integer is a 16-bit signed two's complement number.
Sure, back in the 1990s, you could probably get away with that (and
you'll find a lot of games that flip at 32,767 or 65,535 - or, in one
that I remember, at 3,276,700!), but nobody today would let you
pretend that those are identical. Neither is a list identical to a
coherent block of memory (the way a C array often is implemented) -
and neither is a text string identical to a stream of bytes. Even if
you're restricting your text to the ASCII set, there is still an
encoding involved; a typical C string's encoding is "one character per
byte, followed by 0x00", whereas a Pascal string's encoding might be
"one character per byte, preceded by the character count, represented
in a single byte". Every encoding has consequences, every encoding has
costs. You can't get away from this. You can't pretend that you don't
have an encoding.

ChrisA

[1] Except when you're specifically writing compatibility code, where
getting it identically wrong means your program successfully
interoperates with someone else's buggy code. But if you're doing
that, I pity you. That is not a fun job to have.



More information about the Python-list mailing list