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

[Chris Angelico]

On Thu, Aug 4, 2016 at 7:13 PM, BartC <bc at freeuk.com> wrote:
> On 04/08/2016 04:23, Steven D'Aprano wrote:
>>
>> On Wed, 3 Aug 2016 08:16 pm, BartC wrote:
>
>
>>> So the idea that remembering 'repeat N' is a cognitive burden, and the
>>> myriad string operations for example are not, is ridiculous.
>>
>>
>> Who says it isn't a cognitive burden? Of course it is.
>>
>> The difference is that most of the string methods carry their own weight
>> in
>> usefulness versus burden, and "repeat N" doesn't (according to the core
>> developers). You have weighed "repeat N" high on the usefulness side and
>
>
> OK, let's look at some string features.

Be careful: you're looking at two different things here (the 'string'
module, and methods/attributes on the 'str' type).

> First, you have string.ascii_uppercase, which is just
> "ABCDEFGHIJKLMNOPQRSTUVWXYZ".
>
> Is that really so indispensable that it has to be built-in to the language?
> Is it that much of a hardship to assign it once and for all to some
> variable?

Once and for all? You mean like in a module?

> Now you have string str.lower, str.upper, and str.swapcase. Clearly one of
> those first two is redundant, as you can implement str.upper by writing
> str.lower().swapcase() for example.

"Clearly" only if you're thinking ASCII. You can't actually fudge this
either direction:

>>> s = "\u1e9e"
>>> s.lower().swapcase(), s.upper()
('SS', 'ẞ')
>>> s = "\u00df"
>>> s.upper().swapcase(), s.lower()
('ss', 'ß')

> Then these miss a trick by not having an optional length parameter, so that
> you can operate on the first N characters.
>
> Then you can dispense with str.capitalise by writing str.upper(1). (Or
> str.lower().upper(1) if the current case is unknown.)

You have to use the longer form for true equivalence, and then you run
into the same problem as above.

> (And what about str.reverse()? (The comments here about the readability of
> Python code, and who is entitled to express an opinion about it, are
> amusing:
> http://stackoverflow.com/questions/931092/reverse-a-string-in-python))

Slice it backwards. No need for a method, any more than there is need
of a str.charAt() method to get individual characters.

> Compare all that (and I'm sure there's tons more) with, for example, just
> leaving out the 'i in' in 'for range(N):')

If you want to push for a shorter syntax for simple repeat loops, this
has far better chances of landing than "repeat N" has - "for
<iterable>" is simply an extension of "for <var> in <iterable>" that
discards rather than binding. No new keywords introduced, no
fundamentally new looping structure, just the exact same thing as an
existing 'for' loop. The difference between "for thing in collection"
and "for collection" would then be:

# for thing in collection
_it = iter(collection)
while "moar stuff":
    try: thing = next(_it)
    except StopIteration: break
    # loop body goes here

# for collection
_it = iter(collection)
while "moar stuff":
    try: next(_it)
    except StopIteration: break
    # loop body goes here

That wouldn't be a bad thing, IMO. Whether it's worth the various
costs I still don't know, but its costs would be *way* lower than
adding a new keyword to the language, adding a new control flow form,
etc. Less magic. Just the removal of a name binding.

ChrisA