On Sun, Dec 09, 2001 at 11:00:11AM -0800, Chuck Esterbrook wrote:
> Also, instead of changing how I code in Python, shouldn't editors like
> emacs do the right thing? Python is the first language I've used where
> I was expected to cater to a single editor (and one with source)
> instead of expecting the editor to handle the language's text files.
> That seems like hubris.
Python is the only language (at least among the C[++|#]/Java/Perl/PHP/Lisp
that most Pythoneers would otherwise be using) where indentation affects
the syntax rather than just being an aesthetic convention. Thus, why
we're more sensitive to different editors' behavior.
The 80-column debate, however, I don't think is any different for Python
than for any other language. All projects have to decide whether to
stick to 80 columns or go wider. I personally favor 80 columns (or 79).
This makes the code maintainable anywhere, printable anywhere with the default
printer font, sharable via e-mail (important for debugging and
brainstorming), etc. Yes, it sucks trying to squeeze expressions into
80 columns or having to split the lines, but it's a tradeoff. Usually
when you have a long line you don't want to split, most of the line is a
string literal. So I factor the string out to a separate statement,
put """\ above it and """ below, and type the string without
indentation. I also don't line up function arguments or long
initializers underneath the first argument, but just give them one extra
tab in order to fit as much code on one screenful as possible without
sacrificing the a minimum level of formatting.
Regarding tabs vs spaces, I don't know, there's no one ideal answer.
Universal compatibility argues for using tabs--that is what the tab key
and \t are for anyway---with tabstops at 8 columns. On the other hand,
this encourages mixing tabs and spaces (tabs for the indentation level,
then a few more spaces to line up expression parts vertically), which is
way more trouble than it's worth. And if somebody sets their tabstop to
a different setting, there goes your beautiful formatting (and possible
syntax errors, or functions and loops that end on the wrong line, if
they indent their lines with all spaces and then somebody else opens the
file with a different tabstpop/expandtabs setting and adds their own
lines.
Sooner or later, you've got to reformat the entire file, and
that involves eyeballing to guess where a function/loop/if ends. In
that sense, using only spaces avoids at least some of those problems.
So I have recently gotten into the habit of 4-column spaces, and put:
# vim: shiftwidth=4 tabstop=4 expandtab
at the bottom of every file I edit frequently (as you'll see in some
Cheetah files). Yes, it sucks that you'd need a line like that for
every editor, but maybe it shows that the real culprit is that editors
don't have a common convention for specifying this. And it sucks that
you can't use the \t that was specifically designed for this purpose,
but that's the way the cookie crumbles.
> You say "no, I won't do this and I won't do that for your source", but
> then expect me to say "yes, I'll do this and I'll do that for one
> problematic editor". That seems unbalanced.
It's not one problematic editor. All editors are prolematic for
Python, they're just each problematic in a different way. Vim sometimes
mishighlights in the middle of a triple-quoted string. Emacs' "smart tab"
feature won't allow you to give more indentation to a line than it
thinks you need. Vim inserts four spaces when you press tab, but when
you backspace over it to delete the indentation, you have to eat each
space individually rather than the four as a unit.
--
-Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED])
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
