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