Prothon Prototypes vs Python Classes

[John Roth]

"Michael" <mogmios at mlug.missouri.edu> wrote in message
news:mailman.36.1080541549.20120.python-list at python.org...
>
> >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 don't have very much sympathy for people who
use poor editors to write programs.  I've got a lot of
sympathy for people who are stuck with defective
rendering and printing programs for analyzing programs
that they didn't write in the first place, though. Note that
Python, which is mostly what we're talking about on this
newsgroup, comes with a reasonably competent editor
called Idle. There are very few environments where you
can use Python at all where you can't use Idle.

I've never seen variable width fonts to change the width
of spaces on the left, unless it was doing something like
full justification.

As far as rendering programs, the most obvious
culprit is OE, which for all of its defects and security
problems, is still one of the most used mail and newsgroup
clients out there.

I'll also point out that even programs that properly follow
the tab "standard" will not render well since the standard
is that a tab goes to the next multiple of 8. The number
8 has nothing to do with readability: it was decided on
as the best compromise on compressing the number of
characters going over a line when line speeds were *very*
slow and teletypes really were electromechanical monsters
with these little metal stops called 'tabs' in the back.

There is, of course, no standard at all for how to change
the default tabbing in programs, which means that one
has to deal with each and every one on an individual
basis - if it's even possible.

Reading the source for Idle is quite
enlightening: there is a comment about Tk doing something
rather absurd if you change the tab default.

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

Definitely.

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

Any programming editor worth the name will insert spaces
when you use the tab key; likewise it will adjust with the
backspace key. This is not a problem unique to Python,
after all.

The same comment applies to variable width fonts. A good
programming editor will not use them.

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