When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to figure out how to restore the proper block boundaries after a cut-and-paste has screwed up the indentation.

If boundaries exist they need to be clear. One shouldn't have to count the tabs that make up the level of indentation.

Its already a challenge reading code. Counting invisible tabs makes it even worse.

    def foo(bar)\
    :
        if (bar > 5)\
        :
            return bar + 1;
        #
        else\
        :
            return bar - 1;
        #
    #

Similarly, copying code from StackOverflow, Github and random blogs have all worked without any issues.

So it can't be as easy as you imply.

Mixed spaces and tabs as a next go, and it worked too---converting the pasted tabs into spaces of my style.

Smart-tabbing is pretty smart.

Granted, I knew that so long as the indents were proper (i.e it compiles), that pasting at that point would give valid code but... I can't see how using braces would have been different. Just because it compiles, doesn't mean it works. I've pasted javascript incorrectly multiple time to produce valid, but incorrect for my needs code.

The indentation strategy also looks to produce syntactically valid code, so long as what you are pasting lacked indentation errors.

Unsurprisingly, PEP 8 does have a rule for tabs vs. spaces: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces (spaces, of course)

Tabs are semantic and only take one key press for movement back and forth and to delete.

If you see 1 tab you know it meant one indentation level. With spaces you have to think.

Plus with spaces you are stuck with 2/4/8 spacing(unless you reformat), with tabs you can configure your editor to your preferences.

Configure 1 tab to be 4 spaces.

Sometimes it's easier to go with the flow. I like tabs for the reasons you mentioned, but fixed-width spaces are a bit better for some reasons too. IDE's can do the heavy lifting of re-formatting indentation levels and converting tabs to spaces for me, and it means if I cat a file on a remote server regardless of the bash tab width settings or if I'm in your code or the stdlib it will all make sense.

Except that you can't because people using tabs will invariably start mixing tabs and spaces because they can't separate indentation from layout. So the code will be messed up unless you configure your editor to someone else's preferences. Also, I'm sure there is some obscure git setting to de-uglify tab users' diffs, but I'd rather not find out.

Before you say that I'm crazy... please, go and read pep8.

OK. What am I looking for?

But tabs vs. spaces is indeed a bad analogy, because of course it's 4 spaces. ;-P

pycodestyle, the Python style checker, has a few checks disabled by default (because there's no consensus they're good ideas), and even some mutually exclusive ones:

https://pycodestyle.readthedocs.io/en/latest/intro.html#erro...

The correct answer is whatever the project is already using, unless it is new and then you luckily get to choose.

Tabs vs. Spaces has a fairly good answer that flows out of this way of looking at things. There is a counter-argument to that answer, but it is invalidated if you move toward conventions for argument lists and chained method calls that are also designed to limit noise in the source control system.

IMO, the argument about bracing also has a practical, non-religious answer once you start looking at your coding conventions this way.

    >>> from __future__ import braces
    SyntaxError: not a chance