On Sat, 12 Mar 2016 11:08:25 +0000, BartC wrote:
>
> >> 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.
Why te constant focus on speed?
the majority of code is IO bound, either waiting for user input or
waitimng for file IO
a couple of extra microsecconds here and there between keypresses is
imaterial.
if you are wrighting truly CPU bound performance critical code then
python is probably not the correct language for these portions of the
code.
of course this is whre the 'C' based modules you so dislike can come to
your aid. meaning the performance hog can still run quickly but giving
you an easiy user interface to make the best of it.
as always there is no one language that is all things to all tasks,
python is just another tool in the box
use the correct tool for the correct job or you will invariably end up
with an unmanageable mess
--
In 1914, the first crossword puzzle was printed in a newspaper. The
creator received $4000 down ... and $3000 across.
--
https://mail.python.org/mailman/listinfo/python-list
