Indented multi-line strings

[Dan Stromberg]

On Sat, Jun 2, 2018 at 11:43 AM, Chris Angelico <rosuav at gmail.com> wrote:

> >> 1) Messy code because people unindent inside their source code,
> >> creating wonky indentation (which Python usually avoids)
> >>
> >> 2) Forcing readers to look up the third-party module you're using
> >> before they can understand your code
> >>
> >> 3) Forcing readers to look up your ad-hoc function before
> >> understanding your code.
> >>
> >> All of these make it harder to understand your code, specifically
> >> BECAUSE the language doesn't have the requisite feature. Well-written
> >> language features are good, not bad, for readability.
> >>
> > A well designed language has a small core, and large libraries.
> >
> > Please don't make Python into a big language.
> >
> > Almost anytime you can do something in a library instead of in the core
> > language, it's better to do it in a library.
> >
> > Looking things up in a library isn't onerous.
>
> How small is small, though? And how is a method worse than a library
> function? People keep asserting this about the language needing to be
> smaller, but never backing it up.

It should be small enough to facilitate multiple, compatible
implementations.

It should be small enough that you don't have to learn a lot to start
writing programs.

It should be small enough that you don't have to learn 10 languages to read
someone else's code.

It should not be perl, where anything that seemed a little helpful was
dumped in.

Was Python 1.0 better than Python 3.7 due to having fewer features?

No, generators pretty much rock.  And comprehensions are OK, despite the
obvious duplication with map and filter.  And I like true booleans too.

But there's a reason why so many other implementations of Python are still
stuck on 2.x.  The pace of change in Python, the core language, has just
been too fast.