Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: BartC <bc@freeuk.com>
Newsgroups: comp.lang.python
Subject: Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
Date: Sat, 12 Mar 2016 13:42:09 +0000
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <nc1660$3e2$1@dont-email.me>
References: <mailman.8.1457732171.12893.python-list@python.org> <87h9gcxkd3.fsf@elektro.pacujo.net> <nc0t5o$441$1@dont-email.me> <87shzvgbhq.fsf@elektro.pacujo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 12 Mar 2016 13:39:12 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="cf45b3961a050227b1103bebc3cbc15a"; logging-data="3522"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19htTW8/E8h7fesGxVmU59W"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <87shzvgbhq.fsf@elektro.pacujo.net>
Cancel-Lock: sha1:hN1obzbu5D3ZGuFsp2t7GjKjl0Y=
Xref: csiph.com comp.lang.python:104704

On 12/03/2016 11:51, Marko Rauhamaa wrote:
> BartC <bc@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