Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Newsgroups: comp.lang.python
Subject: Re: Pyhon 2.x or 3.x, which is faster?
Date: Wed, 9 Mar 2016 23:35:24 +0000
Lines: 79
Message-ID: <mailman.98.1457566570.15725.python-list@python.org>
References: <mailman.238.1457265255.20602.python-list@python.org> <87d1r6iltx.fsf@elektro.pacujo.net> <nbjp1e$jhv$1@dont-email.me> <nbjrjm$m16$1@gioia.aioe.org> <nbjvas$h22$1@dont-email.me> <mailman.17.1457364684.10335.python-list@python.org> <nbkhei$dg6$1@dont-email.me> <mailman.43.1457377845.10335.python-list@python.org> <nbknir$avu$1@dont-email.me> <mailman.49.1457383632.10335.python-list@python.org> <nbkvq2$j5s$1@dont-email.me> <mailman.7.1457395587.15725.python-list@python.org> <nbl81v$hii$1@dont-email.me> <mailman.16.1457399576.15725.python-list@python.org> <nblapf$ofi$1@dont-email.me> <mailman.28.1457405184.15725.python-list@python.org> <nbmbnp$hsi$1@dont-email.me> <mailman.45.1457453433.15725.python-list@python.org> <nbn871$8np$1@dont-email.me> <56df6761$0$1588$c3e8da3$5496439d@news.astraweb.com> <mailman.72.1457512871.15725.python-list@python.org> <nbp36e$560$1@dont-email.me> <mailman.96.1457558042.15725.python-list@python.org> <nbqaja$5g5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <nbqaja$5g5$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:104456

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