Debugging (was Re: Why not allow empty code blocks?)

[Terry Reedy]

On 8/2/2016 7:05 AM, BartC wrote:
> On 31/07/2016 19:58, Terry Reedy wrote:
>> On 7/31/2016 6:18 AM, BartC wrote:
>
>>>  repeat N:
>
>>> The benefit is not so much performance, but being able to express
>>> something very easily and quickly.
>>
>> The cost of the 'repeat' contraction is that one cannot use the loop
>> variable, either as part of a modified computation or for monitoring or
>> debugging purposes.
>>        print(i, for_body_result)
>> Beginners are often atrocious at debugging, and it seems not to be
>> taught hardly at all.  'repeat n' erects a barrier to debugging.
>
>> Debugging: probing a computation to see what actually happens, as
>> opposed to what one wanted and expected to happen.  (Me, just now ;-)
>>
>> One major way of debugging is printing values as they are computed.
>> Naming values (objects) allows them to be printed without recomputing
>> the value.  In the 'repeat n' context, recomputing would mean adding 3
>> lines of debugging code instead of 1.
>>
>> i = 0
>> repeat n:
>>    a = f(a)
>>    print(i, a)
>>    n += 1
>
> Your objection to a feature such as 'repeat N' doesn't really stack up.

My objection is that there is a real cost that MUST be stacked up 
against the benefit.

...
> Anyway, if that was a valid objection, it would apply throughout the
> language. In list-comps for example (there is an index, but where do you
> stick the print?).

In the expression.  Given 'f(i) for i in range(n)', a careful debug 
version might be '(f(i), print(i))[0] for i in range(n)'.  If the loop 
does not finish, the extra None component does not matter.  and the 
subscripting could be omitted.

> Or in a for-loop iterating over values:
>
>  a=[10,20,30,40,50]
>  for x in a:
>     print (x)
>
> This will print the element, but what's the index?

Irrelevant.  The end of the sequence of prints says where the loop stopped.

 > According to you,
> every such for-loop needs to be written in a form that provides the
> index of a loop

Don't pretend that I said that.  It is not nice.

> I get that people here don't want such a feature, but I don't think this
> is the reason.
>
> I think the real reason is not willing to admit that the language lacks
> something that could actually be useful,

I think it is you who is unwilling to admit that nearly everything that 
would be useful also has a cost, and that the ultimate cost of adding 
every useful feature, especially syntax features, would be to make 
python less unusable.

Some time around last August to October, I think, someone posted to 
python-ideas that he had produced a children's Python environment that 
accepted 'repeat n' statements and translated them to equivalent for 
loops before running.  His idea was that 'repeat n' should be added to 
python itself so translation would not be needed.  The main use of the 
statement in this context is for logo/turtle code with many 
side-effect-only calls.

I though the idea plausible, at first, and noted that one could add an 
extension to IDLE to experiment further with the idea.  An extension 
could add a menu ited such as 'de-repeat'.  One could also, with about 
the same effort, *patch* IDLE to do the translation just before it calls 
compile(code, ...).

Leaving IDLE aside, one could write a pyre.whatever script to translate 
a .pyre file to a .py file and run the latter.  Any of these methods 
could be applied to experimenting with other 'improvement' ideas.

Anyway, *after thinking about the idea for at least a week*, I became 
less enthusiastic about hiding the loop counter.

-- 
Terry Jan Reedy