The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> Definitely agree with this. Having a way to declare that a name is
> "truly constant" would be extremely handy;

I don't think it would be all that handy. I'm afraid all this type
hinting will turn Python into a poor man's Java.

> Maybe, but I honestly don't miss 'switch' all that often - and when I
> do, it's usually because I want a range.

I don't consider the switch statement an optimization technique but
rather, a readability technique.

Note that Scheme has a "switch statement" (a "case form") despite being
a highly dynamic language. Incidentally, Scheme allows for more
performance optimization than Python as well because

 * Scheme has atoms ("symbols") and literals for them.

 * Scheme has macros ("syntax") that are expanded at compile time.

Compile-time macros are actually a conceptual compromise that violate
full-fledged dynamism: once the compiler has expanded the macro, its
definition can't change.

> Py3 hasn't eliminated int; and yes, all "simple value types" in Python
> are still boxed values.

Conceptually, yes, but that doesn't have to be the implementation. The
redundant bits in memory addresses allow for unboxing of almost all
practical integers, for example.

BTW, even CPython puts limits to complete dynamism:

   >>> (4).__str__ = "four"
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   AttributeError: 'int' object attribute '__str__' is read-only

> You're not mistaken. There are no "character constants" in Python.
> (Note that the definition would be Unicode codepoints, rather than
> ASCII values.) I don't often miss them, though.

Yes, a complete non-issue.


Marko