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

[Christian Tismer]

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/

[Christian Tismer]

Michael wrote:

The basic difficulty with tabs is that there are a huge
number of programs "in the wild" that treat tabs
differently. Unless you're completely in control of all
the programs that will ever be used to edit and display
your program, using tabs will cause formatting errors
somewhere, to someone under some circumstance
that you never thought of.

Which programs? I find spaces to cause weird issues. Especially if you
use some half assed editor that uses variable width fonts.

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

The problems with mixed tabs and spaces are even
worse: you can lose indentation and totally mess up
the program so it won't even compile if you use the
wrong tools on such a program.

That'd just be bad programming to use different formatting standards
within the same program. At least within the same file.

You gave the best example by yourself: Use different editors,
even with fixed fonts, and you will wonder how they try
to "optimize" your tabs. Some try to help you with the indentation,
but they use tabs, even if you are not aware of it.
I don't say it is a hard problem. But it is an extra complication
which consumes a reasonable amount of Python code to check/repair,
like tabnanny.

This is the basic reason why the current standard for
library modules is 4 space indentation; it's the only
thing that is, for all practical purposes, guaranteed to
work for everyone, with any editor, formatter,
renderer and printer out there.

I don't see how it is any better than a standard of always using a
single tab or space for indention. I hate code that requires me to press
multiple space or delete keys to change the block level of a line of
code. I'm a coder and therefore am lazy. Why press four keys when I
could press one?

Becuase there are editors which default to tab==4 spaces
and some with tab==8 spaces. I have this problem still all
over the place in the C code of the Python implementation.
I like tab==4 spaces quite much, and it is the default for
Visual Studio. But sources which are edited in Linux most of
the time, seem to default to tab==8 spaces.
It is very convenient, I agree. But I would like to teach
my editor to convert to tabs for editing only, and then
change them back to spaces on saving. :-)

Python is not Perl. Python's philosophy has never
been to provide several different ways of doing things
just to provide different ways. There needs to be a
demonstrated benefit to the different ways, and tabs
don't make that cut. If you want the space savings,
ziping the file will do much better.

I'm not a fan of multiple ways but I think it's different to remove a
feature than to add a feature. Breaking existing code for pointless
reasons is bad. I'd rather they keep tab support than spaces but since
both have a historical support I'd be wary of removing either. Again
zipping files is adding additional steps which IMO is bad from a lazy
coder point of view. The lazy coder standard of coding keeps code
simple. Smaller isn't a significant problem in most cases.

Well, I don't think it is about removing a feature, but
about removing a problem. Which basically cannot be completely
solved, as long as tabs and different editors exist...

ciao - chris

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

[Christian Tismer]

John Roth wrote:
....

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.

Yeah. And I have even no clue how to get multiple
inheritance right with prototypes.
--
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/

[Michael]

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 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.
I've never seen variable width fonts to change the width
of spaces on the left, unless it was doing something like
full justification.

I have, but then I throw such editors out after a single glance.
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.

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

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.
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.
Reading the source for Idle is quite
enlightening : there is a comment about Tk doing something
rather absurd if you change the tab default.

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

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.
The same comment applies to variable width fonts. A good
programming editor will not use them.

Agreed. I wouldn't use one that did use them.

[Michael]

I think there are enough editors available to be able
to use one with fixed font.
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.
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.
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.
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. :-)
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.
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...

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.

[Christian Tismer]

Michael wrote:

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

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.

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.

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.

If you are on anyone's machine, maybe some Linux server, and
you don't find time to install an editor, then you use vim
for instance, and it depends on its configuration how it
handles Python code. Some indent for you the wrong way.
You have no choice if you are fixing something in a hurry.

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

I make my living by using several editors on several machines,
all the time. 95 % is ok, but it often comes to situations where
I have to hack "that code on this machine right now", and the user
won't give me the rights or the time to fine-tune my editor
environment.
There is also no choice of "hands-off". The customer wants me
to handle such minor problems as "the expert".
This is no matter of choice but daily practice :-)
--
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/

[Michael]

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 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.
I've never seen variable width fonts to change the width
of spaces on the left, unless it was doing something like
full justification.

I have, but then I throw such editors out after a single glance.
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.

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

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.
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.
Reading the source for Idle is quite
enlightening : there is a comment about Tk doing something
rather absurd if you change the tab default.

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

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.
The same comment applies to variable width fonts. A good
programming editor will not use them.

Agreed. I wouldn't use one that did use them.

[Jeff Epler]

On Sun, Mar 28, 2004 at 04:40:03PM +0000, Joe Mason wrote:

In article <ma************ *************** **********@pyth on.org>, Jeff Epler wrote:

def __call__(
__metaclass__ = PrototypeMeta

class Thing:
You're missing most of call() there.

whoops .. that was from the moment when I thought "I'd better do
something about calling a prototype" .. just remove it.

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__

Jeff

[Christian Tismer]

Michael wrote:
....

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?

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.

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

[Michael]

If you are on anyone's machine, maybe some Linux server, and
you don't find time to install an editor, then you use vim
for instance, and it depends on its configuration how it
handles Python code. Some indent for you the wrong way.
You have no choice if you are fixing something in a hurry.
I make my living by using several editors on several machines,
all the time. 95 % is ok, but it often comes to situations where
I have to hack "that code on this machine right now", and the user
won't give me the rights or the time to fine-tune my editor
environment.
There is also no choice of "hands-off". The customer wants me
to handle such minor problems as "the expert".
This is no matter of choice but daily practice :-)

I understand. It just seems a bad idea to try to make the language work
with the editors instead of fixing the editors to work with the
language. If you're using spaces to act like tabs instead of tabs just
because some editors munge tabs.