Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
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 11:27:27 +0000
Lines: 83
Message-ID: <mailman.34.1457782092.12893.python-list@python.org>
References: <mailman.8.1457732171.12893.python-list@python.org> <87h9gcxkd3.fsf@elektro.pacujo.net> <nc0t5o$441$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <nc0t5o$441$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:104691

On 12/03/2016 11:08, BartC wrote:
> On 12/03/2016 06:48, Marko Rauhamaa wrote:
>> Chris Angelico <rosuav@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...
>

Function calls are hugely expensive in Python.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence