On Fri, 05 Apr 2013 17:22:19 -0700, terminatorul 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.
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.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
