Home Original page

Python and Jython are kinda different

Dave Benjamin ramen at lackingtalent.com
Fri Jan 9 18:11:36 EST 2004 
In article <8765fkrig3.fsf at pobox.com>, John J. Lee wrote:
> Yes, but it has been specifically noted by GvR (as well as the
> Jythonistas) that Jython is lacking developers ATM.

I see.

>> represented in books and tutorials--just two implementations of the Python
>> language, we all ought to be more concerned with unifying them. I never see
>> Jython advertised as a limited subset of Python.
> 
> Well, it's *not* a limited subset of CPython 2.1 (apart from tiny
> differences).

True. I suppose this brings up the following question: What *is* "Python"?
Does the concept of Python *today* fit within Jython's feature set? I'd say
much of it does, but a few things stick out, in order of decreasing
importance (IMHO):

 - generators
 - properties
 - getattr/getitem behavior (which is even different from CPython 2.1)
 - type factories being classes
 - dictionary support for "in" keyword

When I think of the Python language, as it stands today, I am tempted to
include all of the above.

I recently ported Python 2.3's "sets" module. I posted a patch here
recently, although I've improved it somewhat and fixed a few bugs 
since then. The lack of an "itertools" module was perhaps my biggest
obstacle (the "for key in adict" feature was another common one). Now, I
suppose I could have tried to port "itertools", but there's no "yield", so
how do I do that? I ended up just using the old map and filter functions,
which means all of that code is back to the old Python memory efficiency.

>> > PyPy is a research effort, so not immediately useful.  It may have big
>> > payoffs if successful, of course.
>> 
>> Well, my thinking is that, since it's an implementation of Python written in
>> Python, many of the new features of CPython that don't require syntactical
>> or fundamental object-model changes could be ported from PyPy to Jython as a
>> temporary fix, to be eventually recoded in Java.
> 
> Library changes don't require PyPy, they already work (most of the
> time) direct from CPython.  It's the fundamentals that take the work.
> I'm not sure whether there's a third category, as you suggest.

Sometimes they do, sometimes they don't. But the list of things that you
can't do in library code if you want to be compatible with Jython 2.1 is
growing. For instance, the "str.join" trick that has been discussed recently
won't work in Jython 2.1 since "str" is not a class. It's a minor thing, but
I bet a lot of people aren't aware of that. Little things like that can add
up.

I've never looked at the code to PyPy, so this is purely speculative, but it
seems like at least a plausible idea to provide an extension mechanism for
Jython such that PyPy code can be incorporated. Imagine if you could add the
"yield" keyword by just importing a pure-Python module. I suppose we'd be
entering macro-like territory, so it'd be controversial...

> I believe GvR said that PyPy might (might!) become a sort of
> executable standard for Python in the future, though.

I think that's an impressive idea, but it almost seems like the resources
spent in keeping PyPy and CPython in parallel could be better spent keeping
Jython and CPython in parallel, seeing as nobody is calling PyPy "Python"
currently.

I will check out the Jython list.

Peace,
Dave

-- 
.:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g   l i f e   o u t   o f   t h e   c o n t a i n e r :
More information about the Python-list mailing list