Python and the need for speed

[Rick Johnson]

On Wednesday, April 12, 2017 at 1:48:57 AM UTC-5, Steven D'Aprano wrote:
> On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote:
>
> > high level languages like Python should make it difficult,
> > if not impossible, to write sub- optimal code (at least in
> > the blatantly obvious cases).
>
> You mean that Python should make it impossible to write:
>
>     near_limit = []
>     near_limit.append(1)
>     near_limit = len(near_limit)
>
> instead of:
>
>     near_limit = 1

Yes.

> ? I look forward to seeing your version of RickPython that
> can enforce that rule.  Oh, in case you think I'm making
> this up, this example came from some real-life code:
> [snip: link]

My guess about that obviously superfluous code is that it is
an artifact of an early algorithm, but since the code
executes without error, the programmer forgot about it.
That's my two cents anyways...

> Here's another example:
>
>     answer = 0
>     for i in range(10):
>         answer += 1
>
> instead of
>
>     answer = 10
>
> So... how exactly does the compiler prohibit stupid code?

Easy. The same way _any_ optimizer optimizes code, by
analysing the code! In this example, the integer named
'answer` is simply being incremented in a superfluous loop.
Nothing here is "dynamic". For example:

  * `range(10)` will always produce a list of the _same_ 10
  integers.

  * `for i in range(10)` will aways iterate over the _same_
  10 integers

  * `answer += 1` will always increment the "current integer
  value" by 1

Therefore, since `answer` will always be `10`, the code
should be optimized to `answer = 10`. What's so difficult to
understand here? Hell, if we have to live with the syntactic
burden of type- hints, we should at least be rewarded with
an optimizer.