On 10/03/2016 13:08, Chris Angelico wrote:
On Thu, Mar 10, 2016 at 11:47 PM, BartC <b...@freeuk.com> wrote:
You just don't get it.
Both of you "just don't get" something that the other sees as
critically important. Before this thread gets to fisticuffs, may I
please summarize the points that probably nobody will concede?
1) Unicode support, intrinsic to the language, is crucial, even if
BartC refuses to recognize this. Anything released beyond the confines
of his personal workspace will need full Unicode support, otherwise it
is a problem to the rest of the world, and should be destroyed with
fire. Thanks.
I don't agree. If I distribute some text in the form of a series of
ASCII byte values (eg. classic TXT format, with either kind of line
separator), then that same data can be directly interpreted as UTF-8.
(And as you know, the first 128 Unicode code points correspond with the
128 ASCII codes. Widening such a data-set so that each 8-bit character
becomes 32-bit will also give you a set of Unicode code-points.)
Importing a text file from elsewhere is a different problem of course.
Although out of the thousands of times I must have done this,
Unicode-related issues have been minimal.
3) There is a point at which performance ceases to matter for a given
application. This point varies from app to app, but generally is
reached when I/O wait time dwarfs CPU usage.
Also when the total runtime is negligible anyway. It doesn't matter if a
program takes 200msec instead of 20msec. (Unless millions of such tasks
are scheduled.)
When people want better performance out of a number-crunching Python
program, they have a few options. One is to rewrite their code in C or
Fortran or something. Another is to make small tweaks so the bulk of
the work is handled by numpy or Cython. A third is to keep their code
completely unchanged, but run it under PyPy instead of whatever they
were previously using (probably CPython). Generally, rewriting in
C/Fortran is generally a bad idea; you pay the price over the whole
application, when optimizing a small subset of it would give 99% of
the performance improvement. That's why actual CPython byte-code
interpretation performance isn't so critical; if we can change 5% of
the code so it uses numpy, we keep 95% of it in idiomatic Python,
while still having the bulk of the work done in Fortran. CPython has
other priorities than performance - not to say that "slow is fine",
but more that "slow and dynamic opens up possibilities that fast and
static precludes, so we're happy to pay the price for the features we
want".
Generally agree. But also, I often develop an algorithm using a dynamic
language, because it's much easier and quicker to try out different
things, before porting the result to a static language.
But during development, it doesn't hurt if the dynamic version isn't
quite so slow!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
