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

[BartC]

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

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

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

-- 
Bartc