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.numInstan ces += 1
def printNumInstanc es():
print "Number of Instances:", Multi.numInstan ces
printNumInstanc es = staticmethod(pr intNumInstances )
def cmeth(cls, x):
print cls, x
cmeth = classmethod(cme th)

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

Multi.printNumI nstances()
a.printNumInsta nces()

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

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

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

Multi.printNumI nstances()
a.printNumInsta nces()

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

[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.m issouri.edu> wrote in message
news:40******** ******@mlug.mis souri.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.notch arles.ca>,
Joe Mason <jo*@notcharles .ca> wrote:

In article <ma************ *************** **********@pyth on.org>, 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********@jhr othjr.com> wrote in message
news:10******** *****@news.supe rnews.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.e du> wrote in message
news:ma******** *************** **************@ python.org...

"John Roth" <ne********@jhr othjr.com> wrote in message
news:10******** *****@news.supe rnews.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****@stackle ss.com>
To: "Mark Hahn" <ma**@prothon.o rg>
Cc: <py*********@py thon.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 "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: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.c c.tut.fi...

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

[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