Prothon Prototypes vs Python Classes
mogmios at mlug.missouri.edu
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