Python 2.0

9990 views
Skip to first unread message

Graham Matthews

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
I read the following interesting snippet at

http://www.python.org/workshops/1997-10/proceedings/hugunin.html

>6.2. Python in Java's Advantages
>
>Using Java as the underlying systems language for Python has a number of
>advantages over the current implementation of Python in C. First and
>foremost of these in my mind is the opportunity to ride the Java
>popularity wave and let Python code run everywhere there's a Java VM.
>It also makes the rich set of portable Java API's available from within
>Python.
>
>There is also a nice collection of technical reasons why Java is a
>superior implementation language for Python than C. These include
>Java's binary portability, thread-safety, object-orientation, true
>exceptions, garbage collection, and friendliness to glue languages.
>More questions need to be answered before I can make a convincing
>argument that Python 2.0 should be implemented in Java rather than C.
>Nonetheless, I think that Java offers many advantages for Python as
>both an implementation language and a widely available run-time platform.

What particular intrigues me here is the sentence

>More questions need to be answered before I can make a convincing
>argument that Python 2.0 should be implemented in Java rather than C.

I was wondering if this is seriously being considered -- that is
implementing Python 2.0 in Java rather than C. While I understand
that there are some technical challenges with this (notably interfacing
to the existing C implemented extensions), I personally think there
is a lot to be said for compiling Python to the JVM. For example:
access to the Java apis, garbage collection, true compilation, the
ability to write statically typed code (just write that part in Java!),
access to Swing, promoting Python on the coat-tails of Java (free
publicity and hype), etc.

Comments?

graham


--
Thanks for the trouble you took from her eyes
I thought it was there for good
So I never really tried

Michael P. Reilly

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
Graham Matthews <gra...@sloth.math.uga.edu> wrote:
: I read the following interesting snippet at
:
: http://www.python.org/workshops/1997-10/proceedings/hugunin.html

: Comments?

Have you looked at http://www.jpython.org/? It seems to be more in
keeping with your desires.

-Arcege


Paul Moore

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
On 27 May 1999 19:33:38 GMT, gra...@sloth.math.uga.edu (Graham
Matthews) wrote:

>I was wondering if this is seriously being considered -- that is
>implementing Python 2.0 in Java rather than C. While I understand
>that there are some technical challenges with this (notably interfacing
>to the existing C implemented extensions), I personally think there
>is a lot to be said for compiling Python to the JVM. For example:
>access to the Java apis, garbage collection, true compilation, the
>ability to write statically typed code (just write that part in Java!),
>access to Swing, promoting Python on the coat-tails of Java (free
>publicity and hype), etc.
>
>Comments?

I have no problem with an implementation of Python in Java (see
JPython). But I would never use it (reliance on a JVM, general
dissatisfaction with Java implementations, etc).

What I *would* object to, strongly, would be the lack of a Python
implementation in C. I assume that there is no intention that this
should happen.

How would I embed Python in a C application, without a C API? And how
would I distribute a C application with embedded (Java-) Python to
machines with no JVM, assuming I don't want to (or don't have the
capability to) distribute a JVM.

Enough said.

Paul.

Sam Schulenburg

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
In article <7ik6mi$lbk$1...@cronkite.cc.uga.edu>,

gra...@sloth.math.uga.edu (Graham Matthews) wrote:
> I read the following interesting snippet at
>
> http://www.python.org/workshops/1997-10/proceedings/hugunin.html
>
> >6.2. Python in Java's Advantages
> >
> >Using Java as the underlying systems language for Python has a
number of
> >advantages over the current implementation of Python in C. First
and
> >foremost of these in my mind is the opportunity to ride the Java
> >popularity wave and let Python code run everywhere there's a Java
VM.
> >It also makes the rich set of portable Java API's available from
within
> >Python.
> >
> >There is also a nice collection of technical reasons why Java is a
> >superior implementation language for Python than C. These include
> >Java's binary portability, thread-safety, object-orientation, true
> >exceptions, garbage collection, and friendliness to glue languages.
> >More questions need to be answered before I can make a convincing
> >argument that Python 2.0 should be implemented in Java rather than
C.

> >Nonetheless, I think that Java offers many advantages for Python as
> >both an implementation language and a widely available run-time
platform.
>
> What particular intrigues me here is the sentence
>
> >More questions need to be answered before I can make a convincing
> >argument that Python 2.0 should be implemented in Java rather than

C.
>
> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably
interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the
> ability to write statically typed code (just write that part in
Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?
>
> graham
>
> --
> Thanks for the trouble you took from her eyes
> I thought it was there for good
> So I never really tried
>


The only problem I see with a java implimentation of python, would be
the java security process. It is my understanding that the java sandbox
would prevent embeded programs from accessing low level hardware
functions. I presently use python-c to access the hardware abstraction
layer of both windowsNT and windows95/98. This would not be posible
under java.

Sam Schulenburg


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Robert Meegan

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
On Thu, 27 May 1999, Graham Matthews wrote:

[...]

>
> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the
> ability to write statically typed code (just write that part in Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?
>

For many (if not most) Python programmers, this would be a disaster. In addition
to the many extensions publicly available, it seems inevitable that anyone
coding for long will pick up a number of homegrown extensions. For the
overwhelming majority of programmers who don't know Java (and especially for the
admittedly smaller number who don't *want* to know Java) implementing Python in
Java would remove the option of creating extensions.

Without this ability, many of the tasks for which I use Python would be
virtually impossible. I suspect that many others would feel the same way.

JPython has many features that make it interesting and there are environments in
which it makes more sense than does CPython, but it should not become the only
(or even primary) implementation of Python.

Hier bin ich, ich kann nicht anders.

--- Robert

--------------------------------
Robert Meegan
MCIWorldCom - Cedar Rapids, Iowa
319.375.2416


Graham Matthews

unread,
May 27, 1999, 3:00:00 AM5/27/99
to
Paul Moore (gus...@morpheus.demon.co.uk) wrote:
: I have no problem with an implementation of Python in Java (see

: JPython). But I would never use it (reliance on a JVM, general
: dissatisfaction with Java implementations, etc).

Sure current implementations of the JVM are not the best, but they
are improving and will continue to do so. So the "dissatisfaction
with the Java implementations" objection will disappear more and
more over time.

Paul Moore (gus...@morpheus.demon.co.uk) wrote:
: How would I embed Python in a C application, without a C API? And how


: would I distribute a C application with embedded (Java-) Python to
: machines with no JVM, assuming I don't want to (or don't have the
: capability to) distribute a JVM.
:
: Enough said.

I don't think so. Soon every machine under the sun (pun intended)
will have a JVM. Java has a C calling interface, so you can use that
to embed Python in a C application.

graham
--
I would gladly die for a man who was looking for the
truth, but would just as gladly kill a man who thought
he had actually found it -- Voltaire

Helge Hess

unread,
May 28, 1999, 3:00:00 AM5/28/99
to Paul Moore
Paul Moore wrote:
>
> How would I embed Python in a C application, without a C API?

Java has JNI which also allows embedding in C applications. This works
quite well for me (at least as good as embedding, personally I even like
it a bit more).

> And how
> would I distribute a C application with embedded (Java-) Python to
> machines with no JVM, assuming I don't want to (or don't have the
> capability to) distribute a JVM.

What's the difference between distributing a JVM or a PyVM ? This is
pretty much the same. Java bytecode also has the advantage that native
compilers are becoming real, eg the gcj compiler of Cygnus.

Maybe Python could use a lightweight/extended JVM, that is, Python could
use Java bytecodes but the JVM native interface could be done more (C)
Python like. This way one could have shared code between (C)Python and
JPython.

Hm, anyway ...
Helge

Hans Nowak

unread,
May 28, 1999, 3:00:00 AM5/28/99
to

On 27 May 99, Graham Matthews wrote:

> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the
> ability to write statically typed code (just write that part in Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?

While an implementation of Python in Java is a very nice thing to
have (see JPython), I would not be too happy if this were the *only*
version. Java does not run on every system or OS. This would mean
that there won't be, for instance, a Python 2.0 for DOS. (And maybe
other systems. Is there Java for the Amiga, for instance?) Now I know
that most people think that DOS is dead, and technically inferior, so
it won't be a big deal, but there are still quite a few DOS users
around, and it does have its advantages over Windows.

If it will be implemented in C or C++, I can't see how Python 2.0
will *not* compile for DOS, but in Java, it's a different bowl of
soup. Anyway, my point is not really that there should be a DOS
version, but... Right now Python can be built on just about any
system. That's because there's a C compiler for just about any
system. Choosing Java as implementation language would change that.
(And, for a working graphical implementation, one would need, say,
Java, Python and Tkinter...)

This argument may seem feeble but many users of less popular systems
are very glad that there's a Python available for them. I think it
would be desirable to keep it that way.

Why not write it in Caml? At least it will have proper garbage
collection then... :o))

Veel liefs,

--Hans Nowak (ivn...@hvision.nl)
Homepage: http://fly.to/zephyrfalcon

Michael P. Reilly

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Hans Nowak <ivn...@hvision.nl> wrote:

Not to mention that quite a few people here have mentioned that they
have been trying to port Python to embedded systems (as opposed to
embedding in an app).

Java is a nice-to-have (and we already have it), but the JVM cannot
deal with the world at the level that C can (or ever will by the nature
of the two languages).

-Arcege


Graham Matthews

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Hans Nowak (ivn...@hvision.nl) wrote:
: (And, for a working graphical implementation, one would need, say,
: Java, Python and Tkinter...)

What about Swing?

graham
--
Je suis pour le communisme
Je suis pour le socialisme
Je suis pour le capitalisme
Parce que je suis opportuniste

Michael P. Reilly

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Graham Matthews <gra...@sloth.math.uga.edu> wrote:

: Hans Nowak (ivn...@hvision.nl) wrote:
: : (And, for a working graphical implementation, one would need, say,
: : Java, Python and Tkinter...)

: What about Swing?

Refer to some of the other threads about the viability of Swing on
various systems.

But I do have to ask, what do you find lacking with JPython, Graham?
It is Python written in Java, on the JVM, with full API support (as far
as I have determined), and supposed "true garbage collection". JPython
functions/methods are written in Java bytecode, not in Python bytecode
(according to the docs).

Not-encouraging-or-discouraging-ly' yrs
-Arcege


Vadim Chugunov

unread,
May 28, 1999, 3:00:00 AM5/28/99
to

> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably
> interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection,
Personally I would hate it, if Python had ever adopted a garbage
collection without keeping a reference counting.
As many people have noted before, you would not be able to use
destructors to free up resources like memory or file descriptors.

> true compilation, the
Why would JVM generate a better code than Py2C does? Does the fact
that the app is spelled using javacode instead of pycode magically
remove the type inferencing problem?

> ability to write statically typed code (just write that part in
> Java!),

Just write that part in C !

> access to Swing, promoting Python on the coat-tails of Java

What makes Swing to be better than any of the existing Python GUI
bindings ?

> (free publicity and hype), etc.

Yeah. Right. Let's rewrite everything using the hottest
language of the day! ;-)

Vadim

Hans Nowak

unread,
May 28, 1999, 3:00:00 AM5/28/99
to

On 28 May 99, Graham Matthews wrote:

> Hans Nowak (ivn...@hvision.nl) wrote:
> : (And, for a working graphical implementation, one would need, say,
> : Java, Python and Tkinter...)
>
> What about Swing?

Sorry, I don't dance. :)

Graham Matthews

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Michael P. Reilly (arc...@shore.net) wrote:
: But I do have to ask, what do you find lacking with JPython, Graham?

: It is Python written in Java, on the JVM, with full API support (as far
: as I have determined), and supposed "true garbage collection". JPython
: functions/methods are written in Java bytecode, not in Python bytecode
: (according to the docs).

I have used JPython (that's where the orginal quote that started this
message came from). My point is that I think implementation via Java is
a good idea and I am wondering if that is being considered for the
future of CPython. ie. abandoning the CPython implementation as the
main Python and adopting a Java implementation instead (reversing the
status of CPython and JPython).

Graham Matthews

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Graham Matthews:
: > true compilation, the
Vadim Chugunov (ch...@my-deja.com) wrote:
: Why would JVM generate a better code than Py2C does?

Sure one can use Py2C. But with Java you get dynamic compilation of
all your code with no need to use some auxiliary program like Py2C.
cf. HotSpot.

Graham Matthews:
: > ability to write statically typed code (just write that part in
: > Java!),
Vadim Chugunov (ch...@my-deja.com) wrote:
: Just write that part in C !

Techically you are correct that C is statically typed. But my post
clearly implies that I am interested in strong static typing. That
is type systems that ensure that code cannot have type errors at
runtime. You cannot do this in C. You can't quite do it in Java yet
either, but I am confident that will be so in the future via the
facilities for parametic polymorphism.

Graham Matthews:
: > access to Swing, promoting Python on the coat-tails of Java
Vadim Chugunov (ch...@my-deja.com) wrote:
: What makes Swing to be better than any of the existing Python GUI
: bindings ?

Have you ever used Swing for anything? It is much cleaner that Tkinter
for example. It has a huge range of widgets, etc -- much more than
other toolkits. etc. etc. Sure there are bugs etc but Java is a new
product. Give it a few years and they will have gone away.

Graham Matthews:
: > (free publicity and hype), etc.
Vadim Chugunov (ch...@my-deja.com) wrote:
: Yeah. Right. Let's rewrite everything using the hottest


: language of the day! ;-)

At this point it's the end of the thread for me. I was making a
serious suggestion that Python's use could be improved by pig
backing off the hype for Python. And you ...

Fred Pacquier

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
In article <1999052805...@axil.hvision.nl>, ivn...@hvision.nl wrote:
>
>If it will be implemented in C or C++, I can't see how Python 2.0
>will *not* compile for DOS, but in Java, it's a different bowl of
>soup. Anyway, my point is not really that there should be a DOS
>version, but... Right now Python can be built on just about any
>system. That's because there's a C compiler for just about any
>system. Choosing Java as implementation language would change that.
>(And, for a working graphical implementation, one would need, say,
>Java, Python and Tkinter...)
>
>This argument may seem feeble but many users of less popular systems
>are very glad that there's a Python available for them. I think it
>would be desirable to keep it that way.
>
Good point. As an example, a port of Python for the Psion Series 5 (under the
EPOC OS) came out shortly after the machine's release, thanks to a British
hacker. OTOH, Psion users have been bemoaning the lack of the long-promised
Java VM for that platform. It looks like it's only going to be fulfilled this
summer, with the next-generation 5mx, over two years after the original...
J-Python, C-Python, choice is better :-)

Stidolph, David

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Speaking for myself, we are using Python as an embedded language for an
application to add scripting abilities to it. We decided to go with Python
instead of Java because of the C-Level interface. It gave us the confidence
that we could "hack" into Python when it was required. That would not be
practical for a Java version of Python.

The main thing I would like about JPython would be the Just In Time
compilers available for it.

-----Original Message-----
From: gra...@sloth.math.uga.edu [mailto:gra...@sloth.math.uga.edu]
Sent: Friday, May 28, 1999 4:14 PM
To: pytho...@cwi.nl
Subject: Re: Python 2.0


Michael P. Reilly (arc...@shore.net) wrote:
: But I do have to ask, what do you find lacking with JPython, Graham?
: It is Python written in Java, on the JVM, with full API support (as far
: as I have determined), and supposed "true garbage collection". JPython
: functions/methods are written in Java bytecode, not in Python bytecode
: (according to the docs).

I have used JPython (that's where the orginal quote that started this
message came from). My point is that I think implementation via Java is
a good idea and I am wondering if that is being considered for the
future of CPython. ie. abandoning the CPython implementation as the
main Python and adopting a Java implementation instead (reversing the
status of CPython and JPython).

graham

Paul Prescod

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
"Stidolph, David" wrote:
>
> Speaking for myself, we are using Python as an embedded language for an
> application to add scripting abilities to it. We decided to go with Python
> instead of Java because of the C-Level interface. It gave us the confidence
> that we could "hack" into Python when it was required. That would not be
> practical for a Java version of Python.

I wonder if this is truth of perception. I have not tried to extend a JVM
in many years but I wonder how easy/hard it woud be today. JNI is supposed
to do it and I know that Microsoft's proprietary extensions made it very
easy on Windows. I also know that Cygnus working on making C/Java
integration easy. I'd be interested in hearing about people's modern
experiences with Java/C integration.

Another thing to consider is whether we should really still be in the
mindset of manually hacking together languages. Isn't that what
COM/CORBA/OLE and a dozen other standards are supposed to do for us? I
kind of feel that things like SWIG and Perl's XSUB are too useful in that
they don't give us enough impetus to solve this problem once and for all
properly.

I hate to say it but you can do some pretty neat stuff on Windows talking
between languages without a bunch of custom glue code. Why is Unix so far
behind in this regard?

--
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco

Alabama's constitution is 100 years old, 300 pages long and has more than
600 amendments. Highlights include "Amendment 393: Amendment of Amendment
No. 351", "Validation of Laws Regulating Court Costs in Randolph County",
"Miscegenation laws", "Bingo Games in Russell County", "Suppression
of dueling". - http://www.legislature.state.al.us/ALISHome.html

Paul

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
On Thu, 27 May 1999, Paul Moore wrote:
>
> How would I embed Python in a C application, without a C API?

A Java-bytecode version of Python could have a C API. It could either
have a Python-specific C API or it could use JNI.

> And how
> would I distribute a C application with embedded (Java-) Python to
> machines with no JVM, assuming I don't want to (or don't have the
> capability to) distribute a JVM.

If you could distribute a PVM (Python Interpreter) then you could
distribute a JVM or PyJVM as easily, right?

Paul Prescod

Jeff Bauer

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Fred Pacquier wrote:
> Good point. As an example, a port of Python for the Psion Series 5
> (under the EPOC OS) came out shortly after the machine's release,
> thanks to a British hacker.

Since this will be the underlying OS for many cell phones (Nokia,
Erikson, Motorola, etc.) I suppose it won't be long before we
can starting hacking Python on our mobile telephones, yes?

Comments, Harri Pasanen?

just-because-you've-absconded-to-the-French-Riviera-doesn't
-mean-you-can-escape-the-Spanish-Inquisition-ly yr's,

-Jeff Bauer

James Logajan

unread,
May 28, 1999, 3:00:00 AM5/28/99
to
Paul Prescod wrote:
> Another thing to consider is whether we should really still be in the
> mindset of manually hacking together languages. Isn't that what
> COM/CORBA/OLE and a dozen other standards are supposed to do for us? I
> kind of feel that things like SWIG and Perl's XSUB are too useful in that
> they don't give us enough impetus to solve this problem once and for all
> properly.
>
> I hate to say it but you can do some pretty neat stuff on Windows talking
> between languages without a bunch of custom glue code. Why is Unix so far
> behind in this regard?

Unix is behind? In what way? Last I checked, Unix was an OS that has evolved
to include useful things like threads, IPC mechanisms up the gazoo, dynamic
linking, and other handy stuff. Now if you meant to say that Unix
APPLICATIONS are behind, then you need to take your compliant to Unix app
writers. CORBA is available on Unix and if app writers don't use it, well,
what can I say? The very old Unix way of gluing was to use pipes: "a process
should do one thing and do it well" and link processes together with them.
Quaint by today's standards I'll admit, but you have to admit the glue code
was not much more that printf() and fread() and friends.

Paul Prescod

unread,
May 29, 1999, 3:00:00 AM5/29/99
to
James Logajan wrote:
>
> > I hate to say it but you can do some pretty neat stuff on Windows talking
> > between languages without a bunch of custom glue code. Why is Unix so far
> > behind in this regard?
>
> Unix is behind? In what way? Last I checked, Unix was an OS that has evolved
> to include useful things like threads, IPC mechanisms up the gazoo, dynamic
> linking, and other handy stuff. Now if you meant to say that Unix
> APPLICATIONS are behind, then you need to take your compliant to Unix app
> writers. CORBA is available on Unix and if app writers don't use it, well,
> what can I say?

You _could_ say that Unix apps are behind in this regard and you can push
application writers and OS vendors to fix it.

Of course I wasn't talking about the Unix *Kernel* but I also wasn't just
talking about Unix applications. What about "distributions" as they are
now called? Does AIX itself with CORBA? Is it source-level compatible with
CORBA on Solaris? Can I write a portable Unix app and depend on an ORB
being available? App writers don't use CORBA so vendors don't always
provide it. Vendors don't always provide it so app writers don't use it.
Result: Unix is behind.

When I can install a Linux distribution and use the same ORB to talk to
Gnome apps, KDE apps, Netscape and Apache then I will feel that at least
that variant of Unix will have caught up in this regard.

Michael P. Reilly

unread,
May 29, 1999, 3:00:00 AM5/29/99
to
Paul Prescod <pa...@prescod.net> wrote:

: James Logajan wrote:
:>
:> > I hate to say it but you can do some pretty neat stuff on Windows talking
:> > between languages without a bunch of custom glue code. Why is Unix so far
:> > behind in this regard?
:>
:> Unix is behind? In what way? Last I checked, Unix was an OS that has evolved
:> to include useful things like threads, IPC mechanisms up the gazoo, dynamic
:> linking, and other handy stuff. Now if you meant to say that Unix
:> APPLICATIONS are behind, then you need to take your compliant to Unix app
:> writers. CORBA is available on Unix and if app writers don't use it, well,
:> what can I say?

: You _could_ say that Unix apps are behind in this regard and you can push
: application writers and OS vendors to fix it.

: Of course I wasn't talking about the Unix *Kernel* but I also wasn't just
: talking about Unix applications. What about "distributions" as they are
: now called? Does AIX itself with CORBA? Is it source-level compatible with
: CORBA on Solaris? Can I write a portable Unix app and depend on an ORB
: being available? App writers don't use CORBA so vendors don't always
: provide it. Vendors don't always provide it so app writers don't use it.
: Result: Unix is behind.

Your conclusion is based on one functionality, which you are incorrect
about. UNIX has had IPCs for as long as Micros**t has been around (and
when it originally sold UNIX). They are as powerful, if not more, than
COM systems, depending on how you use them.

Tooltalk and other middleware systems have existed on UNIX systems for
most of this decade, and many applications use them. Tooltalk and
Softbench are the grandparents of everything you are stating makes the
Windows platform ahead of UNIX, and they are UNIX creations from before
Window NT existed.

I won't get into my thoughts on CORBA.

: When I can install a Linux distribution and use the same ORB to talk to


: Gnome apps, KDE apps, Netscape and Apache then I will feel that at least
: that variant of Unix will have caught up in this regard.

There are often better mechanisms in the systems than to use ORBs and
the like. The applications usually use them. It's not that UNIX is
"behind," it's that UNIX apps utilize the system.. just as Windows apps
utilize that system's components (and that the Windows systems isn't as
"open" as UNIX).

From most of what I have worked with of all the M$ line (which is all
except Win98), those systems (OS and apps) are behind. But this isn't
a troll.

Paul, you like Windows; we've all learned that. But to state that UNIX
is behind simply because you believe that all apps should use one
functionality isn't going to make your point.

-Arcege


Paul Prescod

unread,
May 29, 1999, 3:00:00 AM5/29/99
to
"Michael P. Reilly" wrote:
>
> Your conclusion is based on one functionality, which you are incorrect
> about. UNIX has had IPCs for as long as Micros**t has been around (and
> when it originally sold UNIX). They are as powerful, if not more, than
> COM systems, depending on how you use them.

If you are particular perverse you could implement object protocols on top
of stream IPCs but the reverse is much easier. I conclude that object
protocols are more powerful. Do you have counter evidence?

> Tooltalk and other middleware systems have existed on UNIX systems for
> most of this decade, and many applications use them. Tooltalk and
> Softbench are the grandparents of everything you are stating makes the
> Windows platform ahead of UNIX, and they are UNIX creations from before
> Window NT existed.

So you are saying that Unix was ahead in this regard 15 years ago. Is that
relevant?

> There are often better mechanisms in the systems than to use ORBs and
> the like. The applications usually use them.

Okay, so I'm a Python programmer on Windows versus Unix. On Windows I
communicate with my favorite structured editor (which happens not to be a
Microsoft product) through a well-defined protocol implemented in a Python
library. I can do sophisticated queries and navigations through my
document structure using COM. I can compare object references, iterate
over lists of application objects, modify the document structure etc.

Now I have a similar app on UNIX. Are you really going to claim that
tooltalk and stream IPC is going to give me the same functionality? If so,
you should go tell the creators of all of the Linux Office packages
because none of them are using ToolTalk and they are choosing CORBA over
IPC for all main functionality.

> It's not that UNIX is "behind,"

I didn't say that UNIX is behind in general. I said that UNIX had a
weakness in this area. If you would put away the anti-Microsoft chip on
your shoulder you could recognize that, encourage the UNIX community to
fix the problem and we would all be better off.

> Paul, you like Windows; we've all learned that. But to state that UNIX
> is behind simply because you believe that all apps should use one
> functionality isn't going to make your point.

If my point was "Windows is better" then you would be right. But it isn't
my point and it isn't the truth. My point is that Windows is more
functional *in this area*. Is it so hard to admit that there is something
that Redmond could teach Berkley (or Finland)?

If you don't like CORBA (and many people don't) then lets start talking
about what we can make that does the same job better in a cross-platform
way. Surely that's better than pretending a problem doesn't exist just
because the admission would hurt our pride.

Gang Li

unread,
May 30, 1999, 3:00:00 AM5/30/99
to

Graham Matthews wrote in message <7ik6mi$lbk$1...@cronkite.cc.uga.edu>...

>I read the following interesting snippet at
>
> http://www.python.org/workshops/1997-10/proceedings/hugunin.html
>
>>6.2. Python in Java's Advantages
>>
>>Using Java as the underlying systems language for Python has a number of
>>advantages over the current implementation of Python in C. First and
>>foremost of these in my mind is the opportunity to ride the Java
>>popularity wave and let Python code run everywhere there's a Java VM.
>>It also makes the rich set of portable Java API's available from within
>>Python.


Python is a real programming language. We should not turn it in to a Java
extension.
I hate someone just want to take Python to Java mass and say 'me too'.
Perl, Tcl/Tk,
and Smalltalk have no plan to turn themselves in to a Java extension. Why
Python? If
you love Jave to death, spent all your time to help sun conquer the world.
Don't mess
with Python.

JPython is good enough for Java lover to play with. But Java is not and
will never be
the only universal programming language. Python will live well and better
without Java.

Gang Li
gan...@msn.com

Paul Moore

unread,
May 30, 1999, 3:00:00 AM5/30/99
to
On Sat, 29 May 1999 14:00:58 GMT, Paul Prescod <pa...@prescod.net>
wrote:

>"Michael P. Reilly" wrote:
>> Paul, you like Windows; we've all learned that. But to state that UNIX
>> is behind simply because you believe that all apps should use one
>> functionality isn't going to make your point.
>
>If my point was "Windows is better" then you would be right. But it isn't
>my point and it isn't the truth. My point is that Windows is more
>functional *in this area*. Is it so hard to admit that there is something
>that Redmond could teach Berkley (or Finland)?

I've got to agree here, to a point.

I'm a Windows programmer because that's what I get paid for. I like
Unix - I've known Unix for far longer than I've known Windows, and I
generally prefer its philosophy over that of Windows. I hate buggy
Windows applications, and I hate under-documented closed source.

But Windows' use of COM/OLE/ActiveX *throughout* is a massive plus (in
concept - the implementation is, as usual, annoyingly buggy). Using
OLE, I can write "glue" scripts in any language I like (Perl, Python,
JavaScript, Visual Basic (God Forbid!), anything with an OLE
interface), to control almost anything (a partial list - E-Mail via
MAPI, Office applications like Excel or Word, XML via the IE5 DOM,
databases via ADO, the shell, ...) using an object-oriented model
(much more programmable than using pipes to send command scripts to
applications). It hides the difficulty involved in having proprietary
application data formats and interfaces, which is a bad thing, but
that problem existed before OLE, so we can't blame OLE for that.

Anyway, my point is that pervasive use of a technology like COM is a
big plus for Windows.

Unix would gain a lot if it took that lesson, and implemented it in
the way Unix does best (ie, implemented it *well*). Maybe CORBA is the
way to do this, and maybe not. But it needs to be done.

On a similar point, Unix's biggest downside is that having so much
choice at all levels (even the shell and window manager) tends to work
against implementation of a common infrastructure like this. A pity,
because the choice is my favourite thing in Unix...!

I repeat - I'm a Unix fan rather than a Windows. I just wish that Unix
users would not be so anti-Windows that they miss the (occasional)
good ideas.

We're well off-topic now, so I'll shut up.

Paul.

Peter A. Koren

unread,
May 30, 1999, 3:00:00 AM5/30/99
to
Paul Moore wrote:
>
> ...snip

> Anyway, my point is that pervasive use of a technology like COM is a
> big plus for Windows.
>
> Unix would gain a lot if it took that lesson, and implemented it in
> the way Unix does best (ie, implemented it *well*). Maybe CORBA is the
> way to do this, and maybe not. But it needs to be done.
>
> On a similar point, Unix's biggest downside is that having so much
> choice at all levels (even the shell and window manager) tends to work
> against implementation of a common infrastructure like this. A pity,
> because the choice is my favourite thing in Unix...!
>
> I repeat - I'm a Unix fan rather than a Windows. I just wish that Unix
> users would not be so anti-Windows that they miss the (occasional)
> good ideas.
>

Take a look at the GNOME project. It is more than just a pretty desktop.
It may well be a unifying project for all of the Unix world, bringing
with it a component architecture based on CORBA as the main IPC
mechanism. The GNOME development environment is also designed to be
language neutral. You choose the development language.

The real success of Gnome will come when developers take advantage of
Corba to leverage the resources of others in their own
programs/components/pluggins.


Just my $0.02,

Peter Koren

Darrell

unread,
May 30, 1999, 3:00:00 AM5/30/99
to
> Take a look at the GNOME project. It is more than just a pretty desktop.
> It may well be a unifying project for all of the Unix world, bringing
> with it a component architecture based on CORBA as the main IPC
> mechanism. The GNOME development environment is also designed to be
> language neutral. You choose the development language.
>
> The real success of Gnome will come when developers take advantage of
> Corba to leverage the resources of others in their own
> programs/components/pluggins.
>

I concur with using something like Corba as a parallel to COM.
And that standardized distributed computing is a powerful concept.
Check out QNX where it's fast and transparent.

Yet my gut evaluation says Gnome can be quite slow.
I'm tempted to blame this on Corba.

Has anyone else noticed that Gnome is slow and can Corba be
blamed in part for that ? Is Corba generally slower than COM ?
Does any of this matter ?

Also does an open source bridge exist between Corba and COM ?
Picture a Corba/COM component that lives in UNIX and is
callable from Windows. Sort of takes the hot air out of arguments to use
NT servers.

Thanks.
Darrell

James Logajan

unread,
May 30, 1999, 3:00:00 AM5/30/99
to
Darrell wrote:
> Yet my gut evaluation says Gnome can be quite slow.
> I'm tempted to blame this on Corba.

I'm not familiar with Gnome; whose Corba software do they use?

> Has anyone else noticed that Gnome is slow and can Corba be
> blamed in part for that ? Is Corba generally slower than COM ?
> Does any of this matter ?

Don't know about what is possible theoretically with COM or CORBA,
speed-wise. But at least one free version of CORBA for C++ can optimize a
CORBA call into a simple function call; see
http://siesta.cs.wustl.edu/~schmidt/TAO.html

CORBA has the added advantage that unlike COM, it was always intended to be
platform and language neutral. Given an IDL published for one's favorite
app, I should TODAY be able to build a cooperating app in almost any
language I want. And luckily that includes Python as well as C++.

> Also does an open source bridge exist between Corba and COM ?
> Picture a Corba/COM component that lives in UNIX and is
> callable from Windows. Sort of takes the hot air out of arguments to use
> NT servers.

Good question and good point.

Gordon McMillan

unread,
May 30, 1999, 3:00:00 AM5/30/99
to James Logajan, pytho...@python.org
James Logajan wrote:

> Don't know about what is possible theoretically with COM or CORBA,
> speed-wise. But at least one free version of CORBA for C++ can
> optimize a CORBA call into a simple function call; see
> http://siesta.cs.wustl.edu/~schmidt/TAO.html

In theory, they should be pretty close. An in-process COM call (not
IDispatch) is the equivalent of a virtual function call. For both
systems, the major work of an interprocess call is in marshalling
parameters.

> CORBA has the added advantage that unlike COM, it was always
> intended to be platform and language neutral. Given an IDL published
> for one's favorite app, I should TODAY be able to build a
> cooperating app in almost any language I want. And luckily that
> includes Python as well as C++.

COM is certainly language neutral. The core of it is exposing a C++
virtual function table in C. That part is theoretically also platform
neutral, despite practice.

Both COM and CORBA have 2 ways of being used - statically and
dynamically. I've never seen the dynamic side of CORBA used,
(although I'm sure it is, somewhere). In COM, it is what is most
frequently used. Unfortunately, this side of COM was "engineered"
<hack, cough> by the VB folks, who probably wouldn't know an
architect if he bit them on the *ss (personally, I'd use a pack of
rabid Dobermans).

I don't think there's much question that CORBA has the more complete
(and elegant) architecture. But COM is distributed with the OS; and
the most used feature of COM (Automation) has been around almost 10
years, while CORBAs (far more complete) equivalent (OpenDoc) was
DOA.

nobody-drives-a-Tucker-either-ly y'rs

- Gordon

Markus Stenberg

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
"Darrell" <ne...@dorb.com> writes:
> Yet my gut evaluation says Gnome can be quite slow.
> I'm tempted to blame this on Corba.

Oh? I've played with vanilla-RH6.0 and gnome stuff it had, and it seemed
fairly decent. (Disclaimer: I hate GUI stuff in general, though, so no
Gnome in real use)

> Has anyone else noticed that Gnome is slow and can Corba be
> blamed in part for that ? Is Corba generally slower than COM ?
> Does any of this matter ?

CORBA is about as fast as COM, protocol-wise I think it is even slightly
faster (much less action behind the scenes), _but_ many implementations
suck.

> Also does an open source bridge exist between Corba and COM ?
> Picture a Corba/COM component that lives in UNIX and is
> callable from Windows. Sort of takes the hot air out of arguments to use
> NT servers.

At least M$ brags in their whitepapers that DCOM can access CORBA via some
bridges (available where? I know not), so I suppose such a beast exists.

-Markus

Yukihiro Matsumoto

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Vadim Chugunov <ch...@my-deja.com> writes:

|Personally I would hate it, if Python had ever adopted a garbage
|collection without keeping a reference counting.
|As many people have noted before, you would not be able to use
|destructors to free up resources like memory or file descriptors.

I don't get it. There's no relation between destructors and real
garbage collection. For example, Java uses destructors called
finalizers, even though most Java VM use real GC.

I hate ref counting. It is memory-leak prone, does not reclaim cyclic
data without explicit cycle-cut. I know, by ref counting, object is
recycled as soon as it looses last reference to it, but relying on
that behavior is error prone, I think.

matz.

Markus Stenberg

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
James Logajan <Jam...@Lugoj.Com> writes:

> Darrell wrote:
> > Yet my gut evaluation says Gnome can be quite slow.
> > I'm tempted to blame this on Corba.
> I'm not familiar with Gnome; whose Corba software do they use?

New one, being developed by RH and friends (ORBit),

> > Also does an open source bridge exist between Corba and COM ?
> > Picture a Corba/COM component that lives in UNIX and is
> > callable from Windows. Sort of takes the hot air out of arguments to use
> > NT servers.

> Good question and good point.

I haven't heard good arguments why to use NT servers so far (except two,
obviously: lack of management clue (=NT <-> moderately easy to set up) and
image of NT being 'cheap' server solution)

-Markus

--
Running Windows on a Pentium is like having a brand new Porsche but
only be able to drive backwards with the handbrake on.
(Unknown source)

Graham Matthews

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Graham Matthews wrote in message <7ik6mi$lbk$1...@cronkite.cc.uga.edu>...
>>Using Java as the underlying systems language for Python has a number of
>>advantages over the current implementation of Python in C. First and
>>foremost of these in my mind is the opportunity to ride the Java
>>popularity wave and let Python code run everywhere there's a Java VM.
>>It also makes the rich set of portable Java API's available from within
>>Python.
Gang Li (gan...@msn.com) wrote:
: Python is a real programming language. We should not turn it in to a Java

: extension. I hate someone just want to take Python to Java mass and say 'me
: too'. Perl, Tcl/Tk, and Smalltalk have no plan to turn themselves in to a
: Java extension. Why Python? If you love Jave to death, spent all your
: time to help sun conquer the world. Don't mess with Python.

You are envangelising (a not uncommon response when someone remotely
criticises Python). Stop evangelising and start considering the technical
issues involve (read (!) other posts for what those issues are).

graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown

Paul Prescod

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Yukihiro Matsumoto wrote:
>

First you say:


> I don't get it. There's no relation between destructors and real
> garbage collection. For example, Java uses destructors called
> finalizers, even though most Java VM use real GC.

But then you say:


> I know, by ref counting, object is
> recycled as soon as it looses last reference to it, but relying on
> that behavior is error prone, I think.

So you do get it. There is a relation, but you just don't think that the
"Python way" is right, You consider the guarantees that Java gives to be
more important than the guarantees that Python does.

But note that Python's guarantees are more important in small, simple
programs and Java's guarantees are better for large, complex programs with
complicated data structures.

http://www.quoininc.com/quoininc/Design_Java0197.html

But I think that the bigger problem with "real GC" is that C programs
often hang on to references to Python objects and any kind of compacting
GC would invalidate those references.

Raymond G. Beausoleil

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
On 27 May 1999 19:33:38 GMT, gra...@sloth.math.uga.edu (Graham Matthews) wrote:
> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the

> ability to write statically typed code (just write that part in Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?

Although I have not followed the recent evolution of Java very carefully, I have strong misgivings
about the compromises made in the numerical core of Java. For details, I recommend a quick
review of William Kahan's presentation on this topic:

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

I'm new to Python, but I'm very excited about NumPy and PIL, and I wonder what compromises
would have to made to these extensions if Python were rewritten in Java?

============================
Ray Beausoleil
Hewlett-Packard Laboratories
mailto:bea...@hpl.hp.com
============================


Martijn Faassen

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Graham Matthews wrote:

> Gang Li (gan...@msn.com) wrote:
> : Python is a real programming language. We should not turn it in to a Java
> : extension. I hate someone just want to take Python to Java mass and say 'me
> : too'. Perl, Tcl/Tk, and Smalltalk have no plan to turn themselves in to a
> : Java extension. Why Python? If you love Jave to death, spent all your
> : time to help sun conquer the world. Don't mess with Python.
>
> You are envangelising (a not uncommon response when someone remotely
> criticises Python). Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues are).

While the argument you quote has evangelical overtones, it is not *only*
that. There's a real strategic issue involved here -- should one tie
ones destiny to Java. Leveraging Java has a number of strategical and
technical advantages, which you mention. It also has possible
strategical disadvantages:

* Java is right now tied to a single company. It is not (yet) an open
standard.

* Python people do not have a lot of control/influence over the
direction in which the JVM will develop.

* Positioning Python as something on top of the JVM might give people
the idea that it is not really something you can use stand-alone. It can
give people the impression of a 'Java extension'. 'why not just use Java
proper?'

* I believe there are open source JVMs, but are there Python license
JVMs? The whole licensing issue.

These possible disadvantages need a good answer, even we evil
evangelistic people state them in an evangelistic context. :)

Regards,

Martijn

Vadim Chugunov

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
> I don't get it. There's no relation between destructors and real
> garbage collection. For example, Java uses destructors called
> finalizers, even though most Java VM use real GC.

Right, but java finalizers will not be called till the moment the memory is
collected.
Depending on the GC configuration and the program's memory consumption this
may be quite a while.

> I hate ref counting. It is memory-leak prone, does not reclaim cyclic

> data without explicit cycle-cut. I know, by ref counting, object is


> recycled as soon as it looses last reference to it, but relying on
> that behavior is error prone, I think.

Can you explain exactly why is it more error prone?
If something can be done automatically, without writing explicit
deallocation code,
why can't we let it be that way?

I think it all comes to the fact, that some people value the predictability
of the destructor calls over
the ability to reclaim cyclic references, while others feel the other way
round.

OK, I'll try to propose something constructive. Maybe we need an object
protocol, that would enumerate
all references held by an object ? Writing a portable GC would be then much
easier.

Vadim


Peter A. Koren

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
"Raymond G. Beausoleil" wrote:
>
> Although I have not followed the recent evolution of Java very carefully, I have strong misgivings
> about the compromises made in the numerical core of Java. For details, I recommend a quick
> review of William Kahan's presentation on this topic:
>
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> I'm new to Python, but I'm very excited about NumPy and PIL, and I wonder what compromises
> would have to made to these extensions if Python were rewritten in Java?
>

Has Sun done anything about Kahan's objections? This is indeed a serious
matter. A huge percentage of the statistically based studies prior to
the works of Wilkinson and later, Lawson and Hanson, was garbage,
because of poor numerics. This is a show stopper issue for Java in
science and engineering.

If Java does not change, it should be rejected. Too bad. I am a Linux
junkie and would love to see a reformed Java win and Microsoft lose.

I too am thrilled by NumPy, PIL and the other scientific packages that
Hugunin, Hinsen, and Andrich have cooked up and/or packaged. The user
community is as important as the language and Python is rich in both
respects.

--Regards,

Peter Koren

Vadim Chugunov

unread,
May 31, 1999, 3:00:00 AM5/31/99
to

> Remember the original statement is like this:

>
> >As many people have noted before, you would not be able to use
> >destructors to free up resources like memory or file descriptors.
>
>which, as I understand, means destructors can not be used with real
>GC. That's just not true.

I'm sorry for being unclear, but the key words here were: "to free up
resources".
And I meant "to free up resources the moment I expect them to", not "some time
later".

BTW, this is a common expectation from anyone coming from a C++ background.
In C++, deallocation in destructors is the only way you can use exceptions
without leaking resources.

Vadim


Darrell

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Markus Stenberg <mste...@cc.Helsinki.FI> wrote in message
news:al8pv3i...@kruuna.Helsinki.FI...

>
> CORBA is about as fast as COM, protocol-wise I think it is even slightly
> faster (much less action behind the scenes), _but_ many implementations
> suck.
>
I hope (ORBit) becomes a good one.

> > Also does an open source bridge exist between Corba and COM ?
> > Picture a Corba/COM component that lives in UNIX and is
> > callable from Windows. Sort of takes the hot air out of arguments to use
> > NT servers.
>

> At least M$ brags in their whitepapers that DCOM can access CORBA via some
> bridges (available where? I know not), so I suppose such a beast exists.
>

Wonder if a killer app for python might be to provide scripting on both
sides, DCOM and CORBA.
I have users that run a windows desktop to control Solaris applications.
Currently the NT forces are
winning with the idea of dumping the huge Sun boxes in favor or NT. Of
course everything will be
written in Java ....

This isn't a pressing problem for us yet, but I worry.

--Darrell


Mark Hammond

unread,
May 31, 1999, 3:00:00 AM5/31/99
to
Markus Stenberg wrote in message ...

>> Also does an open source bridge exist between Corba and COM ?
>> Picture a Corba/COM component that lives in UNIX and is
>> callable from Windows. Sort of takes the hot air out of arguments to use
>> NT servers.
>
>At least M$ brags in their whitepapers that DCOM can access CORBA via some
>bridges (available where? I know not), so I suppose such a beast exists.

These tend to cost $$$, as MS typically licenses the technology to 3rd
parties, and you must buy it off them. AFAIK, all COM implementation on
*nix work this way.

OTOH, Python itself would seem an excellent bridge. It has great COM
support, and although I have never seen or used the ILU support, it too is
rumoured to be pretty good :-)

May be an excellent opportunity for someone...

Mark.


Stidolph, David

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
>OK, I'll try to propose something constructive. Maybe we need an object
>protocol, that would enumerate
>all references held by an object ? Writing a portable GC would be then
much
>easier.

Sounds good to me for debugging. A call that could return a list of
everything that holds a reference to an object - that would be cool!

list = GetReferences(object)
print 'List of referencest to',object
for item in list:
print 'item:',item

Anybody know of a current way to do this?

Yukihiro Matsumoto

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Paul Prescod <pa...@prescod.net> writes:

|First you say:


|> I don't get it. There's no relation between destructors and real
|> garbage collection. For example, Java uses destructors called
|> finalizers, even though most Java VM use real GC.
|

|But then you say:


|> I know, by ref counting, object is
|> recycled as soon as it looses last reference to it, but relying on
|> that behavior is error prone, I think.
|

|So you do get it. There is a relation, but you just don't think that the
|"Python way" is right, You consider the guarantees that Java gives to be
|more important than the guarantees that Python does.

Hmm, I said ``there's no relation between destructors and real GC'',
then said ``deterministic destructor invocation is not needed''.

Even though I believe Java garantees is far more important than Python
garantees as you said, that's nothing do with ``relation between
destructors and real GC''.

Remember the original statement is like this:

>As many people have noted before, you would not be able to use
>destructors to free up resources like memory or file descriptors.

which, as I understand, means destructors can not be used with real
GC. That's just not true.

|But I think that the bigger problem with "real GC" is that C programs


|often hang on to references to Python objects and any kind of compacting
|GC would invalidate those references.

It's the common legend especially here in comp.lang.python.

From my experience with Scheme and Ruby, both with real GC, the real
GC is mostly very fast. Fast enough no one notices its "hang" on most
cases. The legend was formed up by old GC implementation and slower
machines of the past, I guess.

|But note that Python's guarantees are more important in small, simple
|programs and Java's guarantees are better for large, complex programs with
|complicated data structures.

Do you really mean Python the object-oriented programming language
rarely treat complicated data structures? I think Python is good
language, good enough to make people write complex program with
complicated data structures.

I admit ref-counting is far easier to implement. But it's too simple
way for the real language like Python.

|http://www.quoininc.com/quoininc/Design_Java0197.html

This document says ``the real GC with the finalizers do the most of
the jobs'', right?

matz.

Paul Prescod

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Yukihiro Matsumoto wrote:
>
> >As many people have noted before, you would not be able to use
> >destructors to free up resources like memory or file descriptors.
>
> which, as I understand, means destructors can not be used with real
> GC. That's just not true.

Is there a language with real GC where destructors are called as
predictably as they are in Python?

> |But I think that the bigger problem with "real GC" is that C programs
> |often hang on to references to Python objects and any kind of compacting
> |GC would invalidate those references.
>
> It's the common legend especially here in comp.lang.python.
>
> >From my experience with Scheme and Ruby, both with real GC, the real
> GC is mostly very fast.

Speed wasn't my concern. I asked about references in C code. Do we use
PyObject **s instead of PyObject *s now?

> |But note that Python's guarantees are more important in small, simple
> |programs and Java's guarantees are better for large, complex programs with
> |complicated data structures.
>
> Do you really mean Python the object-oriented programming language
> rarely treat complicated data structures?

No, I said that Python is optimized for basic users, not for the experts.
The experts can figure out how to work around problems. The beginning
users cannot. "I'm opening all of the files in a directory in a loop and
in large directories I get out of file handle errors."

--
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco

"Silence," wrote Melville, "is the only Voice of God." The assertion,
like its subject, cuts both ways, negating and affirming, implying both
absence and presence, offering us a choice; it's a line that the Society
of American Atheists could put on its letterhead and the Society of
Friends could silently endorse while waiting to be moved by the spirit
to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's

Yukihiro Matsumoto

unread,
Jun 1, 1999, 3:00:00 AM6/1/99