Bartc <b...@freeuk.com>:
> Not just my option. From this 2010 paper for example ('High performance
> implementation of Python for CLI ...' by Antonio Cuni):
>
> "As a language, Python is very hard to implement efficiently: the
> presence of highly dynamic constructs makes static analysis of
> programs extremely difficult, thus preventing ahead of time (AOT)
> compilers to generate efficient target code."
Correct. That's not Python's fault, however. Python should not try to
placate the performance computing people. (Alas, it is now trying to do
just that with the introduction of static typing annotation.)
> Plenty of other people working on faster Pythons appear to have
> trouble with its being so dynamic.
That's, literally, their problem.
> As one example of many, named constants (the 'const' feature earlier
> in the thread), were used for 'switch' statements. Without 'const',
> then I couldn't have a fast 'switch'.)
Fast, fast, fast. We have plenty of fast programming languages. Python
should *not* sacrifice its dynamism (which the fast languages don't
have) for speed. Python is already fast enough for most programming
tasks.
In my work, I currently use bash, Python and C. For many, many tasks,
bash is superior to Python. For others, Python can't compete with C. Yet
the vast gap between bash and C is nicely filled with Python.
Those three golf clubs are all I need in my bag. Java, C#, go, C++ have
great merits. However, I really don't ever miss them.
(The one club I have special sentiments for is Scheme. I don't use it
professionally for, though, because its ecosystem is not quite developed
enough yet.)
> I suppose my coding style is just different from people who write
> Python. When I define a function f(), then it's always going to be
> function f and is never going to change. A call to such a function can
> therefore be streamlined.
Your point of view is really down-to-earth. It's slightly analogous to
protesting against Unicode because you only ever need ASCII.
You would be right in that Python programs hardly ever make use of or
directly depend on the degrees of freedom Python affords. They are used
every here and there, however, and, most imporantly, they make it
possible to define the semantics of the programming language in a sound,
concise manner. That way it is easier to implement Python, learn
Python and use Python correctly.
Imagine there was a national standard that defined that you could only
sell hatchets that split wood in a downward movement. You might argue
that hardly anyone swung a hatchet sideways, and it would be dangerous
anyway. However, that kind of a standard would make it very difficult to
manufacture the simple concept of a hatchet. The contraption would be
expensive, fragile, heavy and difficult to use even for the intended
up-down splitting purpose.
I wouldn't like Python to turn into such a contraption.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
