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

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Aug 3 01:43:40 EDT 2016


On Wednesday 03 August 2016 05:14, BartC wrote:

> It's fundamental in that, when giving instructions or commands in
> English, it frequently comes up when you want something done a set
> number of times:
> 
> "Give me 20 push-ups"

At which point the person will invariable drop to the ground and start counting

one...two.....thrrrrrreee.........fooooooourrrr....................fiiiiiive...

Counting is more fundamental than addition. You cannot do 20 push-ups without 
in some sense counting.


> "Press space 5 times"
> 
> "Do 10 laps"
> 
> Whoever has to execute these may need to keep count somehow,
> but that is not the concern of the person giving the commands.

Perhaps not. I don't doubt that there are times where you don't care about the 
loop variable. Fine, you don't care.

There are times that I perform an operation which might fail, and I don't care 
if it fails. I have to still catch the exception. There's no dedicated syntax 
to "run this and ignore exceptions", you just use the general purpose 
try...except syntax.

try:
    this()
except Exception:
    pass

rather than:

this()   # may raise
$this()  # won't raise

Not everything that is done is worth the cognitive burden of memorising a 
special case.


> You wouldn't say, count from 1 to 20, and for each value in turn, do a
> push-up. You could also say count backwards from 95 to 0 in fives; same
> effect. There are so many ways of specifying a loop that is executed 20
> times, that no one way can be the right one. So that extra information
> is irrelevant.

Sure. That's why we have idioms like `for i in range(20)`, rather than have 
people consider `for i in [None]*20` or `range(53, 114, 3)`. Even if we had a 
dedicated `repeat 20` syntax, it would still be merely a convention that you 
use it rather than `for i in range(53, 114, 3)`.

In some ways, Python is a more minimalist language than you like. That's okay, 
you're allowed to disagree with some design decisions. I personally think that 
new f-strings-that-aren't-actually-strings-but-more-like-eval-in-disguise are a 
terrible idea, and I think that some of the rejected ideas were good ones. 
That's part of the reason why we have so many different languages: people can 
disagree on what things should be features.



-- 
Steve




More information about the Python-list mailing list