Edward Elliott wrote:
What really should happen is that every time an editor reads in source code,
the code is reformatted for display according to the user's settings. The
editor becomes a parser, breaking the code down into tokens and emitting it
in a personally preferred format.
I
Duncan Booth wrote:
No. That is precisely the problem: there is code in the wild which
contains mixed space and tab indentation...
followed by some good examples of mixed tab and space indentation
I wouldn't have a problem with tabs if Python rejected mixed indentation by
default, because
Iain King wrote:
python -tt
Indeed. I reckon the consensus here (to the extent that there is any!)
is that it would be better if this was Python's default behaviour.
The argument (not advanced by Iain but by others in this thread) that:
novices will mix tabs and spaces = we should all use
Andy Sy wrote:
Don't be evil - always configure your editor to
convert tabs to true spaces.
Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.
And I, for the life of me, have never remembered
getting any source code to display
Hitting the spacebar like a madman? If you have a sensible editor then at
the start of a line you press tab once
True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone
Jorge Godoy wrote
Emacs guess what's used in the file and allows me to use tabs all the time,
doing the correct thing...
That sounds like useful behaviour.
Maybe this is an area where modern editors might be able to save us
from ourselves. I'll admit I'm suspicious of relying on editor
Andy Sy
I guess this *REALLY* is how a misguided tab user exercises his 'logic':
Syntax replication (e.g. so-called 'argument construction') is enough,
semantics don't matter.
That's quite amusing.. you've unwittingly stumbled on a pretty concise
statement of Hilbert's first postulate of formal
Andy Sy:
Code with anything other than 8-space tabs will *NEVER* display
properly using everyday unix utilities such as less and cat.
less -xtabstop does what you want.
--
http://mail.python.org/mailman/listinfo/python-list
Dave Hansen wrote:
That will work. As long as the creator of file used four-space TABs,
anyway...
That sentence has no meaning. There is no such thing as a four-space
tab.
--
http://mail.python.org/mailman/listinfo/python-list
Andy Sy wrote:
def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
'from table1 where amount100')
Lines two and three (a continuation line) are both at a syntactic
indentation level of 1. Therefore they should both start with a
Dave Hansen wrote:
However, to twist an observation I've read about C++, while it's
clearly possible to use TABs in a sensible manner like this, it seems
that no one does.
I think it's evident from this thread that quite a few people do that,
judging by the fact that my previous post explaining
It probably says something about your coding style, particularly in
perl. I've found (anecdotally of course) that while perl is potentially
the more economical language, writing *legible* perl takes a lot more
space.
--
http://mail.python.org/mailman/listinfo/python-list
Carl J. Van Arsdall wrote:
The converse can also be said, it's difficult to make sure everyone
uses spaces and not tabs.
I think we've just about beat this discussion to death... nice work
everyone!
Yeah - we've got to the repeating ourselves stage.
But that's the problem with this issue:
Duncan Booth wrote:
but I prefer editors which keep things
simple. The tab key is particularly prone to excessively complicated
actions, for example the editor I use has the following (not simple at
all, and in fact not even an accurate description of what it does) binding
for the tab key:
Kaz Kylheku wrote:
If you want to do nice typesetting of code, you have to add markup
which has to be stripped away if you actually want to run the code.
Typesetting code is not a helpful activity outside of the publishing
industry. You might like the results of your typsetting; I happen not
Duncan Booth wrote:
Because it doesn't mean 'one level of indentation', it means 'move to next
tabstop' and a tabstop isn't necessarily the same as a level of
indentation.
'move to next tabstop' is how your editor interprets a tab character.
'one level of indentation' is how the language parser
Duncan Booth wrote:
However the important thing is that a tab does
not map to a single indentation level in Python: it can map to any number
of indents, and unless I know the convention you are using to display the
tabs I cannot know how many indents are equivalent to a tabstop.
Sorry but this
Harry George wrote:
The reason is simple: People get confused, and accidentally get the
wrong tab indents when they move among editors or among settings on
the same editor.
People certainly do get confused. I'm always amazed that so many
people, even amongst those who manage to make a living
18 matches
Mail list logo
