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

[Mark Lawrence]

On 09/03/2016 23:14, BartC 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.
>
> Actually, you're doing a good job of arguing for not doing using Python
> for real coding! Apart from just launching tasks.
>
>> Not that it matters, when you release BartC or whatever you call your
>> language it'll take over the world, so I'm looking forward to dropping
>> Python.  What is the release date?
>
> (A first version might have been around 1986. I can't remember exactly.
> Perhaps you think this is vapourware? It's not a commercial product at
> the minute, just a hobby. Originally it was a scripting language for a
> commercial app of mine.)
>
>> Could it be the same as that for
>>  Performance wise will it be tested
>> against real world benchmarks or microbechmarks?
>
> (The byte-code compiler for the current version is written in itself. It
> can compile itself (some 25Kloc) in about 1 second (that's running
> interpreted, dynamic byte-code on a not-very-fast PC).

Please answer my question, will it be tested against real world 
benchmarks or microbenchmarks?  The above paragraph, and several 
following paragraphs, are completely irrelevant.

>
> The interpreter for the byte-code is also written in another language of
> mine, which statically typed. The compiler for the latter is written in
> the interpreted language too.
>
> I'd quite like to port either of these compilers to Python, to see what
> PyPy can do with them. (It would also be quite cool to have them in pure
> Python). But I've find these difficult to optimise, because they have
> diverse execution patterns, while PyPy likes loops. I'll see.
>
> A compiler is another good 'pure language' task because, apart from
> input and output at each end, all the computation is self-contained.)

I've no idea what this is meant to mean.

>
>  > 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.
>

Your final comment sums up perfectly your knowledge of computing in 
2016.  I find it fitting that something so funny is put forward on the 
Python mailing list/news group/whatever, given the derivation of the 
name Python.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence