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

[John Roth]

"David MacQuigg" <dm*@gain.com> wrote in message
news:56********************************@4ax.com...

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.
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?
My question for the Python experts is -- What user benefit are we
missing if we eliminate classes?
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
-- Dave

[Michael]

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]

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

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.

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]

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

Can you please point me to those reasons?

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

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

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.

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

[Michael]

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]

In article <56********************************@4ax.com>, David MacQuigg wrote:

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?

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__(someparams):
# 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__(someparams):
# 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(register)
AutoText.register()

# 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(type):
def __init__(klass, name, bases, dict):
autoall.append(klass)

class AutoText(Base):
__metaclass__ = AutoRegister
def __init__(self, text):
Base.__init__(self, 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]

In article <10*************@news.supernews.com>, John Roth wrote:

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.

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]

On Sun, Mar 28, 2004 at 03:37:25AM +0000, Joe Mason wrote:
[...]

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.)
[...] 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:

Actually, in Python, it's even easier than that:

class C(object): pass .... class D(C): pass .... C.__subclasses__()

[<class '__main__.D'>]

-Andrew.

[Joe Mason]

In article <ma************************************@python.org >, Andrew Bennetts wrote:

Actually, in Python, it's even easier than that:

class C(object): pass ... class D(C): pass ... C.__subclasses__()

[<class '__main__.D'>]

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]

"Mark Hahn" <ma**@prothon.org> wrote in message
news:v0r9c.38988$cx5.22021@fed1read04...

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

Can you please point me to those reasons?

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]

John Roth wrote:

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.

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]

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(type):
def __init__(cls, name, bases, dict):
super(PrototypeMeta, cls).__init__(name, bases, dict)
for name, value in dict.items():
if isinstance(value, types.FunctionType):
setattr(cls, name, classmethod(value))
# cls always has __init__ -- it can either be object's init,
# (which is a wrapper_descriptor) or a desired init (which is
# a bound classmethod). call it if it's the right one.
if isinstance(cls.__init__, types.MethodType):
cls.__init__()

def __call__(
__metaclass__ = PrototypeMeta

class Thing:
name = "Unnamed Thing"
desc = "(Undescribed 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 = "(Undescribed 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.split()[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]

"Paul Prescod" <pa**@prescod.net> wrote in message
news:ma*************************************@pytho n.org...

John Roth wrote:

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

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

[Joe Mason]

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

def __call__(
__metaclass__ = PrototypeMeta

class Thing:

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:

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.

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

[David MacQuigg]

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<ne********@jhrothjr.com> wrote:

"Paul Prescod" <pa**@prescod.net> wrote in message
news:ma*************************************@pyth on.org...

John Roth wrote:

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

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

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.

In Ruby you can freeze() any object. But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygon
will remind you not to change its definition later as you create
triangles, rectangles, etc.

I also would have no objection to some syntactic lock, like any object
name ending in an underscore is an immutable object. We could also do
this the other way around. Objects, by default are immutable. That
would take care of most uses. If you want a mutable object, give it a
name ending in ! (bang).

-- Dave

[has]

David MacQuigg wrote:

Is all this complexity unecessary?

Yup. Scary to realise a good chunk of your hard-won expert knowledge
is essentially worthless make-work, eh? Ah well... c'est la vie. <g>
Joe Mason replied:
Complexity's ok if it's in the right place
Hmmm... sort of true. However:

1. Complexity is _never_ desireable. (Unless you're deliberately
obfuscating code, which is the exception that proves the rule.)

2. Essential complexity is something you have to accept; in any large
system it's almost inevitable. Hiding this from casual view may a
reasonable compromise in preventing the average user's head from
exploding.

3. Gratuitous complexity should be eliminated at every opportunity,
however. Hiding it is just a kludge and a copout.

4. Often what's seen as essential complexity is actually gratuitous
complexity that nobody's noticed. (Or have noticed, but prefer to keep
schtum about it for whatever reasons of their own.)
Ed Suominen just posted a situation where classes and instances need to
be treated separately. [...] So here's one point where the simplification of prototypes actually ends
up making the user code more complicated than the full Python version.
Not at all. All it shows is that a class-based programming style
doesn't work well in a classless language. Here's a more sensible
solution:

# Library pseudocode

_fooRegistry = []

obj _Foo: # prototype object
# Foo's code goes here

def Foo(): # constructor function
newFoo = _Foo.copy()
_fooRegistry.append(newFoo)
return newFoo
Dirt simple with not an ounce of class metaprogramming in sight.

To a class-based programmer, prototype-based OO must feel rather like
running down the High Street with no pants on; a wonderfully
liberating experience once you get over the initial embarrassment.
Python's layering of a stiff, complicated, class-oriented programming
model atop such a highly dynamic implementation seems a bit perverse,
as well as a badly missed opportunity. (Needless to say, I'll be
watching Prothon's development with some considerable interest.:)

But someone else said that prototype-based languages "tend to grow
features that mimic class-based ones", or soemthing like that.

One suspects, however, that such languages were getting along just
fine by themselves till the class-based programmers arrived. As with
missionaries, any approaching Java programmers should be shot on sight
or you'll be infested by crappy typesystems and worshipping bloody
generics before you know it. :p

has

[Joe Mason]

In article <69**************************@posting.google.com >, has wrote:

# Library pseudocode

_fooRegistry = []

obj _Foo: # prototype object
# Foo's code goes here

def Foo(): # constructor function
newFoo = _Foo.copy()
_fooRegistry.append(newFoo)
return newFoo
Dirt simple with not an ounce of class metaprogramming in sight.

Is Foo() the standard syntax for making a new _Foo object? If this is a
new wrapper you just created, then it's no different than adding a
register() method - the user has to know that something different is
being done.

If Foo() is the standard syntax, and you're just overriding the
implementation here, does that get inherited? If so, this missed the
condition that only some of the descendants should get added to the
registry. If not - well, inheriting the constructor seems like the more
useful behaviour in general, so why not?

Joe

[Mark Hahn]

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.

Mark Hahn (Prothon Author)

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

"Mark Hahn" <ma**@prothon.org> wrote in message
news:v0r9c.38988$cx5.22021@fed1read04...

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

Can you please point me to those reasons?

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

[John Roth]

"David MacQuigg" <dm*@gain.com> wrote in message
news:bi********************************@4ax.com...

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<ne********@jhrothjr.com> wrote:

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.
In Ruby you can freeze() any object. But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygon
will remind you not to change its definition later as you create
triangles, rectangles, etc.

I also would have no objection to some syntactic lock, like any object
name ending in an underscore is an immutable object. We could also do
this the other way around. Objects, by default are immutable. That
would take care of most uses. If you want a mutable object, give it a
name ending in ! (bang).

A lock would be useful, but the _ to *declare* it immutable probably
won't work in practice: it makes it difficult to initialize properly before
it's locked. Likewise, the ! (borrowed from Ruby) doesn't work because
the vast majority of objects are, in fact, mutable.

John Roth
-- Dave

[Mark Hahn]

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.
"David MacQuigg" <dm*@gain.com> wrote in message
news:bi********************************@4ax.com...

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<ne********@jhrothjr.com> wrote:

"Paul Prescod" <pa**@prescod.net> wrote in message
news:ma*************************************@pyth on.org...

John Roth wrote:

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

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

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.

In Ruby you can freeze() any object. But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygon
will remind you not to change its definition later as you create
triangles, rectangles, etc.

I also would have no objection to some syntactic lock, like any object
name ending in an underscore is an immutable object. We could also do
this the other way around. Objects, by default are immutable. That
would take care of most uses. If you want a mutable object, give it a
name ending in ! (bang).

-- Dave

[John Roth]

"Mark Hahn" <ma**@prothon.org> wrote in message
news:AHF9c.49048$cx5.33872@fed1read04...

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.

Mark Hahn (Prothon Author)
Thank you. That wasn't the impression I had picked up from
the third party discussion of the issue earlier.

John Roth

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

"Mark Hahn" <ma**@prothon.org> wrote in message
news:v0r9c.38988$cx5.22021@fed1read04...

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

Can you please point me to those reasons?

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

[John Roth]

"Mark Hahn" <ma**@prothon.org> wrote in message
news:ZNF9c.49108$cx5.10276@fed1read04...

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)
I think that's a very rational way to go about it. I don't think that
lexical
labeling will work, though. It makes initialization too difficult.

John Roth
P.S. If this belongs in the Prothon list instead of Python, let us know.
"David MacQuigg" <dm*@gain.com> wrote in message
news:bi********************************@4ax.com...

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<ne********@jhrothjr.com> wrote:

"Paul Prescod" <pa**@prescod.net> wrote in message
news:ma*************************************@pyth on.org...
> John Roth wrote:
>
> > 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.
>
> 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

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.

In Ruby you can freeze() any object. But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygon
will remind you not to change its definition later as you create
triangles, rectangles, etc.

I also would have no objection to some syntactic lock, like any object
name ending in an underscore is an immutable object. We could also do
this the other way around. Objects, by default are immutable. That
would take care of most uses. If you want a mutable object, give it a
name ending in ! (bang).

-- Dave

[Paul Prescod]

I'm totally confused. There was a statement of fact about how compilers
work which I refuted. Now it's shifting to a question of programming style.

Let's recap:

John Roth wrote:

"Paul Prescod" <pa**@prescod.net> wrote in message
news:ma*************************************@pytho n.org...

John Roth wrote:

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.

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

Given

class A:
pass

a = A()

Both "a" and "A" are put in the "resulting program" (bytecodes) just as
they would in a prototype-based language. A() is a completely
first-class object, just like a prototype in a prototype-based language.

Paul Prescod

[Harald Massa]

Mark,

I see most discussion about Prothon is concerning prototypes.

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

I never had a problem to "add an attribute" to an existing object; I really
can't see why it should be more than some small hacks to allow "adding a
function to an existing object".
Harald

[Michael]

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.

[John Roth]

"Harald Massa" <cp*********@spamgourmet.com> wrote in message
news:Xn*********************************@62.153.15 9.134...

Mark,

I see most discussion about Prothon is concerning prototypes.

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

I never had a problem to "add an attribute" to an existing object; I really can't see why it should be more than some small hacks to allow "adding a
function to an existing object".
As you note, you can do that with a simple assignment,
and it will work. The two problems are:

1. The clone operation

2. Syntax sugar to make it all nice and palatable.

I suspect that a usable clone() operation is less
than 10 lines. The syntax sugar, on the other hand,
will IMNSHO, take forever to get agreement.

John Roth

Harald

[Michael]

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.

[William Park]

Michael <mo*****@mlug.missouri.edu> 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.

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

--
William Park, Open Geometry Consulting, <op**********@yahoo.ca>
Linux solution for data processing and document management.

[Carl Banks]

William Park wrote:

Michael <mo*****@mlug.missouri.edu> 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.

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.
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon

[John Roth]

"Michael" <mo*****@mlug.missouri.edu> wrote in message
news:ma*************************************@pytho n.org...

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?

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

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

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

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

John Roth

[John Roth]

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

"Harald Massa" <cp*********@spamgourmet.com> wrote in message
news:Xn*********************************@62.153.15 9.134...

Mark,

I see most discussion about Prothon is concerning prototypes.

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

I never had a problem to "add an attribute" to an existing object; I

really

can't see why it should be more than some small hacks to allow "adding a
function to an existing object".

As you note, you can do that with a simple assignment,
and it will work. The two problems are:

1. The clone operation

2. Syntax sugar to make it all nice and palatable.

I suspect that a usable clone() operation is less
than 10 lines. The syntax sugar, on the other hand,
will IMNSHO, take forever to get agreement.

John Roth

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

John Roth

Harald

[Hung Jung Lu]

Harald Massa <cp*********@spamgourmet.com> wrote in message news:<Xn*********************************@62.153.1 59.134>...

Can you explain to me in easy words, why it is NOT possible to integrate
prototypes into Python to stand "side by side" with classes?
It is possible, but you will not be able to retroactively apply it to
many existing objects. You will only be able to do things with your
new customized objects.

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

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

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

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

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

http://groups.google.com/groups?q=g:...le.com&rnum=27

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

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

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

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

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

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

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

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

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

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

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

Hung Jung

[Michael]

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

[Mark Hahn]

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

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

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

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

"Harald Massa" <cp*********@spamgourmet.com> wrote in message
news:Xn*********************************@62.153.15 9.134...

Mark,

I see most discussion about Prothon is concerning prototypes.

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

I never had a problem to "add an attribute" to an existing object; I really can't see why it should be more than some small hacks to allow "adding a
function to an existing object".
Harald

[has]

Harald Massa <cp*********@spamgourmet.com> wrote in message news:<Xn*********************************@62.153.1 59.134>...

Mark,

I see most discussion about Prothon is concerning prototypes.

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

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

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

[Joe Mason]

In article <10*************@news.supernews.com>, 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.

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

Joe

[Ville Vainio]

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

[Dang Griffith]

On Sat, 27 Mar 2004 21:33:50 -0500, "John Roth"
<ne********@jhrothjr.com> wrote:

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

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

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.

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

[John Roth]

"Michael" <mo*****@mlug.missouri.edu> wrote in message
news:ma*************************************@pytho n.org...

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 don't have very much sympathy for people who
use poor editors to write programs. I've got a lot of
sympathy for people who are stuck with defective
rendering and printing programs for analyzing programs
that they didn't write in the first place, though. Note that
Python, which is mostly what we're talking about on this
newsgroup, comes with a reasonably competent editor
called Idle. There are very few environments where you
can use Python at all where you can't use Idle.

I've never seen variable width fonts to change the width
of spaces on the left, unless it was doing something like
full justification.

As far as rendering programs, the most obvious
culprit is OE, which for all of its defects and security
problems, is still one of the most used mail and newsgroup
clients out there.

I'll also point out that even programs that properly follow
the tab "standard" will not render well since the standard
is that a tab goes to the next multiple of 8. The number
8 has nothing to do with readability: it was decided on
as the best compromise on compressing the number of
characters going over a line when line speeds were *very*
slow and teletypes really were electromechanical monsters
with these little metal stops called 'tabs' in the back.

There is, of course, no standard at all for how to change
the default tabbing in programs, which means that one
has to deal with each and every one on an individual
basis - if it's even possible.

Reading the source for Idle is quite
enlightening: there is a comment about Tk doing something
rather absurd if you change the tab default.

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.

Definitely.

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?

Any programming editor worth the name will insert spaces
when you use the tab key; likewise it will adjust with the
backspace key. This is not a problem unique to Python,
after all.

The same comment applies to variable width fonts. A good
programming editor will not use them.

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.

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

[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 electromechanical 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 electromechanical 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*************************************@python.or g>, 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.