On 12/03/2016 06:48, Marko Rauhamaa wrote:
Chris Angelico <ros...@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...
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.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
