jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

Re: [Jython-dev] What is a Skeleton?

[Kevin D. <kda...@we...>]

----- Original Message -----
From: "john coppola" <joh...@ya...>
To: "Samuele Pedroni" <pe...@in...>
Cc: <jyt...@li...>
Sent: Wednesday, August 08, 2001 4:46 PM
Subject: Re: [Jython-dev] What is a Skeleton?


> > I'm confused again,
> >
> > I think that in the end simply unplugging the python
> > class and plugging
> > a java class in would be simpler ...
>
> What happens when one tries to unplug the java class?
> Class doesn't work anymore.  Also, can't use same code
> in cPython because of the java class.

Ahh... this is the first part I've seen that is different from what you can
do with PyMetaClass/ExtensionClass. So, what you're going for is an object
that is completely coded in Python and will run fine in CPython, but can
take advantage of methods and attributes stored directly in Java for
performance reasons.

Something like that may be useful for someone targetting both Python and
Jython. For someone working on Jython alone, there are other ways to
accomplish the same thing.

Kevin

[Jython-dev] Your Web Site is Not Responding

[<ada...@ma...>]

There appears to be a problem in reaching your Web site at
http://www.sunseeker-balearics.com/indexger.html.

   Time of Error: 2001-08-08 16:54:51
   Error Type: 404 Not Found

InternetSeer, a Web site monitoring company, is conducting an
ongoing study of the true connectivity of the Web. As recommended
by the Robots Guidelines, this email is being sent to explain our
research activities and to let you know about the difficulty in
connecting to your site.

If you would like InternetSeer to continue to alert you at no charge
whenever there is a problem reaching your Web site, click here:
http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57g5k5f5j5i55V5qCJPQUntbI5c_RJ5sCSzPW5axwPzRVDwwMM5aIMx53U5pXTxy5p5b5cKTU5dzWyzRMQRP596v_SR_wLRz5bRIH5eXIDVJLVz5dMPNS53T5p5e=e3

InternetSeer does not store or publish the content of your pages,
but rather uses availability and link information for our research.

Click here to learn more about InternetSeer.
http://scclick.internetseer.com/sitecheck/clickthrough.jsp?I5s57g5k5f5j5i55V5qCJPQUnubI5c_RJ5sCSzPW5axwPzRVDwwMM5aIMx53U5pXTxy5p5b5cKTU5dzWyzRMQRP596v_SR_wLRz5bRIH5eXIDVJLVz5dMPNS53T5p5f=e3

Adam Brett
Survey Manager
cs-...@ma...

Note: If you prefer not to receive these occasional alerts regarding
the availability of your Web site, reply to this email with Cancel
in the 

Re: [Jython-dev] What is a Skeleton?

[john c. <joh...@ya...>]

> I'm confused again, 
> 
> I think that in the end simply unplugging the python
> class and plugging
> a java class in would be simpler ...

What happens when one tries to unplug the java class? 
Class doesn't work anymore.  Also, can't use same code
in cPython because of the java class.

What if one tries to set a new attribute a.foo="foo"
on the jclass.  The dynamic behavior is lost.  Can't
do it at all because a jclass is entirely static.  A
Jython class with a backbone still enables attribute
setting dynamically.  It has an ethereal existence in
both the Python world and the Java world.


class EggFarts:
   def __init__(self):
        self.a = 'a'  # defined in skeleton so
                      # set_a called in skeleton
                      # backbone
        self.b = 'b'  # defined in skeleton so
                      # set_b called on skeleton
                      # backbone

        self.drank_too_much_beer = "advil"
             # not defined in skeleton
             # so will be set here in the
             # EggFarts instance. Skeleton
             # class unaware of its
             # exisitence.
                    
public class EggFartsSkeleton extends PyObject {
    private String a;
    private String b;

    public void set_a(PyString ob) {
        a=ob.internedString();
    }
    public String get_a() {
        return a;
    }

    public void set_b(PyString ob) {
        b=ob.internedString();
    }
    public String get_b() {
        return b;
    }

    public void get_a() {
        return a;
    }
    


Why the getter and setter methods?

Enanbles me to delegate retrieval of the skeleton of
another PyObject in the skeleton class itself.


-john


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Jython and native java merged with simplicity

[Samuele P. <pe...@in...>]

[Finn]
> I guess that you get a speed increase because the the test for skeleton
> is located early in the __findattr__ method. The result of such an early
> test is all non-skeleton instances will run a little bit slower, rigth?.
> If that is the case, you will have a tough job selling it.
> 
Yes, but the short-cutting PyInstance should not be the general PyInstance,
that's why I said maybe it can go in, once it will be clear how to express this
in terms of meta-classes.

My concern is that you still have to use reflection to call java code from
jython, so depending on the granularity of the logic that you have rewritten
in java you can get a speed-up or nothing you could even measure.

[Side-note: In general some kind of caching logic can give some similar benefits 
- in a more general setting - but then you have to deal with dynamic changes to 
classes, memory use and multi threading issues. ]

I agree with your opinion on the benchmark but I don't think it (the benchmark) 
is relevant to the problem. It s just a bit of partial sad "truth" exposed in an 
unfair way.

My initial understanding is that this could be used somehow to make some
final optimization using Java code over a design prototyped in pure jython.
But it is still fully unclear whether this buy us something concretely,
or is just (neat) hacking.

Further the idea of nesting, also skeletons all down the way, seems not 
workable.

regards, Samuele Pedroni.

Re: [Jython-dev] Jython and native java merged with simplicity

[<bc...@wo...>]

[john coppola on ghosting and skeletons]

Do you have any code available that I can play with? Based only on your
description, I find it very difficult to understand the philosophy and
goals behind your suggestions.

Assuming that Samuele understod you correctly in the jmerge example, it
seems like the java skeleton should override (or at least hide) the
similar python method. Sort of the same goes for attributes where the
set_/get_ methods in the skeleton is used to intercept attribute access.

Right so far?

I guess that you get a speed increase because the the test for skeleton
is located early in the __findattr__ method. The result of such an early
test is all non-skeleton instances will run a little bit slower, rigth?.
If that is the case, you will have a tough job selling it.

>    public int get_b () {
>        return b;
>    }

I note that references to "b" from python will create a new PyInteger to
hold the returned result. So this particular definition of "get_b"
favors a usage where the skeleton methods makes a lot of changes to "b"
and the python world only retrives the "b" value a few times.

How would a method implemented in the skeleton call a method on the
python instance? Your SpamSkeleton example does not seem to have a
reference to the python instance.

>from time import time
>def test():
>    start = time()
>    total = 0.0
>    for i in range(0,1000000):
>        total = total + i + i*2.0
>    print time()- start
>
>This test on my computer:
>  python2.0:                     2.77 seconds
>  jython2.1a1:                   7.40 seconds
>  native java:                   0.014 seconds

Now, that is the worst test you can possible use and it certainly will
not convince me of anything important. A far better test is the micro
benchmark by Marc-André Lemburg. 

 http://www.lemburg.com/files/python/index.html

(I haven't run this for a while, but older version could run with
jython)

The result of the benchmark can be confusing because of the way hotspot
works, but it clearly show changes (both good and bad) when making
performance related changes to the core. Adding new tests that exercise
a skeleton class should be possible.

Most importantly, I urge you to show some code. You could for instance
make a patch and put in jython's patch manager. 

regards,
finn

Re: [Jython-dev] What is a Skeleton?

[Samuele P. <pe...@in...>]

> 
> Even though in the class self.a is defined, because
> the skeleton has this attribute, it is never stored in
> the PyInstance but instead the skeleton instance via
> the getter and setter methods.
> 
> Thats all for now.  To really utilize the power I must
> implement functionality that will allow nesting.  So a
> list of objects with the restriction that they are of
> the same class will becomes a list of skeletons in the
> native java skeleton.  That's where the real
> performance boost will be.
But this will be quiet tricky, and now you will need to store
things twice (the list of skeleton in the skeleton and the full body list for 
python side), and too keep them synchronized (not simple at all) etc ...


I'm confused again, 

I think that in the end simply unplugging the python class and plugging
a java class in would be simpler ...

regards, Samuele Pedroni.

[Jython-dev] What is a Skeleton?

[john c. <joh...@ya...>]

Hello Michael.

What is a skeleton?

In much the same way a skeleton supports our body, a
skeleton java class will support the native python
class.  Python is amorphous and highly dynamic.  With
this flexibility there comes a penalty, lower speed. 
For most things, speed is not important but for other
things is it.


A skeleton gives our Python class a backbone. 
Even-though we can bend our bodies in many different
shapes, our skeleton prevents us from turning inside
out.


A skeleton is a set of attributes and or methods
implemented in the native java backbone.   They should
in theory do exactly the same thing as they do in the
python class (ghosting).  Of course this is up to the
programmer to verify by use of a good test suite.


Because of the way the Jython interpreter works (and
my implementation), Jython has absolutely no way of
knowing the difference between values stored in the
the java skeleton or the native Python object.

The benefit we get from this is that computationally
intensive algorithms could be ported to native java
while preserving the Python and Jython
interchangeability.  We implement that functionality
in the true python class anyway but if a skeleton
class exists, search the skeleton first for that
attribute.

Things are faster because:
  A) the skeleton class is native java.
  B) data is already available in native java form

The nice thing about it is that the Python class
should still work without the backbone.  The skeleton
has access to the data in native java form without
going through api layers.  We use the skeleton to
address efficiency issues.

Speed boost is enormous.  For a example, here are some
numbers for a simple program:

from time import time
def test():
    start = time()
    total = 0.0
    for i in range(0,1000000):
        total = total + i + i*2.0
    print time()- start

This test on my computer:
  python2.0:                     2.77 seconds
  jython2.1a1:                   7.40 seconds
  native java:                   0.014 seconds

Native java is:
* 197 times faster than Python
* 528 times faster than Jython
 # perhaps I should have used xrange (o:

A big light bulb went off.  I needed a way to harness
this power without sacrificing too much python
flexibility.


Here is an example of how they might be used together.

#a python class
class Spam:
    def __init__(self,aFloat,bInteger,cString):
        self.a = aFloat
        self.b = bInteger
        self.c = cString


//java Skeleton class
public class SpamSkeleton extends PyObject {
    private double a;
    private int b;
    private String c;

    public void set_c(PyString ob) {
        c=ob.internedString();
    }

    public String get_c() {
        return c;
    }

    public void set_b (PyInteger ob) {
        b=ob.getValue();
    }

    public int get_b () {
        return b;
    }

    public void set_a (PyFloat ob) {
        a = ob.getValue();
    }

    public double get_a() {
        return a;
    }
}
    

The concept is still in its conceptual stages.

from Spam import Spam
import SpamSkeleton
a=Spam(__skeleton__=SpamSkeleton())

I intercept the __skeleton__ keyword in the
constructor in PyInstance.  So even though it is not
defined in the __init__ function of Spam it will work.

To make this code portable:
from Spam import Spam

import sys
if sys.platform == "java":
   import SpamSkeleton
   a=Spam(__skeleton__=SpamSkeleton())
else:
   a=Spam()

Even though in the class self.a is defined, because
the skeleton has this attribute, it is never stored in
the PyInstance but instead the skeleton instance via
the getter and setter methods.

Thats all for now.  To really utilize the power I must
implement functionality that will allow nesting.  So a
list of objects with the restriction that they are of
the same class will becomes a list of skeletons in the
native java skeleton.  That's where the real
performance boost will be.

Will have something whipped up by next week with some
hard numbers for performance comparisons.


have fun,
John Coppola


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Pickling for PyMetaClass

[Samuele P. <pe...@in...>]

Hi.

> 
> Good news. A bit of reading through cPickle.c and cPickle.java showed me the
> way. ExtensionClass.c does, in fact, use reduce, and I discovered that
> load_reduce looks for __basicnew__ if the args tuple is None. So, that all
> works fine. (see below...)
> 
> > > With a small patch to __builtin__.type(), we can get around this:
> > >
> > >     public static PyClass type(PyObject o) {
> > >         if (o instanceof PyInstance) {
> > >             return PyJavaClass.lookup(o.getClass());
> > >         } else {
> > >             return o.__class__;
> > >         }
> > >     }
> > >
> > > (replacing PyJavaClass.lookup(PyInstance.class) with
> > > PyJavaClass.lookup(o.getClass())
> > Yes, I see the point. I should admit that I feel a bit uncomfortable
> > with this design driven by the matter of events and without a whole
> > picture. But the patch can go in with the same transitional status
> > of the PyMetaClass hook. See below ...
> 
> This patch is necessary to support user-defined Instance classes and
> pickling... It looks like no other change is needed for this to work,
> though.
> 
> Kevin
> 
I have commited that. BTW with the experimental status of the other
PyMetaClass related stuff.

regards, Samuele Pedroni.

RE: [Jython-dev] Jython and native java merged with simplicity

[Garcia, M. <mg...@Bu...>]

I'm confused about this topic you guys are discussing.  Can you please
elaborate as to what benefits this would have or what purpose this will
serve?

thanks,
Mick 

-----Original Message-----
From: john coppola
To: Samuele Pedroni
Cc: jyt...@li...
Sent: 8/7/01 9:56 PM
Subject: Re: [Jython-dev] Jython and native java merged with simplicity

thanks for the encouraging remarks!

these dev discussions have been really good.

lots of thinking going on...


I already have something preliminary whipped up.
And it is pretty simple like I though it would be.  As
expected the ghosting does not slow the interpreter
down since the method calls on the java skeleton are
fast.

Now the real speed up will be when I do benchmarking
of algorithms done in python against the same
algorithms implemented in the ghost class on ghost
attributes.


> Why this two-places approach? once you have a
> skeleton
> you can store things there, unless an attribute
> is not a pre-existent java field.

Your right!  No duplication at all.  A bit of tweaking
to dir function and __dict__.keys() things like that.
Doesn't look like this will break anything!


So far I haven't needed to use reflection.  I don't
think I will, since that step has already been done
for me by way of the interpreter.

The way that I am doing it now, for each attribute foo
in the skeleton class, one must define accessor
methods set_foo and get_foo.  Perhaps this is
cumbersome.


-john


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
Jython-dev mailing list
Jyt...@li...
http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] dir and __dict__ work!

[john c. <joh...@ya...>]

This was an unexpected dividend!  The skeleton class
is intercepting the attribute in both __findattr__ and
__setitem__ so it is never actually explicitly set on
the python object. Both dir() and __dict__ are showing
the desired result.

quite nice indeed.

ok bed time.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Jython and native java merged with simplicity

[john c. <joh...@ya...>]

thanks for the encouraging remarks!

these dev discussions have been really good.

lots of thinking going on...


I already have something preliminary whipped up.
And it is pretty simple like I though it would be.  As
expected the ghosting does not slow the interpreter
down since the method calls on the java skeleton are
fast.

Now the real speed up will be when I do benchmarking
of algorithms done in python against the same
algorithms implemented in the ghost class on ghost
attributes.


> Why this two-places approach? once you have a
> skeleton
> you can store things there, unless an attribute
> is not a pre-existent java field.

Your right!  No duplication at all.  A bit of tweaking
to dir function and __dict__.keys() things like that.
Doesn't look like this will break anything!


So far I haven't needed to use reflection.  I don't
think I will, since that step has already been done
for me by way of the interpreter.

The way that I am doing it now, for each attribute foo
in the skeleton class, one must define accessor
methods set_foo and get_foo.  Perhaps this is
cumbersome.


-john


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Jython and native java merged with simplicity

[Kevin D. <kda...@we...>]

----- Original Message -----
From: "john coppola" <joh...@ya...>
To: <pe...@in...>; <jyt...@li...>
Sent: Tuesday, August 07, 2001 6:08 PM
Subject: Re: [Jython-dev] Jython and native java merged with simplicity


[snip]

> What is important about the nature of ghosting is that
> information is stored in both the java native skeleton
> and the real PyObject.  The same information in two
> places.  Somewhat of an OO no no.  But I am willing to
> make this trade off to get 500x performance boost.
> Since all it requires is a bit a maintenance work in
> well tucked away places.
>
>
> This seems funny, and alot of work, but really isn't.
> Once you see the speed boost obtained from doing bulk
> processing you may deem this feature worthwhile.

Hmm... It seems like what you're talking about can be already accomplished
with ExtensionClass (today) and possibly 2.2's class/type fix (tomorrow). I
haven't read much about the 2.2 functionality.

phabric's Acquisition module uses the ExtensionClass mechanism.

For convenience, Acquisition is implemented as a Python module:

http://cvs.phabric.org/index.cgi/phabric/py/Acquisition.py?rev=1.5&content-t
ype=text/x-cvsweb-markup

But, if you look at the ImplicitAcquisitionWrapper, the heavy lifting is
done completely in Java and with Java variables. When you have an instance
of an ImplicitAcquisitionWrapper, what you have is not an
org.python.core.PyInstance, but an org.phabric.ec.AqWrapper:

http://cvs.phabric.org/index.cgi/phabric/src/org/phabric/ec/AqWrapper.java?r
ev=1.3&content-type=text/x-cvsweb-markup

Currently, the ExtensionClass package will use reflection to automatically
find public methods, and it adds those methods to the class __dict__. It
would be possible to add support to ExtensionClass to do something similar
for attributes.

So, if you call foo.aq_acquire it looks in foo's __dict__, finds aq_acquire
and calls it. The search through the containment hierarchy happens
completely in Java, using Java's aq_self and aq_parent variables.

Rather than changing PyInstance itself, ExtensionClass just instantiates a
class that extends PyInstance.

Kevin

p.s. What I said above still stands, but I just realized that I haven't yet
committed the more complete form of aq_acquire that I've recently
finished...

[Jython-dev] WebStart

[Romain G. <rom...@je...>]

    Hi everyone !

    I'm developing a programmer's editor called Jext. I intensively use
Jython as a scripting language to write the code of the interface menu
items. I used to provide a Java WebStart release of Jext. Yet, Jython seems
not to be able to use the classes which are stored within the jars
downloaded by WebStart. If, for instance, I try to import org.jext.Utilities
from jext.jar in a Jython script, assuming that jext.jar and jython.jar were
downloaded by WebStart, I got a "module not found: jext" error from Jython.

    Is this planned to fix this, do you know any workaround ? (putting
jython.jar and jext.jar into the same jar does not fixes the bug).

    Thanks (please CC your answers to rom...@je... :)

Romain "Java Swinguer !" Guy
rom...@je...
www.jext.org

"Now, don't you worry. The saucers are up there. The graveyard is out there.
But I'll be locked up safely in there."
- Paula Trent, Plan 9 From Outer Space

Re: [Jython-dev] speed obsession

[Samuele P. <pe...@in...>]

About the recurrent topic of speed obsession:

AFAIK
we probably can improve Jython speed, here and there.
(with some caching and maybe cutting some call-paths).

But Jython is a dynamic language implemented over the JVM, not hosted
by a CPU.

Yes, there is a series of "known" ways to improve speed for dynamic languages:
- tagged arithmetic
- inline (polymorphic) caches
- dynamic/adaptive compilation techniques
etc

(Actual JVMs use them, of course not tagged arithmetic for the obvious reason)

but for the moment I don't see any reasonable way to implement them for Jython 
over the JVM, which is a more rigid beast wrt a hardware CPU and have
a different execution time profile and don't execute everything and
always at full speed. It's also a matter of how much memory one can throw
at speed improvements.

The other possibilities:
- adding (optional) static typing (a remote and not very nice possibility, and a 
quite complicated problem and this has failed on Python side so far)
- add a type inferencer to jythonc, but probably we will loose too
much dynamism and in any case a production version of such a beast is far from
trivial and is a lot of work (!). I can post a list of papers on that.

So we can just wait for further improvements of JVMs implementetions,
expecially related to reflection.
Or wait Sun to change the JVM in order to better accomodate dynamic languages.

regards, Samuele Pedroni.

Re: [Jython-dev] Jython and native java merged with simplicity

[Samuele P. <pe...@in...>]

...

> 
> 
> For demonstration purposes I'm embedding the feature
> in directly into the PyInstance.  I define a new
> private method called setSkeleton in PyInstance.java.
Make sense for demo, but for the long run is a no-go.

> 
> 
> I add a bit of code in __setattr__ and __findattr__
> which will search the skeleton instance first before
> self.  When setting the attribute I check to see if it
> is a "basis type" (i.e. float int string).  If it is
> not I must check that object to see if it has a
> skeleton.  If so, set the ghost attribute with the
> ob's skeleton.
> 
> 
> I include an extra optional argument to init args
> called __skeleton__.  If it's None I do nothing, if it
> is defined, I set the PyInstance's skeleton class
> before we assign attributes to the instance.  This way
> the skeleton will automatically be initialized since
> __setattr__ and __findattr__ have been slightly
> modified.  
> 
> 
> What is important about the nature of ghosting is that
> information is stored in both the java native skeleton
> and the real PyObject.
Why this two-places approach? once you have a skeleton
you can store things there, unless an attribute
is not a pre-existent java field.

> 
> This seems funny, and alot of work, but really isn't. 
> Once you see the speed boost obtained from doing bulk
> processing you may deem this feature worthwhile.
OK, but you stil pay reflection for calling java methods,
so you get a real speedup maybe only if your java methods
are coarse-grain.

> 
> 
> It does retain a great deal of python flexibility.  
> Provided a small set of attributes are not deleted. 
> That should throw an exception.
> 
> 
> thanks for your comments. have been very helpful.
> -john
You're welcome. 
For the momement I see this as an interesting experiment,
but to have such a functionality be distributed with jython
I think we need the 2.2 framework, in order to make
this a flavor of java subclassing under the control of a special-purpose
meta-class.
At least I hope that these words will make sense at that point.

regards, Samuele Pedroni.

Re: [Jython-dev] Jython and native java merged with simplicity

[Joseph G. <oc...@se...>]

Just a quick uneducated question:

I don't suppose there's anyway to use the java machinery by default but kick
in the full flexibility of python on an as-needed basis?  The reason I ask
is that I recall (over 10 years ago) one of the main Smalltalk implementers
(Douglas Engelbart?) giving a great talk on his Smalltalk.  They apparently
did just that: provided the illusion of a full object model while using raw
ints (etc.) under the covers.  According to his talk, when you really got
into the nitty-gritty, that emulation (which appeared hard on the surface)
was not a major challenge; instead, some unexpected stuff became hard!

So, I don't know how hard it is to emulate the full object model while
cheating behind the scenes, but it may be worth trying based on some decade
old Smalltalk experience.  :-)

Just a thought,

= Joe =


john coppola wrote:

> Yes, something of this nature, but not quite like that
> since several layers of code must still be traversed
> before getting to the meat and potatoes slowing it
> down.
>
> It is important that this interface be transparent
> (like a ghost) since that is largely the beauty of it.
>
> For demonstration purposes I'm embedding the feature
> in directly into the PyInstance.  I define a new
> private method called setSkeleton in PyInstance.java.
>
> I add a bit of code in __setattr__ and __findattr__
> which will search the skeleton instance first before
> self.  When setting the attribute I check to see if it
> is a "basis type" (i.e. float int string).  If it is
> not I must check that object to see if it has a
> skeleton.  If so, set the ghost attribute with the
> ob's skeleton.
>
> I include an extra optional argument to init args
> called __skeleton__.  If it's None I do nothing, if it
> is defined, I set the PyInstance's skeleton class
> before we assign attributes to the instance.  This way
> the skeleton will automatically be initialized since
> __setattr__ and __findattr__ have been slightly
> modified.
>
> What is important about the nature of ghosting is that
> information is stored in both the java native skeleton
> and the real PyObject.  The same information in two
> places.  Somewhat of an OO no no.  But I am willing to
> make this trade off to get 500x performance boost.
> Since all it requires is a bit a maintenance work in
> well tucked away places.
>
> This seems funny, and alot of work, but really isn't.
> Once you see the speed boost obtained from doing bulk
> processing you may deem this feature worthwhile.
>
> It does retain a great deal of python flexibility.
> Provided a small set of attributes are not deleted.
> That should throw an exception.
>
> thanks for your comments. have been very helpful.
> -john
>
> --- Samuele Pedroni <pe...@in...> wrote:
> > Hi.
> >
> > I'm still a bit confused, how far is this (up to
> > PyObject subclassing and
> > other not directly related issues) from what you
> > would like?
> >
> > <jc.py>
> >
> > import new
> >
> > class X:
> >   def __init__(self,c):
> >     self.c = c
> >
> >   def add(self,a,b):
> >       return self.c*(a+b)
> >
> >   def mul(self,a,b):
> >       return self.c*a*b
> >
> > x=X(2)
> > print repr(x.__class__)
> > print X.add
> > print X.mul
> > print x.add(1,2)
> > print x.mul(3,2)
> >
> > def jmerge(cls,jskel):
> >   new_cls =
> > new.classobj(cls.__name__,(jskel,cls),{})
> >   new_cls.__module__ = cls.__module__
> >   return new_cls
> >
> > import Xj
> >
> > X=jmerge(X,Xj)
> > x=X(2)
> > print repr(x.__class__)
> > print X.add
> > print X.mul
> > print x.add(1,2)
> > print x.mul(3,2)
> >
> > print x.describe()
> >
> > </jc.py>
> >
> > Output:
> > <class __main__.X at 5783932>
> > <unbound method X.add>
> > <unbound method X.mul>
> > 6
> > 12
> > <class __main__.X at 3462044>
> > <java function add at 3199804>
> > <unbound method X.mul>
> > 6
> > 12
> > Xj(c=2)
> >
> >
> > Consider, Xj is the following java class:
> >
> >
> > public class Xj {
> >
> >  public int c;
> >
> >  public int add(int a,int b) {
> >    return c*(a+b);
> >  }
> >
> >
> >  public String describe() {
> >    return "Xj(c="+c+")";
> >  }
> >
> > }
> >
> >
> >
> > regards, Samuele Pedroni.
> >
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] Jython and native java merged with simplicity

[john c. <joh...@ya...>]

Yes, something of this nature, but not quite like that
since several layers of code must still be traversed
before getting to the meat and potatoes slowing it
down. 


It is important that this interface be transparent
(like a ghost) since that is largely the beauty of it.



For demonstration purposes I'm embedding the feature
in directly into the PyInstance.  I define a new
private method called setSkeleton in PyInstance.java.


I add a bit of code in __setattr__ and __findattr__
which will search the skeleton instance first before
self.  When setting the attribute I check to see if it
is a "basis type" (i.e. float int string).  If it is
not I must check that object to see if it has a
skeleton.  If so, set the ghost attribute with the
ob's skeleton.


I include an extra optional argument to init args
called __skeleton__.  If it's None I do nothing, if it
is defined, I set the PyInstance's skeleton class
before we assign attributes to the instance.  This way
the skeleton will automatically be initialized since
__setattr__ and __findattr__ have been slightly
modified.  


What is important about the nature of ghosting is that
information is stored in both the java native skeleton
and the real PyObject.  The same information in two
places.  Somewhat of an OO no no.  But I am willing to
make this trade off to get 500x performance boost. 
Since all it requires is a bit a maintenance work in
well tucked away places.


This seems funny, and alot of work, but really isn't. 
Once you see the speed boost obtained from doing bulk
processing you may deem this feature worthwhile.


It does retain a great deal of python flexibility.  
Provided a small set of attributes are not deleted. 
That should throw an exception.


thanks for your comments. have been very helpful.
-john

--- Samuele Pedroni <pe...@in...> wrote:
> Hi.
> 
> I'm still a bit confused, how far is this (up to
> PyObject subclassing and
> other not directly related issues) from what you
> would like?
> 
> <jc.py>
> 
> import new
> 
> class X:
>   def __init__(self,c):
>     self.c = c
>     
>   def add(self,a,b):
>   	return self.c*(a+b)
>   	
>   def mul(self,a,b):
>   	return self.c*a*b
> 
> x=X(2)
> print repr(x.__class__)
> print X.add
> print X.mul
> print x.add(1,2)
> print x.mul(3,2)
> 
> def jmerge(cls,jskel):
>   new_cls =
> new.classobj(cls.__name__,(jskel,cls),{})
>   new_cls.__module__ = cls.__module__
>   return new_cls
> 
> import Xj
> 
> X=jmerge(X,Xj)
> x=X(2)
> print repr(x.__class__)
> print X.add
> print X.mul
> print x.add(1,2)
> print x.mul(3,2)
>   	
> print x.describe()
> 
> </jc.py>
> 
> Output:
> <class __main__.X at 5783932>
> <unbound method X.add>
> <unbound method X.mul>
> 6
> 12
> <class __main__.X at 3462044>
> <java function add at 3199804>
> <unbound method X.mul>
> 6
> 12
> Xj(c=2)
> 
> 
> Consider, Xj is the following java class:
> 
> 
> public class Xj {
> 
>  public int c;
>  
>  public int add(int a,int b) {
>    return c*(a+b);
>  }
> 
> 
>  public String describe() {
>    return "Xj(c="+c+")";
>  } 
> 
> }
> 
> 
> 
> regards, Samuele Pedroni.
> 



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Jython and native java merged with simplicity

[Samuele P. <pe...@in...>]

Of course there is a problem with multiple inheritance from java classes,
but in any case I think this "skeleton: trick to be used parsimously and
with leaf classes.

About the idea of re-enabling subclassing from java classes in general:
what is the right thing to do with classes inherited along multiple paths?

Maybe it is possible to weaken the rule a bit:

if pyclass inherits from JClass
then 

class newclass(pyclass,JClass, unrelavant pure python classes)

is OK if JClass2 subclasses JClass.

regards, Samuele Pedroni.

Re: [Jython-dev] Jython and native java merged with simplicity

[Samuele P. <pe...@in...>]

Hi.

I'm still a bit confused, how far is this (up to PyObject subclassing and
other not directly related issues) from what you would like?

<jc.py>

import new

class X:
  def __init__(self,c):
    self.c = c
    
  def add(self,a,b):
  	return self.c*(a+b)
  	
  def mul(self,a,b):
  	return self.c*a*b

x=X(2)
print repr(x.__class__)
print X.add
print X.mul
print x.add(1,2)
print x.mul(3,2)

def jmerge(cls,jskel):
  new_cls = new.classobj(cls.__name__,(jskel,cls),{})
  new_cls.__module__ = cls.__module__
  return new_cls

import Xj

X=jmerge(X,Xj)
x=X(2)
print repr(x.__class__)
print X.add
print X.mul
print x.add(1,2)
print x.mul(3,2)
  	
print x.describe()

</jc.py>

Output:
<class __main__.X at 5783932>
<unbound method X.add>
<unbound method X.mul>
6
12
<class __main__.X at 3462044>
<java function add at 3199804>
<unbound method X.mul>
6
12
Xj(c=2)


Consider, Xj is the following java class:


public class Xj {

 public int c;
 
 public int add(int a,int b) {
   return c*(a+b);
 }


 public String describe() {
   return "Xj(c="+c+")";
 } 

}



regards, Samuele Pedroni.

Multiple inheritance, was Re: [Jython-dev] Jython and native java merged with simplicity

[Kevin B. <kb...@ca...>]

john coppola wrote:

> It would be nice if a python class could leverage the
> speed of java, while having the flexibility of Python.
> We should in theory be able to do this using a Mix-In
> approach.

I think the "ghosting" approach is the wrong approach for this.

The example you cited is trivially solved by multiple inheritance, as you pointed out:

...
> import jSpam # true java class
> class Dummy: pass
> 
> Class Foo(Dummy,jSpam):
>     def __init__(self,name):
>         self.name=name
> 
> Now, in theory this code should work:
> 
> foo=Foo("foo")
> 
> This code bombs because inhereting from jSpam has
> interfered with our inheritence from Dummy.

...

So multiple inheritance seems the right way to approach this (it gives you the ghosting feature, all the multiple inheritance/mixins features, and does it in established Python syntax).

Early versions of jpython allowed multiple inheritance of Java classes. Later versions disabled it explicitly, mostly because it wasn't supported in jpythonc. I believe this was a mistake, but I have yet to put my code where my mouth is, so I should probably shut up about it.  But here goes anyway.  :-)

Ideally, Python code should not care whether a class instance is implemented in Python or in Java (or C...), including when you try to inherit from it.

I haven't investigated the code, but I expect it wouldn't be hard to re-enable.

Here's the FAQ entry that talks about it the history:
http://www.jython.org/cgi-bin/faqw.py?req=show&file=faq03.001.htp

This links to: http://mail.python.org/pipermail/jpython-interest/1998-April/000213.html
and a bad link, that should probably be replaced with:
http://mail.python.org/pipermail/jpython-interest/1999-June/001874.html
http://mail.python.org/pipermail/jpython-interest/1999-January/001162.html

I'd propose that we allow the multiple inheritance behavior, and make jythonc encode that behavior in some rational way based on delegation (multiple inheritance in Python doesn't _have_ to make to inheritance in Java, otherwise we couldn't implement Python on the JVM).

This makes jythonc's job a bit harder - but only for classes that use multiple inheritance.  

The basic approach would be to have the derived class implementation inherit from the _first_ base class.  Any other "base classes" become a contained member as shown below. This lets single inheritance generate exactly the code it does today, and supports multiple inheritance in a reasonable way.

Issues (and suggestions):

- access to protected methods/data of base classes (not needed, because Jython doesn't support it)
- derived methods delegating to base classes (provide 'super_method' that calls super.method)
- base class methods that call derived methods - template method pattern (derived method delegates to method on combined class)
- methods with the same name in two base classes (delegate to method on combined class)
- methods of X that access both A and B (delegate to method on combined class)
- data members with the same name in two base classes (really painful - maybe leave that as a restriction in jythonc?)

class X( A, B, C ):
	def MyCMethod( self ):
		# do stuff, then
		return C.MyCMethod( self )

becomes:

public class X extends A
{
	public X( args )
	{
		super( a_args );
		b = new B_X( this, b_args );
		c = new C_X( this, c_args );
	}

	// overridden methods of A, B, and C
	
	public RETURNVALUE MyCMethod()
	{
		// do stuff, then
		return c.super_MyCMethod();
	}

	// non-overridden methods of just B and C delegate to b and c

	// clients need to access fields of B & C and
	// pass to pass B & C references to other code
	// these could be protected w/ accessor methods
	public B b;  
	public C c;

	// may want to add a 'convenience member'
	public A a = this;
}


class B_X extends B
{
	protected X x;
	B_X( X x, b_args )
	{
		super( b_args );
		this.x = x;
	}

	// overridden methods of B delegate to x
}

class C_X extends C
{
	protected X x;
	C_X( X x, c_args )
	{
		super( c_args );
		this.x = x;
	}

	// overridden methods of C delegate to x
	public RETURNTYPE MyCMethod()
	{
		return x.MyCMethod();
	}

	// for any methods that are called from X code, generate the following:
	public RETURNTYPE super_MyCMethod()
	{
		return super.MyCMethod( ARGS );
	}
}

But again, no code to support the proposal at this point, but I'd appreciate feedback on the idea.

:-)  /   :-(

kb

Re: [Jython-dev] Why Jython?

[Kevin D. <kda...@we...>]

(It seems like this message probably belongs over on the jython-users list)

Jython is a dynamic, OO language with some nice high level data types and
convenient access to Java classes. Unlike Java, you don't have to declare
everything at compile time. Plus, Jython supports operator overloading,
multiple inheritance and other goodies. For information on the language
itself, you should probably check out http://www.python.org. I believe there
are some articles on there that compare Python to other languages.

Jython is very compatible with Python, and adds the ability to directly
access Java classes. It can be useful for rapid prototyping, because it
generally takes less Jython code than Java code to do the same thing.  Since
Jython compiles to Java byte code, it is probably fast enough It can also be
really useful for unit testing, because you can turn off the Java
accessibility rules and create test frameworks that can access private
members in order to set up a test bed.

Jython is very useful and a lot of fun to work with. I use the command line
interpreter all the time to test things out...

Kevin

----- Original Message -----
From: "Om Sivanesan" <c-o...@wc...>
To: <jyt...@li...>
Sent: Tuesday, August 07, 2001 12:46 PM
Subject: [Jython-dev] Why Jython?


> Hi:
>
> I am new to Jython though I have abt 5 years experience in Java. I am
> interested in the usage of Jython. In other words I need to know where I
can
> use Jython and why.
>
> If you could shed some light on thi I would appreciate it greatly.
>
> Thank you,
> Om
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

RE: [Jython-dev] Why Jython?

[Garcia, M. <mg...@Bu...>]

Wow, where do I start...

Jython is a Python interpreter written in java for use with java.  The
syntax is Python which is much more elegant that java's.  It is extremely
powerful in prototyping algorithms and allows for very fast development
cycles.  You can write almost anything in jython and compile it to java
classes.  For GUI development with Swing it is really cool.  

It is an awesome test bed for testing java applications.  We use it for
testing EJB clients in our enterprise application as well as developing
system algorithms.  As a java developer I'm sure that once you try it,
you'll be addicted as most of us are.  You'll never want to write java code
again.  

Within you java programs you can even embed a PythonInterpreter and call
jython.  Check out the homepage www.jython.org and start messing around with
it.  You won't regret it!

Mick


-----Original Message-----
From: Om Sivanesan
To: jyt...@li...
Sent: 8/7/01 12:46 PM
Subject: [Jython-dev] Why Jython?

Hi:

I am new to Jython though I have abt 5 years experience in Java. I am
interested in the usage of Jython. In other words I need to know where I
can
use Jython and why.

If you could shed some light on thi I would appreciate it greatly.

Thank you,
Om


_______________________________________________
Jython-dev mailing list
Jyt...@li...
http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] Why Jython?

[Om S. <c-o...@wc...>]

Hi:

I am new to Jython though I have abt 5 years experience in Java. I am
interested in the usage of Jython. In other words I need to know where I can
use Jython and why.

If you could shed some light on thi I would appreciate it greatly.

Thank you,
Om

Re: [Jython-dev] Jython and native java merged with simplicity

[john c. <joh...@ya...>]

I think I will need to create my own customized
branch. Introducing new keywords is probably not a
good idea. However the feature doesn't rely on that, a
customized builtin function could also do the trick
and be catchable by cPython.

The inconsistency in lets say "hardening" code using
java is that the code is no longer compatable with
cPython, even though syntatically it is.  So in an
abstract way, the skeletons and ghosting concept
promotes compatability between Python and Jython by
allowing certain methods to be overridden in the
skeleton java class (ghost class).  The original
Python class could be used in both Jython and Python. 
Skeleton gives Jython a means to map Python data to
native java data so that java's calculation efficiency
could be exploited directly.  So I am in favor of the
skeletons approach.

I believe that there are few things I will have to
include to the Jython api.  When an attribute is set,
first check the class an see if it has a ghost.  Then,
via introspection or reflection, check to see if the
attribute is defined in the ghost class, if so set the
attribute in the ghost class as well as the python
class.  I will need to check the object being set to
see if it supports ghosting  recursively because
ultimately we want to use the java native types (or
ghosts) for speed.

When getting a method, check to see if the attribute
has a ghost.  If so check to see if the method is
defined in the ghost class, if so, invoke the ghost
method.

Fairly simple.  Within my coding ability to pull off.


--- Samuele Pedroni <pe...@in...> wrote:
> Hi, I found your mail a bit confusing, maybe there
> was just too
> much meta comments <wink>.
> 
> I see three different points:
> - jython is slow vs. java
> - subclassing a PyObject subclass from jython have
> problem with mutability of
> the instances of the resulting class
>   This should be solved, probably in 2.2, given that
> to have a jython 2.2 we
> should somehow implement the descr changes
>   happened to CPython
> - a way to solve (partially) both the above
> problems, although in my opinion
> they are unrelated.
> 
> In any case adding new keywords and strange
> semantics is a no-go.
> 
> Although I have maybe understood what was the idea
> behind your words, I don't
> want to try to re-explain it confusing
> things further, so please please restate it more
> clearly...
> 
> in any case this is an open source projects, prosal
> and patches are always
> welcome.
> 
> Samuele Pedroni.
> 
> 
> 
> ----- Original Message -----
> From: john coppola <joh...@ya...>
> To: <jyt...@li...>
> Sent: Tuesday, August 07, 2001 2:03 AM
> Subject: [Jython-dev] Jython and native java merged
> with simplicity
> 
> 
> > After examining the Jython JAPI, it is quite clear
> > that the internal operation of the Interpreter is
> > quite different.  The jAPI of Jython leverages
> java's
> > object oriented nature to implement a Python
> > equivalent in  java.  The jython API has some
> > interesting features but has some flaws as well. 
> I
> > would like to see these things changed in future
> > releases of Jython:
> >
> > It is very easy to create a true Python class in
> Java
> > using the Jython Api.  But, there is, as usual a
> > better way to go about things which would make
> things
> > run much faster and with greater flexibility.
> >
> > Now, one could create a true Python class in java,
> but
> > the performance boost is minimal and not worth the
> > time.
> >
> > Native java code runs much faster.  Proof of this
> is
> > the cPickle module implementation in java.  The
> speed
> > of "jPickle" is the same speed as cPickle.
> >
> > Here is a code comparison for a simple program:
> > from time import time
> > def test():
> >     start = time()
> >     total = 0.0
> >     for i in range(0,1000000):
> >         total = total + i + i*2.0
> >     print time()- start
> >
> > This test on my computer:
> >   python2.0:                     2.77 seconds
> >   jython2.1a1:                   7.40 seconds
> >   native java:                   0.014 seconds
> >
> > 197 times faster than Python
> > 528 times faster than Jython
> >
> > It would be nice if a python class could leverage
> the
> > speed of java, while having the flexibility of
> Python.
> > We should in theory be able to do this using a
> Mix-In
> > approach.
> >
> > public class jSpam implements PyObject {
> >     public pyOb = new PyObject();
> >
> >     public void setOb(PyObject ob) {
> >         pyOb = ob;
> >     }
> > }
> >
> >
> > import jSpam # true java class
> > class Dummy: pass
> >
> > Class Foo(Dummy,jSpam):
> >     def __init__(self,name):
> >         self.name=name
> >
> > Now, in theory this code should work:
> >
> > foo=Foo("foo")
> >
> > This code bombs because inhereting from jSpam has
> > interfered with our inheritence from Dummy.
> >
> > The reason it bombs is because we cannot set
> > attributes on the java class we inherited from. 
> This
> > makes sense since java is statically typed. We
> should
> > be able to set attributes on the Foo portion of
> the
> > object.  Jython does not understand this.
> >
> >
> > We really need to include a feature in Jython that
> can
> > leverage Java's speed with a simple api layer to
> do
> > so.
> > For lack of better terminology I'll call it a
> ghosting
> > and skeletons.
> >
> > Ghosting is the layer in that will provide hooks
> into
> > python types mapped into java skeleton classes. So
> > everytime we change a python attribute, the
> attribute
> > is updated in the java skeleton automatically. 
> This
> > will in effect pin the Python class to a java
> class
> > removing some of the dynamic flexibility we have
> with
> > the python classes, but the speed gain is
> tremendous,
> > so worth our while.
> >
> > so in java maybe we have:
> >
> >    public class mySkeleton implements ghosting
> >
> > the Ghosting interface are the hooks needed by
> Jython
> > to map a Python object to it's skeleton in java
> >
> > perhaps syntax in Jython would look like:
> >    from spam import Spam with jSpam skeleton
> >
> >    This would import Spam from the spam module and
> >    associate the Spam class with the jSpam
> skeleton.
> >
> > Alternate syntax may look like:
> >    from spam import Spam with jSpam skeleton as
> Spam1
> >    from spam import Spam with jSpam2 skeleton as
> Spam2
> >
> > Where Spam1 and Spam2 have been linked with
> different
> > java skeletons.
> >
> > A system such as this would provide an easy way to
> > utilize java's speed and enable Jython to run
> several
> > times faster than cPython where computationally
> > intensive algorithms could be done in the native
> java
> > skeleton class.
> >
> > John Coppola
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute
> with Yahoo! Messenger
> > http://phonecard.yahoo.com/
> >
> > _______________________________________________
> > Jython-dev mailing list
> > Jyt...@li...
> >
>
http://lists.sourceforge.net/lists/listinfo/jython-dev
> >
> 
=== message truncated ===




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Jython-dev] ANNOUNCE: phabric project - Zope on Java

[Kevin D. <kda...@we...>]

A few weeks back, Web Elite started work on Phabric, a project to bring Zope
to Java via Jython. Since there has been a lot of discussion in the past
couple of weeks on the jython-dev list about Zope related topics
(ExtensionClass, Acquisition and Zope as a whole), we've decided to fully
open the project now rather than telling interested people individually.

Web Elite is committed to this technology. This open source Java software
will bring many of the benefits to Java developers that Python developers
have been enjoying already.

The main phabric website is at http://www.phabric.org. If you're interested
in phabric, we have started some mailing lists to get some discussion going.
You can sign up for the lists at http://lists.webelite.com. If you're just
interested in tracking the general progress of the project, subscribe to
phabric-announce. For developers interested in working on phabric, we have
set up a phabric-dev list to discuss the core phabric work.

Current Status
--------------
ExtensionClass and Acquisition are fairly complete. We're working on the
other C modules (largely in python to begin with) right now. The next step
after that will be to do profiling and move some of the code into
better-optimized Java.

The latest download information for phabric will always be at
http://www.phabric.org/download. Currently, the only access to phabric is
via CVS.

Why phabric?
------------
We chose to call the project phabric because there will not be 100%
compatibility between zope and phabric, and a new name will avoid confusion.
"Phabric" was chosen because it's a framework that holds your web apps
together. Metaphorically speaking, you can weave your objects into the
phabric of the web...

I am sending this message to jython-dev and zope-dev, but not crossposting
to avoid discussions that are irrelevant to the other group.

Hope to hear from you soon!

Kevin Dangoor
Web Elite