Python and the need for speed

[Chris Angelico]

On Sun, Apr 9, 2017 at 10:20 AM,  <breamoreboy at gmail.com> wrote:
> I've an idea that http://www.mos6581.org/python_need_for_speed is a week late for April Fool's but just in case I'm sure that some of you may wish to comment.
>

>From that page:

> Other candidates for banishment from TurboPython include eval and exec.

Bye bye namedtuple. And compile() is going to have to go, since you
could implement eval/exec by creating a new function:

>>> runme = r"""
  print("Hello, world!")
  import sys
  sys.stdout.write("I can import modules.\n")
"""
>>> type(lambda: 1)(compile("def f():" + runme, "exec", "exec").co_consts[0], globals())()
Hello, world!
I can import modules.

So if compile() goes, you also lose ast.parse, which means you lose
introspection tools, plus you lose literal_eval and friends. I'm also
not sure whether the import machinery would have to be rewritten, but
a quick 'git grep' suggests that it would. Removing eval and exec is
not as simple as removing them from the standard library.

In fact, extreme dynamism is baked deep into the language. You'd have
to make some fairly sweeping language changes to get any real benefits
from restricting things. There are better ways to improve performance,
which is why statickification isn't really pursued.

These kinds of posts always come from people who haven't actually
tried it. They think that, hey, it'd be easy to just make a subset of
Python that's optimizable! But if you actually *do* it, you'd have to
either restrict the language HUGELY, or reimplement all sorts of
things in a slower way.

ChrisA