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

[Chris Angelico]

On Thu, Mar 10, 2016 at 10:14 AM, BartC <bc at freeuk.com> wrote:
> On 09/03/2016 21:13, Mark Lawrence wrote:
>>
>> On 09/03/2016 12:02, BartC wrote:
>>>
>>> On 09/03/2016 08:40, Mark Lawrence wrote:
>>>
>>> Here's another: you have a program in Python that you'd quite like to
>>> port to another dynamic language. Transcribing actual Python code is
>>> straightforward. Until you come to an import of a module that you can't
>>> find, because it's not written in Python. Now what? Now, you might
>>> appreciate the advantage of a program in 100% pure Python.
>>>
>>
>> That is not Python's problem, or my problem, that is your problem.
>
>
> Maybe that's not the best example of why someone might prefer a 'Python'
> program to be actually written in Python. Sometimes you want to understand
> how code works or what it does or simply to learn from it. (Or sometimes, to
> rip bits off.) Then it's frustrating when you come up against a dead-end so
> quickly. Because the real meat isn't in Python at all.

What *is* the real meat of a program? Every action is defined in terms
of smaller actions - a Python program is built out of Python
primitives and function calls, a C program is built out of C
primitives and function calls, an 80x86 machine code program is built
out of 80x86 CPU instructions and calls to other code. Does my MUD
server need to have its own memory allocation code? No. Does it need
an algorithm for adding two integers together? Certainly not! And nor
does it need PNG encoding and decoding algorithms; I simply call on
Image.PNG.encode() and Image.PNG.decode() to do the work, passing
images around in my code as first-class objects. Does it detract from
my code? Not in the least. My code treats "load an image from a PNG
file" as a fundamental operation, and gets on with doing its stuff.

Reinventing the wheel does NOT intrinsically make your code better.
Unless there's something you're doing that's fundamentally different
from what's already available (maybe a database client that uses
non-blocking sockets with async/await), it's usually better to use
what someone else has written. I'd much rather use a one-liner that
reads an image from the disk than wade through your pages and pages of
bitshift operations in Python (especially as it's all uncommented -
how can I know if it's even correct, other than by finding a reference
algorithm written in C?).

>> Python 2.8 or RickedPython?  Will the unicode handling be better than
>> that of the dread Python 3.3+, PEP393 Flexible String Representation > as
>> repeatedly pointed out by the RUE?
>
> I'm not much interested in Unicode at the minute. I'll pass.

Then *get interested*. Unicode is the only way that you'll ever not be
parochially bound to a subset of English - or, worse, bound to an
arbitrary eight-bit codepage that you don't even control the choice
of, such that your program behaves differently on different systems.
FIX YOUR LANGUAGE and support non-English text. Integers, floating
point numbers, lists, and images all need encodings; so does text.
It's an abstract data type, just as the others are.

ChrisA