On Mon, Oct 8, 2018 at 5:39 AM Ryan Johnson <rj.amdphr...@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 -- https://mail.python.org/mailman/listinfo/python-list