I hate you all

[Michael Torrie]

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

How did I ever miss this before? That is truly awesome.

 

[Ian Kelly]

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.

So in other words, everybody must be forced to use 8-character tabs
because you want to be able to mix tabs and spaces.

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.

Honestly, I really don't understand why you *want* to do that. If
your indentation is 4 characters, then that would be the natural tab
width to use. If you're not going to tie your indent to your tabs,
then why even use tabs in the first place?

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),

What makes that not good? There is no law anywhere that says tabs are
8 characters. That's just an arbitrary amount that looked appropriate
to the people designing the first teletypes.

 

[Michael Torrie]

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.

I've always been taught that in Python using tabs, particularly in the
way that you use them (which, by the way, is the default way vim uses
them when in C++ mode) is fraught with difficulty. So years ago I
dropped in c couple of lines in my vimrc file to use spaces instead of
tabs and use the PEP standard of 4 spaces. Have never had any problem.

As for your problems, perhaps instead of coming on the list with a
poorly-thought-out subject line, and desire to simply argue, perhaps you
could run your code through a reformatter that would translate your tabs
into spaces using the tab stop that you desired. Open the file in vim,
enter the following commands:

set sw=4
set ts=8
set et
set softtabstop=4
set ai
:retab

Then save the file. Now it's pep-formatted with spaces and no tabs.
Problem solved. Yes it doesn't address your concerns, but it is the
recommended solution for Python given the difficulties in mixing tabs
and spaces and different people's definition of tabs.

 

[Michael Torrie]

What makes that not good? There is no law anywhere that says tabs are
8 characters. That's just an arbitrary amount that looked appropriate
to the people designing the first teletypes.

Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes
per tab character in the source code! Think of the savings.

 

[Ethan Furman]

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.

Python 3 broke a lot of things. Pull on your big-boy underwear and deal with it.

Thank you,

Saying 'thank you' does not mitigate you acting like an ass.

 

[Steven D'Aprano]

Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes
per tab character in the source code! Think of the savings.

If we standardize on 1025 spaces per indent, and use tabs, we can save
1KiB per indent. Let's see now... looking at a typical piece of code in
my code base, I make it that the average line of code is indented about
1.75 levels. (I use a lot of top-level functions, and few classes). With
an average line length of 50 characters, plus indentation, we can reduce
the size of a typical Python module by ninety-seven percent!

Of course, what we save in disk space, we lose in monitor size, but I'm
sure that the price of 300 inch monitors will soon become quite
affordable.

 

[Steven D'Aprano]

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.

Compatibility with Python 2 is not a requirement. Python 3 exists to fix
a bunch of design flaws and mistakes in Python 2. Among the changes:

- print and exec are now functions, not statements
- the dangerous input function is gone
- raw_input is renamed input
- the distinction between int and long is gone
- the second-string "classic classes" are gone
- strings are Unicode, not bytes
- division is done correctly
- the error-prone syntax of the "except" statement is fixed
- inconsistently named modules are fixed
- the plethora of similar dict methods is cleaned up
- map, filter, zip operate lazily rather than eagerly

and of course

- mixed spaces and tabs for indentation is gone

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.

I can argue with that. Changing tab size does *not* change the meaning of
code, provided you *only* use tabs for indentation.

Using only tabs for indentation is fine. Whether you set your editor to
display tabs as 2 columns, 4 columns, 8 columns, or a thousand columns
will make not a whit of difference to the meaning of the code or the
number of indent levels. This is the Killer Feature of tabs, and it is
the primary reason why tabs rule and spaces suck for indentation.

(Alas, too many broken tools that can't handle tabs mean that the less-
good standard won.)

Using only spaces for indentation is also fine. Not as good as tabs,
because if I use spaces, you're stuck reading my code in whatever poorly-
thought out indent I might choose. I've seen developers use *one* space.
But using only spaces does work.

What does not work in general, is mixing the two. Don't mix them for
indents, and you'll be fine.

What I want is an option to use the tabs as I have used them in the
past, with the default size.

You can continue to use tabs, so long as you don't mix them with spaces.

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.

Unnecessary complexity to solve a non-problem. Just pick one, tabs or
spaces, and consistently use it in any one block of code. You don't even
have to be consistent over an entire file.

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.

Mixing spaces and tabs for indentation is bad in brace languages too.

http://mailman.linuxchix.org/pipermail/programming/2004-August/001433.html


Maybe if we had smarter editors and smarter diffs and smarter tools in
general, it wouldn't be a problem. But we don't, so it is.

 

[Timothy Madden]

So in other words, everybody must be forced to use 8-character tabs
because you want to be able to mix tabs and spaces.


Honestly, I really don't understand why you *want* to do that. If
your indentation is 4 characters, then that would be the natural tab
width to use. If you're not going to tie your indent to your tabs,
then why even use tabs in the first place?


What makes that not good? There is no law anywhere that says tabs are
8 characters. That's just an arbitrary amount that looked appropriate
to the people designing the first teletypes.

I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!)
will not justify the time spent debating.

The reason I want to use tabs is that I think there is nothing wrong
with them.

The reason why everybody should use 8-character tabs is so that I and
the rest of the world can use `grep` / `findstr` on their code, and
still see lines of code properly aligned in the terminal. Or to be able
to print fragments of code as plain text only, and get the proper alignment.

But most importantly, the reason that tab size should be 8 is so that
all of us people in this world can freely exchange formatted text like
source code without having to first consider if "will it look the same
in their editor ? What tab size do they use ?"

In other words, the solution to "different people's definition of tabs"
is not to drop them, but only to get a common default. Which is already
there: 8 columns between every tab stop.

What python 3 does is a different attitude, and that is:

everyone likes their own indent. Although I personally find it annoying,
I am aware that many people use an indent of 2 spaces, some use even 3.
Moreover, many C programers still like 8 spaces per indent.

So some development environments find it an advantage to use tabs only
for indentation, and every programmer is then free to set the tab stop
to their liking. Everyone will see the indent they like, with no changes
in the byte stream for the file.

Why I think this is wrong is a little difficult for me explain. First, I
admit this approach toward tabs has some value and is tempting for me,
too. But it assumes everything, everywhere can configure tab sizes.
Consoles and printers usually do not. Next, even if they can, most
people, including all non-technical personal, never bother to change
settings. Then this also assumes I change settings to my liking on
several computers I use (maybe I work for several clients each with
their computers, most people have a work computer and a home computer,
maybe also a laptop and a tablet/smart device). Last, this is also not
helpful if two sometimes use the same computer from time to time, and do
not want to switch users all the time.

So this is not a very good approach, and I have the feeling that most
python programmers and development environment prefer to use only spaces
than to use variable tab sizes.

So the right solution remains a proper default setting for the tab size,
and then we no longer have to drop tabs from source code files.

Thank you,
Timothy Madden

 

[Timothy Madden]

On 06.04.2013 08:58, Michael Torrie wrote:
[...]

As for your problems, perhaps instead of coming on the list with a
poorly-thought-out subject line, and desire to simply argue, perhaps you
could run your code through a reformatter [...]

Hey, I was feeling frustrated ... ! It is how people feel when they no
longer have a choice they used to have.

But I hear programmers should get used to the feeling: using code that
you did not write is bound to trigger that reaction every so often.

Timothy Madden

 

[Joshua Landau]

[...]

So in other words, everybody must be forced to use 8-character tabs
because you want to be able to mix tabs and spaces.

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.

Honestly, I really don't understand why you *want* to do that. If
your indentation is 4 characters, then that would be the natural tab
width to use. If you're not going to tie your indent to your tabs,
then why even use tabs in the first place?

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),

What makes that not good? There is no law anywhere that says tabs are
8 characters. That's just an arbitrary amount that looked appropriate
to the people designing the first teletypes.

I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!)
will not justify the time spent debating.

The reason I want to use tabs is that I think there is nothing wrong with
them.

So use them

The reason why everybody should use 8-character tabs is so that I and the
rest of the world can use `grep` / `findstr` on their code, and still see
lines of code properly aligned in the terminal. Or to be able to print
fragments of code as plain text only, and get the proper alignment.

Oh thanks. I liked using my four character tabs, but I guess you *are* so
important that I'm going to have to change everything I do just for you.
It's obviously not good enough for you just to not mix tabs and spaces so
that we can both enjoy ourselves because that would make *you*, the holiest
of all, have to put some effort in. No, I totally understand and will now
go and change everything after Python is changed to break hundreds of files
of codes for you.

But most importantly, the reason that tab size should be 8 is so that all
of us people in this world can freely exchange formatted text like source
code without having to first consider if "will it look the same in their
editor ? What tab size do they use ?"

Hrm. Hrm. Hrrrrmmm.

Hrrrrmmmm.

No, you're right: spaces are totally not for this in any way and that
no-one has ever made this point before and who the hell cares if you're
reading code with a different indent size anyway it's not like it affects
the actual code.

Yours frustratedly,

Joshua Landau

----------------------------------------------------------------------------------------------------------------

But seriously, please at least look like you've read other people's posts.
It doesn't matter what tabstop you use as long as you don't mix. If your
code depends on tab size then it's categorically wrong. Other people's tab
sizes are as valid. I use tabs because of the variation it lets me have - I
can switch tab sizes on the fly - and it's faster on "dumb" editors. So let
me do that.

But let us assume we were going to standardise on TAB == 8 SPACES. It would
*still* be bad to mix tabs and spaces. Hence you'd change Python in exactly
0 ways. So *what do you want from us*?

 

[G?nther Dietrich]

[...]

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.

You know the Unix command 'expand'? If you used tabs representing eight
columns consequently, use expand on your python scripts to convert tabs
to spaces before running them.



Best regards,

G?nther

 

[Nobody]

8 characters is common, but no more "correct" than any other,

This is pure revisionism. 8-column tabs may never have been a significant
/de jure/ standard (although they have been that in many specific
domains), but they have been a significant /de facto/ standard for almost
as long as computers have existed.

Historically, software and hardware which assigns a meaning to a tab
character has come in two flavours:

1. Tab stops are every 8 columns; this cannot be changed.
2. Tab stops are configurable, defaulting to every 8 columns.

Creating software which, in the absence of both a good reason and an
explicit mechanism for communicating the configured value, treats them as
configurable is usually a consequence of a "code now, think later"
mentality (although there may have be a few cases where it was a
deliberate "embrace, extend, extinguish" tactic).

 

[Chris Angelico]

Historically, software and hardware which assigns a meaning to a tab
character has come in two flavours:

1. Tab stops are every 8 columns; this cannot be changed.
2. Tab stops are configurable, defaulting to every 8 columns.

3. Tab stops are measured in something other than characters.

With variable-width fonts, it's illogical to set tab stops in
characters. DeScribe Word Processor defined them in centimeters, way
back in the early... well, I didn't meet it till the 90s, but I don't
know how long it had been around before that.

ChrisA

 

[Timothy Madden]

On 06.04.2013 13:17, Joshua Landau wrote:
[...]

Yours frustratedly,

Joshua Landau

When the default tab size is 8, than tab size does matter.

Because it is too much to use as indent size. If you still want to use
tabs, you are now supposed to change tab size from the default. I
believe using non-default tab size in a public environment like
open-source code is bound to cause formatting problems for someone at
some point.

If your code depends on tab size then it's categorically wrong. Other
people's tab sizes are as valid. I use tabs because of the variation it
lets me have - I can switch tab sizes on the fly - and it's faster on
"dumb" editors. So let me do that.

But let us assume we were going to standardise on TAB == 8 SPACES. It
would *still* be bad to mix tabs and spaces. Hence you'd change Python
in exactly 0 ways. So *what do you want from us*?

Well all previous (python 2) code is meant to work for a tab size of 8.
You may call this "categorically wrong", but it has been there a long
while, is is still in use, and it sticks to the default.

Spaces-only can achieve compatibility between different people settings
for formatted text like source code. But so does a common default for
the tab size, and with that we do not have to limit ourselves to spaces
only.

Now I understand python 3 people may already use tabs with a size of 4,
as you said. Although I tried to show this is not good practice, (and
that not many people do that, really, since most of them prefer to use
all-spaces instead), still I do not expect the people to change their
settings.

What I would expect is some option in python to make tabs work the way
they used to. I want a choice for me to preserve my settings, the same
way you want to preserve yours.

What I want should not be much to ask, since this is how python 2 used
to do things.

I admit such a '--fixed-tabs' option, that will make tab stops be 8
columns apart, and allow any number of spaces like in python 2, makes
the code I write dependent on that option.

But the option will run all code written for the new "python 3 way", and
brings back some compatibility, so it is not that bad. And some people
might actually want it.

Timothy Madden

 

[Timothy Madden]

3. Tab stops are measured in something other than characters.

With variable-width fonts, it's illogical to set tab stops in
characters. DeScribe Word Processor defined them in centimeters, way
back in the early... well, I didn't meet it till the 90s, but I don't
know how long it had been around before that.

Yes, but systems with variable-width fonts do not make the default for
the tab size now.

 

[Roy Smith]

3. Tab stops are measured in something other than characters.

With variable-width fonts, it's illogical to set tab stops in
characters. DeScribe Word Processor defined them in centimeters, way
back in the early... well, I didn't meet it till the 90s, but I don't
know how long it had been around before that.

What makes sense for a word processor and what makes sense for a
programming language are two very different things.

Word processors are almost always working with blocks of running text,
set in proportional fonts, often with multiple font sizes and styles.
It is usually assumed that line breaks are ephemeral, i.e. as the text
gets edited and reformatted, lines will re-flow.

Program text is almost always(*) displayed in a fixed-width font. No
font information is carried along with the program text at all; it is
assumed the reader will pick a font and size of their own preference,
with the only requirement being that it's monospaced.

(*) There was a fad about 10 or 15 years ago to print code samples in
books in proportional fonts. Prentice-Hall seemed to be particularly
guilty of this. Fortunately, common sense prevailed and everybody has
gone back to monotype.

 

[Neil Cerutti]

(*) There was a fad about 10 or 15 years ago to print code
samples in books in proportional fonts. Prentice-Hall seemed
to be particularly guilty of this. Fortunately, common sense
prevailed and everybody has gone back to monotype.

Bjarne Stroustrup likes it, and I agree with him that code is
even easier to read that way, especially in hard-copy.

But most tools have not caught up with the idea. I'll switch as
soon as vim supports it.

 

[Grant Edwards]

[Mad that in 3.3 you can no longer use ambiguous mixtures of spaces
and tabs within a single indent level.]

My boss would refer to this as a failure to be "bug-compatible" with
the previous version.

Whether or not to maintain bug-compatibility when you bring out a new
version is one of the eternal debates. No matter what you do, it's
going to annoy somebody...

 

[Grant Edwards]

When the default tab size is 8, than tab size does matter.

There is no default size. The size of a tab isn't even constant
across a line -- they're individually adjustable. The tabs "default"
to wherever they were left by the last person who used the typewriter.

All assumptions about the size or predictabilty of tabs are erroneous.

 

[rusi]

What makes sense for a word processor and what makes sense for a
programming language are two very different things.

Word processors are almost always working with blocks of running text,
set in proportional fonts, often with multiple font sizes and styles.
It is usually assumed that line breaks are ephemeral, i.e. as the text
gets edited and reformatted, lines will re-flow.

Program text is almost always(*) displayed in a fixed-width font. ?No
font information is carried along with the program text at all; it is
assumed the reader will pick a font and size of their own preference,
with the only requirement being that it's monospaced.

(*) There was a fad about 10 or 15 years ago to print code samples in
books in proportional fonts. ?Prentice-Hall seemed to be particularly
guilty of this. ?Fortunately, common sense prevailed and everybody has
gone back to monotype.

Hmm?
One of my favourite books on programming is Intro to functional
programming by Bird and Wadler (1st edition Prentice Hall).
I always knew that part of why I liked the book was the beautifully
typeset code.
Now I know how this choice dates me!!
[It was published in 1988; I used it to teach from '89 onwards]