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

[John Roth]

Re: Prothon Prototypes vs Python Classes


"David MacQuigg" <dmq@gain.com > wrote in message
news:569c605ld1 cj8fc1emolk08et e0s1prls1@4ax.c om...[color=blue]
> 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.[/color]

You're mixing two different issues here. The first one I'm going
to address is namespaces. I tend to agree with you, and I've
said it before; most languages would benefit a lot by putting
different kinds of identifiers in lexically distinct namespaces, and
letting the editors take up the slack. We expect modern editors to
colorize keywords, why not let them do some of the dogwork?
[color=blue]
> My question for the Python experts is -- What user benefit are we
> missing if we eliminate classes?[/color]

Duh? Again, as far as I can tell, classes are a leftover idea from
static typing. However, you should think of a lot of the standard
OO patterns. We have, for example, classes which are never
intended to be instantiated, and classes that are, and classes that
have only one instance (singletons.) In interactive fiction (and I
suspect other application areas) having a class with more than
one instance is rare (but not unheard of.)

In more normal applications, you usually have a large number of
instances of any given class; those instances don't vary in their
behavior so it makes sense to optimize access by distinguishing
between the class and the instance. This is, in fact, what Python
does. It has syntactic support for creating instances of type "class",
complete with builtin support for methods and fancy initialization
options, and a very abbreviated syntax for the much more prevalent
operation of creating instances of type "instance."

I've seen another recent comment to the effect that eliminating
classes would remove a very valuable level of abstraction for
larger programs. The idea is superficially attractive. I'd like to see
examples of very large systems done in a prototype based language
and how they handled the problem, or if it was, indeed, a problem.

I doubt very much if I'm going to find that one extreme or the
other is "correct." It seems to differ by what you want to do
with it.

John Roth[color=blue]
>
> -- Dave
>[/color]

[Michael]

Re: Prothon Prototypes vs Python Classes

I'm not terribly familiar with the concept of prototypes although I
believe I understand the basic meaning and I have worked in languages
which do use prototypes (although not called that).

Aren't there many times when it is usefult to work with classes where
you do not want an instance to exist? Such as multiple level of
subclasses where code is kept easily readable by putting it on a the
appropiate class for that function alone. Often useful when you'll be
using many similar but not identical objects? I can see how it'd be
useful to be able to define new methods on an object, or edit the
methods on an object but I can not see the purpose to removing classes
altogether. Am I correct in my impression that with prototyping you must
instantate an object to define it's structure? That would seem wasteful
and cluttering of the namespace. Also he way your prototypes read appear
less clear to me than a class definition. I fear that you'd wind up with
people creating an object.. coding random stuff.. adding a method to
that object.. coding more random stuff.. and then adding more to the
object.

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Michael" <mogmios@mlug.m issouri.edu> wrote in message
news:406635AB.9 050803@mlug.mis souri.edu...[color=blue]
> I'm not terribly familiar with the concept of prototypes although I
> believe I understand the basic meaning and I have worked in languages
> which do use prototypes (although not called that).
>
> Aren't there many times when it is usefult to work with classes where
> you do not want an instance to exist? Such as multiple level of
> subclasses where code is kept easily readable by putting it on a the
> appropiate class for that function alone. Often useful when you'll be
> using many similar but not identical objects? I can see how it'd be
> useful to be able to define new methods on an object, or edit the
> methods on an object but I can not see the purpose to removing classes
> altogether. Am I correct in my impression that with prototyping you must
> instantate an object to define it's structure? That would seem wasteful
> and cluttering of the namespace. Also he way your prototypes read appear
> less clear to me than a class definition. I fear that you'd wind up with
> people creating an object.. coding random stuff.. adding a method to
> that object.. coding more random stuff.. and then adding more to the
> object.[/color]

It's certainly true that in a prototype based language all objects
exist: there are no objects that the compiler deals with but does
not put into the resulting program. And it's quite true that it does
open up the floodgates for a lot of messiness.

On the other hand, there are application areas where that is
exactly what you need: I've already mentioned interactive fiction,
and there are undoubtedly others.

I'd like to play around with a prototype based language to see how it
works, although for reasons I've mentioned elsewhere, I won't use
Prothon. I'd be using IO if they had a windows executable installer,
rather than requiring me to compile the silly thing.

John Roth

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

> although for reasons I've mentioned elsewhere, I won't use Prothon.

Can you please point me to those reasons?

"John Roth" <newsgroups@jhr othjr.com> wrote in message
news:106ceeeqc8 ph126@news.supe rnews.com...[color=blue]
>
> "Michael" <mogmios@mlug.m issouri.edu> wrote in message
> news:406635AB.9 050803@mlug.mis souri.edu...[color=green]
> > I'm not terribly familiar with the concept of prototypes although I
> > believe I understand the basic meaning and I have worked in languages
> > which do use prototypes (although not called that).
> >
> > Aren't there many times when it is usefult to work with classes where
> > you do not want an instance to exist? Such as multiple level of
> > subclasses where code is kept easily readable by putting it on a the
> > appropiate class for that function alone. Often useful when you'll be
> > using many similar but not identical objects? I can see how it'd be
> > useful to be able to define new methods on an object, or edit the
> > methods on an object but I can not see the purpose to removing classes
> > altogether. Am I correct in my impression that with prototyping you must
> > instantate an object to define it's structure? That would seem wasteful
> > and cluttering of the namespace. Also he way your prototypes read appear
> > less clear to me than a class definition. I fear that you'd wind up with
> > people creating an object.. coding random stuff.. adding a method to
> > that object.. coding more random stuff.. and then adding more to the
> > object.[/color]
>
> It's certainly true that in a prototype based language all objects
> exist: there are no objects that the compiler deals with but does
> not put into the resulting program. And it's quite true that it does
> open up the floodgates for a lot of messiness.
>
> On the other hand, there are application areas where that is
> exactly what you need: I've already mentioned interactive fiction,
> and there are undoubtedly others.
>
> I'd like to play around with a prototype based language to see how it
> works, although for reasons I've mentioned elsewhere, I won't use
> Prothon. I'd be using IO if they had a windows executable installer,
> rather than requiring me to compile the silly thing.
>
> John Roth
>
>[/color]

[Michael]

Re: Prothon Prototypes vs Python Classes

I'm not terribly familiar with the concept of prototypes although I
believe I understand the basic meaning and I have worked in languages
which do use prototypes (although not called that).

Aren't there many times when it is usefult to work with classes where
you do not want an instance to exist? Such as multiple level of
subclasses where code is kept easily readable by putting it on a the
appropiate class for that function alone. Often useful when you'll be
using many similar but not identical objects? I can see how it'd be
useful to be able to define new methods on an object, or edit the
methods on an object but I can not see the purpose to removing classes
altogether. Am I correct in my impression that with prototyping you must
instantate an object to define it's structure? That would seem wasteful
and cluttering of the namespace. Also he way your prototypes read appear
less clear to me than a class definition. I fear that you'd wind up with
people creating an object.. coding random stuff.. adding a method to
that object.. coding more random stuff.. and then adding more to the
object.

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <569c605ld1cj8f c1emolk08ete0s1 prls1@4ax.com>, David MacQuigg wrote:[color=blue]
> 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?[/color]

Complexity's ok if it's in the right place - down deep in the heart of
things where you only have to get it right once. If you simplify the
language, it can push the complexity out to the API level where
everybody has to deal with it. (However, see
http://www.ai.mit.edu/docs/articles/...tion3.2.1.html for a
counterargument .)

Ed Suominen just posted a situation where classes and instances need to
be treated separately. He has a class, "AutoText", with various
subclasses (which I'll call "AutoA", "AutoB", etc. because I forget the
details). He wants to notice whenever somebody creates a subclass of
AutoText and add it to a list so that he can have an AutoAll function
which creates just one instance of each. (Or something like that.)

# all examples below will use the same AutoAll()
autoall = []
def AutoAll():
"Return an instance of each 'class'"
l = []
for i in autoall:
l.append(i())
return l

In Python, the easiest way to do this is with metaclasses, which is a
really advanced topic. In Prothon, it's simple to "notice" when a
subclass is created, because __init__ gets called! So you just say:

# This is library code - complexity goes here
AutoText = Base()
with AutoText:
def .__init__():
Base.__init__()
autoall.append( self)

# Users of the library create new subclasses
AutoA = AutoText()

AutoB = AutoText()
with AutoB:
def .__init__(somep arams):
# do stuff with someparams
AutoText.__init __()

The problem with this is that it doesn't work. In AutoAll(), when you
call i() and create a new instance of AutoText, it adds it to autoall,
so now you have an infinite loop as autoall keeps growing.

So you need to build in some way to distinguish classes to add to
autoall from ones you don't. Say, a register() method:

# library code
AutoText = Base()
with AutoText:
# __init__ no longer needed
def .register():
autoall.append( self)

# user code
AutoA = AutoText()
with AutoA: .register()

AutoB = AutoText()
with AutoB:
def .__init__(somep arams):
# do stuff with someparams
AutoText.__init __()
.register()

That's not all that bad, really - if you ignore metaclasses, the only
way I can think of to do this in standard Python is the same, since you
only have a hook when an object is created, not a class:

# library code
class AutoText(Base):
def register(klass) :
autoall.append( klass)
register = classmethod(reg ister)
AutoText.regist er()

# user code
class AutoA(AutoText) : pass
AutoA.register( )

class AutoB(AutoText) :
def __init__(self, someparams):
# do stuff with someparams
AutoText.__init __(self)
AutoB.register( )

But with metaclasses, you can set a metaclass on AutoText which
automatically registers each subclass as it's created, so that the
explicit register() method can be skipped.

# library code - the most complex yet
class AutoRegister(ty pe):
def __init__(klass, name, bases, dict):
autoall.append( klass)

class AutoText(Base):
__metaclass__ = AutoRegister
def __init__(self, text):
Base.__init__(s elf, tet)

# user code - the simplist yet
class AutoA(AutoText) : pass

class AutoB(AutoText) :
def __init__(self, someparams):
AutoText.__init __(self)

So here's one point where the simplification of prototypes actually ends
up making the user code more complicated than the full Python version.
As a user of that code, you have no reason at all to care about
__metaclass__ and what it does - you just need to know that AutoAll()
magically creates an instance of AutoText and all it's subclasses.

If you ever need to actually look at the definition of AutoText, though,
you'll see this __metaclass__ thing which is a little harder to
understand. In the simpler version, the basics of the library are
easier, which means if you have to debug it you'll have an easier time,
but you have to keep calling register(). Which complexity is better is
a matter of philosophy. (In this particular case, I think they're both
pretty good tradeoffs.)

This is obviously pretty specific to Python - most prototype based OO
languages don't have the option of metaclasses. But someone else said
that prototype-based languages "tend to grow features that mimic
class-based ones", or soemthing like that. I think this is a good
example.

Joe

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <106ceeeqc8ph12 6@news.supernew s.com>, John Roth wrote:[color=blue]
> It's certainly true that in a prototype based language all objects
> exist: there are no objects that the compiler deals with but does
> not put into the resulting program. And it's quite true that it does
> open up the floodgates for a lot of messiness.[/color]

Hmm, I bet an optimizing compiler could take care of that for statically
linked programs, although you'd still need to put all the objects in the
libraries just in case some user wants to instantiate them. (Although
an explicit export list could help the compiler out there.)

Joe

[Andrew Bennetts]

Re: Prothon Prototypes vs Python Classes

On Sun, Mar 28, 2004 at 03:37:25AM +0000, Joe Mason wrote:
[...][color=blue]
>
> Ed Suominen just posted a situation where classes and instances need to
> be treated separately. He has a class, "AutoText", with various
> subclasses (which I'll call "AutoA", "AutoB", etc. because I forget the
> details). He wants to notice whenever somebody creates a subclass of
> AutoText and add it to a list so that he can have an AutoAll function
> which creates just one instance of each. (Or something like that.)
>[/color]
[...][color=blue]
> In Python, the easiest way to do this is with metaclasses, which is a
> really advanced topic. In Prothon, it's simple to "notice" when a
> subclass is created, because __init__ gets called! So you just say:[/color]

Actually, in Python, it's even easier than that:
[color=blue][color=green][color=darkred]
>>> class C(object): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> class D(C): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> C.__subclasses_ _()[/color][/color][/color]
[<class '__main__.D'>]

-Andrew.

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <mailman.6.1080 446668.20120.py thon-list@python.org >, Andrew Bennetts wrote:[color=blue]
> Actually, in Python, it's even easier than that:
>[color=green][color=darkred]
>>>> class C(object): pass[/color][/color]
> ...[color=green][color=darkred]
>>>> class D(C): pass[/color][/color]
> ...[color=green][color=darkred]
>>>> C.__subclasses_ _()[/color][/color]
> [<class '__main__.D'>][/color]

Cool. How come this isn't in either the Language Reference or Library
Reference? I just skimmed through those looking for special
class-related methods the other day, when I first started looking at
prototypes, and didn't notice __subclasses__, and now I can't find it in
the index.

Joe

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Mark Hahn" <mark@prothon.o rg> wrote in message
news:v0r9c.3898 8$cx5.22021@fed 1read04...[color=blue][color=green]
> > although for reasons I've mentioned elsewhere, I won't use Prothon.[/color]
>
> Can you please point me to those reasons?[/color]

Since I got into a minor flame war over them, including a
very snide and oh so superior response from one yahoo
who almost hit my killfile over it, 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.

There are enough interesting languages out there to
investigate that I simply won't bother with candidates
that don't play fair with ***all*** the tools I use,
or that people I communicate with use.

John Roth

[Paul Prescod]

Re: Prothon Prototypes vs Python Classes

John Roth wrote:
[color=blue]
> It's certainly true that in a prototype based language all objects
> exist: there are no objects that the compiler deals with but does
> not put into the resulting program. And it's quite true that it does
> open up the floodgates for a lot of messiness.[/color]

Ummm. This is also true for Python. Python classes exist at runtime.

foo = 5

class foo: # oops. I've overwritten foo
def bar(self):
pass

print foo
print dir(foo)
print type(foo)

Paul Prescod

[Jeff Epler]

Re: Prothon Prototypes vs Python Classes

I just wanted to jump on the "Python *can* do prototypes" bandwagon, and
offer my own solution. To me, a prototype looks like a class where all
methods are classmethods. Well, then, just fix that up in a metaclass.
The only other wrinkle I addressed was calling __init__ (because an
instance is never created). Special methods (such as __add__, __call__)
probably don't do anything sane.

This code is distributed under the "Free to a good home" license.

Jeff


import sys, types

class PrototypeMeta(t ype):
def __init__(cls, name, bases, dict):
super(Prototype Meta, cls).__init__(n ame, bases, dict)
for name, value in dict.items():
if isinstance(valu e, types.FunctionT ype):
setattr(cls, name, classmethod(val ue))
# cls always has __init__ -- it can either be object's init,
# (which is a wrapper_descrip tor) or a desired init (which is
# a bound classmethod). call it if it's the right one.
if isinstance(cls. __init__, types.MethodTyp e):
cls.__init__()

def __call__(
__metaclass__ = PrototypeMeta

class Thing:
name = "Unnamed Thing"
desc = "(Undescrib ed thing)"
def __init__(self):
print "created a new thing:", self.name

def look(self):
print "You see a", self.name
print self.desc

class Room:
name = "Unnamed Room"
desc = "(Undescrib ed room)"
contents = []

def look(self):
print "You are in", self.name
print
print self.desc
print
if self.contents:
print "Things here:"
for c in self.contents:
print c.name
print

class Python(Thing):
name = "a snake"
desc = "This snake has the number '%s' written on its belly" \
% sys.version.spl it()[0]

class LivingRoom(Room ):
name = "Living Room"
desc = """There is a large window on the south side of the room, which
is also the location of the door to the outside. On the west wall is an
unused fireplace with plants on the mantle. A hallway is to the west,
and the dining room is north."""
contents = [Python]

class DarkRoom(Room):
def look(self):
print "Where am I? It's dark in here!"
print

print
LivingRoom.look ()
DarkRoom.look()
Python.look()

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Paul Prescod" <paul@prescod.n et> wrote in message
news:mailman.10 .1080485351.201 20.python-list@python.org ...[color=blue]
> John Roth wrote:
>[color=green]
> > It's certainly true that in a prototype based language all objects
> > exist: there are no objects that the compiler deals with but does
> > not put into the resulting program. And it's quite true that it does
> > open up the floodgates for a lot of messiness.[/color]
>
> Ummm. This is also true for Python. Python classes exist at runtime.
>
> foo = 5
>
> class foo: # oops. I've overwritten foo
> def bar(self):
> pass
>
> print foo
> print dir(foo)
> print type(foo)
>
> Paul Prescod[/color]

Sure. But misusing classes as instances is quite rare in
practice, and plugging members into instances is also
quite rare in practice. Python's highly dynamic nature
opens it up to a lot of difficulty in principle, but most
deveopers seem to be quite disciplined in their use of
dynamism.

The difficulty here is simply that there is no way of
isolating a base object that is supposed to be the platform
for other objects from objects that are supposed to be
updatable with new behavior.

The higher a tower you want to build, the firmer the
foundation. Conventions help, but if the conventions
are helped along by the language, that's even better.

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

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <mailman.11.108 0489481.20120.p ython-list@python.org >, Jeff Epler wrote:[color=blue]
> def __call__(
> __metaclass__ = PrototypeMeta
>
> class Thing:[/color]

You're missing most of call() there.

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:
[color=blue][color=green][color=darkred]
>>> class TestProto: l = [][/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> class Test2(TestProto ): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> TestProto.l[/color][/color][/color]
[][color=blue][color=green][color=darkred]
>>> Test2.l[/color][/color][/color]
[][color=blue][color=green][color=darkred]
>>> Test2.l.append( 0)
>>> Test2.l[/color][/color][/color]
[0][color=blue][color=green][color=darkred]
>>> TestProto.l[/color][/color][/color]
[0]

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

A bunch of the solutions already check for method definitions and
convert them to instances of a type ProtoMethod. We could do the same
with COWDict and COWSequence classes in __setattr__, or something like
that. That takes care of 80% of the problem. If we can make it work
for subclasses as well, it works for 90%. For the remaining 10% (large
datastructures unrelated to dicts/sequences) it might be enough just to
let the user handle it.

Any thoughts?

(BTW, I plan to write up all the various solutions I've seen - including
a link to Prothon - in the next few days, if I have time after work.
Next weekend at the latest.)

Joe