Prothon Prototypes vs Python Classes

Michael mogmios at
Mon Mar 29 08:25:43 CEST 2004

>The basic difficulty with tabs is that there are a huge
>number of programs "in the wild" that treat tabs
>differently. Unless you're completely in control of all
>the programs that will ever be used to edit and display
>your program, using tabs will cause formatting errors
>somewhere, to someone under some circumstance
>that you never thought of.
Which programs? I find spaces to cause weird issues. Especially if you 
use some half assed editor that uses variable width fonts.

>The problems with mixed tabs and spaces are even
>worse: you can lose indentation and totally mess up
>the program so it won't even compile if you use the
>wrong tools on such a program.
That'd just be bad programming to use different formatting standards 
within the same program. At least within the same file.

>This is the basic reason why the current standard for
>library modules is 4 space indentation; it's the only
>thing that is, for all practical purposes, guaranteed to
>work for everyone, with any editor, formatter,
>renderer and printer out there.
I don't see how it is any better than a standard of always using a 
single tab or space for indention. I hate code that requires me to press 
multiple space or delete keys to change the block level of a line of 
code. I'm a coder and therefore am lazy. Why press four keys when I 
could press one?

>Python is not Perl. Python's philosophy has never
>been to provide several different ways of doing things
>just to provide different ways. There needs to be a
>demonstrated benefit to the different ways, and tabs
>don't make that cut. If you want the space savings,
>ziping the file will do much better.
I'm not a fan of multiple ways but I think it's different to remove a 
feature than to add a feature. Breaking existing code for pointless 
reasons is bad. I'd rather they keep tab support than spaces but since 
both have a historical support I'd be wary of removing either. Again 
zipping files is adding additional steps which IMO is bad from a lazy 
coder point of view. The lazy coder standard of coding keeps code 
simple. Smaller isn't a significant problem in most cases.

More information about the Python-list mailing list