Python and Jython are kinda different

[Dave Benjamin]

Hey good people,

I've been doing a lot of simultaneous Jython and CPython programming lately,
and just wanted to say, with no intended ill will toward any of the
individuals who have been generous enough to make the two languages
possible, that, well, they're kinda different.

I guess it was inevitable, but with Jython stuck at Python 2.1, it's not
really the same language as CPython is today. You still have to type "from
__future__ import nested_scopes", and there are no generators or properties,
and the type/class dichotomy is still in that awkward state, and you have to
inherit from UserList/Dict, and there are no sets, and you have to roll your
own enumerate() and dict(), and files don't close themselves automatically
(yeah, I know, dream on, hehe...), no csv module, no importing from zips...
wow... it's amazing where CPython has come in such a short time. Well, anyway.

I've never tried the 2.2a0 version (of Jython), mostly because the message
on the site about it being somewhere between 2.1 and 2.3 left me a bit
uncomfortable. ;)

Jython is still a dream to program in compared to Java. So I can't complain.

But it's frozen in a particular state, while CPython is continuing to
aggressivly pursue new ground--like lazy iteration--in ways that change the
Python style; ways that leave me re-implenting not-so-cool versions of the
new style for Jython. In a sense, it's made me really think hard about what
new Python features are really useful, and what are merely new. I definitely
like having the enumerate() function around. And dict(), how could you live
without a complement to dict.items? That should have been in Python -1.0. =)

Is there anyone here that works on Jython? Do you need help? What kind of
help do you need? What's your estimation of the amount of work needed? Is
the work done with PyPy helpful? I'm really curious.

One Love.
One Python.
That sounds dirty.

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 :

[John J. Lee]

Dave Benjamin <ra***@lackingtalent.com> writes:
[...]

Is there anyone here that works on Jython? Do you need help? What kind of
They certainly need help.

help do you need? What's your estimation of the amount of work needed? Is
Asking on the Jython list seems like a good idea.

the work done with PyPy helpful? I'm really curious.

PyPy is a research effort, so not immediately useful. It may have big
payoffs if successful, of course.
John

[Dave Benjamin]

In article <87************@pobox.com>, John J. Lee wrote:

Dave Benjamin <ra***@lackingtalent.com> writes:
[...]

Is there anyone here that works on Jython? Do you need help? What kind of

They certainly need help.

I suppose that was a redundant question. =)

help do you need? What's your estimation of the amount of work needed? Is

Asking on the Jython list seems like a good idea.

Yes. But I think that c.l.p is an appropriate place to bring this issue up
in general, because if CPython and Jython are truly--as they are often
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.

the work done with PyPy helpful? I'm really curious.

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.

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

[John J. Lee]

Dave Benjamin <ra***@lackingtalent.com> writes:

In article <87************@pobox.com>, John J. Lee wrote:

Dave Benjamin <ra***@lackingtalent.com> writes:
[...]

Is there anyone here that works on Jython? Do you need help? What kind of
They certainly need help.

I suppose that was a redundant question. =)

Yes, but it has been specifically noted by GvR (as well as the
Jythonistas) that Jython is lacking developers ATM.

help do you need? What's your estimation of the amount of work needed? Is

Asking on the Jython list seems like a good idea.

Yes. But I think that c.l.p is an appropriate place to bring this issue up
in general, because if CPython and Jython are truly--as they are often

Sure. But the questions you asked can probably be best answered by
the core Jython people.

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

[...]

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.

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

[Dave Benjamin]

In article <87************@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 :

[Jp Calderone]

On Fri, Jan 09, 2004 at 11:11:36PM -0000, Dave Benjamin wrote:

In article <87************@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

All generators can be re-written with classes using the iterator protocol.
Here's a simple example:
# As a generator
def foogen():
yield 1
yield 'a'
yield []

# As classes using the iterator protocol
class _FooGenIterator:
counter = 0

def next(self): return getattr(self, 'state_%d' % self.counter)()
def state_0(self): return 1
def state_1(self): return 'a'
def state_2(self): return []
def state_3(self): raise StopIteration

class FooGen:
def __iter__(self):
return _FooGenIterator()

# Used exactly the same
for i in foogen(): print i
for j in FooGen(): print j
- properties
This is getting closer, I think. More generator, descriptors are pretty
honkin' fundamental these days. On the other hand, most behavior
acheivable with properties can be achieved with __g/setattr__, albeit it
quite as conveniently.
- getattr/getitem behavior (which is even different from CPython 2.1)
I guess I haven't used Jython enough to know what's going on here.
- type factories being classes
This seems pretty important to me, probably the most important on the
list. Metaclasses existed before 2.2, but not without writing an extension
module.
- dictionary support for "in" keyword
This seems pretty trivial to me. It's just a transformation of
dict.has_key().
[snip]

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.

Can't say I agree here, probably because I don't much care about Java ;)
I think PyPy has a lot more bang for the buck for your average Python
programmer. Jython might be nice to bring in some of the Java people, or
make some of that Java work easier when you absolutely have to use it, but
for your average Python application, it hardly enters into the picture.
PyPy, on the other hand opens up a lot of possibilities for future
improvements to the language (because it is easier to prototype new features
in Python than in C) as well as improvements to existing features.
Jp

[Dave Benjamin]

In article <ma**************************************@python.o rg>, Jp Calderone wrote:

All generators can be re-written with classes using the iterator protocol.
Here's a simple example:

Thanks for the nice example. Unfortunately:

Jython 2.1 on java1.4.2_01 (JIT: null)
Type "copyright", "credits" or "license" for more information.

execfile('your-nice-example.py')
for j in FooGen(): print j ....
Traceback (innermost last):
File "<console>", line 1, in ?
AttributeError: __getitem__

Bring back any memories of the days before generators? ;)

- properties

This is getting closer, I think. More generator, descriptors are pretty
honkin' fundamental these days. On the other hand, most behavior
acheivable with properties can be achieved with __g/setattr__, albeit it
quite as conveniently.

Yes, but from my experience the property() builtin is so much more
convenient than __get/setattr__ that I am much more likely to use properties
in CPython. With Jython, I have to overcome my laziness, since it means
writing a fair bit of boilerplate. (example follows)

- getattr/getitem behavior (which is even different from CPython 2.1)

I guess I haven't used Jython enough to know what's going on here.

Here's an example. I sometimes find it useful to create dictionaries that
allow either attribute or item access, a la JavaScript/ActionScript. In
CPython, I can use the (comment to a) recipe from ASPN:

class attrdict(dict):
def __getattr__(self, name):
return self[name]

def __setattr__(self, name, value):
self[name] = value

(http://aspn.activestate.com/ASPN/Coo...n/Recipe/52313)

This seems like it would be a very simple port to Jython, right? It's
actually a bit hairy. In order to get it to work, I had to do the following:

class attrdict(UserDict):
"Dictionary that allows keys to be used as object attributes."

def __init__(self, dict=None, **kwds):
"""attrdict() constructor (behaves like Python 2.3's dict()).
Optionally takes a source dictionary or keyword arguments."""

if hasattr(dict, 'items'):
UserDict.__init__(self, dict)
else:
UserDict.__init__(self)

if dict is not None:
for key, value in dict:
self[key] = value

if kwds:
self.update(kwds)

def __getattr__(self, name):
if self.__dict__.has_key(name):
raise AttributeError, name
elif name == '__members__':
return self.keys()
elif name.startswith('__') and name.endswith('__'):
raise AttributeError, name
else:
return self[name]

def __setattr__(self, name, value):
if name == 'data':
self.__dict__[name] = value
else:
self[name] = value

def __delattr__(self, name):
del self[name]

Whew! Now we're rolling with any version of CPython or Jython 2.1 and up. I
wish I could explain to you how much I had to screw with this to get it to
work. It turns out that the constructor for UserDict tries to create an
attribute called "data", which calls my custom __setattr__, and it gets
stuck in an infinite loop. Many combinations and stack exceptions later, I
finally got what used to be a five-line class working in Jython.

Now, I hope you understand why I'm more privy to properties in CPython. =)

- type factories being classes

This seems pretty important to me, probably the most important on the
list. Metaclasses existed before 2.2, but not without writing an extension
module.

Hmmm... well, metaclasses would be nice, too, but mostly I was thinking of
whether you subclass "dict" or "UserDict" or "types.DictType", and whether
or not things like "str.join" are available. The former, as you can see, can
make a big difference in how you code things. The latter isn't so significant.

- dictionary support for "in" keyword

This seems pretty trivial to me. It's just a transformation of
dict.has_key().

Yep, and there were many such transformations I had to hunt down and fix by
hand when trying to port the "sets" module. A pretty small module, too. It
was error-prone, and I actually missed a serious performance error when I
posted the patch to c.l.p. If anyone is interested, I can post a better
patch, or just send you the file (contact me by email - r!a@m#e%n AT
r^a@m#e&n!f@e&s#t PUNTO com - remove the line noise of course).
> 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.

Can't say I agree here, probably because I don't much care about Java ;)
I think PyPy has a lot more bang for the buck for your average Python
programmer. Jython might be nice to bring in some of the Java people, or
make some of that Java work easier when you absolutely have to use it, but
for your average Python application, it hardly enters into the picture.
PyPy, on the other hand opens up a lot of possibilities for future
improvements to the language (because it is easier to prototype new features
in Python than in C) as well as improvements to existing features.

Well, I have to admit I'm a bit biased. I work in a Java team, and I've been
trying to incorporate Python into the existing infrastructure for the past
year or so. So, personally, I'm not the world's biggest Java fan, and I find
PyPy much more interesting, but Jython has more immediate usefulness.
However, I do find myself doing a lot of extra work to keep my code portable
between Jython and CPython, since it facilitates reuse.

I agree that PyPy presents new possibilities for language experimentation,
and being a total language nerd myself, I'm all for it. =)

However, I just want to make the point that Jython is becoming less and less
"Python" as the evolution of CPython begins to affect the actual style in
which Python code is written. And this makes the popular claim, that Python
is the language, and CPython and Jython are two implementations, a bit
misleading.

But it's a lot easier to complain than to contribute. That I'll readily
admit. =)

Thanks,
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 :