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