Python and the need for speed

[Rick Johnson]

On Saturday, April 15, 2017 at 7:17:55 AM UTC-5, bartc wrote:
> On 15/04/2017 03:35, Rick Johnson wrote:
> > On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart... at gmail.com wrote:
>
> > At a minimum, every language should offer
> > the following four loop-forms (using Python semantics):
> >
> >     while CONDITION:
> >         doSomething()
> >
> >     for VALUE in COLLECTION:
> >         doSomething(value)
> >
> >     loop(N):
> >         doSomething()
> >
> >     loop(N) as i:
> >        doSomething(i)
> >
>
> Yes, I'm constantly surprised at this, as such syntax has a
> very low cost (in my last compiler, supporting 'while' for
> example only added 30 lines to the project).  Of course,
> it's possible to overdo it; if you look at Lisp, you'll
> lose yourself in the myriad looping options.  But very
> common requirements are endless loops, and repeat N times
> without needing an explicit counter. The former /can/ be
> easily written as:
>
>      while 1:
>          body
>
> but it's more psychological; I don't want to use an idiom
> to denote an endless loop, I want to be able to express it
> directly!


A good point. I don't like the idiom of using "always True
conditions" to denote an endless loop either. So it's just a
matter of recognizing that loop() without an "explicit
confining parameter", would be endless.

loop:
    # This loop never ends.

Of course, recognizing that at some point that the loop will
need to end, or that something surprizing will cause it to
end, how then would you end it in a clean manner? Which
would cause the semantics to be:

loop:
    # This loop never ends. Well "never" unless an
    # exception occurs; or the hardware malfunctions; or
    # melts; or unless nuclear war breaks out; or unless the
    # sun expands and envelopes the earth -- except for
    # those cases (and possibly a long list of others...),
    # it never ends. ;-)

> Python's byte-code does at least optimise out the check
> that '1' is true, but that's not what the reader sees,
> which is 'loop while 1 is true'. And one day it will be:
>
>      while l:
>          body
>
> that can be mistaken for that common idiom.

Another good point. However that's more a consequence of
using 1 as a truth value than anything else. Python has
offered booleans for a loooong time, so i don't understand
why some of us feel the need to use 0 and 1 in place of the
more intuitive (and less bug prone) False and True. The
obvious solution is:

while True:
    # This loop never ends.
    # (Note: see exceptions above)

Integers should only be utilized for their numeric value,
and nothing else. Python should never allow an integer to be
used as a truth value, only booleans or expressions that
evaluate to a truth value. Of course, these can perverted
also.

if 1 == 1: # superfluous! 1 will always equal 1

if None: # superfluous! None will always be False

if True == False: # superfluous! True and False will never be equal.

etc...

(of course, i _hope_ those examples are rock solid. Sometimes,
i forget how utterly and stubbornly dynamic this damned
language can be!)