Prothon Prototypes vs Python Classes
Michael
mogmios at mlug.missouri.edu
Mon Mar 29 08:38:18 EST 2004
> I think there are enough editors available to be able
> to use one with fixed font.
Exactly. I'd say the same thing about the problem with tabs. If your
editor has some weird issue with tabs then fix it or use a different
editor. It seems a bit odd to me that it's an issue at all.
> worse: you can lose indentation and totally mess up
> The problems with mixed tabs and spaces are even
>
> You gave the best example by yourself: Use different editors,
> even with fixed fonts, and you will wonder how they try
> to "optimize" your tabs. Some try to help you with the indentation,
> but they use tabs, even if you are not aware of it.
> I don't say it is a hard problem. But it is an extra complication
> which consumes a reasonable amount of Python code to check/repair,
> like tabnanny.
Why should an editor change anything in your program at all unless you
tell it to? If it's changing tabs to spaces or vice versa then it sucks.
If I want something optimized I'll enter a command telling it to do so.
Otherwise hands off.
> Becuase there are editors which default to tab==4 spaces
> and some with tab==8 spaces. I have this problem still all
> over the place in the C code of the Python implementation.
> I like tab==4 spaces quite much, and it is the default for
> Visual Studio. But sources which are edited in Linux most of
> the time, seem to default to tab==8 spaces.
> It is very convenient, I agree. But I would like to teach
> my editor to convert to tabs for editing only, and then
> change them back to spaces on saving. :-)
Who cares how an editor displays code as long as it's smart enough not
to assume things and change that code. Save a tab as a tab and you can
display the tab anyway you want and it shouldn't matter. The whole idea
of having to make your editor imagine tabs when editing and save as
spaces seems to be an example of needless checking and repair as you
mentioned before. Why not just use tabs? Whatever is more convient for
editing should be the standard. Anyone that wants a 1 space tab is free
to configure their editor to make tabs take one space. It'd be incorrect
to set your editor to make a space take four or eight spaces if actting
as indention. If I enter a tab in my editing of code then it is saved to
the file as a tab and not as any number of spaces at all. How is that
undesirable? I'd be just as annoyed if I typed a given number of spaces
and found it saved as a tab in my file. Either behavior would indicate a
poorly designed editor.
> Well, I don't think it is about removing a feature, but
> about removing a problem. Which basically cannot be completely
> solved, as long as tabs and different editors exist...
A tab is a tab. This sounds like adding complexity in the effort to
avoid complexity. If your editors are broken then stop using them.
More information about the Python-list
mailing list