Prothon Prototypes vs Python Classes

[David MacQuigg]

Re: Prothon Prototypes vs Python Classes

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<newsgroups@jhr othjr.com> wrote:
[color=blue]
>
>"Paul Prescod" <paul@prescod.n et> wrote in message
>news:mailman.1 0.1080485351.20 120.python-list@python.org ...[color=green]
>> John Roth wrote:
>>[color=darkred]
>> > It's certainly true that in a prototype based language all objects
>> > exist: there are no objects that the compiler deals with but does
>> > not put into the resulting program. And it's quite true that it does
>> > open up the floodgates for a lot of messiness.[/color]
>>
>> Ummm. This is also true for Python. Python classes exist at runtime.
>>
>> foo = 5
>>
>> class foo: # oops. I've overwritten foo
>> def bar(self):
>> pass
>>
>> print foo
>> print dir(foo)
>> print type(foo)
>>
>> Paul Prescod[/color]
>
>Sure. But misusing classes as instances is quite rare in
>practice, and plugging members into instances is also
>quite rare in practice. Python's highly dynamic nature
>opens it up to a lot of difficulty in principle, but most
>deveopers seem to be quite disciplined in their use of
>dynamism.
>
>The difficulty here is simply that there is no way of
>isolating a base object that is supposed to be the platform
>for other objects from objects that are supposed to be
>updatable with new behavior.
>
>The higher a tower you want to build, the firmer the
>foundation. Conventions help, but if the conventions
>are helped along by the language, that's even better.[/color]

In Ruby you can freeze() any object. But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygo n
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]

Re: Prothon Prototypes vs Python Classes

David MacQuigg wrote:[color=blue][color=green]
>> Is all this complexity unecessary?[/color][/color]

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:
[color=blue]
>Complexity's ok if it's in the right place[/color]

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


[color=blue]
> Ed Suominen just posted a situation where classes and instances need to
> be treated separately.[/color]
[...][color=blue]
> So here's one point where the simplification of prototypes actually ends
> up making the user code more complicated than the full Python version.[/color]

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.ap pend(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.:)

[color=blue]
> But someone else said that prototype-based languages "tend to grow
> features that mimic class-based ones", or soemthing like that.[/color]

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]

Re: Prothon Prototypes vs Python Classes

In article <69cbbef2.04032 80928.438d194f@ posting.google. com>, has wrote:[color=blue]
> # Library pseudocode
>
> _fooRegistry = []
>
> obj _Foo: # prototype object
> # Foo's code goes here
>
> def Foo(): # constructor function
> newFoo = _Foo.copy()
> _fooRegistry.ap pend(newFoo)
> return newFoo
>
>
> Dirt simple with not an ounce of class metaprogramming in sight.[/color]

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]

Re: Prothon Prototypes vs Python Classes

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" <newsgroups@jhr othjr.com> wrote in message
news:106di86neu 1qh4d@news.supe rnews.com...[color=blue]
>
> "Mark Hahn" <mark@prothon.o rg> wrote in message
> news:v0r9c.3898 8$cx5.22021@fed 1read04...[color=green][color=darkred]
> > > although for reasons I've mentioned elsewhere, I won't use Prothon.[/color]
> >
> > Can you please point me to those reasons?[/color]
>
> Since I got into a minor flame war over them, including a
> very snide and oh so superior response from one yahoo
> who almost hit my killfile over it, I'll just mention that there
> are ***very good***, that is ***extremely good***
> reasons why the Python standard is to use spaces for
> indentation, and why the option of using tabs will be
> removed in 3.0.
>
> There are enough interesting languages out there to
> investigate that I simply won't bother with candidates
> that don't play fair with ***all*** the tools I use,
> or that people I communicate with use.
>
> John Roth
>
>
>[/color]

[John Roth]

Re: Prothon Prototypes vs Python Classes


"David MacQuigg" <dmq@gain.com > wrote in message
news:bi1e601vsm 4qtqaieqdo69bco 64m7naupa@4ax.c om...[color=blue]
> On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
> <newsgroups@jhr othjr.com> wrote:
>[color=green]
> >
> >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.[/color]
>
> In Ruby you can freeze() any object. But it seems like in this case,
> just giving your base object a distinct name, like PrototypePolygo n
> 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).[/color]

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[color=blue]
>
> -- Dave
>[/color]

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

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" <dmq@gain.com > wrote in message
news:bi1e601vsm 4qtqaieqdo69bco 64m7naupa@4ax.c om...[color=blue]
> On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
> <newsgroups@jhr othjr.com> wrote:
>[color=green]
> >
> >"Paul Prescod" <paul@prescod.n et> wrote in message
> >news:mailman.1 0.1080485351.20 120.python-list@python.org ...[color=darkred]
> >> 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[/color]
> >
> >Sure. But misusing classes as instances is quite rare in
> >practice, and plugging members into instances is also
> >quite rare in practice. Python's highly dynamic nature
> >opens it up to a lot of difficulty in principle, but most
> >deveopers seem to be quite disciplined in their use of
> >dynamism.
> >
> >The difficulty here is simply that there is no way of
> >isolating a base object that is supposed to be the platform
> >for other objects from objects that are supposed to be
> >updatable with new behavior.
> >
> >The higher a tower you want to build, the firmer the
> >foundation. Conventions help, but if the conventions
> >are helped along by the language, that's even better.[/color]
>
> In Ruby you can freeze() any object. But it seems like in this case,
> just giving your base object a distinct name, like PrototypePolygo n
> 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
>[/color]

[John Roth]

Re: Prothon Prototypes vs Python Classes

"Mark Hahn" <mark@prothon.o rg> wrote in message
news:AHF9c.4904 8$cx5.33872@fed 1read04...[color=blue]
> 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)[/color]

Thank you. That wasn't the impression I had picked up from
the third party discussion of the issue earlier.

John Roth
[color=blue]
>
> "John Roth" <newsgroups@jhr othjr.com> wrote in message
> news:106di86neu 1qh4d@news.supe rnews.com...[color=green]
> >
> > "Mark Hahn" <mark@prothon.o rg> wrote in message
> > news:v0r9c.3898 8$cx5.22021@fed 1read04...[color=darkred]
> > > > although for reasons I've mentioned elsewhere, I won't use Prothon.
> > >
> > > Can you please point me to those reasons?[/color]
> >
> > Since I got into a minor flame war over them, including a
> > very snide and oh so superior response from one yahoo
> > who almost hit my killfile over it, I'll just mention that there
> > are ***very good***, that is ***extremely good***
> > reasons why the Python standard is to use spaces for
> > indentation, and why the option of using tabs will be
> > removed in 3.0.
> >
> > There are enough interesting languages out there to
> > investigate that I simply won't bother with candidates
> > that don't play fair with ***all*** the tools I use,
> > or that people I communicate with use.
> >
> > John Roth
> >
> >
> >[/color]
>
>[/color]

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Mark Hahn" <mark@prothon.o rg> wrote in message
news:ZNF9c.4910 8$cx5.10276@fed 1read04...[color=blue]
> 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[/color]
a[color=blue]
> 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[/color]
of[color=blue]
> research.
> Mark Hahn (Prothon Author)[/color]

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
[color=blue]
> P.S. If this belongs in the Prothon list instead of Python, let us know.
>
>
> "David MacQuigg" <dmq@gain.com > wrote in message
> news:bi1e601vsm 4qtqaieqdo69bco 64m7naupa@4ax.c om...[color=green]
> > On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
> > <newsgroups@jhr othjr.com> wrote:
> >[color=darkred]
> > >
> > >"Paul Prescod" <paul@prescod.n et> wrote in message
> > >news:mailman.1 0.1080485351.20 120.python-list@python.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[/color][/color][/color]
does[color=blue][color=green][color=darkred]
> > >> > 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.[/color]
> >
> > In Ruby you can freeze() any object. But it seems like in this case,
> > just giving your base object a distinct name, like PrototypePolygo n
> > 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
> >[/color]
>
>[/color]

[Paul Prescod]

Re: Prothon Prototypes vs Python Classes

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:
[color=blue]
> "Paul Prescod" <paul@prescod.n et> wrote in message
> news:mailman.10 .1080485351.201 20.python-list@python.org ...
>[color=green]
>>John Roth wrote:
>>
>>[color=darkred]
>>>It's certainly true that in a prototype based language all objects
>>>exist: there are no objects that the compiler deals with but does
>>>not put into the resulting program. And it's quite true that it does
>>>open up the floodgates for a lot of messiness.[/color]
>>[/color][/color]

I responded:
[color=blue][color=green]
>>Ummm. This is also true for Python. Python classes exist at runtime.[/color][/color]

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]

Re: Prothon Prototypes vs Python Classes

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]

Re: Prothon Prototypes vs Python Classes

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?
[color=blue]
>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.
>[/color]

[John Roth]

Re: Prothon Prototypes vs Python Classes

"Harald Massa" <cpl.19.ghum@sp amgourmet.com> wrote in message
news:Xns94BBF15 2E6BBcpl19ghums pamgourmet@62.1 53.159.134...[color=blue]
> 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[/color]
really[color=blue]
> can't see why it should be more than some small hacks to allow "adding a
> function to an existing object".[/color]

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[color=blue]
>
>
> Harald[/color]

[Michael]

Re: Prothon Prototypes vs Python Classes

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?
[color=blue]
>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.
>[/color]

[William Park]

Re: Prothon Prototypes vs Python Classes

Michael <mogmios@mlug.m issouri.edu> wrote:[color=blue]
> 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?
>[color=green]
> >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.[/color][/color]

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, <opengeometry@y ahoo.ca>
Linux solution for data processing and document management.

[Carl Banks]

Re: Prothon Prototypes vs Python Classes

William Park wrote:[color=blue]
> Michael <mogmios@mlug.m issouri.edu> wrote:[color=green]
>> 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?
>>[color=darkred]
>> >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.[/color][/color]
>
> This space-vs-tab war is just insane. I wish Prothon/Python would use
> block terminator, if only to kill this silly trollings.[/color]


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