I hate you all

[terminatorul]

Hello

I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !

I know people have all goten into this frenzy of using either tabs, either spaces for indentation, but using a hard-tab of 8 spaces and a soft tab of 4 spaces has worked fine long before python 3 showed up.

And if they decided to throw a TabError, they should have at least created an option to specify tab size, so I can work around that.

I am aware that so many editors use a tab stop of 4 spaces instead of 8 (which by the way started as a cheap way to work around their initial lack of a "soft tab stop" option, and then was kept at 4 for "compatibility"). But the rest of us who always use a tab stop of 8 should not be forced to change preferences because python reached version 3.

Timothy Madden

 

[Chris Angelico]

Hello

I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !

It is. As long as you're consistent, you can use tabs or spaces
without problems.

You're also most welcome to continue using Python 3.2, or 2.1, or 0.1
(if you're Steven D'Aprano), which might have the semantics you want.

And hey, if you dig into the source, I'm sure you could find how to
make it configurable.

ChrisA

 

[John Gordon]

How can python authors be so arrogant to impose their tabs and spaces
options on me ? It should be my choice if I want to use tabs or not !

You are free to use tabs, but you must be consistent. You can't mix
tabs and spaces for lines of code at the same indentation level.

 

[terminatorul]

You are free to use tabs, but you must be consistent. You can't mix
tabs and spaces for lines of code at the same indentation level.

They say so, but python does not work that way. This is a simple script:

from unittest import TestCase

class SvnExternalCmdTests(TestCase) :
def test_parse_svn_external(self) :
for sample_external in sample_svn_externals :
self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ])

And at the `for` statement at line 5 I get:

C:\Documents and Settings\Adrian\Projects>python sample-py3.py
File "sample-py3.py", line 5
for sample_external in sample_svn_externals :
^
TabError: inconsistent use of tabs and spaces in indentation


Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?

You can try the script as it is, and see python 3.3 will not run it

 

[Andrew Berg]

Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?

The first indent level is done with spaces on the second line (for def)
and then with a tab on the third (and another tab to indent again).
Remember that your for loop is inside the class definition.

 

[Isaac To]

You underestimated the arrogance of Python. Python 3 tab doesn't map to 4
spaces. It doesn't map to any number of spaces. Tabs and spaces are
completely unrelated. If you have a function having the first indentation
level with 4 (or any number of) spaces, the next line starting not with 4
spaces but instead with a tab always lead you to the TabError exception.

If you like to play tricks, you can use "4 spaces plus a tab" as the next
indentation level. I'd rather not do this kind of things, and forget about
use using tabs at all. You are out of luck if you want to play the
tab-space tricks, but if you follow the lead, you'll soon find that code
will be more reliable without tabs, especially if you cut-and-paste code of
others.

In <[email protected]>

You are free to use tabs, but you must be consistent. You can't mix
tabs and spaces for lines of code at the same indentation level.

They say so, but python does not work that way. This is a simple script:

from unittest import TestCase

class SvnExternalCmdTests(TestCase) :
def test_parse_svn_external(self) :
for sample_external in sample_svn_externals :
self.assertEqual(parse_svn_externals(sample_external[0][0],
sample_external[0][1]), [ sample_external[1] ])

And at the `for` statement at line 5 I get:

C:\Documents and Settings\Adrian\Projects>python sample-py3.py
File "sample-py3.py", line 5
for sample_external in sample_svn_externals :
^
TabError: inconsistent use of tabs and spaces in indentation


Line 5 is the only line in the file that starts at col 9 (after a tab).
Being the only line in the file with that indent level, how can it be
inconsistent ?

You can try the script as it is, and see python 3.3 will not run it

 

[Ian Kelly]

They say so, but python does not work that way. This is a simple script:

from unittest import TestCase

class SvnExternalCmdTests(TestCase) :
def test_parse_svn_external(self) :
for sample_external in sample_svn_externals :
self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ])

And at the `for` statement at line 5 I get:

C:\Documents and Settings\Adrian\Projects>python sample-py3.py
File "sample-py3.py", line 5
for sample_external in sample_svn_externals :
^
TabError: inconsistent use of tabs and spaces in indentation


Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

Python 2 resolved this ambiguity by assuming that a hard tab was
simply equivalent to four or eight spaces (I don't remember which).
The problem with assuming this is that the assumption made by Python
does not necessarily match the tab width selected by the user, with
the result that lines that *look* like they are at the same
indentation level might actually be different (and vice-versa),
leading to hard-to-find bugs.

Python 3 instead resolves this ambiguity by not allowing it.

In the code above, because the "def" line has four spaces, the
indentation of the "for" line that is subordinate to it needs to also
start with four spaces (and then you can continue the indentation with
tabs or spaces as you prefer). Because the line after the "for" line
is subordinate to it, it also then needs to begin with the same exact
indentation used by the "for" line (in the sample provided, it
currently does).

My suggestion: choose to use either all tabs or all spaces within a
file, and then you won't have this problem.

 

[terminatorul]

]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

Thank you,
Timothy Madden

 

[terminatorul]

]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

Thank you,
Timothy Madden

 

[Chris Angelico]

]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

If you're indenting four spaces per level, then indent four spaces per
level. The code you posted would work perfectly if the indentation is
four spaces, then eight spaces, then twelve spaces. The problem is
that you have a stupid editor that's enforcing tabs instead of certain
multiples of spaces - get one that'll keep them all as spaces and you
won't have a problem.

Or use actual tabs, and set the displayed tab width to whatever you
feel like. That works, too. Neither option causes any problems with
any sane tools.

ChrisA

 

[Andrew Berg]

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

Python (at least Python 3) has no concept of tab size. A tab is one
character, and how an editor or terminal or whatever chooses to display
it has nothing to do with Python. If you want to convert tabs to a
specific number of spaces or vice versa, there are multiple tools out
there you can use. In fact, many editors have the functionality built in.

Use all tabs or use all spaces. Any editor that isn't broken will let
you do either without problems.

 

[Steven D'Aprano]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns
apart. The "ambiguity" was introduced by editors that do not follow the
default value set in hardware like printers or used by consoles and
terminal emulators.

This is incorrect. Tab stops come from *typewriters*, where they are user-
configurable to any position on the page without limit. There is no
requirement for them to be 8 character columns apart, or even a fixed
number of columns apart. Word processors like OpenOffice and Microsoft
Word get the behaviour of tab stops right. Any editor which forces tabs
to be exactly 8 columns apart gets them wrong.

And now python forces me out of using any tab characters at all.

That is simply not true, and you have been told repeatedly by numerous
people that Python 3 supports tabs. You can use spaces for indentation,
and you can use tabs for indentation. You can even mix spaces and tabs in
the same file. What you cannot do is mix spaces and tabs in the same
block. If you don't believe us, and you don't believe the documentation,
then believe the actual behaviour of the Python 3 compiler. Test it for
yourself. Run this code under Python 3:


=== cut ===

code = """
def spam():
print("indented with five spaces")

def eggs():
\t\tprint("indented with two tabs")


spam()
eggs()
"""

exec(code)

=== cut ===


If it were my language, I would be even stricter about indentation than
Python 3. I would require that each file use *only* tabs, or *only*
spaces, and not allow both in the same file.

 

[Ian Kelly]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

8 characters is common, but no more "correct" than any other, as tab
width has never been standardized. You talk of not wanting tab
options imposed on you, but consider that treating tabs as 8-character
stops imposes that setting on anybody who needs to work with your
mixed-indentation code.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

And then changing that setting could change the meaning of the code,
which would be a disaster for code that you want to distribute.

 

[Dylan Evans]

Hello

I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces
options on me ? It should be my choice if I want to use tabs or not !

Don't like it? Use ruby.

 

[Timothy Madden]

]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

If you're indenting four spaces per level, then indent four spaces per
level. The code you posted would work perfectly if the indentation is
four spaces, then eight spaces, then twelve spaces. The problem is
that you have a stupid editor that's enforcing tabs instead of certain
multiples of spaces - get one that'll keep them all as spaces and you
won't have a problem.

My editor is not the problem, of course, this is about what I think is
right. I think I should be given the option to use tabs as I always
have, and at least to use them with the default tab size, as python 2
used to.

Or use actual tabs, and set the displayed tab width to whatever you
feel like. That works, too. Neither option causes any problems with
any sane tools.

Well this is the problem, the tab size is not "whatever I like", tab
stops are 8 character columns apart (default).

Changing the tab size from this default is what makes the code
incompatible, not the tabs themselves. So the solution is simple: do not
change tab size from the default.

People say I can use tabs all the way, just set them to the indent I want.

Well, I always had my indent independent of the tab size. Which is the
way it should be, after all, since one can indent with or without tabs,
so indent should not be tied to them.

But now I can not; python no longer lets me do that.

Tab size should be 8, so now python 3 says: either indent at 8 with
tabs, either drop tabs and indent with spaces (just the same as if tabs
are not allowed).

But that is so wrong. I can indent at 4 (or any value), and still use
tabs, as long as the interpreter knows tab stops are 8 columns apart.
There is no "ambiguity" and no way to change the meaning of the code.

So as a comparison we have:

- the good old rules
- python has use the default tab stops of 8 columns
- indent is independent of tab stops

- the new rules
- python is independent of the tab stops
- indent is now tied to the tab stop, so users have to :
- use non-default tab size (8 is too much), or
- drop tabs altogether

The new rules may look flexible at first sight, but the net effect they
have is they push me to use non-default tab size (which is not good), or
drop the tabs, which I could have used before python 3 just fine.

Thank you,
Timothy Madden

 

[terminatorul]

Hello


I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !


Don't like it? Use ruby.

Actually next on my list is perl. I know ruby is sexy, but taming the wild beast is what makes me feel like the real cowboy.

 

[terminatorul]

Hello


I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !


Don't like it? Use ruby.

Actually next on my list is perl. I know ruby is sexy, but taming the wild beast is what makes me feel like the real cowboy.

 

[Benjamin Kaplan]

]

The "def" line has four spaces. The "for" line then has a hard tab.
This is ambiguous. If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level. If it is assumed
to have a width of eight spaces, then they are not.

[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

If you're indenting four spaces per level, then indent four spaces per
level. The code you posted would work perfectly if the indentation is
four spaces, then eight spaces, then twelve spaces. The problem is
that you have a stupid editor that's enforcing tabs instead of certain
multiples of spaces - get one that'll keep them all as spaces and you
won't have a problem.

My editor is not the problem, of course, this is about what I think is right. I think I should be given the option to use tabs as I always have, and at least to use them with the default tab size, as python 2 used to.

Or use actual tabs, and set the displayed tab width to whatever you
feel like. That works, too. Neither option causes any problems with
any sane tools.

Well this is the problem, the tab size is not "whatever I like", tab stops are 8 character columns apart (default).

Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default.

People say I can use tabs all the way, just set them to the indent I want.

Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them.

But now I can not; python no longer lets me do that.

Tab size should be 8, so now python 3 says: either indent at 8 with tabs, either drop tabs and indent with spaces (just the same as if tabs are not allowed).

But that is so wrong. I can indent at 4 (or any value), and still use tabs, as long as the interpreter knows tab stops are 8 columns apart. There is no "ambiguity" and no way to change the meaning of the code.

So as a comparison we have:

- the good old rules
- python has use the default tab stops of 8 columns
- indent is independent of tab stops

- the new rules
- python is independent of the tab stops
- indent is now tied to the tab stop, so users have to :
- use non-default tab size (8 is too much), or
- drop tabs altogether

The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), or drop the tabs, which I could have used before python 3 just fine.


Thank you,
Timothy Madden

http://www.xkcd.com/1172/

 

[Timothy Madden]

8 characters is common, but no more "correct" than any other, as tab
width has never been standardized. You talk of not wanting tab
options imposed on you, but consider that treating tabs as 8-character
stops imposes that setting on anybody who needs to work with your
mixed-indentation code.


And then changing that setting could change the meaning of the code,
which would be a disaster for code that you want to distribute.

8-character tab stops should be the default. Debating that is I believe
another topic, and compatibility with python2 should be enough to make
that debate unnecessary.

You are right, to change the tab size means to change the meaning of the
code, and that would be wrong. Can't argue with that.

What I want is an option to use the tabs as I have used them in the
past, with the default size. Since "ambiguity" about the tab size
appears to be the cause for new python 3 rules, I though of an option
the make that size explicit. I still think users should somehow have a
way to use a tab stop of their choice, but how this could be achieved
properly is another problem.

I guess a discussion like this thread is the price to be paid for
relying solely on white space to delimit code blocks, like the python
syntax does.

Thank you,
Timothy Madden

 

[Chris Angelico]

I guess a discussion like this thread is the price to be paid for relying
solely on white space to delimit code blocks, like the python syntax does.

Absolutely. Bring on Python 5000, where all such stupidities are
abolished and we can argue about really important matters, like
whether chr(7) should be allowed in identifiers.

ChrisA