Prothon Prototypes vs Python Classes

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Michael" <mogmios@mlug.m issouri.edu> wrote in message
news:mailman.21 .1080516361.201 20.python-list@python.org ...[color=blue]
> They're planning to remove tab indention support in 3.0? I for one would
> be pissed off at such a change. I don't mind people using spaces if they
> like but I see no reason I shouldn't be able to use tabs if I like. I
> can't see how it should make any difference to Python which you use so
> why not allow for personal preference?[/color]

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.

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.

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.

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.

John Roth

[John Roth]

Re: Prothon Prototypes vs Python Classes

"John Roth" <newsgroups@jhr othjr.com> wrote in message
news:106eo695a9 t8820@news.supe rnews.com...[color=blue]
> "Harald Massa" <cpl.19.ghum@sp amgourmet.com> wrote in message
> news:Xns94BBF15 2E6BBcpl19ghums pamgourmet@62.1 53.159.134...[color=green]
> > Mark,
> >
> > I see most discussion about Prothon is concerning prototypes.
> >
> > Can you explain to me in easy words, why it is NOT possible to integrate
> > prototypes into Python to stand "side by side" with classes?
> >
> > I never had a problem to "add an attribute" to an existing object; I[/color]
> really[color=green]
> > can't see why it should be more than some small hacks to allow "adding a
> > function to an existing object".[/color]
>
> As you note, you can do that with a simple assignment,
> and it will work. The two problems are:
>
> 1. The clone operation
>
> 2. Syntax sugar to make it all nice and palatable.
>
> I suspect that a usable clone() operation is less
> than 10 lines. The syntax sugar, on the other hand,
> will IMNSHO, take forever to get agreement.
>
> John Roth[/color]

Sigh. I'm replying to my own post. After I posted this, I
remembered that something needs to be done to set up an
inheritance chain among instances. That requires a custom
__getattribute_ _() magic method, which will not be all that
easy to write.

John Roth[color=blue][color=green]
> >
> >
> > Harald[/color]
>
>[/color]

[Hung Jung Lu]

Re: Prothon Prototypes vs Python Classes

Harald Massa <cpl.19.ghum@sp amgourmet.com> wrote in message news:<Xns94BBF1 52E6BBcpl19ghum spamgourmet@62. 153.159.134>...[color=blue]
> Can you explain to me in easy words, why it is NOT possible to integrate
> prototypes into Python to stand "side by side" with classes?[/color]

It is possible, but you will not be able to retroactively apply it to
many existing objects. You will only be able to do things with your
new customized objects.

For instance, there is a class called 'module', and in Python you
cannot add attributes to it. Similary, there is a metaclass 'type',
and you cannot add attributes nor insert hooks to it.

Either you start afresh with prototypes from ground up, or you won't
be able to modify the behavior of existing Python objects.

I believe there was already some previous attempts along the line that
you have said.
[color=blue]
> I never had a problem to "add an attribute" to an existing object; I really
> can't see why it should be more than some small hacks to allow "adding a
> function to an existing object".[/color]

Sure, adding an attribute to *your* objects is not an issue. Adding
attributes and modify the behavior of other people's objects is the
issue. These "other people's objects" include system objects, and
objects created by third-party.

The "other people" often include yourself. It is hard to explain.
Maybe I can suggest reading my previous posting:

http://groups.google.com/groups?q=g:thl1486542349d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=8ef9bea6.0403260837.72a8fade%40posting.google.com&rnum=27

There are quite a few software development needs that one only
discovers when one goes to large projects, with various components,
maybe even in different languages.

It is only when things get complex that you wish you had a clean and
pure foundation. When your projects are small, deficiencies and
impurities in your language don't matter too much.

-----------------------

I think the current way how OOP is taught is kind of bad. The lectures
would start with definition of classes, inheritance, virtual
functions, etc.

As I have mentioned a few times in this mailing list, software
engineering, and all human intellectual activities, ultimately come
down to factorization (of code, or of tasks). From simple algebra to
supersymmetric quantum field theory, it has been so. From goto
statements to OOP to metaclasses to AOP to prototype-based, it has
been so.

Instead of starting with dogmas and axioms, people can probably better
focus on factorization and how it happened. People don't just invent
OOP or prototype-based language out of blue, nor did they come up with
database normalization rules out of blue. People arrived at these
devices because they observed: (1) similar tasks or code spots all
over places, that is, they discovered a symmetry, a repetitive
pattern, which often was becoming painful to deal with, (2) they then
figured out a way to factorize the code or organize the tasks, so to
factor out the common part and make their lives less painful.

It's only after (2) that they invent a new concept or technology, and
from then on they know that in the future they can start right away
with the new approach, instead of writing the same code in two spots
and later having to factorize them out.

------------------

I often don't know how to take it when I see people talking about OOP
by using definitions like: polymorphism, data hiding, etc. As if these
definitions were something of utmost importance. To me, OOP is just a
tool for factorizing code, just like using for-loops and using
functions to factor out repetitive code. Polymorphism, data hiding,
etc. are all secondary features: code factorization is the heart and
soul of OOP. Class-based OOP is a way of factorizing. Prototype-based
is just another way of factorizing, which seems to be more elegant:
instead of two concepts (classes and instances), you unify them and
have only one concept (objects). Moreover, in a prototype-based
language like Io, even scopes and objects are unified.

In C++, many new programmers get confused about the usage of macros,
templates (generics in Java in C#) and multiple inheritance (mix-in).
Sure, they are harder to read. But behind each device, the simple and
ultimate goal is nothing but code factorization. Metaprogramming in
Python? The same thing.

A CS professor friend of mine once said: "all problems in CS are
solved by just one more level of indexing," which has been very true
in my experience. I would like to say further that if someone truly
understands factorization and applies it at every moment, then he/she
should not only be awarded a Ph.D. in CS but perhaps also a Nobel
Prize. :)

Hung Jung

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue]
>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.
>
>[/color]
Which programs? I find spaces to cause weird issues. Especially if you
use some half assed editor that uses variable width fonts.
[color=blue]
>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.
>
>[/color]
That'd just be bad programming to use different formatting standards
within the same program. At least within the same file.
[color=blue]
>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.
>
>[/color]
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?
[color=blue]
>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.
>
>[/color]
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.

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

> Can you explain to me in easy words, why it is NOT possible to integrate
prototypes into Python to stand "side by side" with classes?

I certain that it IS possible to add ANYTHING to Python. My whole
motivation for Prothon was to start fresh with a clean slate and have less.
I'm still experimenting with things that can be removed.

I want to make it clear that I don't think Python is broken or needs
replacing. Python is what it is. I have no idea if Prothon will be around
in 10 years or not but I'm sure Python will still be around.

Having said that, I think there are things about Prothon that really kick
ass. The combination of threaded interpreter with extremely simple locking
objects is exceeding my expectations. This engine is really going to shine
when it matures.

"Harald Massa" <cpl.19.ghum@sp amgourmet.com> wrote in message
news:Xns94BBF15 2E6BBcpl19ghums pamgourmet@62.1 53.159.134...[color=blue]
> Mark,
>
> I see most discussion about Prothon is concerning prototypes.
>
> Can you explain to me in easy words, why it is NOT possible to integrate
> prototypes into Python to stand "side by side" with classes?
>
> I never had a problem to "add an attribute" to an existing object; I[/color]
really[color=blue]
> can't see why it should be more than some small hacks to allow "adding a
> function to an existing object".
>
>
> Harald[/color]

[has]

Re: Prothon Prototypes vs Python Classes

Harald Massa <cpl.19.ghum@sp amgourmet.com> wrote in message news:<Xns94BBF1 52E6BBcpl19ghum spamgourmet@62. 153.159.134>...[color=blue]
> Mark,
>
> I see most discussion about Prothon is concerning prototypes.
>
> Can you explain to me in easy words, why it is NOT possible to integrate
> prototypes into Python to stand "side by side" with classes?[/color]

Anything's possible, but would you want to? Aside from increasing
language complexity, introducing a second OO programming model would
violate Python's core "one way to do it" philosophy.

Adding features is easy. It's leaving them out that's hard. ;)

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <106ev65lpu5961 4@news.supernew s.com>, John Roth wrote:[color=blue]
> Sigh. I'm replying to my own post. After I posted this, I
> remembered that something needs to be done to set up an
> inheritance chain among instances. That requires a custom
> __getattribute_ _() magic method, which will not be all that
> easy to write.[/color]

I'm collection up implementations (I've got 4 now) and later this week
(or next weekend, if I get too busy at work) I'll make a post about
what's been done and what still needs to be done.

Joe

[Ville Vainio]

Re: Prothon Prototypes vs Python Classes

>>>>> "Mark" == Mark Hahn <mark@prothon.o rg> writes:

Mark> I certain that it IS possible to add ANYTHING to Python. My
Mark> whole motivation for Prothon was to start fresh with a clean
Mark> slate and have less. I'm still experimenting with things
Mark> that can be removed.

I guess the issue is whether it would have been simpler to fork the
CPython interpreter, providing patches that enable the prototype-based
programming. It would have been quite a jump start, if feasible.

Mark> Having said that, I think there are things about Prothon
Mark> that really kick ass. The combination of threaded
Mark> interpreter with extremely simple locking objects is
Mark> exceeding my expectations. This engine is really going to
Mark> shine when it matures.

Sounds great. If you prove that it's the faster approach, perhaps
we'll be seeing something like that in CPython soon.

FWIW, I would guesstimate that the tab indentation mostly serves to
kill the interest of many who would otherwise take a deeper
look. There are many (like me) who think that the approach is
fundamentally wrong.

--
Ville Vainio http://tinyurl.com/2prnb

[Dang Griffith]

Re: Prothon Prototypes vs Python Classes

On Sat, 27 Mar 2004 21:33:50 -0500, "John Roth"
<newsgroups@jhr othjr.com> wrote:
[color=blue]
>
>"Michael" <mogmios@mlug.m issouri.edu> wrote in message
>news:406635AB. 9050803@mlug.mi ssouri.edu...[color=green]
>> I'm not terribly familiar with the concept of prototypes although I
>> believe I understand the basic meaning and I have worked in languages
>> which do use prototypes (although not called that).
>>[/color]
>I'd like to play around with a prototype based language to see how it
>works, although for reasons I've mentioned elsewhere, I won't use
>Prothon. I'd be using IO if they had a windows executable installer,
>rather than requiring me to compile the silly thing.[/color]

I'm pretty sure PowerBuider is prototype-based, although they don't
document it as such.
It has a Windows-executable installer, also. :-)
--dang

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Michael" <mogmios@mlug.m issouri.edu> wrote in message
news:mailman.36 .1080541549.201 20.python-list@python.org ...[color=blue]
>[color=green]
> >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.
> >
> >[/color]
> Which programs? I find spaces to cause weird issues. Especially if you
> use some half assed editor that uses variable width fonts.[/color]

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 electromechanic al 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.
[color=blue][color=green]
> >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.
> >
> >[/color]
> That'd just be bad programming to use different formatting standards
> within the same program. At least within the same file.[/color]

Definitely.
[color=blue][color=green]
> >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.
> >
> >[/color]
> 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?[/color]

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.
[color=blue][color=green]
> >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.
> >
> >[/color]
> 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.
>[/color]

[Christian Tismer]

Re: Prothon Prototypes vs Python Classes

Mark Hahn wrote:
[color=blue]
> Mutability is an interesting area. I just added an unmutable bit in the
> Prothon internal object which makes the read_lock call a no-op and causes a
> write_lock call to throw an exception. This makes the object
> write-protected and makes the lock code run much faster.
>
> I did this for internal performance reasons, but after doing it I realize
> that extending it to the Ruby freeze() level would be really good. Tying
> the freezing in somehow to the bang! methods is also in interesting area of
> research.
> Mark Hahn (Prothon Author)
>
> P.S. If this belongs in the Prothon list instead of Python, let us know.[/color]

Allthough I'm a known Python-addict, I find this very interesting.
Being prototyped instead of class based was one of the features
of JavaScript, which were concidered "deficienci es". Well, I didn't
share this so much, there are many other much worse problems.

I'm eager to learn how a real language develops if it consequently
builds upon prototypes. Especially this one, since it is stackless
by nature. :-)

ciao - chris

--
Christian Tismer :^) <mailto:tismer@ 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/

[Christian Tismer]

Re: Prothon Prototypes vs Python Classes

Michael wrote:
[color=blue]
>[color=green]
>> 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.
>>
>>[/color]
> Which programs? I find spaces to cause weird issues. Especially if you
> use some half assed editor that uses variable width fonts.[/color]

I think there are enough editors available to be able
to use one with fixed font.
[color=blue][color=green]
>> 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.
>>
>>[/color]
> That'd just be bad programming to use different formatting standards
> within the same program. At least within the same file.[/color]

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.
[color=blue][color=green]
>> 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.
>>
>>[/color]
> 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?[/color]

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. :-)[color=blue]
>[color=green]
>> 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.
>>
>>[/color]
> 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.[/color]

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@ 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/

[Christian Tismer]

Re: Prothon Prototypes vs Python Classes

John Roth wrote:
....[color=blue]
> Sigh. I'm replying to my own post. After I posted this, I
> remembered that something needs to be done to set up an
> inheritance chain among instances. That requires a custom
> __getattribute_ _() magic method, which will not be all that
> easy to write.[/color]

Yeah. And I have even no clue how to get multiple
inheritance right with prototypes.
--
Christian Tismer :^) <mailto:tismer@ 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/

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue]
>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.
>
>[/color]
I have sympathy for neither. If your editor sucks then change it. If
your printing program sucks than change it. I've never bothered using
Idle as I don't like GUI-based editors so I wouldn't really be familiar
with how it behaves.
[color=blue]
>I've never seen variable width fonts to change the width
>of spaces on the left, unless it was doing something like
>full justification.
>
>[/color]
I have, but then I throw such editors out after a single glance.
[color=blue]
>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.
>
>[/color]
Do people actually post and read a lot of source code on mail or
newsgroup lists? Is that the main reason for not using tabs in code?
That'd seem a bit odd to me. Never actually tried using OE to read code.
I really don't use OE. Why wouldn't you just open the code in your code
editor of choice?
[color=blue]
>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 electromechanic al monsters
>with these little metal stops called 'tabs' in the back.
>
>[/color]
What difference does it make what the standard length of a tab is as
long as it remains the same throughout the program? As long as the size
is uniform it should render just fine.
[color=blue]
>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.
>
>[/color]
Again, as long as it's uniform does it matter? It won't change the logic
of the code as long as it opens a tab as a tab and saves a tab as a tab.
If you can't trust your editor to do something that basic then trash it.
[color=blue]
>Reading the source for Idle is quite
>enlightening : there is a comment about Tk doing something
>rather absurd if you change the tab default.
>
>[/color]
I've glanced at it but never really read it. Why would Tk care what the
tab default of your editor is? In the source it's still a single tab
character.
[color=blue]
>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.
>
>[/color]
No, a good editor will do nothing you don't tell it to do. A good editor
will insert a tab when you insert a tab and delete a tab when you delete
a tab. Why should it use spaces to simulate a tab when you can just use
a tab? That sounds like needless complexity.
[color=blue]
>The same comment applies to variable width fonts. A good
>programming editor will not use them.
>
>[/color]
Agreed. I wouldn't use one that did use them.

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue]
> I think there are enough editors available to be able
> to use one with fixed font.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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. :-)[/color]

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.
[color=blue]
> 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...[/color]

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.