Prothon Prototypes vs Python Classes

[David MacQuigg]

Playing with Prothon today, I am fascinated by the idea of eliminating
classes in Python. I'm trying to figure out what fundamental benefit
there is to having classes. Is all this complexity unecessary?

Here is an example of a Python class with all three types of methods
(instance, static, and class methods).

# Example from Ch.23, p.381-2 of Learning Python, 2nd ed.

class Multi:
numInstances = 0
def __init__(self):
Multi.numInstances += 1
def printNumInstances():
print "Number of Instances:", Multi.numInstances
printNumInstances = staticmethod(printNumInstances)
def cmeth(cls, x):
print cls, x
cmeth = classmethod(cmeth)

a = Multi(); b = Multi(); c = Multi()

Multi.printNumInstances()
a.printNumInstances()

Multi.cmeth(5)
b.cmeth(6)
Here is the translation to Prothon.

Multi = Object()
with Multi:
.numInstances = 0
def .__init__(): # instance method
Multi.numInstances += 1
def .printNumInstances(): # static method
print "Number of Instances:", Multi.numInstances
def .cmeth(x): # class method
print Multi, x

a = Multi(); b = Multi(); c = Multi()

Multi.printNumInstances()
a.printNumInstances()

Multi.cmeth(5)
b.cmeth(6)
Note the elimination of 'self' in these methods. This is not just a
syntactic shortcut (substiting '.' for 'self') By eliminating this
explicit passing of the self object, Prothon makes all method forms
the same and eliminates a lot of complexity. It's beginning to look
like the complexity of Python classes is unecessary.

My question for the Python experts is -- What user benefit are we
missing if we eliminate classes?

-- Dave

[Joe Mason]

In article <ma*************************************@python.or g>, Jeff Epler wrote:

BTW, I've got three pure-python solutions now (four when this one's
fixed) but it turns out they all suffer from a flaw:

>>> class TestProto: l = []

...

>>> class Test2(TestProto): pass

...

>>> TestProto.l

[]

>>> Test2.l

[]

>>> Test2.l.append(0)
>>> Test2.l

[0]

>>> TestProto.l

[0]

We really need copy-on-write lists and dicts - and large objects in
general - for this to work.

Can't you just follow the Python rule for classes with a little
difference?
* if you want some data to be shared by reference among the Prototype
and all its children, declare it at 'prototype' ('class') scope
* if you don't, create it in __init__

Possibly. You need something, at least - full copy-on-write seems like
the most transparent, but also the most work to set up. (I'm still
reading up on Self and others to find out how they handle these things.)

Hmm, your method sounds like it would work. In fact, I guess it would
already do that as written, wouldn't it?

The use case I was thinking of was something like this (I'm going to use
"object" instead of "class" from now on for pseudocode):

object UrlDispatcher:

def __init__(self):
self.handlers = { "http:" : HttpHandler, "ftp:" : FtpHandler }

object SSLUrlDispatcher(UrlDispatcher):

def __init__(self):
UrlDispatcher.__init__(self)
self.handlers["https:"] = SSLHttpHandler

So each instance of URLDispatcher and descendants has its own, entirely
unshared copy of handlers. One drawback of this is that if you add a
handler to UrlDispatcher at runtime, it isn't inherited by clones that
have already been initialized.

The other approach I suggested - replacing lists and dicts in
prototype-baed objects with a customized version - could make this more
transparent. Say, look up the value in SSLUrlDispatcher.handlers, then
UrlDispatcher.handlers only if not found, and only then throw an error
if the key still isn't found. The question is whether it's useful to
put this complexity in the prototype system, or just provide classes
that do this in a library (which can just be done by third parties as
needed) and give coders the option of saying "handlers = ProtoDict()"
instead of "handlers = {}".

Joe

[John Roth]

"Michael" <mo*****@mlug.missouri.edu> wrote in message
news:40**************@mlug.missouri.edu...

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.

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

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.

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.

It matters. 8 columns is much too wide for indents in readable code.
People do differ on that, but that seems to be the concensus.

John Roth

[Michael]

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.
It matters. 8 columns is much too wide for indents in readable code.
People do differ on that, but that seems to be the concensus.

So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.

[Michael]

No, I think you don't get at the real problem:
People do use tabs which are 8 spaces, but they
want their code to be indented by steps of four.
This creates mixed tabbing, and that's what you
see way too often when reading foreign code.
You have to adjust your editor to *that* tabbing,
before editing the file, and then convert or
live with it.

How would this create mixed tabbing unless sometimes they are using
spaces as tabs and sometimes using tabs as tabs? Will stopping the use
of tabs improve the situation or will that just mean that some people
use four spaces for indention and some people use eight.. both being a
hack to try to make spaces act like tabs. Why does it matter if a tab is
4 spaces long or 8 spaces long? Either way blocks should line up
assuming that nobody incorrectly tries to use spaces as tabs. If we get
rid of support for using tabs for indenting then what? Some people (like
myself) will continue using programs that insert tabs when they press
the tab key and everyone else will still be adjusting their editors to
try to substitute the desired number of spaces when the tab key is
pressed. What would be fixed?

It took a long time to convince me that Python wasn't insane for making
whitespace significant. If people really have so much trouble with it (I
don't) maybe it is a bad idea to use it to indicate code blocks?

[Christian Tismer]

Michael wrote:

No, I think you don't get at the real problem:
People do use tabs which are 8 spaces, but they
want their code to be indented by steps of four.
This creates mixed tabbing, and that's what you
see way too often when reading foreign code.
You have to adjust your editor to *that* tabbing,
before editing the file, and then convert or
live with it.

How would this create mixed tabbing unless sometimes they are using
spaces as tabs and sometimes using tabs as tabs? Will stopping the use
of tabs improve the situation or will that just mean that some people
use four spaces for indention and some people use eight..

....

Once again:
They use tabs but they want to do 4 space indentation.
That means they use a tab when it fits, and 4 spaces when not...

def mixed_tabs():
.....if blah: # this is 4 spaces
--------pass # this is one tab

--
Christian Tismer :^) <mailto:ti****@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 [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[rzed]

Michael <mo*****@mlug.missouri.edu> wrote in
news:40**************@mlug.missouri.edu:

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab
stop", which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

No, I just fail to see why it matters. A tab could be 4 columns,
8 columns, 15 columns, or whatever on a particular editor and
code blocks will still line up.

It matters. 8 columns is much too wide for indents in readable
code. People do differ on that, but that seems to be the
concensus.

So rather than switch editors or change your editors settings
you'd rather everyone be forced to use spaces? I presume four
spaces? If someone uses eight spaces to indent will that also
break the code? It seems to me that it'd be easier to configure
an editor to show tabs as four columns, if you so desire, than
to configure an editor to show eight spaces as four columns.
Eight spaces is no easier to read than a tab that takes eight
columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent
rather than tabs, then I'll most likely use a single space to
indent because I don't want to deal with pressing the space and
backspace keys multiple times (trying to keep count) to make
blocks line up correctly. I also don't find it acceptable to use
an editor which kludges together such space using behavior for
me to do what tabs would have done in the first place. Overall,
I think I find code that uses a single tab, rather than a single
space, to be easier to read.

As long as you are the only one to work on your code, your
viewpoint may not cause you any problems. I and others are telling
you that tabs can cause problems with some software, and you can
rightly avoid using that software as long as you don't share your
code. Once that happens, though, things get more complicated.

One aspect of the tab/spaces issue involves working on other
people's code. You like tabs, I like spaces. Supposing that I
prefer to show a single level of indention as five spaces (for some
reason), what happens when I have to make a change to your code? If
I am aware that you use tabs, then I can adjust to it, but how do I
become aware? To me, it looks like you're putting five spaces in
for each level of indention. The chances are that I won't know
otherwise until I've made some changes, saved the file and tried to
run it. If some of those changes involve changing an indention
level, I may insert spaces before or after your tabs, so now such a
change leaves a line with mixed tabs and spaces, but no visible
indication of which is where. Now when someone else grabs the code
and displays it with tabs set to four spaces instead, what happens?
No sympathy there, either, I would bet, but you do see how things
like that can happen even using only your tools, don't you?

--
rzed

[Michael]

As long as you are the only one to work on your code, your
viewpoint may not cause you any problems. I and others are telling
you that tabs can cause problems with some software, and you can
rightly avoid using that software as long as you don't share your
code. Once that happens, though, things get more complicated.

That's what you're saying but what I'm hearing is that using tabs +
spaces causes problems with some (crappy) software. If I start using an
editor that only allows uppercase letters is Python going to disallow
lowercase letters to solve a problem with my editor? I'd hope not.
Likewise it makes no sense to remove tab indenting because some software
has a problem with the difference between tabs and spaces.
One aspect of the tab/spaces issue involves working on other
people's code. You like tabs, I like spaces. Supposing that I
prefer to show a single level of indention as five spaces (for some
reason), what happens when I have to make a change to your code? If
I am aware that you use tabs, then I can adjust to it, but how do I
become aware? To me, it looks like you're putting five spaces in
for each level of indention. The chances are that I won't know
otherwise until I've made some changes, saved the file and tried to
run it. If some of those changes involve changing an indention
level, I may insert spaces before or after your tabs, so now such a
change leaves a line with mixed tabs and spaces, but no visible
indication of which is where. Now when someone else grabs the code
and displays it with tabs set to four spaces instead, what happens?
No sympathy there, either, I would bet, but you do see how things
like that can happen even using only your tools, don't you?

Couldn't you just look at the code and see that it's using tabs or
spaces as long as it's uniform? How hard is it to tell the difference?
Or is it that your editor makes spaces look like tabs so that it's
difficult to tell? I can see how it could be a problem. I just can't see
how making tabs not work will fix the problem. If anything I'd make it
so one whitespace character counts as one level of indention..
regardless to if your editor shows you the fact. Using multiple spaces
or tabs or a combination thereof which don't add up correctly to the
required indention level should just throw an error. That's closer to
what happens currently and it makes more sense to me than limiting
indenting to using only spaces. I think the problem will exist as long
as whitespace is significant but I happen to have grown fond of Python's
use of whitespace.

[PF]

I use tabs only. Can't stand spaces. I don't want to hit backspace 4
times to indent back after the end of a block.
When I open python files which use spaces, and I insert a code line into
them, my editor will insert tabs. And here is a bug. Then I set it to use
spaces. Then I open another files, which contains tabs. Argh. I'd like my
editor to test automatically if a file has spaces or tabs. Anyone knows a
good editor on linux which does this ? And also has good macros ?

--
Utilisant M2, le client e-mail révolutionnaire d'Opera :
http://www.opera.com/

[Michael]

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.
It matters. 8 columns is much too wide for indents in readable code.
People do differ on that, but that seems to be the concensus.

So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.

[Michael]

Once again:
They use tabs but they want to do 4 space indentation.
That means they use a tab when it fits, and 4 spaces when not...

def mixed_tabs():
....if blah: # this is 4 spaces
--------pass # this is one tab

Ahh, I think I follow you. I think that'd be the mark of a bad coder.
Whichever method of indenting a program uses should be carried out in a
uniform manner. Either all spaces or all tabs. I just use one tab per
level of indention. One space per level of indention would also be
acceptable to me (but hard to read). Four spaces to me would be
confussing (because of the need to count) and annoying (because of the
need to press space four times per level of indention per line). Mixed
would be right out.

[Michael]

As long as you are the only one to work on your code, your
viewpoint may not cause you any problems. I and others are telling
you that tabs can cause problems with some software, and you can
rightly avoid using that software as long as you don't share your
code. Once that happens, though, things get more complicated.

That's what you're saying but what I'm hearing is that using tabs +
spaces causes problems with some (crappy) software. If I start using an
editor that only allows uppercase letters is Python going to disallow
lowercase letters to solve a problem with my editor? I'd hope not.
Likewise it makes no sense to remove tab indenting because some software
has a problem with the difference between tabs and spaces.
One aspect of the tab/spaces issue involves working on other
people's code. You like tabs, I like spaces. Supposing that I
prefer to show a single level of indention as five spaces (for some
reason), what happens when I have to make a change to your code? If
I am aware that you use tabs, then I can adjust to it, but how do I
become aware? To me, it looks like you're putting five spaces in
for each level of indention. The chances are that I won't know
otherwise until I've made some changes, saved the file and tried to
run it. If some of those changes involve changing an indention
level, I may insert spaces before or after your tabs, so now such a
change leaves a line with mixed tabs and spaces, but no visible
indication of which is where. Now when someone else grabs the code
and displays it with tabs set to four spaces instead, what happens?
No sympathy there, either, I would bet, but you do see how things
like that can happen even using only your tools, don't you?

Couldn't you just look at the code and see that it's using tabs or
spaces as long as it's uniform? How hard is it to tell the difference?
Or is it that your editor makes spaces look like tabs so that it's
difficult to tell? I can see how it could be a problem. I just can't see
how making tabs not work will fix the problem. If anything I'd make it
so one whitespace character counts as one level of indention..
regardless to if your editor shows you the fact. Using multiple spaces
or tabs or a combination thereof which don't add up correctly to the
required indention level should just throw an error. That's closer to
what happens currently and it makes more sense to me than limiting
indenting to using only spaces. I think the problem will exist as long
as whitespace is significant but I happen to have grown fond of Python's
use of whitespace.

[John Roth]

"Michael" <mo*****@mlug.missouri.edu> wrote in message
news:40**************@mlug.missouri.edu...

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.

It matters. 8 columns is much too wide for indents in readable code.
People do differ on that, but that seems to be the concensus.

So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the

problem.
By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.

You're contradicting yourself. In a prior post, you said that if you
had a crappy editor, then change it. Now you're saying that you
think you would have to press the space bar or the backspace key
multiple times, and you're not going to give up that crappy editor
for one that works properly.

Get real.

John Roth

[Glenn Andreas]

In article <sl****************@gate.notcharles.ca>,
Joe Mason <jo*@notcharles.ca> wrote:

In article <ma*************************************@python.or g>, Jeff Epler
wrote:

BTW, I've got three pure-python solutions now (four when this one's
fixed) but it turns out they all suffer from a flaw:

>>> class TestProto: l = []
...
>>> class Test2(TestProto): pass
...
>>> TestProto.l
[]
>>> Test2.l
[]
>>> Test2.l.append(0)
>>> Test2.l
[0]
>>> TestProto.l
[0]

We really need copy-on-write lists and dicts - and large objects in
general - for this to work.

Can't you just follow the Python rule for classes with a little
difference?
* if you want some data to be shared by reference among the Prototype
and all its children, declare it at 'prototype' ('class') scope
* if you don't, create it in __init__

Possibly. You need something, at least - full copy-on-write seems like
the most transparent, but also the most work to set up. (I'm still
reading up on Self and others to find out how they handle these things.)

copy-on-write wouldn't handle the above issue though, since you aren't
writing Test2.l, you are sending a message to Test2.l (which may, or may
not, mutate Test2.l). You could provide some formalization of "mutable"
vs "immutable" and make copy-on-mutate, but even that is subtle - at
what point does something count as being "mutated"? If you've got an
immutable array of object and you call a mutating method of one of those
objects, does the original mutate (and invoke copy-on-mutate)?

Or even simpler, even if you can catch:

Test2.l.append(0)

to be copy-on-mutate, what about:

x = Test2.l
x.append(0)

Since that would be identical to:

x = TestProto.l
x.append(0)

how would you tell the difference?
Self basically provides two different methods for getting & setting
instance variables, both of which can be replaced independantly. The
"setter" part is more interest for this since "foo.bar = 5" is just
synatic sugar for "foo x: 5" (which by default will simply set the "x"
slot equal to the value, so when you then execute "foo x" you get that
new value).

It does take a while to wrap your brain around the subtle edge cases
here, especially when combined with multiple inheritance (since the
setter and getter might both come from a different parent then), but
"Organizing Programs Without Classes" [Ungar, Chambers, Chang, Holzle]
is well worth reading, re-reading, and digging out an reading again
every couple of years.

[Terry Reedy]

"John Roth" <ne********@jhrothjr.com> wrote in message
news:10*************@news.supernews.com...

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.

Actually, the mechanical typewrite standard (in US, 1960s) was every 5
spaces == 1/2 inch (10 chars per inch, fixed). That was also the standard
paragraph indent. WordPerferct, for one program, stuck with 1/2 inch even
as it accommodated different fixed and variable pitched fonts. I remember
thinking 8 spaces a bit weird when I first used Unix (early 80s).
Power-of-2 4 and 8 are computerisms. Don't remember about Teletypes, nor
about typewriters in non-inch countries.

Terry J. Reedy

[John Roth]

"Terry Reedy" <tj*****@udel.edu> wrote in message
news:ma*************************************@pytho n.org...

"John Roth" <ne********@jhrothjr.com> wrote in message
news:10*************@news.supernews.com...

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.
Actually, the mechanical typewrite standard (in US, 1960s) was every 5
spaces == 1/2 inch (10 chars per inch, fixed). That was also the standard
paragraph indent. WordPerferct, for one program, stuck with 1/2 inch even
as it accommodated different fixed and variable pitched fonts. I remember
thinking 8 spaces a bit weird when I first used Unix (early 80s).

You're right about that, although that was only for the 1st tab. After
that, it was whereever you needed them for columns.
Power-of-2 4 and 8 are computerisms. Don't remember about Teletypes, nor
about typewriters in non-inch countries.
I don't think it was a power of two thing. I very vaguely remember
some papers on the "ideal" tab spacing for inserting tabs in TTY
data streams. They were there to shrink runs of spaces to
something the mechanical teletypes could move over faster.
Some of the computations to insert a tab and then a specific
number of nulls to compensate for the exact mechanics at the
other end got quite intricate.

John Roth
Terry J. Reedy

[Mark Hahn]

I would greatly appreciate it if you could take a peek at my stackless
implementation and give me a grade :)

I don't know if you remember me, but I pissed you off in a rude posting I
made in a reply to you months ago (I apologize once again). I was trying to
pickle a complicated graph of objects and getting recursions limit errors in
Python. You were very helpfully telling me how to get around the problem in
a long message and I replied curtly and rudely that Python was broken and
I'd rather write something from scratch than try to use broken tools (it was
a bad day).

To make a long story short, that was the straw that broke the camel's back
and caused me to start work on Prothon. I had been daydreaming about an
extrememly simple but powerful language with just a pile of lockable objects
for some time. The fact that is uses Python syntax is secondary and only
because I like the syntax. My real love is the internal object structure,
threading, and interpreter.

----- Original Message -----
From: "Christian Tismer" <ti****@stackless.com>
To: "Mark Hahn" <ma**@prothon.org>
Cc: <py*********@python.org>
Sent: Monday, March 29, 2004 4:55 AM
Subject: Re: Prothon Prototypes vs Python Classes

Mark Hahn wrote:

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.

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 "deficiencies". 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:ti****@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 [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Mark Hahn]

> I would guesstimate that the tab indentation mostly serves to

kill the interest of many who would otherwise take a deeper
look.

Prothon has announced that we are caving in and going to spaces instead of
tabs, even though both of the Prothon authors abhor spaces.

"Ville Vainio" <vi***@spammers.com> wrote in message
news:du*************@lehtori.cc.tut.fi...

>> "Mark" == Mark Hahn <ma**@prothon.org> 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

[Michael]

You're contradicting yourself. In a prior post, you said that if you
had a crappy editor, then change it. Now you're saying that you
think you would have to press the space bar or the backspace key
multiple times, and you're not going to give up that crappy editor
for one that works properly.

An editor is crappy if it inserts anything other than what you type into
the code. If I press tab and four spaces are inserted that is crap. If I
press 'A' and 'a' is inserted that is crap. To me, it sounds as if this
entire issue is caused by crappy editors that think they know better
than the programmers. If you want a smart alec paper clip telling you
what to do when you're editing code then feel free to do so but I just
want raw access to my code.

[Michael]

You're contradicting yourself. In a prior post, you said that if you
had a crappy editor, then change it. Now you're saying that you
think you would have to press the space bar or the backspace key
multiple times, and you're not going to give up that crappy editor
for one that works properly.

An editor is crappy if it inserts anything other than what you type into
the code. If I press tab and four spaces are inserted that is crap. If I
press 'A' and 'a' is inserted that is crap. To me, it sounds as if this
entire issue is caused by crappy editors that think they know better
than the programmers. If you want a smart alec paper clip telling you
what to do when you're editing code then feel free to do so but I just
want raw access to my code.

[Greg Ewing (using news.cis.dfn.de)]

Mark Hahn wrote:

Prothon has announced that we are caving in and going to spaces instead of
tabs, even though both of the Prothon authors abhor spaces.

You don't have to choose between them if you don't
want to. Disallowing *mixed* tabs and spaces is sensible,
but you could allow either all-tabs or all-spaces in a
given file.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Aahz]

In article <AHF9c.49048$cx5.33872@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

I didn't know I was going the opposite direction from Python. I guess I'll
have to change that.

I guess I didn't make it clear that no design decisions were frozen in the
language.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Charles Hixson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael wrote:

| 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?
|
|> I'll just mention that there are ***very good***, that is
|> ***extremely good*** reasons why the Python standard is to use
|> spaces for indentation, and why the option of using tabs will be
|> removed in 3.0.
|>
They can't possibly be good enough (for my needs). That said, where
can I check this. I don't want to make important decisions on
incomplete information.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAaO9xE1guSVL8NK8RAuZCAJ9k2jZSLxwG6Ql3rHqV8u 5APcuPJgCghjjo
AW0ROHktFKNbSKSWYn1q9BM=
=AR/9
-----END PGP SIGNATURE-----

[Mark Hahn]

A2. People that bitch about top-posting.

"Aahz" <aa**@pythoncraft.com> wrote in message
news:c4**********@panix2.panix.com...

In article <AHF9c.49048$cx5.33872@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

I didn't know I was going the opposite direction from Python. I guess I'llhave to change that.

I guess I didn't make it clear that no design decisions were frozen in thelanguage.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
--
Aahz (aa**@pythoncraft.com) <*>

http://www.pythoncraft.com/
"usenet imitates usenet" --Darkhawk

[Mark Hahn]

> but you could allow either all-tabs or all-spaces in a given file.

Maybe that the is most sensible solution I've heard yet.
"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:40**************@sneakemail.com...

Mark Hahn wrote:

> Prothon has announced that we are caving in and going to spaces instead of > tabs, even though both of the Prothon authors abhor spaces.

You don't have to choose between them if you don't
want to. Disallowing *mixed* tabs and spaces is sensible,
but you could allow either all-tabs or all-spaces in a
given file.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Michael]

but you could allow either all-tabs or all-spaces in a given file.

Maybe that the is most sensible solution I've heard yet.

That'd seem agreeable to me. Especially if how strict the rule was could
be set at run time as a Python argument. So you could either have mixed
spaces and tabs refuse to run, give an error, or be ignored and run (if
possible) as we might currently expect.

[Michael]

but you could allow either all-tabs or all-spaces in a given file.

Maybe that the is most sensible solution I've heard yet.

That'd seem agreeable to me. Especially if how strict the rule was could
be set at run time as a Python argument. So you could either have mixed
spaces and tabs refuse to run, give an error, or be ignored and run (if
possible) as we might currently expect.

[John Roth]

"Mark Hahn" <ma**@prothon.org> wrote in message
news:9C8ac.68303$cx5.4075@fed1read04...

but you could allow either all-tabs or all-spaces in a given file.
Maybe that the is most sensible solution I've heard yet.

That mostly works. In fact, the original suggestion to use
tabs followed by spaces *only* for alignining continuations
also works: the most toxic case is the one where someone
has their indentation set to 4, and the editor blithely compresses
runs of 8 spaces to one tab. Then it goes to someone
else whose editor is set up for four character tabs, and
the indentation gets messed up.

John Roth

PS - I may have gotten several private e-mails at the address
on these postings. Please don't - the address that's availible
on Usenet is virus checked, spam checked and then deleted
without being read.

JR.



"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:40**************@sneakemail.com...

Mark Hahn wrote:

> Prothon has announced that we are caving in and going to spaces

instead

of > tabs, even though both of the Prothon authors abhor spaces.

You don't have to choose between them if you don't
want to. Disallowing *mixed* tabs and spaces is sensible,
but you could allow either all-tabs or all-spaces in a
given file.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Gerrit]

John Roth wrote:

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.

<pre>
T h e r e i s a s o l u t i o n ; - )
</pre>

Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:55 UTC:
15.0°C wind 5.8 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Gerrit]

Mark Hahn wrote:

A2. People that bitch about top-posting.

Mark - I really find it a bit difficult to read your postings. I keep
scrolling to below to see whether there is still more to come - because you
do sometimes quote others and then answer below. When I see quoting in a
message, I automatically assume there's more to come, and I am not the
only one. I think it is the wrong answer to say that people shouldn't
bitch about top-posting - it _does_ annoy people (including me and Aahz).
There are conventions on usenet (and mailing lists), and they are there
with reason. I would like to kindly ask you to try to do more
'bottom-posting'. It makes your postings easier and prettier to read.

Really, it does - please try it...

yours,
Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:55 UTC:
15.0°C wind 5.8 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Terry Reedy]

The irony of this idiocy is that is shows precisely why top-posting is bad.

"Mark Hahn" <ma**@prothon.org> wrote in message
news:Sz8ac.68272$cx5.62681@fed1read04...

A2. People that bitch about top-posting.

"Aahz" <aa**@pythoncraft.com> wrote in message
news:c4**********@panix2.panix.com...

In article <AHF9c.49048$cx5.33872@fed1read04>,
Mark Hahn <ma**@prothon.org> wrote:

I didn't know I was going the opposite direction from Python. I guess I'llhave to change that.

I guess I didn't make it clear that no design decisions were frozen in thelanguage.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
--
Aahz (aa**@pythoncraft.com) <*>

http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

--
http://mail.python.org/mailman/listinfo/python-list

[John Roth]

"Gerrit" <ge****@nl.linux.org> wrote in message
news:ma**************************************@pyth on.org...
John Roth wrote:

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.

<pre>
T h e r e i s a s o l u t i o n ; - )
</pre>

1. This only works if you are using html, which is
strongly discouraged (but still depressingly prevalent)

2. The OE problem is on the recipient's side, not
on the sender's side.

John Roth

Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:55 UTC:
15.0°C wind 5.8 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Peter Hickman]

Gerrit wrote:

only one. I think it is the wrong answer to say that people shouldn't
bitch about top-posting - it _does_ annoy people (including me and Aahz).
Will you please reign in you ego and qualify your statement 'it annoys
*SOME* people'. I find all the bitching about top posting to be a
greater distraction than top posting itself!
There are conventions on usenet (and mailing lists), and they are there
with reason. I would like to kindly ask you to try to do more
'bottom-posting'. It makes your postings easier and prettier to read.
I find bottom posting to be a real pain as when I look at a new message
it defaults to showing me the top of the message and I then have to
scroll through pages of quoted posts that I have already read just to
read one or two lines stuck at the bottom.
Really, it does - please try it...

It also doesn't, so once you have worked out how to keep both parties
happy, perhaps 'middle posting' would be a working compromise, you can
get on to curing cancer and bringing peace to the middle east.

I have never left a group because of the trolls.
I have never left a group because of the noobies.
I have left a group because of the constant whining about top posting.

People who whine on about 'top posting' are the sort of people who draft
'clean desk' policies. If you want to whine about top posting then start
alt.whine.top.posting and have fun.

[David M. Cooke]

At some point, Michael <mo*****@mlug.missouri.edu> wrote:

You're contradicting yourself. In a prior post, you said that if you
had a crappy editor, then change it. Now you're saying that you
think you would have to press the space bar or the backspace key
multiple times, and you're not going to give up that crappy editor
for one that works properly.

An editor is crappy if it inserts anything other than what you type
into the code. If I press tab and four spaces are inserted that is
crap. If I press 'A' and 'a' is inserted that is crap. To me, it
sounds as if this entire issue is caused by crappy editors that think
they know better than the programmers. If you want a smart alec paper
clip telling you what to do when you're editing code then feel free to
do so but I just want raw access to my code.

Does your backspace key insert a backspace character (^H), also?

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

[Michael]

A2. People that bitch about top-posting.

Mark - I really find it a bit difficult to read your postings. I keep
scrolling to below to see whether there is still more to come - because you
do sometimes quote others and then answer below. When I see quoting in a
message, I automatically assume there's more to come, and I am not the
only one. I think it is the wrong answer to say that people shouldn't
bitch about top-posting - it _does_ annoy people (including me and Aahz).
There are conventions on usenet (and mailing lists), and they are there
with reason. I would like to kindly ask you to try to do more
'bottom-posting'. It makes your postings easier and prettier to read.

Really, it does - please try it...

The 'standard' I've seen worked out in about a decade of watching this
exact argument.. when responding to individual parts of someones message
then post your reply directly underneath the section you're replying to.
If you're making a short response to the entire message it's okay to top
post. Of course, either bottom or top posting, clip any text in the
previous messages you aren't directly responding to.

[Magnus Lyck?]

Michael <mo*****@mlug.missouri.edu> wrote in message news:<40**************@mlug.missouri.edu>...

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 think you need to worry. AFAIK Python 3 is the mythological
if-I-could-turn-back-the-clock-and-undo-all-my-mistakes version
of Python, which Guido probably won't have time to work with
until his son is big enough to help him. (He'll be 3 in November.)
It will have little regard for backward compatibility, and if it
does appear sooner than expected, you can expect Python 2.x to be
maintaned in parallel for a long time.

[Michael]

I don't think you need to worry. AFAIK Python 3 is the mythological
if-I-could-turn-back-the-clock-and-undo-all-my-mistakes version
of Python, which Guido probably won't have time to work with
until his son is big enough to help him. (He'll be 3 in November.)
It will have little regard for backward compatibility, and if it
does appear sooner than expected, you can expect Python 2.x to be
maintaned in parallel for a long time.

That's good. I was thinking that if they actually took out tab support
I'd have to fork the code base and keep applying a patch that added tab
support back in. Not to hard I think but not the kind of thing I like to do.

Overall I dislike features being removed, once added as
non-experimental. I think if a languages authors want to do major
changes like that which will break compatibility it's better to create a
new language. Even if the two languages are highly similar. Otherwise
you end up into weird issues like Perl where new versions take forever
and if they are released as many people are annoyed as are pleased. Call
them a family of languages if you like. So prehaps we could see the
language Monty with some of Guido's new and improved ideas.

[Michael]

I don't think you need to worry. AFAIK Python 3 is the mythological
if-I-could-turn-back-the-clock-and-undo-all-my-mistakes version
of Python, which Guido probably won't have time to work with
until his son is big enough to help him. (He'll be 3 in November.)
It will have little regard for backward compatibility, and if it
does appear sooner than expected, you can expect Python 2.x to be
maintaned in parallel for a long time.

That's good. I was thinking that if they actually took out tab support
I'd have to fork the code base and keep applying a patch that added tab
support back in. Not to hard I think but not the kind of thing I like to do.

Overall I dislike features being removed, once added as
non-experimental. I think if a languages authors want to do major
changes like that which will break compatibility it's better to create a
new language. Even if the two languages are highly similar. Otherwise
you end up into weird issues like Perl where new versions take forever
and if they are released as many people are annoyed as are pleased. Call
them a family of languages if you like. So prehaps we could see the
language Monty with some of Guido's new and improved ideas.

[David MacQuigg]

On 30 Mar 2004 12:37:25 -0800, ma****@thinkware.se (Magnus Lyck?)
wrote:

I don't think you need to worry. AFAIK Python 3 is the mythological
if-I-could-turn-back-the-clock-and-undo-all-my-mistakes version
of Python, which Guido probably won't have time to work with
until his son is big enough to help him. (He'll be 3 in November.)
It will have little regard for backward compatibility, and if it
does appear sooner than expected, you can expect Python 2.x to be
maintaned in parallel for a long time.

Maybe Prothon will *become* Python 3.0 That could happen quicker than
migrating all the Python libraries to Prothon. Open source is an
amazing phenomenon!

Nothing like a little kick-in-the-butt competition to stimulate
progress. :>)

-- Dave

[Bruno Desthuilliers]

Peter Hickman wrote:

Gerrit wrote:

only one. I think it is the wrong answer to say that people shouldn't
bitch about top-posting - it _does_ annoy people (including me and Aahz).

Will you please reign in you ego and qualify your statement 'it annoys
*SOME* people'.

Well, it seems that it annoys *most* people here. BTW, I was about to do
the same... (Mark, if you read us : your work seems pretty interesting,
so do *yourself* a favor and make your posts more readable !-).
I find all the bitching about top posting to be a
greater distraction than top posting itself!
So please stop bitching about people bitching about top-posting.

There are conventions on usenet (and mailing lists), and they are there
with reason. I would like to kindly ask you to try to do more
'bottom-posting'. It makes your postings easier and prettier to read.

I find bottom posting to be a real pain as when I look at a new message
it defaults to showing me the top of the message and I then have to
scroll through pages of quoted posts that I have already read just to
read one or two lines stuck at the bottom.

If you have to do so, then the poster didn't get point : only quote
what's needed.

(snip)

I have never left a group because of the trolls.
I have never left a group because of the noobies.
I have left a group because of the constant whining about top posting.
May I suggest you to count how many messages Mark posted here before
someone kindly suggested that he could help everyone by doing a simple
thing ? If that's what you call 'constant whining', then you are the troll.
People who whine on about 'top posting' are the sort of people who draft
'clean desk' policies. If you want to whine about top posting then start
alt.whine.top.posting and have fun.

Après vous, mon cher.

Bruno

[Bruno Desthuilliers]

Carl Banks wrote:

William Park wrote:

(snip)

This space-vs-tab war is just insane. I wish Prothon/Python would use
block terminator, if only to kill this silly trollings.

Right. Then we can have "does the brace go on the same line or the
next line" wars.

lol !

[Charles Hixson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Hixson wrote:

| Michael wrote:
|
| | 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? | |> I'll just mention that there are ***very good***,
| that is |> ***extremely good*** reasons why the Python standard is
| to use |> spaces for indentation, and why the option of using tabs
| will be |> removed in 3.0. |> They can't possibly be good enough
| (for my needs). That said, where can I check this. I don't want
| to make important decisions on incomplete information.

Well, I've just checked the cvs source build (version of 2004/03/30),
and it handles files with tab-based indentation without problem or
warning. So I suspect that it will continue to do so. (I also
checked all the PEPs and the BDFL's commentary, and a few other places.)

I think someone was just spreading FUD. (Quite effectively though, as
far as I'm concerned.)
There are good reasons to not mix tab indentation and space
indentation, and that would cause me no problems. The other though
(shudder).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAaeEnE1guSVL8NK8RAvt1AKDmXEzW7w7zFRzjXsoEdD ooUMg5iACdFtL2
RAzmwQiE4G1VffB3B8ecXW8=
=HE84
-----END PGP SIGNATURE-----

[Bruno Desthuilliers]

Hung Jung Lu wrote:
(snip)

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.
(snip)
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.
Well, last time I tried to explain OOP I started with the 'object'
concept (object = id + state + behavior), then came to the 'class'
concept, first defined as 'a class is the set of objects that share the
same behavior'. It's hard to tell because no two brains works the same,
but it seemed that the person I was trying to teach OO found this
approach quite clear...
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
Err... I would not say that polymorphism is 'secondary'. It's IMHO one
of the most important concepts in OO.

(snip)
A CS professor friend of mine once said: "all problems in CS are
solved by just one more level of indexing,"

IIRC, the exact quote is : "any problem can be solved by adding a level
of indirection - except for 'too much levels of indirection'" (now don't
ask me who said this !-)

Bruno

[Mark Hahn]

> make your posts more readable

Sorry.

I really really try to remember to quote from below. If you go through my
posts you will see that I remember most of the time. The last few days I
have been reponding to four or five mailing lists after months of only
coding and my fingers are worn out.

"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr> wrote in
message news:40**********************@news.free.fr...

Peter Hickman wrote:

Gerrit wrote:

only one. I think it is the wrong answer to say that people shouldn't
bitch about top-posting - it _does_ annoy people (including me and

Aahz).

Will you please reign in you ego and qualify your statement 'it annoys
*SOME* people'.
Well, it seems that it annoys *most* people here. BTW, I was about to do
the same... (Mark, if you read us : your work seems pretty interesting,
so do *yourself* a favor and make your posts more readable !-).

I find all the bitching about top posting to be a
greater distraction than top posting itself!

So please stop bitching about people bitching about top-posting.
There are conventions on usenet (and mailing lists), and they are there
with reason. I would like to kindly ask you to try to do more
'bottom-posting'. It makes your postings easier and prettier to read.

I find bottom posting to be a real pain as when I look at a new message
it defaults to showing me the top of the message and I then have to
scroll through pages of quoted posts that I have already read just to
read one or two lines stuck at the bottom.

If you have to do so, then the poster didn't get point : only quote
what's needed.

(snip)

I have never left a group because of the trolls.
I have never left a group because of the noobies.
I have left a group because of the constant whining about top posting.

May I suggest you to count how many messages Mark posted here before
someone kindly suggested that he could help everyone by doing a simple
thing ? If that's what you call 'constant whining', then you are the

troll.

People who whine on about 'top posting' are the sort of people who draft
'clean desk' policies. If you want to whine about top posting then start
alt.whine.top.posting and have fun.

Après vous, mon cher.

Bruno

[Michael]

Well, last time I tried to explain OOP I started with the 'object'
concept (object = id + state + behavior), then came to the 'class'
concept, first defined as 'a class is the set of objects that share
the same behavior'. It's hard to tell because no two brains works the
same, but it seemed that the person I was trying to teach OO found
this approach quite clear...

I always teach the object concept by putting objects into real world
terms. An object is a car, cup, or bowling ball. Each has properties
that help define what the object is. Color, weight, or size. Each also
has methods which are things which the object can do. Start it's engine,
be sipped from, or be rolled. Even novice programmers can pick that
concept up pretty easily. Classes take a little more work. Just
explaining that there could be different types of cars which in turn are
different types of vehicles but that certain design aspects are often
the same. I just explain a class as being a design for an object and
that when you instantate an objectit's like manufacturing something from
a design. Most people grasp the idea pretty quickly when put into such
non-abstract terms. I might explain polymorphism as something like
different brands of the same item. Your car can use generic tires that
cost $50 or stylishh tires that cost $500. As long as they follow
certain design rules they are interchangable parts but they can differ
greatly outside those rules.

Maybe it's underestimating people but I think a lot of novices don't
really understand the abstract ideas we throw at them. I see even
somewhat experienced coders still avoiding using such things as
functions and objects. Clearly not good. :)

[Skip Montanaro]

Michael> An editor is crappy if it inserts anything other than what you
Michael> type into the code. If I press tab and four spaces are
Michael> inserted that is crap.

Not if that's what I asked it to do. I have python-mode in Emacs set to use
4-space indents and only insert SPACE characters, not TAB characters.
Pressing the TAB key while the cursor is at the beginning of line inserts or
deletes enough SPACEs to put the cursor at the correct indentation for the
current line (based upon the indentation and content of the previous line).

Michael> If I press 'A' and 'a' is inserted that is crap.

not if I placed my editor in e.e. cummings mode...

Michael> To me, it sounds as if this entire issue is caused by crappy
Michael> editors that think they know better than the programmers.

It has nothing to do with the editors considered in isolation. By in large
they are doing exactly what the programmers ask them to do. The problem is
with the interchange of program files between unlike systems (via whatever
means: email, CVS checkins, grabbing from a web page, etc) which have tools
(editors in particular) which interpret TAB characters differently based
upon how the programmers have configured them. To the best of my knowledge
no systems interpret SPACE characters in weird ways, so using them to
indicate indentation is the only foolproof solution.

Skip

[Michele Simionato]

Peter Hickman <pe***@semantico.com> wrote in message news:<40**********************@news.easynet.co.uk> ...

I have never left a group because of the trolls.
I have never left a group because of the noobies.
I have left a group because of the constant whining about top posting.

Then maybe you should consider leaving c.l.py ?

Michele Simionato

[JanC]

"Mark Hahn" <ma**@prothon.org> schreef:

I really really try to remember to quote from below. If you go through my
posts you will see that I remember most of the time. The last few days I
have been reponding to four or five mailing lists after months of only
coding and my fingers are worn out.

Try OE-QuoteFix, it can help you, and it's free:
<http://home.in.tum.de/~jain/software/oe-quotefix/>

Also, I think OE allows you to select the text-to-quote _before_ replying.

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Hamilcar Barca]

In article <Sz8ac.68272$cx5.62681@fed1read04> (Mon, 29 Mar 2004 22:36:55
-0800), Mark Hahn wrote:

A2. People that bitch about top-posting.

A3. People professing to be computer literate -- some claiming to be
programming language designers and wanting to be taken seriously -- who
refuse to understand why top-posting doesn't follow the rules of written
European language.

A4. People who refuse to trim unnecessary quoted material from their
follow-ups.

--
"Posting at the top because that's where the cursor happened to
be is like shitting in your pants because that's where your
asshole happened to be."
-- Andreas Prilop (c.i.w.a.h)

[Michael]

Not if that's what I asked it to do. I have python-mode in Emacs set to use
4-space indents and only insert SPACE characters, not TAB characters.
Pressing the TAB key while the cursor is at the beginning of line inserts or
deletes enough SPACEs to put the cursor at the correct indentation for the
current line (based upon the indentation and content of the previous line).

If you tell it to do that then that's fine. But then if you can do that
then why can't you just tell the editor to handle tabs as tabs? The
whole discussion being about why tabs should be removed because some
editors are to stupid to handle them correctly, or maybe just some
programmers are to stupid to tell their editor how to handle tabs. If
you can tell the editor to not allow mixing of spaces and tabs then the
entire issue would be moot.
not if I placed my editor in e.e. cummings mode...

That'd be rather funny. It reminds me of the time I wrote a projects
documentation in Suess-like language.
It has nothing to do with the editors considered in isolation. By in large
they are doing exactly what the programmers ask them to do. The problem is
with the interchange of program files between unlike systems (via whatever
means: email, CVS checkins, grabbing from a web page, etc) which have tools
(editors in particular) which interpret TAB characters differently based
upon how the programmers have configured them. To the best of my knowledge
no systems interpret SPACE characters in weird ways, so using them to
indicate indentation is the only foolproof solution.

I have experienced the problem of cutting and pasting from some apps
where tabs are replaced as spaces. Annoying, but still an error in those
apps and not in Python. On the rare occassion that happens I just fix
the code. I would like if Python could spit out warnings where tabs and
spaces were mixed. That'd be a handy alert in cases where I might forget
to fix a line.

I can see that the mishandling of tabs by certain apps is annoying. I
just don't see how adding Python to that list will be any less annoying.

[Greg Ewing (using news.cis.dfn.de)]

Peter Hickman wrote:

I find bottom posting to be a real pain as when I look at a new message
it defaults to showing me the top of the message and I then have to
scroll through pages of quoted posts that I have already read just to
read one or two lines stuck at the bottom.

That's equally bad. The issue isn't about so-called "top-posting"
vs. "bottom-posting". The issue is that you should only be
quoting SMALL amounts of the original post -- just enough to
establish a context for what you're about to say.

Then people don't have to scroll either way to find the
new content.

(You will notice that I did not quote any more of the original
message, either at the top or the bottom.)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg