Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 8, 2018 at 5:39 AM Ryan Johnson <rj.amdphreak at gmail.com> wrote:
>
> > What library? From where?
>
> It was a GitHub repository for a zebra scanner (barcode scanner) module (and sorry for calling it a library; I don’t recall if it was a library or module).
>
> The logic is that all the text editors that are designed to work with Python code will KNOW to replace tab input with 3 characters, while still parsing the \t tab character as 4 characters; while the editors that aren’t made for python input are generally older or non-coding text editors that maintain the older Tab convention that looks like 4 spaces, so it is visually distinguishable, when loading code that a person made on one of these non-python-aware text editors.
>
> The difference we want to see is that Python-aware creates 3 spaces from the keyboard, while still displaying 4 spaces on parsing \t . If this becomes a coding convention for Python, it’ll be enforced by editors that are intended to be used with Python (i.e. the ones that currently replace `Tab` keyboard input with 4 characters).
>

So.... why not just have them display differently from each other? Or
have an editor that notices when a line disagrees with the one above
it, and highlights that as an error?

> It’s slick. And annoying, because every OCD person in the room is going to choke when they see 3 characters for a tab.

Ahh, yes. The "annoy everyone until they do what you want" technique.
Remind me why the language should mandate that editors annoy their
users?

> > If someone violates a law, does that make the law bad? And if people follow a law, does that make it good?
>
> No, the question you should ask is “if the current law causes an unintended ambiguity or side-effect, could there be a more clear law that makes the ambiguity go away?” Clearly the current law wasn’t up to the task of delineating 1: bad code from a bad editor opened in a good editor, and 2: good code from a good editor opened in a good editor or bad editor.
>

Only if you're using bad code from a bad editor in a different bad
editor. Lots of good editors will correctly differentiate.

> If I was less than accurate in my explanation, I apologize, but the concept itself is solid, except for the annoyance of being an odd number of spaces.
>

Your explanation is fine. Your concept is internally consistent. I
strongly disagree with it. :)

ChrisA