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

BartC bc at freeuk.com
Sat Mar 12 08:42:09 EST 2016


On 12/03/2016 11:51, Marko Rauhamaa wrote:
> 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 was talking about 'top-level' names more than attributes (names that 
follow a dot).

Ad-hoc attributes I don't have as much of a problem with, as they can be 
handy. But predefined ones also have their points. (For one thing, I 
know how to implement those efficiently.)

However, when you have a function call like this: M.F(), where M is an 
imported module, then it is very unlikely that the functions in M are 
going to be created, modified, deleted or replaced while the program 
runs. [I mean, after the usual process of executing each 'def' statement.]

Why then should it have to suffer the same overheads as looking up 
arbitrary attributes? And on every single call?

> 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

This example, I don't understand. Do you mean that when your write X.Y, 
that Y can be an attribute of X one minute, and a method the next? (In 
which case I wouldn't want to have to maintain your code!)

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

I don't follow this either. What's the advantage of dynamism here?

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

When you dabble with lots of little things, then they can add up. To the 
point where an insignificant optimisation can become significant.

-- 
Bartc



More information about the Python-list mailing list