Python indentation (3 spaces)
> 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).
It?s slick. And annoying, because every OCD person in the room is going to choke when they see 3 characters for a tab.
> 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.
The distinction can be made known to the good programmer by having the good editors follow a convention that makes the difference evident, while a bad editor continues to show no distinction between good and bad code. Remember, the primary rule is that a good editor will obviously not permit a bad coder to type bad spacing, but a bad editor will.
This convention change would allow a person using a good editor to know that the code was made in a non-python-oriented editor immediately, instead of blowing up their debug console with Syntax errors.
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.
Sent from Mail for Windows 10
From: Terry Reedy
Sent: Sunday, October 7, 2018 10:35 AM
To: python-list at python.org
Subject: Re: Python indentation (3 spaces)
On 10/5/2018 11:30 PM, Ryan Johnson wrote:
> The point that OP is trying to make is that a fixed standard that is
> distinguishable from the even-spacing Tab-length convention in code and
> text editors will establish a level of trust between the end developer and
> upstream developers or co-developers who may not have the same development
And my counter point is that a) we will not change the standard and b)
we deliver an editor that by default enforces the standard, and c) to be
fair, many other editors will do the same.
> For example, the first Python library I ever tried to use was
What library? From where?
> poorly maintained and had spaces on one line with tabs on the next, and the
> author mixed naming conventions and syntax from Python 2 and 3 in his code.
> That type of experience doesn?t exactly instill trust in the coding
> language?s standards, when a noob tries to use a library they found and
> ends up having to debug weird errors with weirder error messages on the
> first project they do.
I don't follow the logic. If someone violates a law, does that make the
law bad? And if people follow a law, does that make it good?
People obviously should not distribute buggy messes, at least not
without warning. Were you using the library with an unsupported
version? Or inform the author or distributor?
> Flexibility is great until the learning curve comes into play. That said,
> there is an easy fix for tab misuse: in Visual Studio Code, you can replace
> all Tabs with Spaces by highlighting the entire code block, hitting Tab
> once and Shift-Tab after.
IDLE does that also.
Terry Jan Reedy