Prothon Prototypes vs Python Classes

[Christian Tismer]

Michael wrote:

> 
>> 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.

I think there are enough editors available to be able
to use one with fixed font.

>> 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.

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.

>> 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?

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. :-)
> 
>> 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.

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...

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/