On Mon, Oct 8, 2018 at 10:31 AM Terry Reedy <tjre...@udel.edu> wrote: > > On 10/7/2018 2:35 PM, Ryan Johnson wrote: > > > 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; > > What do you mean by 'parsing a tab character as 4 characters'? If the > editor *converts* the tab to k spaces in its buffer, then k must be the > same number as when the user types a tab, and there is no tab left to > worry about. If the editor put the tab into its buffer (and saves it > with tabs), then what users on particular display devices depends on > what the device does with tabs. > > Theoretically, all tabs might seem like a good idea, but since 0 spaces, > 1/2 inch, and 8 spaces are possible display results, in addition to a > users custom setting, this does not work except in a circumscribed > environment. That leaves space indents and no tabs except in strings > where needed. >
TBH, I think that tab width should be up to the display, just like the font. You're allowed to view code in any font that makes sense for you, and you should be able to view code with any indentation that makes sense for you. If someone submits code and says "it looks tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making sure it doesn't matter [1]; if someone submits code and says "you have to set your tabs equal to 5 spaces or it looks ugly", you'd say the same, right? How wide my indents are on my screen shouldn't influence your screen or your choices. ChrisA [1] eg the last of the Pet Peeves https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements -- https://mail.python.org/mailman/listinfo/python-list
