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

[Chris Angelico]

On Wed, Aug 3, 2016 at 8:16 PM, BartC <bc at freeuk.com> wrote:
> On 03/08/2016 06:43, Steven D'Aprano wrote:
>
>> Not everything that is done is worth the cognitive burden of memorising a
>> special case.
>
> ....
>
>> In some ways, Python is a more minimalist language than you like. That's
>> okay,
>> you're allowed to disagree with some design decisions.
>
>
> Well it's minimalist in some ways, and completely the opposite in others!
>
> It uses minimal basic syntax (missing a couple of loop forms, loop controls,
> switch/case, select-expressions... it's just a handful of features).
>
> But then you get to the standard library, and the plethora of different data
> types, methods and options. It's never-ending!

The standard library doesn't have the cognitive burden that the core
language has. For starters, it's all namespaced; for seconds, once
you've mastered language syntax, you can introspect for documentation
(simplest form: help(obj) at the interactive prompt).

> So the idea that remembering 'repeat N' is a cognitive burden, and the
> myriad string operations for example are not, is ridiculous.
>
> (Especially when 'repeat N' will have an obvious counterpart in some other
> languages, but 'str.encode(...)' for example will not.)

Myriad string operations? Let's see.

>>> dir("")
['__add__', '__class__', '__contains__', '__delattr__', '__dir__',
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__iter__', '__le__', '__len__', '__lt__',
'__mod__', '__mul__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', 'capitalize', 'casefold',
'center', 'count', 'encode', 'endswith', 'expandtabs', 'find',
'format', 'format_map', 'index', 'isalnum', 'isalpha', 'isdecimal',
'isdigit', 'isidentifier', 'islower', 'isnumeric', 'isprintable',
'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip',
'maketrans', 'partition', 'replace', 'rfind', 'rindex', 'rjust',
'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith',
'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']

We have:

* Dunder methods and attributes, used for implementing other features.
You ignore them in regular code.

* Methods that do what other languages do with stand-alone functions.
It's not much different to do "spam".capitalize() than
capitalize("spam") or "spam".replace("sp","h") than
replace("spam","sp","h"). Likewise the "is*" functions,
startswith/endswith, and other querying functions.

* String formatting (both format and format_map). That probably
belongs in the previous category, but since Python's .format() method
differs from every other string formatting out there, you could say it
takes extra cognitive load. But honestly, what modern language doesn't
have some sort of formatted-string system, at least in its standard
library?

* join(), which most languages have as an array method that takes a
string, but Python has as a string method that takes any iterable.
Yes, that's a bit weird, I know. We can give you that one.

* And, uhh... you specifically mentioned encoding strings to bytes.
Well, Pike doesn't have that as a method. Instead, you have
string_to_utf8() for the most common case (and, naturally,
utf8_to_string() to convert bytes to text), and then has a Charset
module for all other conversions. Cognitive burden? Pretty much
equivalent.

I would say str.encode() has barely more cognitive burden than repeat
N would have. To get your head around "repeat N", you have to
understand that a computer can do things more than once. To get your
head around "spam".encode("utf-8"), you have to understand that bytes
are a means of representing text, and that they're not the same thing.
Yes, that's a bit harder (if you teach algorithms using a pen and
paper, you'll probably conflate data with its representation, since
there's no representation of the representation), but not hugely.

ChrisA