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

[BartC]

On 12/03/2016 06:48, Marko Rauhamaa wrote:
> 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.

It's not type hinting. Otherwise you can say that using 'def' or 'class' 
is a form of type hinting. Think of 'const' as operating like the latter 
and declaring something a little different.

Although the volatility of the names so defined is still the problem.

>> 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.

Yes, you can have simpler forms of switch, that have the same overall 
structure, but do a series of sequential tests rather than using any 
form of table indexed by the value being tested.

The advantage here is that that test-value need only be evaluated once. 
It stays on the stack until some match is found, or the statement comes 
to an end.

It won't have as dramatic an impact on performance, but enhances 
readability as you say.

> 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.

What's big deal with dynamism anyway? I could never understand Python's 
obsession with it.

For me, 'dynamic' means that a variable has a dynamic type; that's all. 
But you know at compile-time (or when looking at source code) whether a 
name is a variable, or a function, class, module, named constant and so on.

If you need a variable-function, then you just have a variable contain 
the name of a function (ie a reference to it). You can bolt on dynamism 
/when you need it/.

OK, mini-rant over...

 >> 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.

Really? The issue as I see it is this:

Writing: a=65 generates this byte-code for the right-hand-side:

     LOAD_CONST      1 (65)       An integer

But writing instead: a=ord('A') generates this:

     LOAD_GLOBAL     0 (ord)
     LOAD_CONST      1 ('A')      A string
     CALL_FUNCTION   1

You might be right: doing an unnecessary global name lookup and 
executing a function call are unlikely to have any impact on performance...

The problem here is that 'ord' is dynamic, so this operation cannot 
simply be done at compile-time. Even when you try and optimise by 
assuming that ord is immutable, you don't really want to be doing any 
runtime checks. It might be faster than calling LOAD_GLOBAL and 
CALL_FUNCTION, but not quite as fast as just doing LOAD_CONST.

-- 
Bartc