At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote:
>I was pleasantly surprised to find a pointer to this article in a news
>digest that the ACM emails me regularly (ACM TechNews).
>
>http://gcn.com/vol1_no1/daily-updates/28026-1.html
>
>One thing that bugs me: the article says 3 or 4 times that Python is
>slow, each time with a refutation ("but it's so flexible", "but it's
>fast enough") but still, they sure seem to harp on the point. This is
>a PR issue that Python needs to fight -- any ideas?
The only thing that will fix the PR issue is to have a Python compiler
distributed as part of the language. It doesn't matter if it doesn't
support the full generality of Python, or even if it doesn't speed many
operations up much. The only real requirements are that it can be used to
produce "native" executables, and that it be an official part of the
language, not a separately-distributed tool like Psyco or Pyrex. Then, it
will perhaps be a sufficient "security blanket" to stop people FUDding
about it.
I imagine you could speed up the Python interpreter until it's faster than
half the Java JIT's out there, and people will still ask, "But can I
compile to an .exe?" On the other hand, if you add a compiler, we'll see
articles like the above talking about how Python can now be compiled and so
therefore it's suitable for all kinds of things it wasn't before. :)
Of course, it would be *really* useful if the compiler were coupled with
optional type declarations for Python-the-language, because then we could
ultimately dispense with the current syntax warts of Pyrex (and the
runtime/distribution warts of ctypes) for interfacing with C. But I don't
think that having the compiler actually be useful is a prerequisite for
solving the PR issue. :)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4