From: <bc...@wo...> - 2000-11-20 11:19:15
|
On Mon, 20 Nov 2000 02:11:58 +0100, you wrote: >Hi. > >first some bugs status: >1) I have put in place the fix for [ Bug #122610 ] SecEx in MS applerviewer. > http://sourceforge.net/bugs/?func=detailbug&bug_id=122610&group_id=12867 >2) Bug [ Bug #122793 ] Calling reload on java class loaded from sys.path >cause NPE > http://sourceforge.net/bugs/?func=detailbug&bug_id=122793&group_id=12867 > is clearly closed because actually reload for a jclass is nop, > or open if we want to keep it as reminder that we should implement >reloading for jclasses <wink>. Let us close as many bug reports as we can. If we want to have remainders we can always open a new one with a more accurate description. >Now about importing compiled code: > >I'm not convinced about *my* proposal: > >[Finn] >> ... >> >Notice that with this design choice if someone load a compiled >> >module through a java package it will get simply the java class >> >not the module, for me this makes sense >> >> I fear it will be FAQ. In some setups you will get the module, in others >> you will get the proxy. They have the same name so it is not obvious >> which you happened to import. >> ... >> >> I would not mind too much if the generated proxy classes wasn't >> available from jython at all. As long as the module and all the classes >> inside the module are available. >> >I'm not conviced that what we can quickly(?) implement is what people >expect. >It seems to me that jythonc is more there to build applets or make jython >classes >resemble java classes, such that people can forget about their jythonic >nature. >If someone subclasses a swing panel or builds a bean with jythonc I believe >it expects a class >not a module when he imports that back in the interpreter. That is all true. I just don't think we can fullfill that expectation in the more complicated situations: =========== test260s1.py =========== import java class test260s1(java.util.Vector): def foo(self): pass class P(java.awt.Panel): pass class foo: pass =========== END =========== If the main code isn't run at some time during import, all the python code (foo above) is lost. It is my believe (at the moment anyway) that is is easier to explain that the test260s1 class is in fact called test260s1.test260s1 then it is to explain what exactly that test260s1 thing is in the first place. >I know this is just philosophy... >but there is also a technical side: >* as noticed the java class and the python module have the same name, > this is really a problem, e.g w.r.t. to sys.modules > I always felt that top-level jclasses should not end up in sys.modules but >that > is what jython does. My viewpoint is that java classes are not modules... >* actually one can get to import the compiled class, but constructed >instances > do not work, I have done few experiments and read the code a bit, so maybe >I'm missing something, > but this point could be solved making the PyJavaClass.__call__ return a >python > class in this case, here it does not make sense to put a proxy around a >proxy. Yes, that could be a likely solution. > We should take care of > this also by subclassing. (see transcript at the end). >* but the most serious issue is the following and this is an issue >concerning both choices (class/pkg import): > we should be careful choosing with which classloader we load things, in >mixed java/jython code case > it is quite is easy and natural use the pre-built proxy from the java >side (and this at java compilation time), I can imagine that if we are >not careful we risk to load things twice and get a new series of interop >problems ... >* what should reload do? He. I dunno, but if anyone wants to use reloading on a compiled python class they shouldn't have compiled it in the first place. >Are we in hurry to offer such a feature. No. I added it because I though it would be a small and easy change. I'll remove my ModuleDictInit changes. >Personally I need more time to >study the issue. >Could you [Finn] list what is left to do (up to bugs), what should be in for >alpha1 ... and the final release. >For example the cache issue as a step toward reloading - I think - is >important. > >About that there are still some questions around that I should answer you. >I will post the answers together with a list of ideas (many are very >low-prio). > >Comments are welcome. > >regards, Samuele > >----- an experiment >This just indicates that the other choice (class import) is not hopeless, >but this does not mean easy. > >Setup: ><Z.py> >import java > >class Z(java.lang.Object): > def value(self): > "@sig public int value()" > return 1 ></Z.py> >This gets compiled with jythonc to Z.class and Z$_PyInner.class. > ><SZ.java> >public class SZ { > public static int svalue(Z z) { > return z.value(); > } >} ></SZ.java> >This gets compiled with javac against Z.class (from jythonc) to SZ.class. > >The bad news: >Jython 2.0 pre-alpha on java1.3.0 (JIT: null) >Type "copyright", "credits" or "license" for more information. >>>> import Z >>>> z=Z() >>>> z.value() >Traceback (innermost last): > File "<console>", line 1, in ? >AttributeError: abstract method "value" not implemented > >The "good" news: >Jython 2.0 pre-alpha on java1.3.0 (JIT: null) >Type "copyright", "credits" or "license" for more information. >>>> import sys >>>> from java.lang import Class >>>> import Z,SZ >>>> (Z.getClassLoader(),SZ.getClassLoader()) # things loaded from sys.path >(org.python.core.BytecodeLoader@ae1cf, org.python.core.BytecodeLoader@ae1cf) >>>> sys.modules['Z'] ><jclass Z at 8321686> >>>> del sys.modules['Z'] # otherwise we get an exception >>>> z=Class.newInstance(Z) >>>> z ><Z.Z instance at 3180698> >>>> z.value() >1 >>>> sys.modules['Z'] ><module Z at 4920025> >>>> z1=Class.newInstance(Z) >>>> sys.modules['Z'] ><module Z at 4920025> >>>> (SZ.svalue(z),SZ.svalue(z1)) >(1, 1) >>>> class Y(Z): >... pass >... >>>> y=Y() >>>> y.value() >Traceback (innermost last): > File "<console>", line 1, in ? >AttributeError: abstract method "value" not implemented >>>> # but >>>> class Y(z.__class__): >... pass >... >>>> y=Y() >>>> y.value() >1 >>>> # and most important >>>> SZ.svalue(y) >1 >>>> # seems to work. So maybe the ability to use the proxies directly from jython isn't so far away. Rather than trying to decide if "z" should be a module or a class, we should give the user the option of choosing. Maybe as additional options to jythonc where the user can specify which of classes what should become main proxies (main proxies are real java classes, ordinary proxies are innerclasses). By default the module name will be importable as a module unless it is overridden as a main proxy. So jythonc z.py would create a z.class proxy and no module, and jython --mainproxy="" z.py would create a z.class module and a z$z.class proxy. There is probably better and more natural ways of specifing this, but I hope you get the general idea. regards, finn |