Python 2.0

4807 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
to
Hi.

"Vadim Chugunov" <che...@yahoo.com> writes:

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

Well, OK. I understand now. Now only thing I can say is, why do you
emphasize so much on reclaiming object at the time you exepcted?
Because of your C++ background?

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

Yes, but it's not true for HIGHER languages like Python or Java (or Ruby).

matz.

Yukihiro Matsumoto

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Hi.

Paul Prescod <pa...@prescod.net> writes:

|> >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?

I said nothing about the destructor invocation predictability.

I don't understand and really interested in why you guys require
to predict destructor invocation so much, but it's another story.

|> >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?

Sorry, I don't understand. Do we have to use PyObject **s instead of
PyObject *s, if we choose real GC?

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

First, it's not the straight result from real GC. For exapmle, Ruby
uses real GC, and starts GC automatically on that situation. No
problem arise. It's totally a implementation matter.

Second, do you think that optimization for basic users compensates the
risk of potential memory leak, by cyclic structures or missing DECREF
in extension modules? Do you mean it's easy for experts to find
cyclic structure and cut their reference to destruct? For me, it's
not. I hate that. Is this because I'm not a Python expert?

matz.

Fredrik Lundh

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Graham Matthews <gra...@sloth.math.uga.edu> 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).

read his message again. he's saying that Python
shouldn't be tied to Java. sure looks like a tech-
nical argument to me.

if you want some numbers to support his argument,
take a look at GvR's Python poll from the latest
python conference:
http://www.foretec.com/python/workshops/1998-11/polls.html

10% of the audience used JPython today, for non-web
applications. about the same amount used COM.

in other words, proposals to make Python dependent on
Java should be treated about as seriously as proposals to
make Python dependent on COM. they're both available
on all major platforms (at least if you ignore those you
don't happen to use). and they're both supported by
many other tools (at least if you ignore those I don't
happen to use). etc.

> Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues
> are).

exactly. and since you seem to imply that you have con-
sidered those issues, maybe you should follow up on some
of the "non-envangelising" posts instead of miscrediting
people who don't happen to agree with you?

</F>


Paul Boddie

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Yukihiro Matsumoto wrote:
>
> "Vadim Chugunov" <che...@yahoo.com> writes:

[...]

> |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".
>
> Well, OK. I understand now. Now only thing I can say is, why do you
> emphasize so much on reclaiming object at the time you exepcted?

Because, and I have seen this happen in real-life situations, there's no
guarantee that as the last reference to an object is released all the resources
associated with that object are going to be released at that time. Now, if one
has some kind of object containing a reference to a socket object (for
simplicity let us say that this is a basic resource), then it means that the
socket may for an indefinite amount of time be floating around in a reserved,
but unusable state. Now, if the garbage collector doesn't get around to this
object before one instantiates more of them it is possible that one runs out of
resources: too many sockets in use.

As has been discussed before on this newsgroup/list, such resources get
overlooked in many a garbage collection scheme. I'm sure a perusal of various
news/list archives would provide a substantial amount of relevant literature.

> Because of your C++ background?

It is amusing to note that in (probably most implementations of) Java one has to
write code as one would in C++ in situations like that outlined above, using
explicit destructor-like "close" methods on all resource objects. It isn't
sufficient to let the last reference slip away through one's fingers with a
happy feeling. ;-)

> |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.
>
> Yes, but it's not true for HIGHER languages like Python or Java (or Ruby).

Absolutely, as far as memory is concerned, but for resources there is a kind of
temporary "resource leak" which is critical, and about which the collector
doesn't apparently care.

Paul

Michael Hudson

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
"Stidolph, David" <stid...@origin.ea.com> writes:

If you recompile Python with Py_TRACE_REFS defined, then the sys
module sprouts a "getobjects" function that returns a list of all
objects in existence. This could probably be used to implement
something like this. It would be veeeeery slow, I suspect.

I've never resorted to this approach, tending always to make cyclic
references go away be staring at them very, very hard.

I'm not sure this is at all what is being asked for, but it seems kind
of relavent.

Yours,
Michael

Hisao Suzuki

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
In article <7iv86a$i...@news.dns.microsoft.com>,

"Vadim Chugunov" <che...@yahoo.com> wrote:
> 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.

You are right. The JLS (Java Language Specification) says:
The Java language does not specify how soon a finalizer
will be invoked, except to say that it will happen before
the storage for the object is reused. (sect.12.6)

In fact, there is no guarantee that all garbages will be reused,
up to their last one byte, within the life time of the java
process, and there is also no guarantee that ALL finalizers will
be eventually invoked. It is an issue of the quality of JVM
implementation, you know.

> 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?

Perhaps it is safe to say that destructors with real GC are more
error prone. (The present Python is safer in this respect!)

In general, real GC simulates infinite memory virtually, and one
should not rely on finalizers; objects remain virtually forever.
With real GC, finalizers should be used only as the last resort.

BTW, Mr. Matz has invented and implemented his excellent
language, Ruby, which is a sort of Perl's successor with some
intrinsic object-oriented features. IMHO, we must have respect
for his opinion as such or, at the very least, as the evangelist
of his own language. See http://www.netlab.co.jp/ruby/

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzu...@okisoft.co.jp, suz...@acm.org.

Paul Prescod

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Dennis Lee Bieber wrote:
>
> Ever seen the Amiga variant of REXX? AREXX had a very simple
> interface to compatible applications (compatible meaning that the
> application creates an "AREXX message port"). In (A)REXX, a statement
> line that is not recognized as part of the language itself is sent to
> the current "command interpreter" -- default is the command shell, but
> it can just as easily be an application (ADDRESS
> <application-port-name>).

That's all cool, but on Windows you get to choose your scripting language
which, for Python users, is even cooler. Still, I take your point that
AREXX was years ahead of Windows. And AREXX was ripped off of mainframe
REXX which was, of course, even older.

Paul Prescod

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Yukihiro Matsumoto wrote:
>
> |Is there a language with real GC where destructors are called as
> |predictably as they are in Python?
>
> I said nothing about the destructor invocation predictability.

I consider that a part of the definition of destructor.

> I don't understand and really interested in why you guys require
> to predict destructor invocation so much, but it's another story.

What if I am holding GUI "device context" objects and the GUI has a
limited number of them. I don't think that there is a way to tell the GC
that there is a limited number of them. It doesn't know that device
contexts are a limited resource, just as memory is.

> |Speed wasn't my concern. I asked about references in C code. Do we use
> |PyObject **s instead of PyObject *s now?
>
> Sorry, I don't understand. Do we have to use PyObject **s instead of
> PyObject *s, if we choose real GC?

Imagine I have some C code. It stores away a pointer to a Python object:

PyObject *myObject=someObject;

Now a compacting GC moves someObject. My pointer is out of date, right? If
I want to be able to move someObject around in a mark and sweep style
operation then I need the pointer I hold to be static.

What GC algorithm does Ruby use and how much overhead does it add?

> Second, do you think that optimization for basic users compensates the
> risk of potential memory leak, by cyclic structures or missing DECREF
> in extension modules? Do you mean it's easy for experts to find
> cyclic structure and cut their reference to destruct? For me, it's
> not. I hate that. Is this because I'm not a Python expert?

It's pretty much a toss-up for me. In general I prefer optimizations that
make the language easy for new users to those that are for complex, long
running programs but full garbage collection would make complex programs a
fair bit easier.

Graham Matthews

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Paul Prescod (pa...@prescod.net) wrote:
: 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.

You have two classes of references, compactable and non-compactable.
That solves that little problem.

graham
--
This mountain is not visible from any inhabitable place.
It has no name, and since it's discovery in 1856 by a
British survey team, it has mysteriously resisted every
attempt to name it. The mountain is known simply and starkly
by it's original designation on the surveyor's map ... K2.

Graham Matthews

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Paul Boddie (pa...@infercor.no) wrote:
: As has been discussed before on this newsgroup/list, such resources get

: overlooked in many a garbage collection scheme. I'm sure a perusal of various
----
: news/list archives would provide a substantial amount of relevant literature.

That word "many" is your key Paul. Just because many a garbage collection
scheme works that way doesn't mean all do, or all have to. It's entirely
an implementation dependent thing.

You are creating a strawman argument that GC cannot properly free resources
like files. But some GC do just that so what is your point?

Stidolph, David

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
Py_TRACE_REFS seems to be defined if Py_DEBUG is defined.

I cannot find a "getobjects" or any other similar function in the source
code or docs. I am using the Win32 version 1.5.2.

Any help would be appreciated,

David Stidolph.

Graham Matthews

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
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.
Graham Matthews <gra...@sloth.math.uga.edu> wrote:
> You are envangelising (a not uncommon response when someone remotely
> criticises Python).
Fredrik Lundh (fre...@pythonware.com) wrote:
: read his message again. he's saying that Python

: shouldn't be tied to Java. sure looks like a tech-
: nical argument to me.

I suggest you read his post again Fredrik. The only "reasons" he offers
for why Python shouldn't be "tied to Java" are all hyperbole and
evangelism. No technical content whatsoever.

Graham Matthews <gra...@sloth.math.uga.edu> wrote:
> Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues
> are).

Fredrik Lundh (fre...@pythonware.com) wrote:
: exactly. and since you seem to imply that you have con-


: sidered those issues, maybe you should follow up on some
: of the "non-envangelising" posts instead of miscrediting
: people who don't happen to agree with you?

I have followed up Fredrik -- cf. posts on classes of references (some
compactable, some not), colouring mark and sweep collectors, JNI, etc.
But then again I should have known better than to start such a thread.

Michael Hudson

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
On Tue, 1 Jun 1999, Stidolph, David wrote:
> Py_TRACE_REFS seems to be defined if Py_DEBUG is defined.
>
> I cannot find a "getobjects" or any other similar function in the source
> code or docs. I am using the Win32 version 1.5.2.

Well, Python/sysmodule.c in the source contains this:

static PyMethodDef sys_methods[] = {
/* Might as well keep this in alphabetic order */
{"exc_info", sys_exc_info, 0, exc_info_doc},
{"exit", sys_exit, 0, exit_doc},
#ifdef COUNT_ALLOCS
{"getcounts", sys_getcounts, 0},
#endif
#ifdef DYNAMIC_EXECUTION_PROFILE
{"getdxp", _Py_GetDXProfile, 1},
#endif
#ifdef Py_TRACE_REFS
{"getobjects", _Py_GetObjects, 1},
#endif
{"getrefcount", sys_getrefcount, 0, getrefcount_doc},
#ifdef USE_MALLOPT
{"mdebug", sys_mdebug, 0},
#endif
{"setcheckinterval", sys_setcheckinterval, 1,
setcheckinterval_doc},
{"setprofile", sys_setprofile, 0, setprofile_doc},
{"settrace", sys_settrace, 0, settrace_doc},
{NULL, NULL} /* sentinel */
};

and this:

#ifdef Py_TRACE_REFS
/* Defined in objects.c because it uses static globals if that file */
extern PyObject *_Py_GetObjects Py_PROTO((PyObject *, PyObject *));
#endif

and Objects/object.c contains:

PyObject *
_Py_GetObjects(self, args)
PyObject *self;
PyObject *args;
{
...

This is all on Linux, but the source is the source, as I understand it. I
mean the C source, not the Python Library source... I'd hoped that was
obvious.

I doubt it is documented anywhere - a quick grep through the docs finds
nowt, though Doc/api/api.tex contains the line:

XXX Explain Py_DEBUG, Py_TRACE_REFS, Py_REF_DEBUG.

I'd heard about it sometime on the newsgroup.

> Any help would be appreciated,

If this is what you were looking for, you're welcome.

Michael

Aahz Maruch

unread,
Jun 1, 1999, 3:00:00 AM6/1/99
to
In article <87k8toq...@ev.netlab.co.jp>,

Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
>
>Well, OK. I understand now. Now only thing I can say is, why do you
>emphasize so much on reclaiming object at the time you exepcted?
>Because of your C++ background?

In addition to Paul's excellent comments, if one is writing an
interactive process, one cannot afford the unpredictability of random
garbage collection. Garbage collection could run in a thread, but then
one is restricted to environments where threads are well-supported.
--
--- Aahz (@netcom.com)

Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het

"NRE is a lot like cocaine. Feels great while you're on it, makes you
feel very special and talented, and you become highly annoying to those
who aren't on it." -- Stef

Amit Patel

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