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