Python 2.0
Graham Matthews
http://www.python.org/workshops/1997-10/proceedings/hugunin.html
>6.2. Python in Java's Advantages
>
>Using Java as the underlying systems language for Python has a number of
>advantages over the current implementation of Python in C. First and
>foremost of these in my mind is the opportunity to ride the Java
>popularity wave and let Python code run everywhere there's a Java VM.
>It also makes the rich set of portable Java API's available from within
>Python.
>
>There is also a nice collection of technical reasons why Java is a
>superior implementation language for Python than C. These include
>Java's binary portability, thread-safety, object-orientation, true
>exceptions, garbage collection, and friendliness to glue languages.
>More questions need to be answered before I can make a convincing
>argument that Python 2.0 should be implemented in Java rather than C.
>Nonetheless, I think that Java offers many advantages for Python as
>both an implementation language and a widely available run-time platform.
What particular intrigues me here is the sentence
>More questions need to be answered before I can make a convincing
>argument that Python 2.0 should be implemented in Java rather than C.
I was wondering if this is seriously being considered -- that is
implementing Python 2.0 in Java rather than C. While I understand
that there are some technical challenges with this (notably interfacing
to the existing C implemented extensions), I personally think there
is a lot to be said for compiling Python to the JVM. For example:
access to the Java apis, garbage collection, true compilation, the
ability to write statically typed code (just write that part in Java!),
access to Swing, promoting Python on the coat-tails of Java (free
publicity and hype), etc.
Comments?
graham
--
Thanks for the trouble you took from her eyes
I thought it was there for good
So I never really tried
Michael P. Reilly
: I read the following interesting snippet at
:
: http://www.python.org/workshops/1997-10/proceedings/hugunin.html
: Comments?
Have you looked at http://www.jpython.org/? It seems to be more in
keeping with your desires.
-Arcege
Paul Moore
Matthews) wrote:
>I was wondering if this is seriously being considered -- that is
>implementing Python 2.0 in Java rather than C. While I understand
>that there are some technical challenges with this (notably interfacing
>to the existing C implemented extensions), I personally think there
>is a lot to be said for compiling Python to the JVM. For example:
>access to the Java apis, garbage collection, true compilation, the
>ability to write statically typed code (just write that part in Java!),
>access to Swing, promoting Python on the coat-tails of Java (free
>publicity and hype), etc.
>
>Comments?
I have no problem with an implementation of Python in Java (see
JPython). But I would never use it (reliance on a JVM, general
dissatisfaction with Java implementations, etc).
What I *would* object to, strongly, would be the lack of a Python
implementation in C. I assume that there is no intention that this
should happen.
How would I embed Python in a C application, without a C API? And how
would I distribute a C application with embedded (Java-) Python to
machines with no JVM, assuming I don't want to (or don't have the
capability to) distribute a JVM.
Enough said.
Paul.
Sam Schulenburg
gra...@sloth.math.uga.edu (Graham Matthews) wrote:
> I read the following interesting snippet at
>
> http://www.python.org/workshops/1997-10/proceedings/hugunin.html
>
> >6.2. Python in Java's Advantages
> >
> >Using Java as the underlying systems language for Python has a
number of
> >advantages over the current implementation of Python in C. First
and
> >foremost of these in my mind is the opportunity to ride the Java
> >popularity wave and let Python code run everywhere there's a Java
VM.
> >It also makes the rich set of portable Java API's available from
within
> >Python.
> >
> >There is also a nice collection of technical reasons why Java is a
> >superior implementation language for Python than C. These include
> >Java's binary portability, thread-safety, object-orientation, true
> >exceptions, garbage collection, and friendliness to glue languages.
> >More questions need to be answered before I can make a convincing
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
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?
>
>
> --
> Thanks for the trouble you took from her eyes
> I thought it was there for good
> So I never really tried
>
The only problem I see with a java implimentation of python, would be
the java security process. It is my understanding that the java sandbox
would prevent embeded programs from accessing low level hardware
functions. I presently use python-c to access the hardware abstraction
layer of both windowsNT and windows95/98. This would not be posible
under java.
Sam Schulenburg
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Robert Meegan
[...]
>
> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the
> ability to write statically typed code (just write that part in Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?
>
For many (if not most) Python programmers, this would be a disaster. In addition
to the many extensions publicly available, it seems inevitable that anyone
coding for long will pick up a number of homegrown extensions. For the
overwhelming majority of programmers who don't know Java (and especially for the
admittedly smaller number who don't *want* to know Java) implementing Python in
Java would remove the option of creating extensions.
Without this ability, many of the tasks for which I use Python would be
virtually impossible. I suspect that many others would feel the same way.
JPython has many features that make it interesting and there are environments in
which it makes more sense than does CPython, but it should not become the only
(or even primary) implementation of Python.
Hier bin ich, ich kann nicht anders.
--- Robert
--------------------------------
Robert Meegan
MCIWorldCom - Cedar Rapids, Iowa
319.375.2416
Graham Matthews
: I have no problem with an implementation of Python in Java (see
: JPython). But I would never use it (reliance on a JVM, general
: dissatisfaction with Java implementations, etc).
Sure current implementations of the JVM are not the best, but they
are improving and will continue to do so. So the "dissatisfaction
with the Java implementations" objection will disappear more and
more over time.
Paul Moore (gus...@morpheus.demon.co.uk) wrote:
: How would I embed Python in a C application, without a C API? And how
: would I distribute a C application with embedded (Java-) Python to
: machines with no JVM, assuming I don't want to (or don't have the
: capability to) distribute a JVM.
:
: Enough said.
I don't think so. Soon every machine under the sun (pun intended)
will have a JVM. Java has a C calling interface, so you can use that
to embed Python in a C application.
graham
--
I would gladly die for a man who was looking for the
truth, but would just as gladly kill a man who thought
he had actually found it -- Voltaire
Helge Hess
>
> How would I embed Python in a C application, without a C API?
Java has JNI which also allows embedding in C applications. This works
quite well for me (at least as good as embedding, personally I even like
it a bit more).
> And how
> would I distribute a C application with embedded (Java-) Python to
> machines with no JVM, assuming I don't want to (or don't have the
> capability to) distribute a JVM.
What's the difference between distributing a JVM or a PyVM ? This is
pretty much the same. Java bytecode also has the advantage that native
compilers are becoming real, eg the gcj compiler of Cygnus.
Maybe Python could use a lightweight/extended JVM, that is, Python could
use Java bytecodes but the JVM native interface could be done more (C)
Python like. This way one could have shared code between (C)Python and
JPython.
Hm, anyway ...
Helge
Hans Nowak
On 27 May 99, Graham Matthews wrote:
> I was wondering if this is seriously being considered -- that is
> implementing Python 2.0 in Java rather than C. While I understand
> that there are some technical challenges with this (notably interfacing
> to the existing C implemented extensions), I personally think there
> is a lot to be said for compiling Python to the JVM. For example:
> access to the Java apis, garbage collection, true compilation, the
> ability to write statically typed code (just write that part in Java!),
> access to Swing, promoting Python on the coat-tails of Java (free
> publicity and hype), etc.
>
> Comments?
While an implementation of Python in Java is a very nice thing to
have (see JPython), I would not be too happy if this were the *only*
version. Java does not run on every system or OS. This would mean
that there won't be, for instance, a Python 2.0 for DOS. (And maybe
other systems. Is there Java for the Amiga, for instance?) Now I know
that most people think that DOS is dead, and technically inferior, so
it won't be a big deal, but there are still quite a few DOS users
around, and it does have its advantages over Windows.
If it will be implemented in C or C++, I can't see how Python 2.0
will *not* compile for DOS, but in Java, it's a different bowl of
soup. Anyway, my point is not really that there should be a DOS
version, but... Right now Python can be built on just about any
system. That's because there's a C compiler for just about any
system. Choosing Java as implementation language would change that.
(And, for a working graphical implementation, one would need, say,
Java, Python and Tkinter...)
This argument may seem feeble but many users of less popular systems
are very glad that there's a Python available for them. I think it
would be desirable to keep it that way.
Why not write it in Caml? At least it will have proper garbage
collection then... :o))
Veel liefs,
--Hans Nowak (ivn...@hvision.nl)
Homepage: http://fly.to/zephyrfalcon
Michael P. Reilly
Not to mention that quite a few people here have mentioned that they
have been trying to port Python to embedded systems (as opposed to
embedding in an app).
Java is a nice-to-have (and we already have it), but the JVM cannot
deal with the world at the level that C can (or ever will by the nature
of the two languages).
-Arcege
Graham Matthews
: (And, for a working graphical implementation, one would need, say,
: Java, Python and Tkinter...)
What about Swing?
graham
--
Je suis pour le communisme
Je suis pour le socialisme
Je suis pour le capitalisme
Parce que je suis opportuniste
Michael P. Reilly
: Hans Nowak (ivn...@hvision.nl) wrote:
: : (And, for a working graphical implementation, one would need, say,
: : Java, Python and Tkinter...)
: What about Swing?
Refer to some of the other threads about the viability of Swing on
various systems.
But I do have to ask, what do you find lacking with JPython, Graham?
It is Python written in Java, on the JVM, with full API support (as far
as I have determined), and supposed "true garbage collection". JPython
functions/methods are written in Java bytecode, not in Python bytecode
(according to the docs).
Not-encouraging-or-discouraging-ly' yrs
-Arcege
Vadim Chugunov
> 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,
collection without keeping a reference counting.
As many people have noted before, you would not be able to use
destructors to free up resources like memory or file descriptors.
> true compilation, the
Why would JVM generate a better code than Py2C does? Does the fact
that the app is spelled using javacode instead of pycode magically
remove the type inferencing problem?
> ability to write statically typed code (just write that part in
> Java!),
Just write that part in C !
> access to Swing, promoting Python on the coat-tails of Java
What makes Swing to be better than any of the existing Python GUI
bindings ?
> (free publicity and hype), etc.
Yeah. Right. Let's rewrite everything using the hottest
language of the day! ;-)
Vadim
Hans Nowak
On 28 May 99, Graham Matthews wrote:
> Hans Nowak (ivn...@hvision.nl) wrote:
> : (And, for a working graphical implementation, one would need, say,
> : Java, Python and Tkinter...)
>
> What about Swing?
Sorry, I don't dance. :)
Graham Matthews
: But I do have to ask, what do you find lacking with JPython, Graham?
: It is Python written in Java, on the JVM, with full API support (as far
: as I have determined), and supposed "true garbage collection". JPython
: functions/methods are written in Java bytecode, not in Python bytecode
: (according to the docs).
I have used JPython (that's where the orginal quote that started this
message came from). My point is that I think implementation via Java is
a good idea and I am wondering if that is being considered for the
future of CPython. ie. abandoning the CPython implementation as the
main Python and adopting a Java implementation instead (reversing the
status of CPython and JPython).
Graham Matthews
: > true compilation, the
Vadim Chugunov (ch...@my-deja.com) wrote:
: Why would JVM generate a better code than Py2C does?
Sure one can use Py2C. But with Java you get dynamic compilation of
all your code with no need to use some auxiliary program like Py2C.
cf. HotSpot.
Graham Matthews:
: > ability to write statically typed code (just write that part in
: > Java!),
Vadim Chugunov (ch...@my-deja.com) wrote:
: Just write that part in C !
Techically you are correct that C is statically typed. But my post
clearly implies that I am interested in strong static typing. That
is type systems that ensure that code cannot have type errors at
runtime. You cannot do this in C. You can't quite do it in Java yet
either, but I am confident that will be so in the future via the
facilities for parametic polymorphism.
Graham Matthews:
: > access to Swing, promoting Python on the coat-tails of Java
Vadim Chugunov (ch...@my-deja.com) wrote:
: What makes Swing to be better than any of the existing Python GUI
: bindings ?
Have you ever used Swing for anything? It is much cleaner that Tkinter
for example. It has a huge range of widgets, etc -- much more than
other toolkits. etc. etc. Sure there are bugs etc but Java is a new
product. Give it a few years and they will have gone away.
Graham Matthews:
: > (free publicity and hype), etc.
Vadim Chugunov (ch...@my-deja.com) wrote:
: Yeah. Right. Let's rewrite everything using the hottest
: language of the day! ;-)
At this point it's the end of the thread for me. I was making a
serious suggestion that Python's use could be improved by pig
backing off the hype for Python. And you ...
Fred Pacquier
>
>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.
>Java, Python and Tkinter...)
>
>are very glad that there's a Python available for them. I think it
>would be desirable to keep it that way.
>
EPOC OS) came out shortly after the machine's release, thanks to a British
hacker. OTOH, Psion users have been bemoaning the lack of the long-promised
Java VM for that platform. It looks like it's only going to be fulfilled this
summer, with the next-generation 5mx, over two years after the original...
J-Python, C-Python, choice is better :-)
Stidolph, David
application to add scripting abilities to it. We decided to go with Python
instead of Java because of the C-Level interface. It gave us the confidence
that we could "hack" into Python when it was required. That would not be
practical for a Java version of Python.
The main thing I would like about JPython would be the Just In Time
compilers available for it.
-----Original Message-----
From: gra...@sloth.math.uga.edu [mailto:gra...@sloth.math.uga.edu]
Sent: Friday, May 28, 1999 4:14 PM
To: pytho...@cwi.nl
Subject: Re: Python 2.0
Michael P. Reilly (arc...@shore.net) wrote:
: But I do have to ask, what do you find lacking with JPython, Graham?
: It is Python written in Java, on the JVM, with full API support (as far
: as I have determined), and supposed "true garbage collection". JPython
: functions/methods are written in Java bytecode, not in Python bytecode
: (according to the docs).
I have used JPython (that's where the orginal quote that started this
message came from). My point is that I think implementation via Java is
a good idea and I am wondering if that is being considered for the
future of CPython. ie. abandoning the CPython implementation as the
main Python and adopting a Java implementation instead (reversing the
status of CPython and JPython).
graham
Paul Prescod
>
> Speaking for myself, we are using Python as an embedded language for an
> application to add scripting abilities to it. We decided to go with Python
> instead of Java because of the C-Level interface. It gave us the confidence
> that we could "hack" into Python when it was required. That would not be
> practical for a Java version of Python.
I wonder if this is truth of perception. I have not tried to extend a JVM
in many years but I wonder how easy/hard it woud be today. JNI is supposed
to do it and I know that Microsoft's proprietary extensions made it very
easy on Windows. I also know that Cygnus working on making C/Java
integration easy. I'd be interested in hearing about people's modern
experiences with Java/C integration.
Another thing to consider is whether we should really still be in the
mindset of manually hacking together languages. Isn't that what
COM/CORBA/OLE and a dozen other standards are supposed to do for us? I
kind of feel that things like SWIG and Perl's XSUB are too useful in that
they don't give us enough impetus to solve this problem once and for all
properly.
I hate to say it but you can do some pretty neat stuff on Windows talking
between languages without a bunch of custom glue code. Why is Unix so far
behind in this regard?
--
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco
Alabama's constitution is 100 years old, 300 pages long and has more than
600 amendments. Highlights include "Amendment 393: Amendment of Amendment
No. 351", "Validation of Laws Regulating Court Costs in Randolph County",
"Miscegenation laws", "Bingo Games in Russell County", "Suppression
of dueling". - http://www.legislature.state.al.us/ALISHome.html
Paul
>
> How would I embed Python in a C application, without a C API?
A Java-bytecode version of Python could have a C API. It could either
have a Python-specific C API or it could use JNI.
> And how
> would I distribute a C application with embedded (Java-) Python to
> machines with no JVM, assuming I don't want to (or don't have the
> capability to) distribute a JVM.
If you could distribute a PVM (Python Interpreter) then you could
distribute a JVM or PyJVM as easily, right?
Paul Prescod
Jeff Bauer
> Good point. As an example, a port of Python for the Psion Series 5
> (under the EPOC OS) came out shortly after the machine's release,
> thanks to a British hacker.
Since this will be the underlying OS for many cell phones (Nokia,
Erikson, Motorola, etc.) I suppose it won't be long before we
can starting hacking Python on our mobile telephones, yes?
Comments, Harri Pasanen?
just-because-you've-absconded-to-the-French-Riviera-doesn't
-mean-you-can-escape-the-Spanish-Inquisition-ly yr's,
-Jeff Bauer
James Logajan
> 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
>
> > I hate to say it but you can do some pretty neat stuff on Windows talking
> > between languages without a bunch of custom glue code. Why is Unix so far
> > behind in this regard?
>
> Unix is behind? In what way? Last I checked, Unix was an OS that has evolved
> to include useful things like threads, IPC mechanisms up the gazoo, dynamic
> linking, and other handy stuff. Now if you meant to say that Unix
> APPLICATIONS are behind, then you need to take your compliant to Unix app
> writers. CORBA is available on Unix and if app writers don't use it, well,
> what can I say?
You _could_ say that Unix apps are behind in this regard and you can push
application writers and OS vendors to fix it.
Of course I wasn't talking about the Unix *Kernel* but I also wasn't just
talking about Unix applications. What about "distributions" as they are
now called? Does AIX itself with CORBA? Is it source-level compatible with
CORBA on Solaris? Can I write a portable Unix app and depend on an ORB
being available? App writers don't use CORBA so vendors don't always
provide it. Vendors don't always provide it so app writers don't use it.
Result: Unix is behind.
When I can install a Linux distribution and use the same ORB to talk to
Gnome apps, KDE apps, Netscape and Apache then I will feel that at least
that variant of Unix will have caught up in this regard.
Michael P. Reilly
: 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
>
> Your conclusion is based on one functionality, which you are incorrect
> about. UNIX has had IPCs for as long as Micros**t has been around (and
> when it originally sold UNIX). They are as powerful, if not more, than
> COM systems, depending on how you use them.
If you are particular perverse you could implement object protocols on top
of stream IPCs but the reverse is much easier. I conclude that object
protocols are more powerful. Do you have counter evidence?
> Tooltalk and other middleware systems have existed on UNIX systems for
> most of this decade, and many applications use them. Tooltalk and
> Softbench are the grandparents of everything you are stating makes the
> Windows platform ahead of UNIX, and they are UNIX creations from before
> Window NT existed.
So you are saying that Unix was ahead in this regard 15 years ago. Is that
relevant?
> There are often better mechanisms in the systems than to use ORBs and
> the like. The applications usually use them.
Okay, so I'm a Python programmer on Windows versus Unix. On Windows I
communicate with my favorite structured editor (which happens not to be a
Microsoft product) through a well-defined protocol implemented in a Python
library. I can do sophisticated queries and navigations through my
document structure using COM. I can compare object references, iterate
over lists of application objects, modify the document structure etc.
Now I have a similar app on UNIX. Are you really going to claim that
tooltalk and stream IPC is going to give me the same functionality? If so,
you should go tell the creators of all of the Linux Office packages
because none of them are using ToolTalk and they are choosing CORBA over
IPC for all main functionality.
> It's not that UNIX is "behind,"
I didn't say that UNIX is behind in general. I said that UNIX had a
weakness in this area. If you would put away the anti-Microsoft chip on
your shoulder you could recognize that, encourage the UNIX community to
fix the problem and we would all be better off.
> Paul, you like Windows; we've all learned that. But to state that UNIX
> is behind simply because you believe that all apps should use one
> functionality isn't going to make your point.
If my point was "Windows is better" then you would be right. But it isn't
my point and it isn't the truth. My point is that Windows is more
functional *in this area*. Is it so hard to admit that there is something
that Redmond could teach Berkley (or Finland)?
If you don't like CORBA (and many people don't) then lets start talking
about what we can make that does the same job better in a cross-platform
way. Surely that's better than pretending a problem doesn't exist just
because the admission would hurt our pride.
Gang Li
Graham Matthews wrote in message <7ik6mi$lbk$1...@cronkite.cc.uga.edu>...
>I read the following interesting snippet at
>
> http://www.python.org/workshops/1997-10/proceedings/hugunin.html
>
>>6.2. Python in Java's Advantages
>>
>>Using Java as the underlying systems language for Python has a number of
>>advantages over the current implementation of Python in C. First and
>>foremost of these in my mind is the opportunity to ride the Java
>>popularity wave and let Python code run everywhere there's a Java VM.
>>It also makes the rich set of portable Java API's available from within
>>Python.
Python is a real programming language. We should not turn it in to a Java
extension.
I hate someone just want to take Python to Java mass and say 'me too'.
Perl, Tcl/Tk,
and Smalltalk have no plan to turn themselves in to a Java extension. Why
Python? If
you love Jave to death, spent all your time to help sun conquer the world.
Don't mess
with Python.
JPython is good enough for Java lover to play with. But Java is not and
will never be
the only universal programming language. Python will live well and better
without Java.
Gang Li
gan...@msn.com
Paul Moore
wrote:
>"Michael P. Reilly" wrote:
>> Paul, you like Windows; we've all learned that. But to state that UNIX
>> is behind simply because you believe that all apps should use one
>> functionality isn't going to make your point.
>
>If my point was "Windows is better" then you would be right. But it isn't
>my point and it isn't the truth. My point is that Windows is more
>functional *in this area*. Is it so hard to admit that there is something
>that Redmond could teach Berkley (or Finland)?
I've got to agree here, to a point.
I'm a Windows programmer because that's what I get paid for. I like
Unix - I've known Unix for far longer than I've known Windows, and I
generally prefer its philosophy over that of Windows. I hate buggy
Windows applications, and I hate under-documented closed source.
But Windows' use of COM/OLE/ActiveX *throughout* is a massive plus (in
concept - the implementation is, as usual, annoyingly buggy). Using
OLE, I can write "glue" scripts in any language I like (Perl, Python,
JavaScript, Visual Basic (God Forbid!), anything with an OLE
interface), to control almost anything (a partial list - E-Mail via
MAPI, Office applications like Excel or Word, XML via the IE5 DOM,
databases via ADO, the shell, ...) using an object-oriented model
(much more programmable than using pipes to send command scripts to
applications). It hides the difficulty involved in having proprietary
application data formats and interfaces, which is a bad thing, but
that problem existed before OLE, so we can't blame OLE for that.
Anyway, my point is that pervasive use of a technology like COM is a
big plus for Windows.
Unix would gain a lot if it took that lesson, and implemented it in
the way Unix does best (ie, implemented it *well*). Maybe CORBA is the
way to do this, and maybe not. But it needs to be done.
On a similar point, Unix's biggest downside is that having so much
choice at all levels (even the shell and window manager) tends to work
against implementation of a common infrastructure like this. A pity,
because the choice is my favourite thing in Unix...!
I repeat - I'm a Unix fan rather than a Windows. I just wish that Unix
users would not be so anti-Windows that they miss the (occasional)
good ideas.
We're well off-topic now, so I'll shut up.
Paul.
Peter A. Koren
>
> ...snip
> Anyway, my point is that pervasive use of a technology like COM is a
> big plus for Windows.
>
> Unix would gain a lot if it took that lesson, and implemented it in
> the way Unix does best (ie, implemented it *well*). Maybe CORBA is the
> way to do this, and maybe not. But it needs to be done.
>
> On a similar point, Unix's biggest downside is that having so much
> choice at all levels (even the shell and window manager) tends to work
> against implementation of a common infrastructure like this. A pity,
> because the choice is my favourite thing in Unix...!
>
> I repeat - I'm a Unix fan rather than a Windows. I just wish that Unix
> users would not be so anti-Windows that they miss the (occasional)
> good ideas.
>
Take a look at the GNOME project. It is more than just a pretty desktop.
It may well be a unifying project for all of the Unix world, bringing
with it a component architecture based on CORBA as the main IPC
mechanism. The GNOME development environment is also designed to be
language neutral. You choose the development language.
The real success of Gnome will come when developers take advantage of
Corba to leverage the resources of others in their own
programs/components/pluggins.
Just my $0.02,
Peter Koren
Darrell
> 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.
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
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
Yukihiro Matsumoto
|Personally I would hate it, if Python had ever adopted a garbage
|collection without keeping a reference counting.
|As many people have noted before, you would not be able to use
|destructors to free up resources like memory or file descriptors.
I don't get it. There's no relation between destructors and real
garbage collection. For example, Java uses destructors called
finalizers, even though most Java VM use real GC.
I hate ref counting. It is memory-leak prone, does not reclaim cyclic
data without explicit cycle-cut. I know, by ref counting, object is
recycled as soon as it looses last reference to it, but relying on
that behavior is error prone, I think.
matz.
Markus Stenberg
> Darrell wrote:
> > Yet my gut evaluation says Gnome can be quite slow.
> > I'm tempted to blame this on Corba.
New one, being developed by RH and friends (ORBit),
> > Also does an open source bridge exist between Corba and COM ?
> > Picture a Corba/COM component that lives in UNIX and is
> > callable from Windows. Sort of takes the hot air out of arguments to use
> > NT servers.
> Good question and good point.
I haven't heard good arguments why to use NT servers so far (except two,
obviously: lack of management clue (=NT <-> moderately easy to set up) and
image of NT being 'cheap' server solution)
-Markus
--
Running Windows on a Pentium is like having a brand new Porsche but
only be able to drive backwards with the handbrake on.
(Unknown source)
Graham Matthews
>>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.
You are envangelising (a not uncommon response when someone remotely
criticises Python). Stop evangelising and start considering the technical
issues involve (read (!) other posts for what those issues are).
graham
--
we howled into Berlin
tore the smoking buildings down
raised the red flag high
burnt the Reichstag brown
Paul Prescod
>
First you say:
> I don't get it. There's no relation between destructors and real
> garbage collection. For example, Java uses destructors called
> finalizers, even though most Java VM use real GC.
But then you say:
> I know, by ref counting, object is
> recycled as soon as it looses last reference to it, but relying on
> that behavior is error prone, I think.
So you do get it. There is a relation, but you just don't think that the
"Python way" is right, You consider the guarantees that Java gives to be
more important than the guarantees that Python does.
But note that Python's guarantees are more important in small, simple
programs and Java's guarantees are better for large, complex programs with
complicated data structures.
http://www.quoininc.com/quoininc/Design_Java0197.html
But I think that the bigger problem with "real GC" is that C programs
often hang on to references to Python objects and any kind of compacting
GC would invalidate those references.
Raymond G. Beausoleil
> 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:
> ability to write statically typed code (just write that part in Java!),
> publicity and hype), etc.
>
> Comments?
Although I have not followed the recent evolution of Java very carefully, I have strong misgivings
about the compromises made in the numerical core of Java. For details, I recommend a quick
review of William Kahan's presentation on this topic:
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
I'm new to Python, but I'm very excited about NumPy and PIL, and I wonder what compromises
would have to made to these extensions if Python were rewritten in Java?
============================
Ray Beausoleil
Hewlett-Packard Laboratories
mailto:bea...@hpl.hp.com
============================
Martijn Faassen
> Gang Li (gan...@msn.com) wrote:
> : Python is a real programming language. We should not turn it in to a Java
> : extension. I hate someone just want to take Python to Java mass and say 'me
> : too'. Perl, Tcl/Tk, and Smalltalk have no plan to turn themselves in to a
> : Java extension. Why Python? If you love Jave to death, spent all your
> : time to help sun conquer the world. Don't mess with Python.
>
> You are envangelising (a not uncommon response when someone remotely
> criticises Python). Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues are).
While the argument you quote has evangelical overtones, it is not *only*
that. There's a real strategic issue involved here -- should one tie
ones destiny to Java. Leveraging Java has a number of strategical and
technical advantages, which you mention. It also has possible
strategical disadvantages:
* Java is right now tied to a single company. It is not (yet) an open
standard.
* Python people do not have a lot of control/influence over the
direction in which the JVM will develop.
* Positioning Python as something on top of the JVM might give people
the idea that it is not really something you can use stand-alone. It can
give people the impression of a 'Java extension'. 'why not just use Java
proper?'
* I believe there are open source JVMs, but are there Python license
JVMs? The whole licensing issue.
These possible disadvantages need a good answer, even we evil
evangelistic people state them in an evangelistic context. :)
Regards,
Martijn
Vadim Chugunov
> garbage collection. For example, Java uses destructors called
> finalizers, even though most Java VM use real GC.
Right, but java finalizers will not be called till the moment the memory is
collected.
Depending on the GC configuration and the program's memory consumption this
may be quite a while.
> I hate ref counting. It is memory-leak prone, does not reclaim cyclic
> data without explicit cycle-cut. I know, by ref counting, object is
> recycled as soon as it looses last reference to it, but relying on
> that behavior is error prone, I think.
Can you explain exactly why is it more error prone?
If something can be done automatically, without writing explicit
deallocation code,
why can't we let it be that way?
I think it all comes to the fact, that some people value the predictability
of the destructor calls over
the ability to reclaim cyclic references, while others feel the other way
round.
OK, I'll try to propose something constructive. Maybe we need an object
protocol, that would enumerate
all references held by an object ? Writing a portable GC would be then much
easier.
Vadim
Peter A. Koren
>
> Although I have not followed the recent evolution of Java very carefully, I have strong misgivings
> about the compromises made in the numerical core of Java. For details, I recommend a quick
> review of William Kahan's presentation on this topic:
>
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> I'm new to Python, but I'm very excited about NumPy and PIL, and I wonder what compromises
> would have to made to these extensions if Python were rewritten in Java?
>
Has Sun done anything about Kahan's objections? This is indeed a serious
matter. A huge percentage of the statistically based studies prior to
the works of Wilkinson and later, Lawson and Hanson, was garbage,
because of poor numerics. This is a show stopper issue for Java in
science and engineering.
If Java does not change, it should be rejected. Too bad. I am a Linux
junkie and would love to see a reformed Java win and Microsoft lose.
I too am thrilled by NumPy, PIL and the other scientific packages that
Hugunin, Hinsen, and Andrich have cooked up and/or packaged. The user
community is as important as the language and Python is rich in both
respects.
--Regards,
Peter Koren
Vadim Chugunov
> 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.
>
>GC. That's just not true.
I'm sorry for being unclear, but the key words here were: "to free up
resources".
And I meant "to free up resources the moment I expect them to", not "some time
later".
BTW, this is a common expectation from anyone coming from a C++ background.
In C++, deallocation in destructors is the only way you can use exceptions
without leaking resources.
Vadim
Darrell
news:al8pv3i...@kruuna.Helsinki.FI...
>
> CORBA is about as fast as COM, protocol-wise I think it is even slightly
> faster (much less action behind the scenes), _but_ many implementations
> suck.
>
> > Also does an open source bridge exist between Corba and COM ?
> > Picture a Corba/COM component that lives in UNIX and is
> > callable from Windows. Sort of takes the hot air out of arguments to use
> > NT servers.
>
> At least M$ brags in their whitepapers that DCOM can access CORBA via some
> bridges (available where? I know not), so I suppose such a beast exists.
>
Wonder if a killer app for python might be to provide scripting on both
sides, DCOM and CORBA.
I have users that run a windows desktop to control Solaris applications.
Currently the NT forces are
winning with the idea of dumping the huge Sun boxes in favor or NT. Of
course everything will be
written in Java ....
This isn't a pressing problem for us yet, but I worry.
--Darrell
Mark Hammond
>> Also does an open source bridge exist between Corba and COM ?
>> Picture a Corba/COM component that lives in UNIX and is
>> callable from Windows. Sort of takes the hot air out of arguments to use
>> NT servers.
>
>At least M$ brags in their whitepapers that DCOM can access CORBA via some
>bridges (available where? I know not), so I suppose such a beast exists.
These tend to cost $$$, as MS typically licenses the technology to 3rd
parties, and you must buy it off them. AFAIK, all COM implementation on
*nix work this way.
OTOH, Python itself would seem an excellent bridge. It has great COM
support, and although I have never seen or used the ILU support, it too is
rumoured to be pretty good :-)
May be an excellent opportunity for someone...
Mark.
Stidolph, David
>protocol, that would enumerate
>all references held by an object ? Writing a portable GC would be then
much
>easier.
Sounds good to me for debugging. A call that could return a list of
everything that holds a reference to an object - that would be cool!
list = GetReferences(object)
print 'List of referencest to',object
for item in list:
print 'item:',item
Anybody know of a current way to do this?
Yukihiro Matsumoto
|First you say:
|> I don't get it. There's no relation between destructors and real
|> garbage collection. For example, Java uses destructors called
|> finalizers, even though most Java VM use real GC.
|
|But then you say:
|> I know, by ref counting, object is
|> recycled as soon as it looses last reference to it, but relying on
|> that behavior is error prone, I think.
|
|So you do get it. There is a relation, but you just don't think that the
|"Python way" is right, You consider the guarantees that Java gives to be
|more important than the guarantees that Python does.
Hmm, I said ``there's no relation between destructors and real GC'',
then said ``deterministic destructor invocation is not needed''.
Even though I believe Java garantees is far more important than Python
garantees as you said, that's nothing do with ``relation between
destructors and real GC''.
Remember the original statement is like this:
>As many people have noted before, you would not be able to use
>destructors to free up resources like memory or file descriptors.
which, as I understand, means destructors can not be used with real
GC. That's just not true.
|But I think that the bigger problem with "real GC" is that C programs
|often hang on to references to Python objects and any kind of compacting
|GC would invalidate those references.
It's the common legend especially here in comp.lang.python.
From my experience with Scheme and Ruby, both with real GC, the real
GC is mostly very fast. Fast enough no one notices its "hang" on most
cases. The legend was formed up by old GC implementation and slower
machines of the past, I guess.
|But note that Python's guarantees are more important in small, simple
|programs and Java's guarantees are better for large, complex programs with
|complicated data structures.
Do you really mean Python the object-oriented programming language
rarely treat complicated data structures? I think Python is good
language, good enough to make people write complex program with
complicated data structures.
I admit ref-counting is far easier to implement. But it's too simple
way for the real language like Python.
|http://www.quoininc.com/quoininc/Design_Java0197.html
This document says ``the real GC with the finalizers do the most of
the jobs'', right?
matz.
Paul Prescod
>
> >As many people have noted before, you would not be able to use
> >destructors to free up resources like memory or file descriptors.
>
> which, as I understand, means destructors can not be used with real
> GC. That's just not true.
Is there a language with real GC where destructors are called as
predictably as they are in Python?
> |But I think that the bigger problem with "real GC" is that C programs
> |often hang on to references to Python objects and any kind of compacting
> |GC would invalidate those references.
>
> It's the common legend especially here in comp.lang.python.
>
> >From my experience with Scheme and Ruby, both with real GC, the real
> GC is mostly very fast.
Speed wasn't my concern. I asked about references in C code. Do we use
PyObject **s instead of PyObject *s now?
> |But note that Python's guarantees are more important in small, simple
> |programs and Java's guarantees are better for large, complex programs with
> |complicated data structures.
>
> Do you really mean Python the object-oriented programming language
> rarely treat complicated data structures?
No, I said that Python is optimized for basic users, not for the experts.
The experts can figure out how to work around problems. The beginning
users cannot. "I'm opening all of the files in a directory in a loop and
in large directories I get out of file handle errors."
--
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco
"Silence," wrote Melville, "is the only Voice of God." The assertion,
like its subject, cuts both ways, negating and affirming, implying both
absence and presence, offering us a choice; it's a line that the Society
of American Atheists could put on its letterhead and the Society of
Friends could silently endorse while waiting to be moved by the spirit
to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's
Yukihiro Matsumoto
"Vadim Chugunov" <che...@yahoo.com> writes:
|> Remember the original statement is like this:
|>
|> >As many people have noted before, you would not be able to use
|> >destructors to free up resources like memory or file descriptors.
|>
|>which, as I understand, means destructors can not be used with real
|>GC. That's just not true.
|
|I'm sorry for being unclear, but the key words here were: "to free up
|resources".
|And I meant "to free up resources the moment I expect them to", not "some time
|later".
Well, OK. I understand now. Now only thing I can say is, why do you
emphasize so much on reclaiming object at the time you exepcted?
Because of your C++ background?
|BTW, this is a common expectation from anyone coming from a C++ background.
|In C++, deallocation in destructors is the only way you can use exceptions
|without leaking resources.
Yes, but it's not true for HIGHER languages like Python or Java (or Ruby).
matz.
Yukihiro Matsumoto
Paul Prescod <pa...@prescod.net> writes:
|> >As many people have noted before, you would not be able to use
|> >destructors to free up resources like memory or file descriptors.
|>
|> which, as I understand, means destructors can not be used with real
|> GC. That's just not true.
|
|Is there a language with real GC where destructors are called as
|predictably as they are in Python?
I said nothing about the destructor invocation predictability.
I don't understand and really interested in why you guys require
to predict destructor invocation so much, but it's another story.
|> >From my experience with Scheme and Ruby, both with real GC, the real
|> GC is mostly very fast.
|
|Speed wasn't my concern. I asked about references in C code. Do we use
|PyObject **s instead of PyObject *s now?
Sorry, I don't understand. Do we have to use PyObject **s instead of
PyObject *s, if we choose real GC?
|> Do you really mean Python the object-oriented programming language
|> rarely treat complicated data structures?
|
|No, I said that Python is optimized for basic users, not for the experts.
|The experts can figure out how to work around problems. The beginning
|users cannot. "I'm opening all of the files in a directory in a loop and
|in large directories I get out of file handle errors."
First, it's not the straight result from real GC. For exapmle, Ruby
uses real GC, and starts GC automatically on that situation. No
problem arise. It's totally a implementation matter.
Second, do you think that optimization for basic users compensates the
risk of potential memory leak, by cyclic structures or missing DECREF
in extension modules? Do you mean it's easy for experts to find
cyclic structure and cut their reference to destruct? For me, it's
not. I hate that. Is this because I'm not a Python expert?
matz.
Fredrik Lundh
> Gang Li (gan...@msn.com) wrote:
> : Python is a real programming language. We should not turn it in to a Java
> : extension. I hate someone just want to take Python to Java mass and say 'me
> : too'. Perl, Tcl/Tk, and Smalltalk have no plan to turn themselves in to a
> : Java extension. Why Python? If you love Jave to death, spent all your
> : time to help sun conquer the world. Don't mess with Python.
>
> You are envangelising (a not uncommon response when someone remotely
> criticises Python).
read his message again. he's saying that Python
shouldn't be tied to Java. sure looks like a tech-
nical argument to me.
if you want some numbers to support his argument,
take a look at GvR's Python poll from the latest
python conference:
http://www.foretec.com/python/workshops/1998-11/polls.html
10% of the audience used JPython today, for non-web
applications. about the same amount used COM.
in other words, proposals to make Python dependent on
Java should be treated about as seriously as proposals to
make Python dependent on COM. they're both available
on all major platforms (at least if you ignore those you
don't happen to use). and they're both supported by
many other tools (at least if you ignore those I don't
happen to use). etc.
> Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues
> are).
exactly. and since you seem to imply that you have con-
sidered those issues, maybe you should follow up on some
of the "non-envangelising" posts instead of miscrediting
people who don't happen to agree with you?
</F>
Paul Boddie
>
> "Vadim Chugunov" <che...@yahoo.com> writes:
[...]
> |I'm sorry for being unclear, but the key words here were: "to free up
> |resources".
> |And I meant "to free up resources the moment I expect them to", not "some
> |time later".
>
> Well, OK. I understand now. Now only thing I can say is, why do you
> emphasize so much on reclaiming object at the time you exepcted?
Because, and I have seen this happen in real-life situations, there's no
guarantee that as the last reference to an object is released all the resources
associated with that object are going to be released at that time. Now, if one
has some kind of object containing a reference to a socket object (for
simplicity let us say that this is a basic resource), then it means that the
socket may for an indefinite amount of time be floating around in a reserved,
but unusable state. Now, if the garbage collector doesn't get around to this
object before one instantiates more of them it is possible that one runs out of
resources: too many sockets in use.
As has been discussed before on this newsgroup/list, such resources get
overlooked in many a garbage collection scheme. I'm sure a perusal of various
news/list archives would provide a substantial amount of relevant literature.
> Because of your C++ background?
It is amusing to note that in (probably most implementations of) Java one has to
write code as one would in C++ in situations like that outlined above, using
explicit destructor-like "close" methods on all resource objects. It isn't
sufficient to let the last reference slip away through one's fingers with a
happy feeling. ;-)
> |BTW, this is a common expectation from anyone coming from a C++ background.
> |In C++, deallocation in destructors is the only way you can use exceptions
> |without leaking resources.
>
> Yes, but it's not true for HIGHER languages like Python or Java (or Ruby).
Absolutely, as far as memory is concerned, but for resources there is a kind of
temporary "resource leak" which is critical, and about which the collector
doesn't apparently care.
Paul
Michael Hudson
If you recompile Python with Py_TRACE_REFS defined, then the sys
module sprouts a "getobjects" function that returns a list of all
objects in existence. This could probably be used to implement
something like this. It would be veeeeery slow, I suspect.
I've never resorted to this approach, tending always to make cyclic
references go away be staring at them very, very hard.
I'm not sure this is at all what is being asked for, but it seems kind
of relavent.
Yours,
Michael
Hisao Suzuki
"Vadim Chugunov" <che...@yahoo.com> wrote:
> Right, but java finalizers will not be called till the moment the memory is
> collected.
> Depending on the GC configuration and the program's memory consumption this
> may be quite a while.
You are right. The JLS (Java Language Specification) says:
The Java language does not specify how soon a finalizer
will be invoked, except to say that it will happen before
the storage for the object is reused. (sect.12.6)
In fact, there is no guarantee that all garbages will be reused,
up to their last one byte, within the life time of the java
process, and there is also no guarantee that ALL finalizers will
be eventually invoked. It is an issue of the quality of JVM
implementation, you know.
> Can you explain exactly why is it more error prone?
> If something can be done automatically, without writing explicit
> deallocation code,
> why can't we let it be that way?
Perhaps it is safe to say that destructors with real GC are more
error prone. (The present Python is safer in this respect!)
In general, real GC simulates infinite memory virtually, and one
should not rely on finalizers; objects remain virtually forever.
With real GC, finalizers should be used only as the last resort.
BTW, Mr. Matz has invented and implemented his excellent
language, Ruby, which is a sort of Perl's successor with some
intrinsic object-oriented features. IMHO, we must have respect
for his opinion as such or, at the very least, as the evangelist
of his own language. See http://www.netlab.co.jp/ruby/
--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzu...@okisoft.co.jp, suz...@acm.org.
Paul Prescod
>
> Ever seen the Amiga variant of REXX? AREXX had a very simple
> interface to compatible applications (compatible meaning that the
> application creates an "AREXX message port"). In (A)REXX, a statement
> line that is not recognized as part of the language itself is sent to
> the current "command interpreter" -- default is the command shell, but
> it can just as easily be an application (ADDRESS
> <application-port-name>).
That's all cool, but on Windows you get to choose your scripting language
which, for Python users, is even cooler. Still, I take your point that
AREXX was years ahead of Windows. And AREXX was ripped off of mainframe
REXX which was, of course, even older.
Paul Prescod
>
> |Is there a language with real GC where destructors are called as
> |predictably as they are in Python?
>
> I said nothing about the destructor invocation predictability.
I consider that a part of the definition of destructor.
> I don't understand and really interested in why you guys require
> to predict destructor invocation so much, but it's another story.
What if I am holding GUI "device context" objects and the GUI has a
limited number of them. I don't think that there is a way to tell the GC
that there is a limited number of them. It doesn't know that device
contexts are a limited resource, just as memory is.
> |Speed wasn't my concern. I asked about references in C code. Do we use
> |PyObject **s instead of PyObject *s now?
>
> Sorry, I don't understand. Do we have to use PyObject **s instead of
> PyObject *s, if we choose real GC?
Imagine I have some C code. It stores away a pointer to a Python object:
PyObject *myObject=someObject;
Now a compacting GC moves someObject. My pointer is out of date, right? If
I want to be able to move someObject around in a mark and sweep style
operation then I need the pointer I hold to be static.
What GC algorithm does Ruby use and how much overhead does it add?
> Second, do you think that optimization for basic users compensates the
> risk of potential memory leak, by cyclic structures or missing DECREF
> in extension modules? Do you mean it's easy for experts to find
> cyclic structure and cut their reference to destruct? For me, it's
> not. I hate that. Is this because I'm not a Python expert?
It's pretty much a toss-up for me. In general I prefer optimizations that
make the language easy for new users to those that are for complex, long
running programs but full garbage collection would make complex programs a
fair bit easier.
Graham Matthews
: But I think that the bigger problem with "real GC" is that C programs
: often hang on to references to Python objects and any kind of compacting
: GC would invalidate those references.
You have two classes of references, compactable and non-compactable.
That solves that little problem.
graham
--
This mountain is not visible from any inhabitable place.
It has no name, and since it's discovery in 1856 by a
British survey team, it has mysteriously resisted every
attempt to name it. The mountain is known simply and starkly
by it's original designation on the surveyor's map ... K2.
Graham Matthews
: As has been discussed before on this newsgroup/list, such resources get
: overlooked in many a garbage collection scheme. I'm sure a perusal of various
: news/list archives would provide a substantial amount of relevant literature.
That word "many" is your key Paul. Just because many a garbage collection
scheme works that way doesn't mean all do, or all have to. It's entirely
an implementation dependent thing.
You are creating a strawman argument that GC cannot properly free resources
like files. But some GC do just that so what is your point?
Stidolph, David
I cannot find a "getobjects" or any other similar function in the source
code or docs. I am using the Win32 version 1.5.2.
Any help would be appreciated,
David Stidolph.
Graham Matthews
: Python is a real programming language. We should not turn it in to a Java
: extension. I hate someone just want to take Python to Java mass and say 'me
: too'. Perl, Tcl/Tk, and Smalltalk have no plan to turn themselves in to a
: Java extension. Why Python? If you love Jave to death, spent all your
: time to help sun conquer the world. Don't mess with Python.
> You are envangelising (a not uncommon response when someone remotely
> criticises Python).
: read his message again. he's saying that Python
: shouldn't be tied to Java. sure looks like a tech-
: nical argument to me.
I suggest you read his post again Fredrik. The only "reasons" he offers
for why Python shouldn't be "tied to Java" are all hyperbole and
evangelism. No technical content whatsoever.
Graham Matthews <gra...@sloth.math.uga.edu> wrote:
> Stop evangelising and start considering the technical
> issues involve (read (!) other posts for what those issues
> are).
Fredrik Lundh (fre...@pythonware.com) wrote:
: exactly. and since you seem to imply that you have con-
: sidered those issues, maybe you should follow up on some
: of the "non-envangelising" posts instead of miscrediting
: people who don't happen to agree with you?
I have followed up Fredrik -- cf. posts on classes of references (some
compactable, some not), colouring mark and sweep collectors, JNI, etc.
But then again I should have known better than to start such a thread.
Michael Hudson
> Py_TRACE_REFS seems to be defined if Py_DEBUG is defined.
>
> I cannot find a "getobjects" or any other similar function in the source
> code or docs. I am using the Win32 version 1.5.2.
Well, Python/sysmodule.c in the source contains this:
static PyMethodDef sys_methods[] = {
/* Might as well keep this in alphabetic order */
{"exc_info", sys_exc_info, 0, exc_info_doc},
{"exit", sys_exit, 0, exit_doc},
#ifdef COUNT_ALLOCS
{"getcounts", sys_getcounts, 0},
#endif
#ifdef DYNAMIC_EXECUTION_PROFILE
{"getdxp", _Py_GetDXProfile, 1},
#endif
#ifdef Py_TRACE_REFS
{"getobjects", _Py_GetObjects, 1},
#endif
{"getrefcount", sys_getrefcount, 0, getrefcount_doc},
#ifdef USE_MALLOPT
{"mdebug", sys_mdebug, 0},
#endif
{"setcheckinterval", sys_setcheckinterval, 1,
setcheckinterval_doc},
{"setprofile", sys_setprofile, 0, setprofile_doc},
{"settrace", sys_settrace, 0, settrace_doc},
{NULL, NULL} /* sentinel */
};
and this:
#ifdef Py_TRACE_REFS
/* Defined in objects.c because it uses static globals if that file */
extern PyObject *_Py_GetObjects Py_PROTO((PyObject *, PyObject *));
#endif
and Objects/object.c contains:
PyObject *
_Py_GetObjects(self, args)
PyObject *self;
PyObject *args;
{
...
This is all on Linux, but the source is the source, as I understand it. I
mean the C source, not the Python Library source... I'd hoped that was
obvious.
I doubt it is documented anywhere - a quick grep through the docs finds
nowt, though Doc/api/api.tex contains the line:
XXX Explain Py_DEBUG, Py_TRACE_REFS, Py_REF_DEBUG.
I'd heard about it sometime on the newsgroup.
> Any help would be appreciated,
If this is what you were looking for, you're welcome.
Michael
Aahz Maruch
Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
>
>Well, OK. I understand now. Now only thing I can say is, why do you
>emphasize so much on reclaiming object at the time you exepcted?
In addition to Paul's excellent comments, if one is writing an
interactive process, one cannot afford the unpredictability of random
garbage collection. Garbage collection could run in a thread, but then
one is restricted to environments where threads are well-supported.
--
--- Aahz (@netcom.com)
Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het
"NRE is a lot like cocaine. Feels great while you're on it, makes you
feel very special and talented, and you become highly annoying to those
who aren't on it." -- Stef
Amit Patel
| Hi.
|
| "Vadim Chugunov" <che...@yahoo.com> writes:
|
| |> Remember the original statement is like this:
| |>
| |> >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.
| |
| |resources".
| |And I meant "to free up resources the moment I expect them to", not "some time
| |later".
|
| 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
Gordon McMillan
[re Py_TRACE_REFS]
> 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
Gordon McMillan
> |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?
As someone used to GC, you would probably never write:
txt = open('blahbalh.txt','r').read()
This is a common idiom for those of us used to ref counting.
You would certainly take a reference to the file object so you could
explicitly close it.
On the other hand, you don't worry about circular references, while
we train ourselves to recognize them and take corrective action.
> Because of your C++ background?
Ironically, C++ can beat the pants off anything else in this regard.
With smart pointers, you can handle ref counts automatically, even
when there are circular references. And since you have the choice
between heap and stack, you can be absolutely certain that you
release resources, even when an exception is thrown.
> |BTW, this is a common expectation from anyone coming from a C++ background.
> |In C++, deallocation in destructors is the only way you can use exceptions
> |without leaking resources.
>
> Yes, but it's not true for HIGHER languages like Python or Java (or
> Ruby).
In this regard, they're a step backwards.
- Gordon
scott cotton
features which might be explored for python 2.0:
0601 12:11 bort:src/kaffe-1.0b4# kaffe --help
Unknown flag: --help
usage: kaffe [-options] class
Options are:
[...]
-ss <size> Maximum native stack size
-mx <size> Maximum heap size
-ms <size> Initial heap size
-as <size> Heap increment
-verbosegc Print message during garbage collection
-noclassgc Disable class garbage collection
[...]
-noasyncgc * Do not garbage collect asynchronously
-oss <size> * Maximum java stack size
0601 12:11 bort:src/kaffe-1.0b4#
Additionally, it's garbage collection takes place through an
interface which can be implemented any number of ways,
including using reference counting.
import gc; gc.refcounting(1)
or
gc.markandsweep(1)
or
class MyGC: pass
gc.setgc(MyGC)
seems like they could come in handy.
memory management has no single ideal for any language, it
seems best to let the programmer manipulate it a bit.
in the land of python-2.0 anything is possible ;)
scott
On Tue, Jun 01, 1999 at 03:39:27PM +0000, Graham Matthews wrote:
| Paul Boddie (pa...@infercor.no) wrote:
| : As has been discussed before on this newsgroup/list, such resources get
| : overlooked in many a garbage collection scheme. I'm sure a perusal of various
| ----
| : news/list archives would provide a substantial amount of relevant literature.
|
| That word "many" is your key Paul. Just because many a garbage collection
| scheme works that way doesn't mean all do, or all have to. It's entirely
| an implementation dependent thing.
|
| You are creating a strawman argument that GC cannot properly free resources
| like files. But some GC do just that so what is your point?
|
| graham
|
|
| --
| This mountain is not visible from any inhabitable place.
| It has no name, and since it's discovery in 1856 by a
| British survey team, it has mysteriously resisted every
| attempt to name it. The mountain is known simply and starkly
| by it's original designation on the surveyor's map ... K2.
|
Barry A. Warsaw
>>>>> "YM" == Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
YM> I don't get it. There's no relation between destructors and
YM> real garbage collection. For example, Java uses destructors
YM> called finalizers, even though most Java VM use real GC.
Interesting side-note, re finalizers and JPython. I recall JimH
talking about finalizers during his JPython code review a few months
back. Here's what I wrote down at the time:
"PyInstances were 2-5x slower [than now] because __del__() was
implemented in a finalize method. But [current] JVMs assume most
classes don't have a finalize [overriding Object's no-op'd
version] and having them on everything slows frees down /a lot/
[emphasis somebody's :) ]"
Apologies to JimH for any transcription errors! But I think he's
correct as implied by the discussion in section 12.6 of the Java
Language Specification:
"We encourage implementations to treat such objects [those that
don't override Object.finalize() or do so only trivially] as
having a finalizer that is not overridden, and to finalize them
more efficiently."
And if you look at the diagram and discussion in section 12.6.1, you
can see why this might be so inefficient!
-Barry
Jeremy Hylton
PP> Yukihiro Matsumoto wrote:
>> |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
>
> 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.
Jeremy Hylton
PP> Jeremy Hylton wrote:
>> 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.
PP> It looks like this conversation has come all of the way
PP> around. We are talking about whether the JVM should be the
PP> default, standard Python distribution platform. It isn't fair,
PP> then, to use the flaws in the JVM version of Python to argue FOR
PP> that change.
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.
It isn't a flaw in JPython that performs differently. It's just a
difference. Your skate on thin ice when you write code that depends
on implementation issues rather than the language spec. It may be
fine if you know what you're doing (love those bytecodehacks!), but
it's hardly something you want to encourage a beginner to do.
Of course, the implementation was sometimes posing as the language
spec until JPython came along.
PP> "Oh well, we'll lose compatibility with PIL but JPython users
PP> have alreadly lost that so I guess it isn't a big deal."
Tilt away <wink>. I took issue with your non-explicit close of a
file, and didn't say anything about the merits of JPython
vs. CPython. See my earlier post in this thread. I think I was
unequivocal in my belief that the next version of Python needed to be
in C or C++.
Jeremy
Yukihiro Matsumoto
|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 <87n1ykr...@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.
Yukihiro Matsumoto
|> I said nothing about the destructor invocation predictability.
|
|I consider that a part of the definition of destructor.
Well,.. is it? That's fine, anyway. Now I understand you.
|> 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.
Of cource you can tell the GC about limitaion, if you can detect
outage of the resource somehow. And you can detect outage for most of
the resources on the machine.
e.g.
fd = open(path, mode);
if (fd < 0 && (errno == EMFILE || errno == ENFILE)) {
call_gc();
fd = open(path, mode);
}
if (fd < 0) {
raise("can't help it");
}
Ruby uses this scheme for most of the resources like fd, sockets. So
you can write something like:
txt = open('blahbalh.txt','r').read()
close() will be called sometime later (not immediately after), but
called for sure. If not called, it's a bug in interpreter.
I don't mean real GC does everything ref counting does. For
exapmle, with real GC:
dialog = GUItoolkit.dialog(params)
... do something with the dialog ...
dialog = None
will close the dialog at unpredictable timing, which is not
desirable for everyone. But I prefer explicit termination of the
dialog for this case.
dialog = GUItoolkit.dialog(params)
... do something with the dialog ...
dialog.close
|What GC algorithm does Ruby use and how much overhead does it add?
Ruby uses conservative mark and sweep GC. It never moves the objects.
The overhead tends to depend on applications, but memory management
overhead is normally less than 5% of the execution (Ruby often runs
faster than Python). And as I said before, the hang is not noticable
for interactive processes.
|> 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.
So you think ref counting is nice for new users, maybe by its
predictability. I don't think so because even new users can make
cyclic references. But it's a toss-up indeed.
matz.
Yukihiro Matsumoto
|> I don't get it. There's no relation between destructors and real
|> garbage collection. For example, Java uses destructors called
|> finalizers, even though most Java VM use real GC.
|
|Right, but java finalizers will not be called till the moment the memory is
|collected.
|Depending on the GC configuration and the program's memory consumption this
|may be quite a while.
|> I hate ref counting. It is memory-leak prone, does not reclaim cyclic
|> data without explicit cycle-cut. I know, by ref counting, object is
|> recycled as soon as it looses last reference to it, but relying on
|> that behavior is error prone, I think.
|
|Can you explain exactly why is it more error prone?
|If something can be done automatically, without writing explicit
|deallocation code,
|why can't we let it be that way?
Well, the reasons why ref counting is more error prone are:
* ref counting never reclaim cyclic references, resulting memory
leak.
* extension module writers are easy to forget to put INCREF(),
DECREF() properly, resulting memory problems (leak or crash).
These two never be caused by real GC. From my viewpoint (of cource
biased), avoiding these is more important than predictability.
|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.
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?
matz.
Yukihiro Matsumoto
|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.
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
Martijn Faassen
[Graham says you're just evangelizing]
[Fredrik replies Gang Li did say something: Python not on Java, and
offers some statistics on what developers do now]
Graham Matthews wrote:
> The only "reasons" he offers
> for why Python shouldn't be "tied to Java" are all hyperbole and
> evangelism. No technical content whatsoever.
Please read my own reply about strategical arguments, which are in my
opinion important as well, along with technical arguments. You offer
some strategical arguments for building Python on top of Java, after
all. For instance, the argument that building Python on top of the JVM
is good because of continued heavy development in speeding up the JVM is
not a purely technical argument, but also a strategical one.
My post didn't have much technical content but seems well-reasoned and
not overly evangelical, I think. I do agree Gang Li's arguments appeal
to emotions a bit too much, but after all I'm butting in on you being
involved in an emotional interchange yourself right now. :) (i.e. "But
then again I should have known better than to start such a thread.")
So let's try to calm down a little and go back to the technical and
strategical concerns behind our emotions. And emotions aren't that bad
after all, as long as we recognize that they're that, instead of shining
rationality. :)
Emotions-are-useful-ly yours,
Martijn
> Graham Matthews <gra...@sloth.math.uga.edu> wrote:
> > Stop evangelising and start considering the technical
> > issues involve (read (!) other posts for what those issues
> > are).
> Fredrik Lundh (fre...@pythonware.com) wrote:
> : exactly. and since you seem to imply that you have con-
> : sidered those issues, maybe you should follow up on some
> : of the "non-envangelising" posts instead of miscrediting
> : people who don't happen to agree with you?
>
> I have followed up Fredrik -- cf. posts on classes of references (some
> compactable, some not), colouring mark and sweep collectors, JNI, etc.
> But then again I should have known better than to start such a thread.
>
Hisao Suzuki
Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
> |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.
This sounds a sort of advocacy of your Ruby...
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.
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.
# Well, in this respect, Ruby might be more indeterministic
# than Python.
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.
# Or, deprecate both __del__ methods and reference counting?
# --- it will result in another language than Python.
Paul Boddie
>
> Paul Boddie (pa...@infercor.no) wrote:
> : As has been discussed before on this newsgroup/list, such resources get
> : overlooked in many a garbage collection scheme. I'm sure a perusal of
> : various news/list archives would provide a substantial amount of relevant
> : literature.
>
> That word "many" is your key Paul. Just because many a garbage collection
> scheme works that way doesn't mean all do, or all have to. It's entirely
> an implementation dependent thing.
Absolutely. I'm not ruling anything out here. ;-)
> You are creating a strawman argument that GC cannot properly free resources
> like files. But some GC do just that so what is your point?
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. Since you have probably played as important a role as anyone in the
previous discussions I mentioned, Graham, perhaps you could indeed enlighten us.
I really don't have any objections to "full" GC, provided it is done in a way
which avoids the pitfalls described in previous posts.
Paul
Yukihiro Matsumoto
|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.
salv...@my-deja.com
Paul Prescod <pa...@prescod.net> wrote:
> Yukihiro Matsumoto wrote:
> >
> > >As many people have noted before, you would not be able to use
> > >destructors to free up resources like memory or file descriptors.
> >
> > which, as I understand, means destructors can not be used with real
> > GC. That's just not true.
>
> predictably as they are in Python?
No, but it could be done in Python, GC isn't incompatible with reference
counting and both can be combined. A simple GC could be added just to
detect ciclical data structures and remove it
Even new special obect methods could be suported by the language to
handle it, say __gc__, that gets called by the GC requesting the object
to liberate its references to other objects so the ciclid data breaks.
> > |But I think that the bigger problem with "real GC" is that C
programs
> > |often hang on to references to Python objects and any kind of
compacting
> > |GC would invalidate those references.
> >
> > It's the common legend especially here in comp.lang.python.
> >
> > >From my experience with Scheme and Ruby, both with real GC, the
real
> > GC is mostly very fast.
>
> Speed wasn't my concern. I asked about references in C code. Do we use
> PyObject **s instead of PyObject *s now?
GC doesn't need to move objects in memory, it's only an optimization
that speeds up memory allocation (it could be implemented with reference
counting too).
The problems associated to GC an foreign modules are usually caused
because the GC doesn't know enough about external objects to determine
its references to native language objects.
- Salva.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Aahz Maruch
Martijn Faassen <M.Fa...@vet.uu.nl> wrote:
>
>* 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.
It might make more sense to simply add tools to locate and stomp
circular references, perhaps augmented by explicit calls to delete
specific instances of circular references.
I'm curious: does GC provide any advantages other than its ability to
deal with circular references?
Donn Cave
...
| I don't mean real GC does everything ref counting does. For
| exapmle, with real GC:
|
| dialog = GUItoolkit.dialog(params)
| ... do something with the dialog ...
| dialog = None
|
| will close the dialog at unpredictable timing, which is not
| desirable for everyone. But I prefer explicit termination of the
| dialog for this case.
|
| dialog = GUItoolkit.dialog(params)
| ... do something with the dialog ...
| dialog.close
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.
I wonder if reference counts could be maintained at a higher level,
still internal but optional as a complement to GC or whatever. The
C extension writer could forget about reference counts, unless the
extension's own objects use the option or its functions handle external
objects that might have reference counts - or perhaps a C extension
could choose to use reference counts when its external library routines
have memory allocation issues that can't be integrated with the GC.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Martijn Faassen
> It might make more sense to simply add tools to locate and stomp
> circular references, perhaps augmented by explicit calls to delete
> specific instances of circular references.
Well, those tools would essentially be a form of garbage collecting,
right?
> 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.
Regards,
Martijn
Graham Matthews
: 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. :)
Here. I posted comments in this thread and in a similar thread about
such systems. They are generally all variations on mark and sweep
collection. The more efficient ones use colouring.
Martijn Faassen (faa...@pop.vet.uu.nl) wrote:
: * 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.
I don't buy either of these difficulties since I have worked with and
implemented systems which have full garbage collection and have no
problems interfacing to C, or dealing with resources like files. These
are all arguments against *some* garbage collection schemes, but not
all.
graham
--
Like a bird on a wire
Like a drunk in a midnight choir
I have tried in my way
To be free
Graham Matthews
: 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.
Graham Matthews
: I'm curious: does GC provide any advantages other than its ability to
: deal with circular references?
You have obviously never worked on a large C project! GC promotes code
modularity. For example say I am using some library, L, and I do a call
to one of it's routines, say f, as follows,
b = some_temporarily_allocated_thing
a = L.f(some_arguments_including_b)
Now at this point does my code have to decref b, delete b, incref a?
The answers to all these questions depends on the precise calling
conventions of the routine f in L. Now what say I had called function
g in L, instead of f, then what would have been the answer to those
questions? It depends on the conventions for g, which may of course
be different to those for f. Moreover what happens if I upgrade to
a new version of the library L -- then what are the answers to the
above questions (they might depend on the version number of the
library L!).
In a garbage collection system you have none of these problems. Code
modularity is improved.
graham
PS: before anyone scoffs I should note that I have encountered all of
the above in large C projects. As well as the usual errors where the
library code forget to incref/decref, or decreffed where they should
have increffed, etc.
Graham Matthews
: 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
Graham Matthews
: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.
Darrell
http://www.iona.com/products/orbix/comet1.html
Also saw a book on this product but can't recall the name.
I go buy it.
--
--Darrell
Darrell
news:11A17AA2B9EAD111BCEA...@forest.origin.ea.com...
> >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.
>
> everything that holds a reference to an object - that would be cool!
>
This would be very useful.
When I've needed this, I didn't want to see everything in the system.
In an effort to avoid performance problems and major changes.
Insert a soon to be designed trace object as a member of the instance you
want to trace. It captures file/line number ...
Haven't I seen this sort of thing here before ?
For those times when you have no idea where to begin.
sys.settrace could be used in some way to watch everything. Slowly yes.
The output could be analyzed for cyclic references. Run this like a lint.
Now that you've found the cycles could some code be auto generated to handle
the clean up ?
--
--Darrell
Tim Peters
> Although I have not followed the recent evolution of Java very
> carefully, I have strong misgivings about the compromises made in
> the numerical core of Java. For details, I recommend a quick
> review of William Kahan's presentation on this topic:
Make that Welvel Kahan, or W. Kahan as he seems to prefer.
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> I'm new to Python, but I'm very excited about NumPy and PIL,
> and I wonder what compromises would have to made to these extensions
> if Python were rewritten in Java?
None, actually -- Python has no IEEE-754 story at all to tell today,
inheriting whatever random stuff the platform's C delivers, and having a
design in some areas that precludes 754 conformance (e.g., x == x is always
true in Python, and by design). Java's rules are actually closer to 754
conformance than most popular languages'.
[Peter Koren]
> Has Sun done anything about Kahan's objections? This is indeed a serious
> matter.
If you read to the end of the paper, you'll find
Java’s floating-point suffers from serious oversights. The same could
be said of several other programming languages,
Ahem -- try replacing "several" with "virtually all" <0.1 wink>.
some of them venerable, but Java lacks their historical excuses.
Recognize the polemic for what it is. Java is likely much closer to
mandating substantial 754 conformance that whatever language you're using
today!
> A huge percentage of the statistically based studies prior to
> the works of Wilkinson and later, Lawson and Hanson, was garbage,
> because of poor numerics. This is a show stopper issue for Java in
> science and engineering.
Java is a whale of a lot closer than Fortran or C++ -- or are the sci/eng
folks all programming Borneo now <wink>?
754 provides some wonderful tools for true experts that Java doesn't yet
expose, but no tweaking of finite floating-point arithmetic rules is going
to save anyone from a numerically naive algorithm. Directed rounding modes
and signed zeroes et alia don't do you any good unless you know how to use
them and apply them with extreme care -- and very few people do or can. For
the rest, Java mandates IEEE nearest/even results, which is likely more than
what they're guaranteed today.
> If Java does not change, it should be rejected. Too bad. I am a Linux
> junkie and would love to see a reformed Java win and Microsoft lose.
MS has seemed to move away from the 754 spirit in its language
implementations rather than closer to it. So if full access to all 754
features is what drives the market, MS will surely die within a few short
years <breath-holding wink>.
> I too am thrilled by NumPy, PIL and the other scientific packages that
> Hugunin, Hinsen, and Andrich have cooked up and/or packaged. The user
> community is as important as the language and Python is rich in both
> respects.
Yes it is! But if Java's 754 story is a disaster, we'll need a new word for
Python's.
754-is-a-hw-std-that-almost-all-sw-still-ignores-ly y'rs - tim
Tim Peters
> 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
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.
Gordon McMillan
> Yukihiro Matsumoto wrote:
>
> > 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. :)
That would probably be Ken Thompson discussing Inferno. William
Tanksley mentioned this recently. You can read the interview at
http://computer.org/computer/thompson.htm
> * 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.
Unpredictability has been well-thrashed recently. Two posters have
mentioned that GC doesn't *have* to be unpredictable, but I've never
seen one that wasn't. I can attest to GC not necessarily imposing
difficulties in writing extensions. Writing Java native methods in
MS's RNI is very straightforward. No pointers to pointers. They use
generational GC. In the context of a native call, nothing will be
moved. You can "fix" an object before returning to Java, and
otherwise control GC. Not as slick as using CXX, but easier than
Python's C API.
- Gordon
Jeremy Hylton
PP> Jeremy Hylton wrote:
>> 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.
PP> This is a documented feature of Python (documented in the FAQ at
PP> least). New users do not currently need to learn otherwise
That doesn't count! Among other reasons, the FAQ predates JPython.
Guido and Jim spent some time going through the differences between
CPython and JPython, and deciding which of the differences where
legitimate and which were bugs or incompatibilities. I believe that
memory management is one of those implementation-dependent issues that
the language semantics do not specify.
PP> unless they use JPython which is incompatible in this regard. In
PP> other words, this IS a demonstration of a flaw in GC, or at
PP> least in Java GC because it required a change in the Python
PP> language semantics.
Don't think it's fair to call it a change-- just a clarification. Nor
would the problem necessarily lie with the garbage collector. If the
language spec had said that finalizers were always called such that
you could depend on it to free resources like file descriptors, then
it would have been a bug in the spec <0.1 wink>.
PP> I think that that is all anyone has been saying. Many people
PP> like the current semantics and don't trust that a full GC would
PP> deterministically invoke finalizers for arbitrary resources.
I'm sure it wouldn't, but as the FAQ entry you mentioned explains,
there are some exceptions with reference counting, too. In general,
it's a rather risky to depend on the finalizers to close resources for
you. Even with reference counting, it's easy to have one more
reference than you think and not have some files get closed.
Jeremy
Hisao Suzuki
Yukihiro Matsumoto <ma...@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 see that is the way of your own excellent Ruby, but it is not
the manner of the present Python.
Donn Cave
| Donn Cave (do...@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).
Does JPython use reference counts, and invoke delete methods as soon as
reference count drops to 0?
| ... 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.
Well, I think there's something to be said for it. With Python, we're
free from the obnoxious requirement imposed by the storage model of
languages like C, that forces the programmer to account for each scrap
of malloc'd memory lest there be leaks. That allows me to export an
object reference (e.g., via function return) and forget about it, and
that has radically beneficial implications for how things can be structured.
Why should I enjoy this freedom with memory resources, but welcome exactly
the same constraints when an object has other termination requirements?
Graham Matthews
| 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).
: Does JPython use reference counts, and invoke delete methods as soon as
: reference count drops to 0?
I don't think reference counting garbage collection is mandated in Java
(it used to be but I think that has changed).
But I am not sure I see what the connection is between how JPython does
memory management and garbage collection in Python in general.
gra...@sloth.math.uga.edu (Graham Matthews) writes:
: | ... 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.
Donn Cave (do...@u.washington.edu) wrote:
: Well, I think there's something to be said for it. With Python, we're
: free from the obnoxious requirement imposed by the storage model of
: languages like C, that forces the programmer to account for each scrap
: of malloc'd memory lest there be leaks.
: ...
: Why should I enjoy this freedom with memory resources, but welcome exactly
: the same constraints when an object has other termination requirements?
Because other kinds of objects are different to memory? Also I am not
sure why you think GC can't handle other kinds of objects as well. Maybe
Java doesn't do a good job of resource finalisation, but that doesn't
mean it can't be done.
graham
--
Bang, bang, Maxwell's silver hammer came down on her head
Bang, bang, Maxwell's silver hammer made sure that she was dead
Yukihiro Matsumoto
|In article <87pv3eo...@ev.netlab.co.jp>,
|Yukihiro Matsumoto <ma...@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 <u37lpnd...@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.
Hisao Suzuki
gra...@sloth.math.uga.edu (Graham Matthews) wrote:
> 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.
Hisao Suzuki
Martijn Faassen <faa...@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?
|
| 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...
Paul Boddie
[...]
> But I am not sure I see what the connection is between how JPython does
> memory management and garbage collection in Python in general.
[...]
> Donn Cave (do...@u.washington.edu) wrote:
> : Well, I think there's something to be said for it. With Python, we're
> : free from the obnoxious requirement imposed by the storage model of
> : languages like C, that forces the programmer to account for each scrap
> : of malloc'd memory lest there be leaks.
> : ...
> : Why should I enjoy this freedom with memory resources, but welcome exactly
> : the same constraints when an object has other termination requirements?
>
> Because other kinds of objects are different to memory? Also I am not
> sure why you think GC can't handle other kinds of objects as well. Maybe
> Java doesn't do a good job of resource finalisation, but that doesn't
> mean it can't be done.
So, we have established that it can indeed be done, but reaching back into the
depths of time and pulling out the original proposal - being that Python should
have its primary (or only) implementation running in the Java environment - we
can see that regardless of the existence of satisfactory GC schemes, the typical
Java implementation surely falls short of what many people require.
Therefore, whilst there may well be a need for more sophisticated GC in Python
2.0, we must conclude that the Java environment may not be the appropriate place
in which such technologies are to be found.
Paul
ad...@technologist.com
gra...@sloth.math.uga.edu (Graham Matthews) wrote:
> Aahz Maruch (aa...@netcom.com) wrote:
> : 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.