Python's biggest compromises

[Dennis Lee Bieber]

Re: Python's biggest compromises

Andrew Dalke fed this fish to the penguins on Friday 01 August 2003
01:22 am:

[color=blue]
> or a more detailed description at http://www.kbasic.org/1/history.php3
> which says the first interpreted BASIC was the Micro-Soft one for
> the Altair.
>[/color]
I'd swear that the BASIC I learned on -- via a timeshare
Honeywell-Bull using a dial-up from an ASR-33 -- back in 1972 was
interpreted... At the least, we had no seperate compile/link/run
phase... We'd invoke BASIC, enter the source, and type RUN.

My college mainframe (Xerox Sigma 6) also had an interpreted BASIC,
and I can't believe that was created for the machine way down in the
late 70s -- when the hardware dates to the late 60s...

I'll concede that those may have been "compile on <ret>", wherein each
statement was compiled, but statement labels (and branching thereby)
was interpreted (look up in a table to get a pointer to the actual
code).
[color=blue]
> One thing to consider is - what's the *compromise* in the different
> versions of BASIC? That is, how was the support for backwards-
> compatible operations in BASIC (which you list as a compromise)
> any different than Python's backwards compatibility support?
>[/color]
Python's compatibility doesn't /feel/ like a different language;
through all the changes in Python, a Python 1.3 program /looks/ like a
Python 2.2+ program.

But between early 70s BASIC and what passes for BASIC today looks like
totally different languages. Not even FORTRAN underwent that great a
/visual/ change between (say) FORTRAN IV (aka FORTRAN 66) and FORTRAN
77 (essentially adding block IF constructs) and then Fortran 90 -- yes,
the packaging of modules, dynamic allocation, and new line continuation
do make it a different language... but it /still/ LOOKS like FORTRAN on
quick glance... Let a non-programmer look at source files from K&K
type BASIC, Visual BASIC, F-IV, F77, and F90... and he likely will be
able to identify the three Fortrans as being related -- but would not
consider K&K to be a relation of VB.


Then again, I consider Java (and now .NET) to be nothing more than a
reinvention of the UCSD P-Code Pascal system...
[color=blue]
> Andrew
> dalke@dalkescie ntific.com
>
>[/color]

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

[Dennis Lee Bieber]

Re: Python's biggest compromises

Daniel Dittmar fed this fish to the penguins on Friday 01 August 2003
06:09 am:

[color=blue]
>
> see also: DOS sucks, let's use an operating system instead.
>[/color]
WHICH "DOS"... I have source code listings for something called
"K2FDOS"... Along with the source code volumes for LS-DOS. <G>

Now, if you mean MS-DOS... YES. LS-DOS (later licensed as TRSDOS 6)
had features that barely made it into MS-DOS v2. I distinctly recall
laughing in surprised shock when Dr. Dobbs boasted about MS-DOS having
"user installable device drivers" (and what later came to be called
TSRs); LS-DOS 5! had those features at least a year earlier, on an
8-bit OS. It also had a "compiled" JCL, ability to not only redirect
I/O but link I/O -- letting one use a serial port as in/out while still
using the keyboard/display for the /same/ channels, ability for a Job
Log -- tracking commands and errors messages, and a 7-level password
protection scheme (originally every file had two passwords, user and
owner, and the user password was linked to a privilege level --even
knowing the user password might only give you execute-only access to a
file. When updated to handle dates outside 1980-1987, the user password
was dropped -- effectively given all files a "blank" user password. The
owner password was needed to assign a user privilege level to the file)
[no fear of the secretary deleting the word processor executable if it
were set to execute-only].

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

[Andrew Dalke]

Re: Python's biggest compromises

Dennis Lee Bieber:[color=blue]
> I'd swear that the BASIC I learned on -- via a timeshare
> Honeywell-Bull using a dial-up from an ASR-33 -- back in 1972 was
> interpreted...[/color]

Well, my background is all microcomputer basics in the 80s, including
some (very little) HP BASIC for lab equipment, so I'm not a good
judge. Were I to implement a compiled BASIC I would have done
the "compile on <ret>" you suggested. One of the links described the
Dartmouth BASIC commands and they would be easy to implement
that way.
[color=blue]
> Python's compatibility doesn't /feel/ like a different language;
> through all the changes in Python, a Python 1.3 program /looks/ like a
> Python 2.2+ program.[/color]

In playing around with some of the new Python 2.3 features, I noticed
myself using a more functional style, like

d = {"A": 1, "B": 9", ...} # all uppercase keys
d.update(dict([(k.lower(), v) for k, v in d.items()]))

instead of the more readable and faster

for k, v in d.items():
d[k.lower] = v

It's easier in Python 2.2+ to make Python code which doesn't
look like Python 1.3. Which I think is the version I started with. ;)

When I got QuickBasic in 1988 or so, it would run just about
all of my old GW-BASIC programs, which was distributed some
5 years previous. But it's true, the GW-BASIC program wouldn't
look like a QB program.

Thinking some more ... the 1.3 code would have string
exceptions, so that's one age indicator. It would use the
"while 1 / readline / if not line / break" idiom instead of the
more modern 'for line in file'. It didn't have module support,
IIRC, and only the regex module for regular expressions.
Ahh, and no string methods. That's very noticible when I
look at pre-2.0 code.

Okay, so the two main things that would make a 1.3-style
code stick out is using string.* and raising string exceptions.
In other words, I mostly agree with you, but couldn't let
you get a complete bye :)
[color=blue]
> But between early 70s BASIC and what passes for BASIC today looks[/color]
like[color=blue]
> totally different languages.[/color]

I stopped about 10 years ago. I do recall reading an article by
a VB book author saying VB_(N+1) was too different from VB(N)
and the differences were driven by marketing and not for good
programming reasons.

There's also the TrueBASIC folks. I believe they started in the
mid-80s and argue their BASIC is essentially the same.
[color=blue]
> quick glance... Let a non-programmer look at source files from K&K
> type BASIC, Visual BASIC, F-IV, F77, and F90... and he likely will be
> able to identify the three Fortrans as being related -- but would not
> consider K&K to be a relation of VB.[/color]

Interesting test. Nasty idea: get that same person to judge if
Lisp and Scheme are closely related then post the results on c.l.lisp.

Andrew
dalke@dalkescie ntific.com

[Lulu of the Lotus-Eaters]

Re: Python's biggest compromises

"Daniel Dittmar" <daniel.dittmar @sap.com> wrote previously:
|But a lot of Python code depends on reference counting or more exactly it
|depends on the timely call of the destructor. So even if a much better GC is
|added to Python, reference counting would perhaps be kept for backwards
|compatibility (see Python's biggest compromises)

Did this thread get caught in a time warp, and posts from two years ago
get posted again. Exactly this all happened years ago.

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...idea s have nothing to lose but their chains. Unite
| against "intellectu al property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Lulu of the Lotus-Eaters]

Re: Python's biggest compromises

"Daniel Dittmar" <daniel.dittmar @sap.com> wrote previously:
|But a lot of Python code depends on reference counting or more exactly it
|depends on the timely call of the destructor. So even if a much better GC is
|added to Python, reference counting would perhaps be kept for backwards
|compatibility (see Python's biggest compromises)

Did this thread get caught in a time warp, and posts from two years ago
get posted again. Exactly this all happened years ago.

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...idea s have nothing to lose but their chains. Unite
| against "intellectu al property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Dennis Lee Bieber]

Re: Python's biggest compromises

Andrew Dalke fed this fish to the penguins on Saturday 02 August 2003
11:09 pm:
[color=blue]
> There's also the TrueBASIC folks. I believe they started in the
> mid-80s and argue their BASIC is essentially the same.
>[/color]
Unless I'm mistaken, the folks behind TrueBASIC /were/ Kemeny and
Kurtz (spellings)... IE, the creators of the original BASIC. <G>
[color=blue]
>
> Interesting test. Nasty idea: get that same person to judge if
> Lisp and Scheme are closely related then post the results on c.l.lisp.
>[/color]
Heh... Toss in MPI (the only expansion I've seen for that is "my
personal insanity" -- it's similar except for using {, :, and ,! Been
way too long since I've done any MUCKing but... it was easier to learn
than MUF, which I never could get into even though I used to program HP
calculators).

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

[Andrew Dalke]

Re: Python's biggest compromises

Dennis Lee Bieber:[color=blue]
> Unless I'm mistaken, the folks behind TrueBASIC /were/ Kemeny and
> Kurtz (spellings)... IE, the creators of the original BASIC. <G>[/color]

Yup. From truebasic.com
] John G. Kemeny and Thomas E. Kurtz invented BASIC in 1964
] for use at Dartmouth College. They made it freely available to
] everyone who wanted to learn how to program computers. It
] soon became a world standard.
]
] In 1983 they created True BASIC to incorporate and showcase
] all the advanced developments they had added to their language,
] and offered it as a commercial product.

But that doesn't implement the original BASIC language. OTOH,
it does say it can convert older BASIC to TrueBASIC, so there
is still backwards compatibility. That's gotta warm someone's heart
knowing code written back in the 1960s on a teletype machine
will still run today.. and even on a handheld.

Andrew
dalke@dalkescie ntific.com

[Alex Martelli]

Re: Python's biggest compromises

Andy C wrote:
[color=blue]
> OK, then unless I'm missing something, tabs vs. spaces shouldn't matter
> for
> you. The editor should be able to handle tabs in a satisfactory manner as
> well.[/color]

There seems to be an unspoken assumption here that an editor is the only
program that will need to deal with Python code I receive. It isn't --
mail and news readers, for example, are often involved -- and those often
can't deal satisfactorily with tabs. Thus, it should be the job of the
editor of the person who PRODUCES code (if said code is to be sent outside
at all) to store spaces, not tabs.


Alex

[Michael Hudson]

Re: Python's biggest compromises

hanzspam@yahoo. com.au (Hannu Kankaanpää) writes:
[color=blue]
> Michael Hudson <mwh@python.net > wrote in message news:<7h3brv9a9 oz.fsf@pc150.ma ths.bris.ac.uk> ...[color=green]
> > <button nature="hot">
> > Reference counting *is* a form of garbage collection.
> > </button>[/color]
>
> You apparently have such a loose definition for garbage
> collection, that even C programs have "a form of garbage
> collection" on modern OSes: All garbage is reclaimed by
> the OS when the program exits. It's just a very lazy collector.
>
> I don't consider something a garbage collector unless it
> collects all garbage (ref.counting doesn't) and is a bit more
> agile than the one provided by OS.[/color]

Well, OK, but people do tend to allow a bit of 'conservativene ss' in
their collectors, don't they? Boehm's GC-for-C is usually considered
a 'real GC' and that doesn't necessarily collect everything (AIUI, I'm
not an expert in this field).

CPython's 'ref counting + gimmicks' certainly *would* seem to qualify
as a GC, by your definitions.
[color=blue][color=green]
> > Saying "Ref. counting sucks, let's use GC instead" is a statement near
> > as dammit to meaningless.[/color]
>
> You, I and everyone knows what I was talking about, so it could
> hardly be regarded as "meaningles s".[/color]

Well, OK, but: even if we don't allow refcounting as 'GC' I would
(really!) like to know which form of garbage collection you would use
instead.
[color=blue][color=green]
> > Given the desires above, I really cannot think of a clearly better GC
> > strategy for Python that the one currently employed. AFAICS, the
> > current scheme's biggest drawback is its memory overhead, followed by
> > the cache-trashing tendencies of decrefs.[/color]
>
> It's not "the one currently employed". It's the *two* currently
> employed and that causes grief as I described in my previous post.[/color]

You mean two, as in the ones used by Jython and CPython? If have to
admit, I
[color=blue]
> And AFAIK, Ruby does use GC (mark-and-sweep, if you wish) and
> seems to be working.[/color]

With finalizers? Just curious.
[color=blue]
> However, this is rather iffy knowledge. I'm actually longing for
> real GC because I've seen it work well in Java and C#, and I know
> that it's being used successfully in many other languages.
>[color=green]
> > What would you use instead?[/color]
>
> A trick question?[/color]

Not at all!

I think it would be practically very difficult to move to a radically
different memory management methodology without breaking the vast
majority of C extensions out there, but I would like to see some
more concrete speculation about alternatives.

Cheers,
mwh

--
Considering that this thread is completely on-topic in the way only
c.l.py threads can be, I think I can say that you should replace
"Oblivion" with "Gravity", and increase your Radiohead quotient.
-- Ben Wolfson, comp.lang.pytho n

[Michael Hudson]

Re: Python's biggest compromises

Lulu of the Lotus-Eaters <mertz@gnosis.c x> writes:
[color=blue]
> "Daniel Dittmar" <daniel.dittmar @sap.com> wrote previously:
> |But a lot of Python code depends on reference counting or more exactly it
> |depends on the timely call of the destructor. So even if a much better GC is
> |added to Python, reference counting would perhaps be kept for backwards
> |compatibility (see Python's biggest compromises)
>
> Did this thread get caught in a time warp, and posts from two years ago
> get posted again. Exactly this all happened years ago.[/color]

Welcome to USENET!

Cheers,
mwh

--
Not only does the English Language borrow words from other
languages, it sometimes chases them down dark alleys, hits
them over the head, and goes through their pockets. -- Eddy Peters

[Andrew Dalke]

Re: Python's biggest compromises

Mel Wilson:[color=blue]
> (Idea for obfuscated Python: a program that mixes spaces
> and tabs in the indenting so as to perform two or more
> distinct useful functions depending on the space-to-tab
> rate. Bonus points for a program that undoes itself at
> different settings.)[/color]

That's just not possible because Python only has one setting
for a tag - 8 spaces. At most there would appear to be a
difference if your editor was configured to display tabs as,
say, 4 spaces. But Python's understanding of it would not
change.

Andrew
dalke@dalkescie ntific.com

[Dang Griffith]

Re: Python's biggest compromises

Anthony_Barker wrote:
...[color=blue]
> What about immutable strings? I'm not sure I understand Guido's
> preference for them.[/color]
...
Strings are also immutable in Java. Maybe Guido likes Java? ;-)
--dang

[Aahz]

Re: Python's biggest compromises

In article <bgp1e7$i3g$1@g ateway.northgru m.com>,
Dang Griffith <dmgriffith_not _@tasc.com> wrote:[color=blue]
>Anthony_Bark er wrote:[color=green]
>>
>> What about immutable strings? I'm not sure I understand Guido's
>> preference for them.[/color]
>
> Strings are also immutable in Java. Maybe Guido likes Java? ;-)[/color]

Python predates Java.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

[enoch]

Re: Python's biggest compromises

anthony_barker@ hotmail.com (Anthony_Barker ) wrote in message news:<899f842.0 307310555.56134 f71@posting.goo gle.com>...[color=blue]
> I have been reading a book about the evolution of the Basic
> programming language. The author states that Basic - particularly
> Microsoft's version is full of compromises which crept in along the
> language's 30+ year evolution.
>
> What to you think python largest compromises are?[/color]

Its non existant SMP scalability.
If you try to sell clients somewhat bigger server apps, they don't
want to hear that having these run on a SMP system might (and will)
actually _hurt_ performance without special administrative
interference (processor binding), which isn't even possible on some
older operating systems.
We seem to be more or less at the end concerning ramping up single
processor speeds, and SMP like hardware becomes more and more
ubiquitous, e.g. Intel's Hyperthreading, IBM's SMP-on-a-chip, Sun's
"Throughput Computing".
As far as I know, there seems to be no interest to get rid of the GIL.
To do this might be a big technical problem, but I fear if it stays
the way it is, the actual trend in the hardware industry might work
against python (in server apps) big time.

[Aahz]

Re: Python's biggest compromises

In article <ad02da8c.03080 60705.7ff1fa4f@ posting.google. com>,
enoch <enoch@gmx.ne t> wrote:[color=blue]
>anthony_barker @hotmail.com (Anthony_Barker ) wrote in message news:<899f842.0 307310555.56134 f71@posting.goo gle.com>...[color=green]
>>
>> What to you think python largest compromises are?[/color]
>
>Its non existant SMP scalability.[/color]

Would you care to back up your claim with some actual evidence?

(Yes, there are issues with Python on SMP machines, but to call Python's
built-in threading "non-existent SMP scalability" is either a lie or
revelatory of near-complete ignorance. That doesn't even count the
various IPC mechanisms.)
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz