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

[Marko Rauhamaa]

BartC <bc at freeuk.com>:

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

*I* am obsessed with dynamism. It means I don't have to declare object
data members but can write ad hoc:

       def some_method(self):
           self.update_state()
           self.state_specific_info = "Kilroy was here"

The "state_specific_info" attribute didn't exist before I wished it into
existence. No bureaucracy, just add it where it belongs.

I also have a high level of method/attribute transparency. It doesn't
matter if I declare:

       def this_or_that(self):
           if self.that:
               self.that()
           else:
               self.this()

       [...]

           self.that = True

or:

           self.this_or_that = self.that


Somewhat related, every method is an automatic delegate. Defining
callbacks is a breeze:

       def clickety_click(self, x, y):
           [...]

       [...]
           window.register_mouse_click_callback(self.clickety_click)


> On 12/03/2016 06:48, Marko Rauhamaa wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>> 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...

Simply put: I don't use "ord()" almost at all. I couldn't find any
example in any of my code.

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

That optimization wouldn't have any effect on any of my code.

More generally, every method call in Python is such an elaborate
exercise that dabbling with character constants is going to be a drop in
the ocean.


Marko