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

[Joe Mason]

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

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

>>> class TestProto: l = []

...

>>> class Test2(TestProto ): pass

...

>>> TestProto.l

[]

>>> Test2.l

[]

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

[0]

>>> TestProto.l

[0]

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

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

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

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

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

object UrlDispatcher:

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

object SSLUrlDispatche r(UrlDispatcher ):

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

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

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

Joe

[John Roth]

"Michael" <mo*****@mlug.m issouri.edu> wrote in message
news:40******** ******@mlug.mis souri.edu...

What difference does it make what the standard length of a tab is as
long as it remains the same throughout the program? As long as the size
is uniform it should render just fine.

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

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

Again, as long as it's uniform does it matter? It won't change the logic
of the code as long as it opens a tab as a tab and saves a tab as a tab.
If you can't trust your editor to do something that basic then trash it.

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

John Roth

[Michael]

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

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

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

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

[Michael]

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

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

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

[Christian Tismer]

Michael wrote:

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

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

....

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

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

--
Christian Tismer :^) <mailto:ti****@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[rzed]

Michael <mo*****@mlug.m issouri.edu> wrote in
news:40******** ******@mlug.mis souri.edu:

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

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

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

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

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

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

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

--
rzed

[Michael]

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

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

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

[PF]

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

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

[Michael]

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

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

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

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

[Michael]

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

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

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