Looping [was Re: Python and the need for speed]
bc at freeuk.com
Sun Apr 16 14:21:58 EDT 2017
On 16/04/2017 17:30, Steve D'Aprano wrote:
> On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
>> (The 30 Loc figure is with support for loops /in
>> general/ already in place, and is for /adding/ a new loop statement, in
>> this case 'while')
> What part of *testing* and *documenting* do you not understand?
> Do you have any unit tests for your compiler? How about regression tests --
> when you fix a bug, do you write a regression test to ensure it never
> creeps back in?
> Do you have any documentation for your compiler? Does it include doctests?
> Are there any tutorials that beginners can read?
> I'm guessing you don't have any of those things. The code snippet you posted
> doesn't even have any comments.
Here is a function from some old CPython source that appears to be
something to do with While statements:
int nch = NCH(tree);
int res = (validate_ntype(tree, while_stmt)
&& ((nch == 4) || (nch == 7))
&& validate_name(CHILD(tree, 0), "while")
&& validate_test(CHILD(tree, 1))
&& validate_colon(CHILD(tree, 2))
&& validate_suite(CHILD(tree, 3)));
if (res && (nch == 7))
res = (validate_name(CHILD(tree, 4), "else")
&& validate_colon(CHILD(tree, 5))
&& validate_suite(CHILD(tree, 6)));
Look, no comments! Are you going to castigate the developers of CPython
for that? (I guess not.)
Anyway I took out the one or two comments from my posted extract.
> If Python added something like:
> loop N times:
> we would need *at least* the following:
> - a test that `loop` was interpreted as a keyword;
> - a test that `times` was interpreted as a keyword;
> - a test that `loop 0 times` didn't execute the body at all;
> - a test that `loop 1 times` executed the body exactly once;
> - a test that `loop N times` executed the body exactly N times, for
> a few different (and probably randomly selected) values of N;
> - a test that the statement handled negative integers and floats correctly;
> - a test that the statement handled non-numeric values correctly
> (probably by raising an exception);
> - a test that `continue` worked as expected inside this statement;
> - a test that `break` worked as expected;
> - a test that `return` worked as expected;
> - a test that `raise` worked as expected;
> - a test that signals will be caught correctly inside the statement;
> and possibly more.
Well, I was talking more about just 'loop:', to repeat endlessly. Then
half of those tests disappear. See, a dedicated statement can make
The other half would be the same for loops generally as, after you get
to the compiler output (if I can't call it byte-code), then the chances
are that the original identity of the loop is lost.
Loop N times could be on top of While or For. Or it could have its own
implementation where it /knows/ the loop counter is an integer, and a
64-bit one. See, another optimisation opportunity.
>> BTW supporting a dedicated endless loop was only about 20 lines in
>> another project. Believe me, it is /nothing/. I wish other aspects were
>> just as trivial. It didn't even need a dedicated keyword.
> Of course it's "nothing" for you, since by the evidence given you don't
> bother with the hard parts. No comments, no communication with other
> developers (except to gloat over how awesome you are and how stupid their
> choices are), no documentation, no tests.
There are a couple of aspects I like of dynamic languages, which is the
informality and spontaneity.
The informality with Python seems to have disappeared (with all this
paperwork, and committees and applications to get more features added;
about as interesting as making a proposal for a new office block).
While the spontaneity seems to have suffered too if a feature takes
years to be accepted, even if it would only take an hour or two to add
(on a smaller project like mine).
At least, I get the benefits immediately. If I had to wait five years
(when I might be dead anyway) then I might as well wait forever.
>> The loops I use are categorised as:
>> * Endless
> That's just a special case of "until some condition is true".
No, because there is no condition to test or think about. There should
not be one to specify. Python requires that a dummy condition is
provided to satisfy the language syntax (but internally it compiles to
an endless loop, as there there is no bureaucracy telling it what to do).
>> * N times
> That's just a special case of "over an integer sequence".
No, because you don't care about what that sequence is, nor about having
to present it as named object to the body of the loop. Another
Neither does the user really want to be bothered with writing the name
of a variable. And providing a range() is overkill, as you just want a
count not a sequence.
>> * Until some condition is true
> You missed one: do you check the condition before the first loop, or at the
> end of the loop? That makes a difference between the loop running zero or
> more times, or one or more times.
Both are included. (I suppose you could have 'until' at the head of a loop.)
>> * Iterate over an integer sequence
> And that in turn is just a special case of iterating over a set of values.
No, because an integer sequence can be optimised; the iteration can be
simple. Another case for optimisation.
>> * Iterate over a set of values of some object
> Out of your five fundamental loops, you missed one important distinction,
> and invented three unimportant ones.
(Ada has a dedicated endless loop. Will you tell them they wasted their
time, or shall I?)
>> Other languages like to have even more elaborate schemes. That includes
>> advanced uses of Python's for loop, were, for example, there are
>> multiple loop variables.
>> I wonder how much testing that took to get it right?
> Probably a lot. And it would be worth it even if it took fifty times more
This is for a feature I've never used and only came across by accident?
There must be some real power users on this group. I imagine most would
be more pedestrian.
More information about the Python-list