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
--
https://mail.python.org/mailman/listinfo/python-list
