Dennis Lee Bieber wrote:
>
> Unless there has been a major change in the parser... (I still don't
> have Python 3.x installed)
>
> I believe <tab> is expanded to 8-spaces -- NOT TO NEXT MULTIPLE OF
> 8...
A tab is *one* character. Your *editor* may show tabs visually
"expanded" or convert them to spaces. This is entirely editor dependent.
My current (python) editor, does expands tabs to the next *multiple* of 4.
It helps keep code aligned, and I have no need for 4 hard spaced tabs
without regards to alignment (yet). I have had editors that did 4 hard
spaced tabs, so it might be a developer/application preference.
>>> with open(r'c:\ramit\mix_tab_space.txt')as f:
... d = f.read()
...
>>> print repr(d)
'\tblah\n test\n\t'
>>> print d[0] + 'goo'
goo
>>> print repr(d[0] + 'goo')
'\tgoo'
>
> So the first is 8+4 => 12 spaces, the second is 2+8+4 => 14 spaces.
>
> Does 2 + <tab> + 2 vs 4 + <tab> vs <tab> + 4 succeed? That would
> confirm the treatment.
>
> The main concern with mixed tab and spaces, as I recall, was due to
> having /editors/ and /terminals/ configured to show <tab> as a four
> space (or anything other than an eight space) increment; so visually
> four spaces and one <tab> might look the same... One user might have the
> editor showing 4-space indents on <tab> but entering text using 4 spaces
> on input -- which now is mis-aligned if the source file HAD <tab> in it.
~Ramit
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
--
http://mail.python.org/mailman/listinfo/python-list
