On 06.04.2013 03:35, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 11:22 AM, <terminato...@gmail.com> wrote:
On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote:
[...]
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://mail.python.org/mailman/listinfo/python-list
