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

[BartC]

On 02/08/2016 22:27, Terry Reedy wrote:
> On 8/2/2016 7:05 AM, BartC wrote:

>> 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.

That's quite a big edit to the original code. I would duplicate the 
line, comment out the original, and add the print code to the copy. Then 
I can revert to the original without bugs creeping in. (Unless the rest 
of the line has to change anyway.)

Same method is used with repeats:

    for N:        # or whatever syntax is used

If a loop index /has/ to be printed, comment out the above and extend a 
copy of it to:

    for i in range(N):

But only /if/ that value is needed; most won't. (I suspect that loops 
repeated a set number of times might be simpler anyway.)

>> 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.

But it might go wrong before it gets to the end. You need the index to 
know how far along the list it's at.

>> 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.

[Did you mean 'less usable' here?]

I'm only concerned here with basic syntax. And most ideas already exist 
in other languages (not just mine). But here's one I idea I think I 
mentioned last year: having separators in numeric literals.

Now I look and see that PEP 515 describes it! (I think some versions of 
Python will already have it).

Do people think that makes Python top-heavy in features and less usable?

I *know* that actually implementing most of this stuff is trivial 
because I've done it a dozen times. And I appreciate that doing it in a 
very large, existing 'live' language with millions of users has 
administrative problems.

But the technical side of it is nothing compared to the 50Mloc tools 
that have been mentioned.

>
> 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.

Apparently 'repeat N' is a Logo statement so it makes sense to try and 
emulate that within Python (to simplify porting Logo algorithms for 
example).

> 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.

Yes, I've experimented with that approach myself. Using a 
source-to-source translator with Python as output. But the input was an 
entirely different syntax (example: http://pastebin.com/Zj89YfTN).

-- 
Bartc