Prothon Prototypes vs Python Classes

[Michael]

Re: tabbing probs

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

[John Roth]

Re: tabbing probs (was: Prothon Prototypes vs Python Classes)


"Michael" <mogmios@mlug.m issouri.edu> wrote in message
news:406848CD.5 070100@mlug.mis souri.edu...[color=blue]
>[color=green]
> >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.
> >
> >[/color]
> 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.
>[color=green]
> >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.
> >
> >[/color]
> 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[/color]
problem.[color=blue]
>
> 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.[/color]

You're contradicting yourself. In a prior post, you said that if you
had a crappy editor, then change it. Now you're saying that you
think you would have to press the space bar or the backspace key
multiple times, and you're not going to give up that crappy editor
for one that works properly.

Get real.

John Roth

[Glenn Andreas]

Re: Prothon Prototypes vs Python Classes

In article <slrnc6gc7a.i1i .joe@gate.notch arles.ca>,
Joe Mason <joe@notcharles .ca> wrote:
[color=blue]
> In article <mailman.55.108 0568422.20120.p ython-list@python.org >, Jeff Epler
> wrote:[color=green][color=darkred]
> >> 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.[/color]
> >
> > 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__[/color]
>
> 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.)[/color]

copy-on-write wouldn't handle the above issue though, since you aren't
writing Test2.l, you are sending a message to Test2.l (which may, or may
not, mutate Test2.l). You could provide some formalization of "mutable"
vs "immutable" and make copy-on-mutate, but even that is subtle - at
what point does something count as being "mutated"? If you've got an
immutable array of object and you call a mutating method of one of those
objects, does the original mutate (and invoke copy-on-mutate)?

Or even simpler, even if you can catch:

Test2.l.append( 0)

to be copy-on-mutate, what about:

x = Test2.l
x.append(0)

Since that would be identical to:

x = TestProto.l
x.append(0)

how would you tell the difference?


Self basically provides two different methods for getting & setting
instance variables, both of which can be replaced independantly. The
"setter" part is more interest for this since "foo.bar = 5" is just
synatic sugar for "foo x: 5" (which by default will simply set the "x"
slot equal to the value, so when you then execute "foo x" you get that
new value).

It does take a while to wrap your brain around the subtle edge cases
here, especially when combined with multiple inheritance (since the
setter and getter might both come from a different parent then), but
"Organizing Programs Without Classes" [Ungar, Chambers, Chang, Holzle]
is well worth reading, re-reading, and digging out an reading again
every couple of years.

[Terry Reedy]

Re: Prothon Prototypes vs Python Classes


"John Roth" <newsgroups@jhr othjr.com> wrote in message
news:106gg1jifa 2n9c2@news.supe rnews.com...[color=blue]
> 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.[/color]

Actually, the mechanical typewrite standard (in US, 1960s) was every 5
spaces == 1/2 inch (10 chars per inch, fixed). That was also the standard
paragraph indent. WordPerferct, for one program, stuck with 1/2 inch even
as it accommodated different fixed and variable pitched fonts. I remember
thinking 8 spaces a bit weird when I first used Unix (early 80s).
Power-of-2 4 and 8 are computerisms. Don't remember about Teletypes, nor
about typewriters in non-inch countries.

Terry J. Reedy

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Terry Reedy" <tjreedy@udel.e du> wrote in message
news:mailman.73 .1080588424.201 20.python-list@python.org ...[color=blue]
>
> "John Roth" <newsgroups@jhr othjr.com> wrote in message
> news:106gg1jifa 2n9c2@news.supe rnews.com...[color=green]
> > 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.[/color]
>
> Actually, the mechanical typewrite standard (in US, 1960s) was every 5
> spaces == 1/2 inch (10 chars per inch, fixed). That was also the standard
> paragraph indent. WordPerferct, for one program, stuck with 1/2 inch even
> as it accommodated different fixed and variable pitched fonts. I remember
> thinking 8 spaces a bit weird when I first used Unix (early 80s).[/color]

You're right about that, although that was only for the 1st tab. After
that, it was whereever you needed them for columns.
[color=blue]
> Power-of-2 4 and 8 are computerisms. Don't remember about Teletypes, nor
> about typewriters in non-inch countries.[/color]

I don't think it was a power of two thing. I very vaguely remember
some papers on the "ideal" tab spacing for inserting tabs in TTY
data streams. They were there to shrink runs of spaces to
something the mechanical teletypes could move over faster.
Some of the computations to insert a tab and then a specific
number of nulls to compensate for the exact mechanics at the
other end got quite intricate.

John Roth[color=blue]
>
> Terry J. Reedy
>
>
>
>[/color]

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

I would greatly appreciate it if you could take a peek at my stackless
implementation and give me a grade :)

I don't know if you remember me, but I pissed you off in a rude posting I
made in a reply to you months ago (I apologize once again). I was trying to
pickle a complicated graph of objects and getting recursions limit errors in
Python. You were very helpfully telling me how to get around the problem in
a long message and I replied curtly and rudely that Python was broken and
I'd rather write something from scratch than try to use broken tools (it was
a bad day).

To make a long story short, that was the straw that broke the camel's back
and caused me to start work on Prothon. I had been daydreaming about an
extrememly simple but powerful language with just a pile of lockable objects
for some time. The fact that is uses Python syntax is secondary and only
because I like the syntax. My real love is the internal object structure,
threading, and interpreter.

----- Original Message -----
From: "Christian Tismer" <tismer@stackle ss.com>
To: "Mark Hahn" <mark@prothon.o rg>
Cc: <python-list@python.org >
Sent: Monday, March 29, 2004 4:55 AM
Subject: Re: Prothon Prototypes vs Python Classes

[color=blue]
> Mark Hahn wrote:
>[color=green]
> > 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[/color][/color]
causes a[color=blue][color=green]
> > 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[/color][/color]
realize[color=blue][color=green]
> > that extending it to the Ruby freeze() level would be really good.[/color][/color]
Tying[color=blue][color=green]
> > the freezing in somehow to the bang! methods is also in interesting area[/color][/color]
of[color=blue][color=green]
> > research.
> > Mark Hahn (Prothon Author)
> >
> > P.S. If this belongs in the Prothon list instead of Python, let us know.[/color]
>
> Allthough I'm a known Python-addict, I find this very interesting.
> Being prototyped instead of class based was one of the features
> of JavaScript, which were concidered "deficienci es". Well, I didn't
> share this so much, there are many other much worse problems.
>
> I'm eager to learn how a real language develops if it consequently
> builds upon prototypes. Especially this one, since it is stackless
> by nature. :-)
>
> ciao - chris
>
> --
> Christian Tismer :^) <mailto:tismer@ 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 +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
> PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
> whom do you want to sponsor today? http://www.stackless.com/
>
>
>
>
>[/color]

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

> I would guesstimate that the tab indentation mostly serves to[color=blue]
> kill the interest of many who would otherwise take a deeper
> look.[/color]

Prothon has announced that we are caving in and going to spaces instead of
tabs, even though both of the Prothon authors abhor spaces.

"Ville Vainio" <ville@spammers .com> wrote in message
news:du73c7r7tu b.fsf@lehtori.c c.tut.fi...[color=blue][color=green][color=darkred]
> >>>>> "Mark" == Mark Hahn <mark@prothon.o rg> writes:[/color][/color]
>
> 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[/color]

[Michael]

Re: tabbing probs

[color=blue]
>You're contradicting yourself. In a prior post, you said that if you
>had a crappy editor, then change it. Now you're saying that you
>think you would have to press the space bar or the backspace key
>multiple times, and you're not going to give up that crappy editor
>for one that works properly.
>[/color]
An editor is crappy if it inserts anything other than what you type into
the code. If I press tab and four spaces are inserted that is crap. If I
press 'A' and 'a' is inserted that is crap. To me, it sounds as if this
entire issue is caused by crappy editors that think they know better
than the programmers. If you want a smart alec paper clip telling you
what to do when you're editing code then feel free to do so but I just
want raw access to my code.

[Michael]

Re: tabbing probs

[color=blue]
>You're contradicting yourself. In a prior post, you said that if you
>had a crappy editor, then change it. Now you're saying that you
>think you would have to press the space bar or the backspace key
>multiple times, and you're not going to give up that crappy editor
>for one that works properly.
>[/color]
An editor is crappy if it inserts anything other than what you type into
the code. If I press tab and four spaces are inserted that is crap. If I
press 'A' and 'a' is inserted that is crap. To me, it sounds as if this
entire issue is caused by crappy editors that think they know better
than the programmers. If you want a smart alec paper clip telling you
what to do when you're editing code then feel free to do so but I just
want raw access to my code.

[Greg Ewing (using news.cis.dfn.de)]

Re: Prothon Prototypes vs Python Classes

Mark Hahn wrote:[color=blue]
> Prothon has announced that we are caving in and going to spaces instead of
> tabs, even though both of the Prothon authors abhor spaces.[/color]

You don't have to choose between them if you don't
want to. Disallowing *mixed* tabs and spaces is sensible,
but you could allow either all-tabs or all-spaces in a
given file.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Aahz]

Re: Prothon Prototypes vs Python Classes

In article <AHF9c.49048$cx 5.33872@fed1rea d04>,
Mark Hahn <mark@prothon.o rg> wrote:[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.[/color]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Charles Hixson]

Re: Prothon Prototypes vs Python Classes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 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.
|>
They can't possibly be good enough (for my needs). That said, where
can I check this. I don't want to make important decisions on
incomplete information.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAaO9xE1g uSVL8NK8RAuZCAJ 9k2jZSLxwG6Ql3r HqV8u5APcuPJgCg hjjo
AW0ROHktFKNbSKS WYn1q9BM=
=AR/9
-----END PGP SIGNATURE-----

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

A2. People that bitch about top-posting.

"Aahz" <aahz@pythoncra ft.com> wrote in message
news:c4akqh$gml $1@panix2.panix .com...[color=blue]
> In article <AHF9c.49048$cx 5.33872@fed1rea d04>,
> Mark Hahn <mark@prothon.o rg> wrote:[color=green]
> >
> >I didn't know I was going the opposite direction from Python. I guess[/color][/color]
I'll[color=blue][color=green]
> >have to change that.
> >
> >I guess I didn't make it clear that no design decisions were frozen in[/color][/color]
the[color=blue][color=green]
> >language.[/color]
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet?
> --
> Aahz (aahz@pythoncra ft.com) <*>[/color]
http://www.pythoncraft.com/[color=blue]
>
> "usenet imitates usenet" --Darkhawk[/color]

[Mark Hahn]

Re: Prothon Prototypes vs Python Classes

> but you could allow either all-tabs or all-spaces in a given file.

Maybe that the is most sensible solution I've heard yet.


"Greg Ewing (using news.cis.dfn.de )" <ieyf4fu02@snea kemail.com> wrote in
message news:4068D66A.7 060800@sneakema il.com...[color=blue]
> Mark Hahn wrote:[color=green]
> > Prothon has announced that we are caving in and going to spaces instead[/color][/color]
of[color=blue][color=green]
> > tabs, even though both of the Prothon authors abhor spaces.[/color]
>
> You don't have to choose between them if you don't
> want to. Disallowing *mixed* tabs and spaces is sensible,
> but you could allow either all-tabs or all-spaces in a
> given file.
>
> --
> Greg Ewing, Computer Science Dept,
> University of Canterbury,
> Christchurch, New Zealand
> http://www.cosc.canterbury.ac.nz/~greg
>[/color]

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue][color=green]
>>but you could allow either all-tabs or all-spaces in a given file.
>>
>>[/color]
>
>Maybe that the is most sensible solution I've heard yet.
>[/color]
That'd seem agreeable to me. Especially if how strict the rule was could
be set at run time as a Python argument. So you could either have mixed
spaces and tabs refuse to run, give an error, or be ignored and run (if
possible) as we might currently expect.