Python 2.0

[A.M. Kuchling]

Spam detection software, running on the system "albatross.python.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: Michael P. Reilly writes: > 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). [...]

Content analysis details: (10.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[207.172.52.51 listed in zen.spamhaus.org]
4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr
2)
0.5 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
1.6 TVD_RCVD_IP TVD_RCVD_IP
2.0 FH_DATE_IS_19XX The date is not 19xx.
1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[207.172.52.51 listed in dnsbl.sorbs.net]
0.1 RDNS_DYNAMIC Delivered to trusted network by host with
dynamic-looking rDNS


-------------- next part --------------
An embedded message was scrubbed...
From: "A.M. Kuchling" <amk1 at erols.com>
Subject: Re: Python 2.0
Date: Sat, 29 May 1999 22:34:37 -0400
Size: 2083
URL: <http://mail.python.org/pipermail/python-list/attachments/19990529/fc2ffd4c/attachment.mht>

[Graham Matthews]

Graham Matthews:
: > true compilation, the
Vadim Chugunov (chega at 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 (chega at 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 (chega at 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 (chega at 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 ...

graham

[Helge Hess]

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

[Graham Matthews]

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

[Graham Matthews]

Michael P. Reilly (arcege at 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

[Jeremy Hylton]

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

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

That sounds like a good way to answer the question, because it allows
for any easy answer :-). I think it's safe to say that there is
absolutely no consideration given to abandoning CPython in favor of
JPython. Both versions will exist through Python 2.0.

The investment in C-based code and C programming expertise is large;
and it is unreasonable to expect that all that code and all those
people will be replaced by Java programs and programmers. Nor is it
likely that all that existing C code will be easily integrated into a
JVM via some Java native code interface. So there is going to
continue to be a need for CPython.

Jeremy

[Jeff Bauer]

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

[Graham Matthews]

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

What about Swing?

graham

[Michael P. Reilly]

Graham Matthews <graham at sloth.math.uga.edu> wrote:
: Hans Nowak (ivnowa at 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

[Hans Nowak]

Post by Graham Matthews
: (And, for a working graphical implementation, one would need, say,
: Java, Python and Tkinter...)
What about Swing?

Sorry, I don't dance. :)

--Hans Nowak (ivnowa at hvision.nl)
Homepage: http://fly.to/zephyrfalcon

[Fred Pacquier]

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

[Barry A. Warsaw]

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.

GM> I was wondering if this is seriously being considered -- that
GM> is implementing Python 2.0 in Java rather than C.

It's been talked about, as has using C++ as the implementation
platform. All three (C, C++, Java) and any other more exotic ones you
can think of each bring in their own mix of benefits and problems.

IANAG, but if I had to guess I'd say Python2 will probably still be
implemented in C, with an outside chance that some parts may be C++
(e.g. built-in types -- this might resolve the types/class dichotomy),
and JPython will continue to exist side-by-side as a separate
implementation.

Two things to remember: at this point probably Guido doesn't even know
for sure, and Python2 is still years away. ;)

-Barry

[Graham Matthews]

Paul Moore (gustav at 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 (gustav at 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

[Hans Nowak]

Post by Graham Matthews
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
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 (ivnowa at hvision.nl)
Homepage: http://fly.to/zephyrfalcon

[Michael P. Reilly]

Hans Nowak <ivnowa at hvision.nl> wrote:

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

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

[Yukihiro Matsumoto]

Vadim Chugunov <chega at 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.

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

|In article <87pv3eorg4.fsf at ev.netlab.co.jp>,
|Yukihiro Matsumoto <matz at netlab.co.jp> wrote:
|> BTW, did I say Ruby can invoke arbitrary destructors specified by
|> arbitrary users? It can't.
|
|Is this your mental premise in your opinion about garbage
|collection? Then, the unpredictability might not be matter at
|all...

I was talking about real GC in general. I was saying real GC does not
fall into unpredictable automatically. As for Python, I agree with
your statement in <u37lpndko6.fsf at ares.sys1.ngo.okisoft.co.jp>:

|Even if Python has "real" GC someday, IMHO, the GC should be
|used only to imitate infinite resources. For the sake of
|conceptual simplicity, the future Python should still use
|reference counting both to invoke __del__ methods and to free
|storages; the GC routine should be used as the last resort.

matz.

[Yukihiro Matsumoto]

Hi.

Paul Prescod <paul at 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.

[Paul Prescod]

Post by Yukihiro Matsumoto
|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.

Post by Yukihiro Matsumoto
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.

Post by Yukihiro Matsumoto
|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?

Post by Yukihiro Matsumoto
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.
--
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

[Hisao Suzuki]

In article <7j45iv$908$4 at cronkite.cc.uga.edu>,

You also seem to believe that with GC finalisation will disappear. Why
do you believe that (a lot of GC schemes have finalisation).

You might misunderstand Donn's saying. As far as I understand,
he says that explicit finalization (or close call, in your
wording) disappears if reference counting is used; finalization
will be done implicitly with destructor such as __del__(self)
all at the expected time then.

Finally I
believe you are mis-using finalisation if you use it to close up files,
sockets, etc. That's what close calls are for.

You are all right in some other languages. However, if we adopt
such a manner as Pythonic style, we would have to write the code
like this:

a = SomeClass(....)
try:
...do something with a...
finally:
a.close()

instead of providing the __del__ method for SomeClass once and
for all.

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Paul Boddie]

sure looks like the "community" thinks that changing the
language is more important that using it...

Improvements should always be considered if Python is to continue to get better
- not that it isn't very good already. However, there is a difference between
those suggestions which genuinely attempt to improve Python "under the hood",
and those which are primarily concerned with changing the syntax. The latter
often seem to stem from the desire to import "cool tricks" from other languages
rather than genuinely improve the language.

It would arguably be better if people concentrated their attention on
applications of Python through the development and usage of modules rather than
getting bogged down with issues which aren't necessarily going to increase the
adoption of Python (of concern to those who feel confident in a larger
community), or make it appropriate or more convenient for a larger number of
tasks.

Just as applications sell operating systems, so modules "sell" languages. Well,
why else would Perl be as successful as it is? (Ruling out for a moment that it
all wasn't a big accident resulting from fortuitous timing.)

Paul

[Barry A. Warsaw]

Hrvoje> Would this right approach ever work in Python? Given
Hrvoje> Python's dynamism, it's perfectly legal to write:

Hrvoje> x.__del__ = FN

Hrvoje> where x is an instance of a class without a __del__()
Hrvoje> method. But then again, maybe it would be OK to silently
Hrvoje> ignore such __del__ methods...

Yep, that's exactly what would be broken with my approach.

-Barry

[Graham Matthews]

Donn Cave (donn at u.washington.edu) wrote:
: You're in good company here, I think the leading lights of the Python
: world all prefer explicit termination in these cases. Ref counting sure
: offers a great convenience here, though. Files close and flush their
: buffers, dialogues disappear, all in accordance with their programmatic
: lifetime. I personally will miss this finalization more than any resource
: management if reference counting is taken away.

You seem to believe that garbage collection implies no reference counts.
Why do you believe that? (a lot of GC schemes use reference counts).
You also seem to believe that with GC finalisation will disappear. Why
do you believe that (a lot of GC schemes have finalisation). Finally I
believe you are mis-using finalisation if you use it to close up files,
sockets, etc. That's what close calls are for.

graham

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

|Me too. And I am afraid that some evangelists would do nothing
|but _only_ point out Python's some so-called fault in order to
|drive us into convert to their favorite or invented language...

Sorry for bothering the newsgroup. But I couldn't resist pointing out
misunderstanding about "real GC" among some part of Python users.

http://www.iecc.com/gclist/GC-faq.html

It's totally OK for Python to use ref counting.

[Graham Matthews]

so I don't understand the above comment? As for circularly
referred data it will be deleted in the order determined by the collector,
but that's better than current Python which doesn't delete it at all.

Salvador =?iso-8859-1?Q?Fandi=F1o?= (fandino at usa.net) wrote:
: If I can't remove objects in the right order I would have to delete it
: explicitly the same way I have to do it now with ref counting. Lots of
: current __del__ methods will not perform properly and will raise
: exceptions if called after deleting related objects.
: You could use __del__ methods only for trivial task like freeing
: resources. It's an incomplete solution like reference counting is.

I really don't understand this. A lot of languages (eg. Java) have
garbage collection and finalisers. All these languages manage to delete
objects in an order that does not cause any problems (all finalisers etc
work). If a collector can do that in these languages why can't it do in
Python (__del__ methods are Python's finalisers)?

I am very very confused by your question. You seem to have a misconception
about __del__ methods. They are finalisers, used only to close resources
like files, etc. In a garbage collection scheme the __del__ methods are
not used to implement the actual collection.

graham

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

|This sounds a sort of advocacy of your Ruby...

Well, maybe..

|Any way, the idea of destructors with "real" GC is a conceptual
|contradiction. Such GC emulates infinite memories and objects
|are never destroyed *virtually*. Thus the destructors should
|never be invoked with real GC.

I thought GC is the way to reclaim the unreferenced objects. I think
it is not directly related to infinite memory space, even though you
can choose it as the conceptial model for GC.

|Certainly you may make your GC routine retrieve not only
|memories but also various resources (such as file descriptors),
|but it is highly error prone to make the routine invoke
|ARBITRARY destructors specified by arbitrary users. Such
|invocation may introduce serious indeterminism or
|unpredictability into the behavior of user's program.

Do you mean finalizers with real GC (as in Java) is the source of
indeterminism? Maybe you're right.

BTW, did I say Ruby can invoke arbitrary destructors specified by
arbitrary users? It can't.

|# Well, in this respect, Ruby might be more indeterministic
|# than Python.

I don't think it is. But, well, I have to confess Ruby is unstable
than Python yet.

|Even if Python has "real" GC someday, IMHO, the GC should be
|used only to imitate infinite resources. For the sake of
|conceptual simplicity, the future Python should still use
|reference counting both to invoke __del__ methods and to free
|storages; the GC routine should be used as the last resort.

I agree with it. I wouldn't claim to remove ref counting from Python.
Combination of ref counting and real GC may be the best for Python,
accomplishes both compatibility and reliability.

matz.

[Hisao Suzuki]

In article <87pv3eorg4.fsf at ev.netlab.co.jp>,

Post by Yukihiro Matsumoto
BTW, did I say Ruby can invoke arbitrary destructors specified by
arbitrary users? It can't.

Is this your mental premise in your opinion about garbage
collection? Then, the unpredictability might not be matter at
all...

I see that is the way of your own excellent Ruby, but it is not
the manner of the present Python.

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Jeremy Hylton]

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

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

I don't think this is a good example. Even beginning users are going
to have to learn a little about resource management about some point.
People should not rely on files getting deallocated and closed by
Python. All the beginners who start with JPython are going to get
Java's GC. And they're going to need to close the files by hand.

Jeremy

[Paul Prescod]

Perhaps this is what I get for jumping in in the middle of a
conversation without learning how it got started. The example I was
responding to depended on file object being immediately finalized to
avoid leaking file descriptors.

This is a documented feature of Python (documented in the FAQ at least).
New users do not currently need to learn otherwise unless they use JPython
which is incompatible in this regard. In other words, this IS a
demonstration of a flaw in GC, or at least in Java GC because it required
a change in the Python language semantics.

I think that that is all anyone has been saying. Many people like the
current semantics and don't trust that a full GC would deterministically
invoke finalizers for arbitrary resources.
--
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

[Paul Prescod]

Post by Jeremy Hylton
I don't think this is a good example. Even beginning users are going
to have to learn a little about resource management about some point.
People should not rely on files getting deallocated and closed by
Python. All the beginners who start with JPython are going to get
Java's GC. And they're going to need to close the files by hand.

It looks like this conversation has come all of the way around. We are
talking about whether the JVM should be the default, standard Python
distribution platform. It isn't fair, then, to use the flaws in the JVM
version of Python to argue FOR that change.

"Oh well, we'll lose compatibility with PIL but JPython users have
alreadly lost that so I guess it isn't a big deal."

Personally, I wouldn't mind if Python ran on the JVM or had real GC. I
just think that both sides need to be told. Python is the way it is not by
accident but through design decisions intended to keep it simple to use
and embed.
--
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

[Martijn Faassen]

Some languages use both. Ref counting for usual basis, real GC for
full clean up. How about adding real GC to Python 2.0, co-working
with ref counting?

This sounds like an interesting idea; I believe I saw references to
garbage collecting schemes that help clean up circular references caused
by referencing counting. I forget where, though. :)

I agree with the general principle that for Python 2, garbage collecting
should be taken a good look at. I suppose the two main issues are:

* The predictability of reference counting is nice in the simple case.
In the complex case, you get into a mess of circular references too
easily, though.

* In the complex case, garbage collecting is nice as it cleans up
circular references. There are unwanted side-effects of its
unpredictability, though; a possible leaking of resources (files which
aren't closed), and some difficulties interfacing with C.

In that light combining the two schemes might be very interesting.

Repeatingly yours,

Martijn

[Graham Matthews]

Why is it so hard for people to see that adding a mark sweep collector
*ON TOP OF* the existing ref count scheme essentially changes nothing.
All the current ref count behaviour that people love will stay. The
only additional behaviour will be that circular refs are mopped up
correctly.

Vladimir Marangozov (Vladimir.Marangozov at inrialpes.fr) wrote:
: Why don't you try implementing it?
: There's nothing more convincing than good working code.
:
: If you try, I suspect that not we, but you'll realize that it's not so
: immediate and that there would be other additional effects, either
: inacceptable or undesirable.

How does one respond to the above? The old "I suspect" line. Well I don't
suspect because:

a) many many languages have garbage collection outlined exactly as I
have proposed and they all work just fine.

b) I work on a product which pretty much does exaclty what I outlined
for a collection scheme, and it works beautifully. Moreover it contains
many similarites with Python (the need to interface to C, complex
objects, etc).

c) I have implemented 3 collectors in my "coding life", so I have some
experience.

You on the other hand just "suspect that I will realise that it's not so
immediate"? Do you have any basis for these suspicions? For example have
you ever implemented a reference counting mark sweep collector, maybe
with colouring.

I am sorry to sound sooo sarcastic, but what can I reply to "I suspect ...".
I put up facts, and you put up "I suspect ..."
:
graham

[Vladimir Marangozov]

Why is it so hard for people to see that adding a mark sweep collector
*ON TOP OF* the existing ref count scheme essentially changes nothing.
All the current ref count behaviour that people love will stay. The
only additional behaviour will be that circular refs are mopped up
correctly.

Why don't you try implementing it?
There's nothing more convincing than good working code.

If you try, I suspect that not we, but you'll realize that it's not so
immediate and that there would be other additional effects, either
inacceptable or undesirable.

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

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

In Java, right?

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

Safer than Java, probably.

Ruby garantees (well, trying to garantee) that ALL finalizers will be
called before process termination, so that Ruby is as safe as Python,
at least theoretically.

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

Thank you for mentioning it. But my first intention is not
evangelism. I wanted to resolve the misunderstanding abount real GC
in this newsgroup, and make Python better. Believe it or not.

But, of cource, new comers are always welcome. :-)

matz.

[Paul Prescod]

Post by Yukihiro Matsumoto

Post by Yukihiro Matsumoto
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?

Post by Yukihiro Matsumoto
|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.

Post by Yukihiro Matsumoto
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?

Post by Yukihiro Matsumoto
|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]

graham at sloth.math.uga.edu (Graham Matthews) writes:

|Why is it so hard for people to see that adding a mark sweep collector
|*ON TOP OF* the existing ref count scheme essentially changes nothing.
|All the current ref count behaviour that people love will stay. The
|only additional behaviour will be that circular refs are mopped up
|correctly.

They may be worrying about resurrection of the dead objects by __del__
finalizers, which is solvable by Java approach (maybe inefficient though).

matz.

[Ron Klatchko]

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 it never hurts to release a resource as soon as you're done with
it and it can hurt to hold onto it longer then necessaary. Think about
an object the implements a mutex, do you want to hold it until GC is
done?

moo
----------------------------------------------------------------------
Ron Klatchko - Manager, Advanced Technology Group
UCSF Library and Center for Knowledge Management
ron at library.ucsf.edu

[Michael P. Reilly]

Graham Matthews <graham at sloth.math.uga.edu> 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?

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

-Arcege

[Gang Li]

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

Post by Graham Matthews
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
gangli at msn.com

[Graham Matthews]

Graham Matthews wrote in message <7ik6mi$lbk$1 at 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 (gangli at 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

[Graham Matthews]

Gang Li (gangli at 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.

Post by Graham Matthews
You are envangelising (a not uncommon response when someone remotely
criticises Python).

Fredrik Lundh (fredrik at 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.

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

Fredrik Lundh (fredrik at 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.

graham

[Jeremy Hylton]

DS> Hrvoje Niksic <hniksic at srce.hr> writes: | Kumar Balachandran
DS> <kumar*xspam*@*xspam*rtp.ericsson.se> writes: | | > What you
DS> said is quite wrong. Since Python provides closures, I can | >
DS> change my programming style to be completely different from the
DS> | > standard C or Fortran style and use a functional interface.
DS> | | Since when does Python provide closures?

DS> The bytecodehacks module allows the creation of closures as I
DS> understand them.

Yes and no. The bytecodehacks closures work right most of the time,
but there some problems with them. Hence, I would guess, the name
"hacks." A "BCH closure" does what you want most of the time, but it
does not work for immutable types or for assignments to mutable types.

The Scheme world view has a different world view, and a closure in
Scheme works a bit differently. I suspect it may be a little
confusing for people expect BCH to make Python's variable binding work
like Scheme's variable binding. In Scheme, a variable is bound to a
location that stores a value. You can store a new value in that
location using set!. If two different functions share the same
binding for a variable, a set! performed in one function is visible in
the other.

(let ((sum 0))

(let ((add (lambda (x) (set! sum (+ sum x))))
(sub (lambda (x) (set! sum (- sum x)))))
(add 2)
(add 3)
(sub 1)
sum))
4

The BCH model is different, because it doesn't allow two functions to
share the same "location." It only allows them to share the same
value. This is a limitation of the way BCH implements closures;
non-local references are turned into references to constants when the
bind call is made. This approach often works the constant is an
object and you're referencing one of its attributes or calling a
method. It doesn't work for assignment.

The natural translation of the above Scheme code in Python+BCH would
probably be:
from bytecodehacks import closure

def notQuite():
sum = 0
def add(x):
sum = sum + x
def sub(x):
sum = sum - x
cadd = closure.bind_locals(add)
csub = closure.bind_locals(sub)
cadd(2)
cadd(3)
csub(1)
return sum

But this doesn't work. You need to bind sum to a mutable object (not
a string or tuple) and that operator on that object indirectly. The
following works because it contains the value of interest inside a
list (and list operations are methods on the list object).
Effectively, you need to create the shared location that Scheme
creates for free.

def works():
sum = [0]
def add(x):
sum[0] = sum[0] + x
def sub(x):
sum[0] = sum[0] - x
cadd = closure.bind_locals(add)
csub = closure.bind_locals(sub)
cadd(2)
cadd(3)
csub(1)
return sum[0]

Jeremy

[Hrvoje Niksic]

Post by Jeremy Hylton
| Since when does Python provide closures?
The bytecodehacks module allows the creation of closures as I
understand them.

I've never seen bytecodehacks. Where can I get it?

[Dan Schmidt]

Hrvoje Niksic <hniksic at srce.hr> writes:

| Dan Schmidt <dfan at harmonixmusic.com> writes:
|
| > | Since when does Python provide closures?
| >
| > The bytecodehacks module allows the creation of closures as I
| > understand them.
|
| I've never seen bytecodehacks. Where can I get it?

ftp://starship.python.net/pub/crew/mwh/

Thanks to Jeremy Hylton for his post pointing out that closure
capability is still somewhat limited, even with bytecodehacks. But
my original, carefully phrased, statement is still correct :)

[Kumar Balachandran]

What you said is quite wrong. Since Python provides closures, I can
change my programming style to be completely different from the
standard C or Fortran style and use a functional interface. Or, I
could just as easily implement a message-passing interface. So, your
comment about beauty in the language due to discouragement of
individuality is not grounded in reality. The issues that a good
programming language should address include a structure that makes it
easy to use, write in and debug as well. The first and the last are
somewhat marred by the subject of my complaint.

It is quite clear that the authors of the language treat the design of
the syntax very religiously, and my intent is not to denigrate their
efforts, but I must point out that valuable criticism rarely comes
from people that have accepted the philosophy being espoused, but
rather from persons that are able to rise to a metalevel corresponding
to the system (in this case Python).

I like to quote an analogy that occured to me sometime ago. When I
started learning C many years ago, I wondered how life without
malloc had been possible. Then I learnt C++ and was equally enamoured by the
new operator and the concept of destructors. Finally I learnt Scheme
and Lisp, and now wonder why people use languages without closures and
garbage collection. I still have to master continuations, something I
feel ashamed about constantly. The problem of course is that Lisp and its
dialects are like Latin -- quite difficult to use with too many tools
for any given task. The notation tends to throw people off as
well. So, in any collaborative work we have to settle for a lesser
language such as Matlab (blech!) or Python. What do we get out of it
-- we get closures. We also get a nice interactive environment with
easy prototyping ability. But wait a minute, it's like FORTRAN. It uses
indentation and blank lines as part of the syntax. At least it does
not require a label in a particular column of the line. In conclusion,
lets face the fact that that design decision was flawed, and people
have to conjure up excuses to save face.

I did suggest "wend" instead of "elihw", and in any case I was not
presenting a specification, just a suggestion.
Charles> I vociferously disagree that adding junk like "elihw"
Charles> adds anything to readability.

Charles> And one of the beautiful things about Python, especially
Charles> in projects with more than one programmer, is that it
Charles> explicitly *discourages* individual programmers from
Charles> developing their own coding styles, since in general
Charles> there are *not* multiple ways to do the same thing.
Charles> "Optional" syntax is very much against this spirit.

[Kumar Balachandran]

Graham> Graham Matthews wrote in message
Graham> <7ik6mi$lbk$1 at cronkite.cc.uga.edu>...
Graham> You are envangelising (a not uncommon response when
Graham> someone remotely criticises Python). Stop evangelising and
Graham> start considering the technical issues involve (read (!)
Graham> other posts for what those issues are).

Graham> graham
Here is some useful evangelizing (methinks). One of the irritating things about
Python is the use of whitespace in syntax. Agreed, the code is
readable without parentheses or braces, but why not have optional
syntactic sugar such as

if
...
elif
...
else
...
fi

def
...
...
fed


while
...
elihw or wend



for
...
rof

etc. It makes the language more elegant. When I see code using
indentation or blank likes to achieve blocking of constructs, it
reminds me of an old language (FORTRAN I think it was called:-).

The change is simple to achieve if backward compatibility is given to
accomodate people that grew up with FORTRAN.

[Graham Matthews]

Graham Matthews <graham at sloth.math.uga.edu> writes:
:> 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).
Kumar Balachandran (kumar*xspam*@*xspam*rtp.ericsson.se) wrote:
: Here is some useful evangelizing (methinks). One of the irritating things
: about Python is the use of whitespace in syntax. Agreed, the code is
: readable without parentheses or braces, but why not have optional
: syntactic sugar such as

I am not sure what the point here is? I don't like whitespace in syntax
either but I also don't think it's worth trying to change (unlike something
really major like garbage collection). So I must have missed the point.

graham

[Dennis Lee Bieber]

On 04 Jun 1999 15:07:05 -0400, Kumar Balachandran

if
...
elif
...
else
...
fi
def
...
...
fed
while
...
elihw or wend

Ugh... I have never liked languages that use a reversed spelling
to signify the end of a block... "end if", "end while" all read easier
to me than "fi", "elihw"...

At that level, I'll take Ada's more generic "end loop", as "for"
and "while" loops are both built up as conditions on a "loop ... end
loop" block.

etc. It makes the language more elegant. When I see code using
indentation or blank likes to achieve blocking of constructs, it
reminds me of an old language (FORTRAN I think it was called:-).

No FORTRAN that I know of ever relied on indentation, etc. to
block constructs. Heck, a true FORTRAN totally ignored white space.

do 10 i = 1.20
do10i=1.20
assignments, identical.

do10i=1,20
do 10 i = 1, 20
loop, identical.

The change is simple to achieve if backward compatibility is given to
accomodate people that grew up with FORTRAN.

FORTRAN 77 added a nice blocked IF

IF (cond) THEN
ELSE IF (cond) THEN
ELSE
END IF
but again, no required indentation. Indentation is solely up to the
programmer for understanding of code -- Python's usage I find nice, as
it ensures visible blocking without having to match start and end
markers.

Fortran 90 (for some reason it has now been declared that
"Fortran" is not a contraction of "FORmula TRANslator" but a proper
name, and to be treated with lowercase <G>) even permits the use of <, >
in conditionals !


--

============================================================== <
wlfraed at ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wulfraed at dm.net | Bestiaria Support Staff <
============================================================== <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <

[Vadim Chugunov]

Post by Graham Matthews
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
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.

Post by Graham Matthews
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?

Post by Graham Matthews
ability to write statically typed code (just write that part in Java!),

Just write that part in C !

Post by Graham Matthews
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 ?

Post by Graham Matthews
(free publicity and hype), etc.

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

Vadim


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

[Barry A. Warsaw]

What we need is CODE. Somebody's gotta step up to the plate and
generate some patches that people can play with. The best idea I've
heard yet is to graft some GC on top of the already existing
refcounting scheme. Sounds good to me, but I'm no GC expert so I have
no idea how to do this. I'm just sitting here waiting for someone to
pick a scheme, snag an implementation, and post some hacks. Then
we'll have a starting point from which the real fun can begin!

garbage-in-garbage-out-who's-gonna-garbage-collect-this-thread?-ly y'rs,
-Barry

[Graham Matthews]

Hisao Suzuki (suzuki611 at okisoft.co.jp) wrote:
: Me too. And I am afraid that some evangelists would do nothing
: but _only_ point out Python's some so-called fault in order to
: drive us into convert to their favorite or invented language...

I am sorry Hisao but this is pure fantasy. This kind of "anyone
suggesting improvement to Python is a critic" mentality pervades
this thread and this newsgroup. Can you give even one example of
where someone has tried to convert anyone to another language in
this thread? The only other language mentioned in this thread is
Ruby, and the author of the article about Ruby was very clear to
point out that he was reporting his experience with GC in Ruby
and not evangelising it. If you cannot give an example then what
you write above is fantasy.

Hisao Suzuki (suzuki611 at okisoft.co.jp) wrote:
: Anyway, as you say, I'd think that we need an actual experience.

But people do have experience with GC. Sure that experience is not
in Python, but why do you believe that GC in Python will be radically
different to GC in any other language?

graham

[Jeremy Hylton]

GM> Hisao Suzuki (suzuki611 at okisoft.co.jp) wrote: : Me too. And I
GM> am afraid that some evangelists would do nothing : but _only_
GM> point out Python's some so-called fault in order to : drive us
GM> into convert to their favorite or invented language...

GM> I am sorry Hisao but this is pure fantasy. This kind of "anyone
GM> suggesting improvement to Python is a critic" mentality pervades
GM> this thread and this newsgroup.

Strictly speaking, I believe a critic is "a person who judges,
evaluates, or criticizes." (http://infoplease.lycos.com/ipd/A0393235.html)
So, yeah, people suggesting improvements are critics. I think we all
benefit from having good critics. All sorts of changes have come as
the result of constructive critism -- packages, the threading module,
[].pop, {}.get, etc. Probably lots more that I'm not thinking of.

GM> Hisao Suzuki (suzuki611 at okisoft.co.jp) wrote: : Anyway, as you
GM> say, I'd think that we need an actual experience.

GM> But people do have experience with GC. Sure that experience is
GM> not in Python, but why do you believe that GC in Python will be
GM> radically different to GC in any other language?

I think the problem is that the people who have experience
implementing garbage collection are not the people who advocating
adding it to Python. It's one thing to have used languages with
garbage collectors or to have read books and papers about them; it's
quite another thing to have done the implementation. The gap between
theory and practice is greater in practice than in theory.

So go for it. Many of us would love to look at some rough, but
running code. Just make sure it is portable enough to run on all the
platforms that Python runs on, and make sure it has minimal impact on
C extension modules. I doubt that it's impossible, but I expect that
it's hard.

Jeremy

[Yukihiro Matsumoto]

adjih at technologist.com writes:

| It is true that it shouldn't be hard to make a mark-sweep collector
|that is working in practice on many platforms.
|
| Pedantically I doubt that ANSI-C tells you the current stack top
|address, or guarantees that the whole address space between the current
|stack pointer and this top stack address is stack space. But I agree
|that actual C compilers wouldn't do something too stupid, we
|shouldn't care about this :-)

You don't have to know stack address to implement mark-sweep register,
unless you want to make it conservative. The mark-sweep GC can be
written in ANSI-C portable.
matz.

[Graham Matthews]

Paul Boddie (paulb at infercor.no) wrote:
:Well, my statement was actually an invitation for more enlightened contributors
:to give examples of such schemes, and this has evidently had the intended
:effect.

cf the posts on Ruby.

graham

[Robert Meegan]

On Thu, 27 May 1999, Graham Matthews wrote:

[...]

Post by Graham Matthews
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
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

[Paul]

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

[Paul Moore]

On 27 May 1999 19:33:38 GMT, graham at sloth.math.uga.edu (Graham

Post by Graham Matthews
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
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]

In article <7ik6mi$lbk$1 at cronkite.cc.uga.edu>,

Post by Graham Matthews
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

Post by Graham Matthews
to the existing C implemented extensions), I personally think there
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.

[Yukihiro Matsumoto]

Hisao Suzuki <suzuki611 at okisoft.co.jp> writes:

|In article <7j90va$6lk$1 at cronkite.cc.uga.edu>,
|graham at sloth.math.uga.edu (Graham Matthews) wrote:
|> I am completely confused by this statement. The two people that have
|> been advocating GC the hardest are myself and the author of Ruby. Since
|> Ruby has GC the author has clearly implemented a collector. ...
|
|Regrettably, I'd have to say that Ruby is (was?) suffering from
|its insufficient portability. Once I have used a certain i860
|SVR4 box. On that box, Ruby did not run but dumped immediately
|with its twiddling the machine stack, while Python ran perfectly
|with no difficulty. As far as I know, the collector of Ruby has
|not changed so much since then.

It's because conservative-ness of Ruby's GC, you know. There should
be no portability problem with Graham's proposal, mark and sweep GC
with ref counting, unless implementor try to make it conservative.

I've never claimed Ruby is as portable as Python. Definitely Python
runs on the machines where Ruby cannot run, say on small devices.

|(I have before told this to the author of Ruby on a Japanese
|Pythoneers' mailing-list against his advocacy of Ruby, and now
|he appeared here again with just the same opinion before...)

What opinion of mine do you have in mind?

I claimed in summary:

* I don't like mere ref counting; it cannot reclaim cyclic data, and
easy to forget INCREF/DECREF.

* Many among Python users misunderstood about real GC.
(slow, hangs, non portable, etc.)

* ref counting with GC may be good for Python 2.0.

Did I do any advocacy on Ruby? I was trying constructive discussion.

matz.

[Blake Winton]

In article <87pv384koy.fsf at ev.netlab.co.jp>,
| * I don't like mere ref counting; it cannot reclaim cyclic data, and
| easy to forget INCREF/DECREF.
| * Many among Python users misunderstood about real GC.
| (slow, hangs, non portable, etc.)
| * ref counting with GC may be good for Python 2.0.
| Did I do any advocacy on Ruby? I was trying constructive discussion.
I'm sorry to say, but your argument is too trivial (or rather
naive) to consider as a constructive discussion. Having almost
nothing to do with real problems on Python, your referrings to
your Ruby (surely in triumphant tones) sound evangelic. I'd be
glad if you would present a non-trivial viewpoint or propose a
practical solution _relevant_ to Python actually.

I think this is a little harsh. I've been reading this entire thread
(No, I don't know why), and Matz has seemed to me to be remarkably
restrained in his evangelical attempts. Whenever he mentions Ruby, he
makes the disclaimer that it's not particularly portable, and only seems
to use it as a proof-of-concept, or demonstration that he has some skill
in writing GCs.

Ref counting with GC sounds to me like a good idea for Python 2.0, as it
will eliminate a class of memory leaks that Python can currently fall
prey to. As long as you don't move stuff around in memory, and only
collect things where all the refcounts are accounted for, and can't be
reached, you should be safe. Granted, this means that the people
writing the extensions will have to be careful to INCREF/DECREF where
they're supposed to, but I don't see that as a bad thing since they
should already be careful about that sort of stuff.

Later,
Blake.

[Graham Matthews]

Blake Winton (bwinton at tor.dhs.org) wrote:
: Ref counting with GC sounds to me like a good idea for Python 2.0, as it
: will eliminate a class of memory leaks that Python can currently fall
: prey to. As long as you don't move stuff around in memory, and only
: collect things where all the refcounts are accounted for, and can't be
: reached, you should be safe. Granted, this means that the people
: writing the extensions will have to be careful to INCREF/DECREF where
: they're supposed to, but I don't see that as a bad thing since they
: should already be careful about that sort of stuff.

Actually Blake I have a feeling that I have read a paper somewhere that
says that a mark sweep collector with refcounts can in fact patch up
refcount errors, so it won't be so critical that extension writers get
their INCREF/DECREFs just right. I am not 100% sure of this but at least
on the surface it seems plausible (even if it can only give a warning
about such errors). Anyone know more about this?
graham

[adjih]

In article <7j44ql$908$1 at cronkite.cc.uga.edu>,

: 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.
You appear to be making an argument like "when a GC occurs the system
pauses, and this is bad in an interactive environment". If that's the
case then this is an old chestnut. Modern GC implementations do not
have such pauses. Look up papers on real-time garbage collection for
example.

Hmm... How do you do multi-thread real-time (i.e. incremental) GC being
a) portable (must run on PalmPilot, WinCE, Unix, Mac,...) b) without
relying on assumptions [that will fail in some programs] (such as "very
few writes in shared space"). The supplementary condition would be "c)
efficient" which would be useful for languages such as C/C++ or compiled
Java, but I grant you that this is not necessary for the current Python,
and that we are comparing here to reference counting anyway.


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

[Hisao Suzuki]

In article <3755714F.294CCB8D at pop.vet.uu.nl>,
Martijn Faassen <faassen at pop.vet.uu.nl> wrote:
| Aahz Maruch wrote:
[snip]
| > I'm curious: does GC provide any advantages other than its ability to
| > deal with circular references?
|
| I think certain forms of GC can use less memory; I don't think all forms
| of GC need extra data for all objects, like you need to store the ref
| counter in.

Yes. And it is also often said that GC can be faster than
reference counting. But this does not solely determine the
whole speed of every interpreter of every language.

For example, mostly Perl runs faster than Ruby (which is Perl's
successor invented by Mr. Matz --- {'June':'Pearl', 'July':'Ruby'}),
whereas Perl uses reference counting and Ruby uses some
sophisticated GC.

As for the issue of circular references, in my opinion, the
future Python should use non-compacting GC at the end of the
last thread and destroy the remained objects by invoking their
__del__ methods --- it is THE time to destroy all the objects
remained, so this is conceptually clean (thus very Pythonic :-),
though it is the way of memory management used in the present
Perl in fact...

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Yukihiro Matsumoto]

aahz at netcom.com (Aahz Maruch) writes:

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

Well, in <87n1ykr0z9.fsf at ev.netlab.co.jp> I said:

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

You can see STk (Scheme Tk, of cource with real GC) works just fine
for interactive process.
matz.

[Aahz Maruch]

In article <87k8toqv70.fsf at ev.netlab.co.jp>,

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.

[Graham Matthews]

Why is it so hard for people to see that adding a mark sweep collector
*ON TOP OF* the existing ref count scheme essentially changes nothing.
All the current ref count behaviour that people love will stay. The
only additional behaviour will be that circular refs are mopped up
correctly.

Aahz Maruch (aahz at netcom.com) wrote:
: I don't disagree with this; I only claim that GC should only happen by
: explicit call from the programmer. I also claim that there should be a
: debug mode for GC that merely informs the programmer about cyclic
: references so that zie can locate their source (and that this should be
: the primary mode for GC).

I don't understand why you want GC only by explict call and in "inform"
mode only?

graham

[Aahz Maruch]

In article <7j6ua4$fp6$1 at cronkite.cc.uga.edu>,

Post by Graham Matthews
I don't understand why you want GC only by explict call and in "inform"
mode only?

I don't think inform mode should be the only mode, but it should be the
default and primary mode. As for explicit GC, just call me a Luddite.
(IOW, I think of GC as primarily a debugging tool and I don't trust
autoGC to not impact real-time programs.)

[Graham Matthews]

Hisao Suzuki (suzuki611 at okisoft.co.jp) wrote:
: Just now I tried to make the recent stable version of Ruby on a
: box of the same type. Regrettably it crushed as the similar way
: as before. Certainly Ruby _is_ suffering from its insufficient
: portability.

And what do we conclude from this?

graham

[Hisao Suzuki]

In article <7jgk4j$s8p$1 at cronkite.cc.uga.edu>,

Post by Graham Matthews
: Just now I tried to make the recent stable version of Ruby on a
: box of the same type. Regrettably it crushed as the similar way
: as before. Certainly Ruby _is_ suffering from its insufficient
: portability.
And what do we conclude from this?

In article <u3g1443iht.fsf at ares.sys1.ngo.okisoft.co.jp>,
I also wrote:
| ... On that box, Ruby did not run but dumped immediately
| with its twiddling the machine stack, while Python ran perfectly
| with no difficulty. ...

We have been enjoying Python's portability for many years.

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Hisao Suzuki]

In article <u3g1443iht.fsf at ares.sys1.ngo.okisoft.co.jp>,
I wrote:
| Regrettably, I'd have to say that Ruby is (was?) suffering from
| its insufficient portability. Once I have used a certain i860
| SVR4 box. On that box, Ruby did not run but dumped immediately
| with its twiddling the machine stack, while Python ran perfectly
| with no difficulty. As far as I know, the collector of Ruby has
| not changed so much since then.

Just now I tried to make the recent stable version of Ruby on a
box of the same type. Regrettably it crushed as the similar way
as before. Certainly Ruby _is_ suffering from its insufficient
portability.

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Graham Matthews]

Post by Graham Matthews
Anyway, as you
say, I'd think that we need an actual experience.
But people do have experience with GC. Sure that experience is
not in Python, but why do you believe that GC in Python will be
radically different to GC in any other language?

Jeremy Hylton (jeremy at cnri.reston.va.us) wrote:
: I think the problem is that the people who have experience
: implementing garbage collection are not the people who advocating
: adding it to Python. It's one thing to have used languages with
: garbage collectors or to have read books and papers about them; it's
: quite another thing to have done the implementation. The gap between
: theory and practice is greater in practice than in theory.

I am completely confused by this statement. The two people that have
been advocating GC the hardest are myself and the author of Ruby. Since
Ruby has GC the author has clearly implemented a collector. As for myself
I have implemented 3 collectors, one of which is used in a system that
is used by quite a few people worldwide. So I am not sure where your
comment is coming from?

Jeremy Hylton (jeremy at cnri.reston.va.us) wrote:
: So go for it. Many of us would love to look at some rough, but
: running code. Just make sure it is portable enough to run on all the
: platforms that Python runs on, and make sure it has minimal impact on
: C extension modules. I doubt that it's impossible, but I expect that
: it's hard.

I have no plans to implement a GC for Python. I have already implemented
enough standard collectors for one lifetime. Besides which someone far
more intimate with the implementation details of Python would take less
time. That's not a cop out. I just don't have the time.

graham

[Amit Patel]

Yukihiro Matsumoto <matz at netlab.co.jp> wrote:
| Hi.
|
| "Vadim Chugunov" <chega_ at 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?

In my case it's because in Python and C++ I tend to deal with
resources a LOT. Sockets especially, but also files. When I write
Scheme and ML code, I rarely ever deal with resources other than
memory, so it doesn't bother me.

It's not the language but how I tend to use it that colors my opinion
on destructors.

- Amit

[Aahz Maruch]

In article <7j6jnl$58f$3 at cronkite.cc.uga.edu>,

Why is it so hard for people to see that adding a mark sweep collector
*ON TOP OF* the existing ref count scheme essentially changes nothing.
All the current ref count behaviour that people love will stay. The
only additional behaviour will be that circular refs are mopped up
correctly.

I don't disagree with this; I only claim that GC should only happen by
explicit call from the programmer. I also claim that there should be a
debug mode for GC that merely informs the programmer about cyclic
references so that zie can locate their source (and that this should be
the primary mode for GC).

[James Logajan]

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]

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.

[Markus Stenberg]

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

[Mark Hammond]

Markus Stenberg wrote in message ...

Post by Markus Stenberg

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.

[Darrell]

Markus Stenberg <mstenber at cc.Helsinki.FI> wrote in message

Post by Markus Stenberg
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.

Post by Markus Stenberg

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

[Paul Moore]

On Sat, 29 May 1999 14:00:58 GMT, Paul Prescod <paul at prescod.net>

Post by Paul Prescod

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.

[Markus Stenberg]

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

[Darrell]

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]

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.

[Peter A. Koren]

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

[Dennis Lee Bieber]

On Tue, 1 Jun 1999 14:21:15 GMT, Paul Prescod <paul at prescod.net>

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.

I've (unfortunately in one way) had to migrate to a W95 machine,
but the last Amiga Python port I saw did incorporate an AREXX interface
mechanism.

--

============================================================== <
wlfraed at ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wulfraed at dm.net | Bestiaria Support Staff <
============================================================== <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <

[Michael P. Reilly]

Paul Prescod <paul at 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]

Post by James Logajan

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.

[Paul Prescod]

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?

[Gordon McMillan]

[Paul Moore, on the possibility of Python 2.0 in Java]

Post by Graham Matthews
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.

And you'd only have to get it working with N different JVMs, all
without anything resembling autoconf.

#ifdef-considered-dangerous-<snort>-ly y'rs

- Gordon

[Barry A. Warsaw]

GM> And you'd only have to get it working with N different JVMs,
GM> all without anything resembling autoconf.

GM> #ifdef-considered-dangerous-<snort>-ly y'rs

You ain't kiddin' Gordon! One of my recent JPython slaps has been
trying to use JDK 1.2 APIs to provide better functionality. Well,
y'can't because most JPython users want 1.1 compatibility (for good
reasons) and there's no way[1] to have a single Java codebase that
supports the new APIs and is still compilable under Java 1.1.

they-got-so-much-right-why'd-they-get-this-one-wrong?-ly y'rs,
-Barry

[1] that I know of, without growing our own Java preprocessor

[Stidolph, David]

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: graham at sloth.math.uga.edu [mailto:graham at sloth.math.uga.edu]
Sent: Friday, May 28, 1999 4:14 PM
To: python-list at cwi.nl
Subject: Re: Python 2.0


Michael P. Reilly (arcege at 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

[Gordon McMillan]

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

[Gordon McMillan]

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.

The security stuff only applies to applets, which are the sideshow
that hijacked Java. However, you'd still have to write in C, and
then make it work not only on all the hardware you're interested in,
but all the JVMs that run on that hardware.

- Gordon

[Hisao Suzuki]

| >[Salvador]
| > I have been using Java since it was invented and I haven't programed a
| > finaliser ever. They should run under so unknown and inconsistent
| > environment that they are not usable at all (except for freeing external
| > resources).

I have not ever programmed any finalizer, too, while I have
programmed a lot of codes in Java.

| [Graham Matthews]
| > I am not sure I understand this. Can you explain to me how a finaliser
| > can run in an unknown environment. Surely everything the finaliser needs
| > is referenced by the finaliser (either directly or indirectly) and hence
| > is still there.

| The caveats are explained well in the Java Language Spec, section 12.6.
| ...

| All Java defines is enough so that the Java runtime itself never chokes on
| e.g. an internal null pointer, i.e., your "still there" guarantee. Say you
| have a mail server holding a ref to a mail client, which in turn holds a ref
| back to the mail server. Can the client object tell the server it's going
| away at finalization time? Not if the server object shut down the
| communications link beforehand because the server's finalizer happened to
| get called first. Etc. Yes, the references are "still there", but without
| a lot of pain there's no guarantee they're still in a *useful* state.

It would be an issue of distributed garbage collection. And it
is a difficulty for automatic GC with finalization. In
addition, perhaps we should also take a (close) look at
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz

It summarizes other (or rather more general) issues to consider
in the design of a finalization mechanism (and presents one
solution for Scheme---actually it is adapted by gnu guile). I'd
think anyone who is planning improvements on Python's storage
management has to _notice_ what are summarized there first.
(The solution is another story. It is not so obvious for
Python.)

# Certainly the current reference counting system of Python
# reduces the issues to fairly (though _not_ fully) tolerable
# ones...

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.

[Tim Peters]

[Paul Prescod]

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.

[Yukihiro Matsumoto]

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.

Matz, this one is just a misunderstanding. Paul's "hang" doesn't refer to
time. It's more like "retain", as in "keep a pointer to". "compacting" is
the key there: compacting GC (one that relocates live objects) creates
problems for C extensions that have saved away ("hung on to") the addresses
of objects. But GC doesn't have to be compacting in order to reclaim
cycles; Paul is likely reacting to the "self-contained universe"
inter-language hostility common among languages with compacting GC (like
Icon or Java).

betting-a-nickel-python2-won't-compact-ly y'rs - tim

[Tim Peters]

Post by Hisao Suzuki
[Salvador]
I have been using Java since it was invented and I haven't programed a
finaliser ever. They should run under so unknown and inconsistent
environment that they are not usable at all (except for freeing external
resources).

[Graham Matthews]

Post by Hisao Suzuki
I am not sure I understand this. Can you explain to me how a finaliser
can run in an unknown environment. Surely everything the finaliser needs
is referenced by the finaliser (either directly or indirectly) and hence
is still there.

The caveats are explained well in the Java Language Spec, section 12.6. In
short, you can't know which thread a finalizer will run in; you can't be
sure that an object is unreachable at the time its finalizer is invoked; you
can't know *when* a finalizer will be invoked; even if it is unreachable at
the time its finalizer is invoked, you can't be sure that it won't become
reachable again *after* the finalizer returns; and in the case of cyclic
object structures nothing is specified about the order in which the objects'
finalizers will be called (indeed, they may all run simultaneously).

All Java defines is enough so that the Java runtime itself never chokes on
e.g. an internal null pointer, i.e., your "still there" guarantee. Say you
have a mail server holding a ref to a mail client, which in turn holds a ref
back to the mail server. Can the client object tell the server it's going
away at finalization time? Not if the server object shut down the
communications link beforehand because the server's finalizer happened to
get called first. Etc. Yes, the references are "still there", but without
a lot of pain there's no guarantee they're still in a *useful* state.

"Therefore, we recommend that the design of finalize methods be kept simple
and that they be programmed defensively, so that they will work in all
cases."

good-advice-in-any-language-ly y'rs - tim

[Stidolph, David]

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.


-----Original Message-----
From: Michael Hudson [mailto:mwh21 at cam.ac.uk]
Sent: Tuesday, June 01, 1999 4:55 AM
To: python-list at cwi.nl
Subject: Re: Python 2.0

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
print 'item:',item
Anybody know of a current way to do this?

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

[Ivan Van Laningham]

Hi All--

[re Py_TRACE_REFS]

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

Ay. This is my approach. WIth the added advantage that now I find I
can hypnotize a brick, simply by starting at it.
that-one's-already-asleep-ly y'rs
- Gordon

Yes, but the question we really want to know the answer to is ``Who is
the brick? The starer or the staree?''

<dialectic>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
ivanlan at callware.com
http://www.pauahtun.org
See also:
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
----------------------------------------------

[Tim Peters]

[Hisao Suzuki]

Post by Hisao Suzuki
...
It would be an issue of distributed garbage collection. And it
is a difficulty for automatic GC with finalization.

Yes, there are real problems here, and Python certainly isn't the first to
face them.

Post by Hisao Suzuki
In addition, perhaps we should also take a (close) look at
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz
It summarizes other (or rather more general) issues to consider
in the design of a finalization mechanism (and presents one
solution for Scheme---actually it is adapted by gnu guile). I'd
think anyone who is planning improvements on Python's storage
management has to _notice_ what are summarized there first.

Excellent suggestion; excellent paper, too <wink>.

Post by Hisao Suzuki
(The solution is another story. It is not so obvious for
Python.)
# Certainly the current reference counting system of Python
# reduces the issues to fairly (though _not_ fully) tolerable
# ones...

It automatically deals with the order-of-finalization problem in a correct
way, by following a topological sort of the "references" graph. Which says
almost nothing, since that's *natural* for RC. In return it can't deal with
cycles at all, and indeed it's still easy to write __del__ methods that
trigger mysterious exceptions at system shutdown time, when Python *does*
clean up *some* kinds of cyclic trash (namely the cycles the interpreter
itself creates for its own nefarious purposes).

All in all, though, the lack of "real GC" has never stopped me from doing
anything in Python, nor the lack of "real RC" from doing anything in any
GC'd language. The lack of "any C" in C <wink> has stopped me often in that
language, though.

the-ocean-holds-many-mysteries-but-we-live-longer-than-fish-ly y'rs - tim

[Hans Nowak]

Here is some useful evangelizing (methinks). One of the irritating things about
Python is the use of whitespace in syntax. Agreed, the code is
readable without parentheses or braces, but why not have optional
syntactic sugar such as
if
...
elif
...
else
...
fi
def
...
...
fed
while
...
elihw or wend
for
...
rof
etc. It makes the language more elegant. When I see code using
indentation or blank likes to achieve blocking of constructs, it
reminds me of an old language (FORTRAN I think it was called:-).

If you think it's more elegant, why not try things like this:

if blahblah:
do_this()
do_that()
#fi

for x in my_sequence:
print x
print booze.append(x)
#rof

Or use #endif, #endfor, etc. People have even "implemented" curly
braces this way. It's as optional as you can get, and it really
doesn't require a syntax change.

Veel liefs,

--Hans Nowak (ivnowa at hvision.nl)
Homepage: http://fly.to/zephyrfalcon

[Gordon McMillan]

Michael Hudson writes:

[re Py_TRACE_REFS]

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

Ay. This is my approach. WIth the added advantage that now I find I
can hypnotize a brick, simply by starting at it.

that-one's-already-asleep-ly y'rs

- Gordon