Prothon Prototypes vs Python Classes

Michael mogmios at
Mon Mar 29 15:38:18 CEST 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