From: Oti <oh...@ya...> - 2002-05-03 07:25:41
|
Hello developers, would it make sense to add a patch for a convenience method: public Object __tojava__() { return super.__tojava__( __class__.proxyClass ); } in PyJavaInstance.java ? In an embedding situation where you don't know what eval() will return, it would be nice if a PyJavaInstance result could be simply turned into a java object. Best wishes, Oti. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
From: Oti <oh...@ya...> - 2002-05-13 20:32:54
|
Hello, with the help from this list, I finally managed to lift BISON Solution from JPython 1.0.3 to Jython 2.1 - many THANKS to you all ! So, if you don't mind, we would be glad to see our project mentioned on http://www.jython.org/users.html, e.g. as follows: <p><b><a href="http://www.bison-group.com">BISON Solution</a></b> BISON Solution is the first process oriented Business Solution developed in 100% pure Java and fulfilling the J2EE Standards. BISON Solution uses Jython for scripting and high-level customizing of existing business objects. <p> Best wishes from a proud new Jython user, Oti. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
From: Finn B. <bc...@wo...> - 2002-05-14 14:27:45
|
[Oti] > Hello, > > with the help from this list, I finally managed to lift BISON Solution > from JPython 1.0.3 to Jython 2.1 - many THANKS to you all ! > > So, if you don't mind, we would be glad to see our project mentioned on > http://www.jython.org/users.html, > e.g. as follows: Done. Thank you for the link and info. regards, finn |
From: Oti <oh...@ya...> - 2002-05-29 20:58:56
Attachments:
import.zip
|
Hello Samuele, please find below my second approach, hopefully closer to your requirements. I'd like to hear your comments before I flush the SF package manager with more code. This approach: - keeps the precedence 'python over java' - does not load any classes - IMHO is at the highest level possible - passes test/test_import.py from the CPython 2.1.3 distribution - passes test/dynamic_import.py - allows package imports, too - enables fixing a bug The idea is still the same: If (for whatever reasons) a java package was neither scanned nor added with sys.add_package(), we add it dynamically, after all other imports failed. There is a unittest attached (dynamic_import.py) which I expect to fail with standard jython 2.1 (ImportError: no module named dynamic), while it should succeed with the changes to imp.java and __builtin__.java attached and described below. In order to run this test, please add dynamic_import.jar to the classpath, but do not add dynamic_extension.jar. Both jars have to be in the same directory, though. As a second step, you could disable the package scan (patch No. 525092; safely leave the .py files untouched) and delete the cachedir. Again the test should pass! Thank you very much for your time reviewing this. Best wishes, Oti. imp.java ( 'Release_2_1' = revision 2.59 ) ------------------------------------------ - add the constant: String NO_MODULE_NAMED = "no module named "; - replace the two "N/no module named" strings with this constant: throw Py.ImportError(NO_MODULE_NAMED + name); - add the two methods isJavaClass() and isJavaPackage() __builtin__.java ( 'Release_2_1' = revision 2.41 ) -------------------------------------------------- There are only changes to class ImportFunctions: - in method __call__(), replace load() with dynamicLoad() - add the methods: dynamicLoad(), findJavaPackage(), getFirstFrom(), eliminateNoneModules() While developing the above I was able to fix a funny bug. Consider the following situation: 1) somewhere on the classpath, there is aClass.class in package p1.p2: /p1 +-- /p2 +- aClass.class 2) somewhere on sys.path, there is aModule.py in directory /m1, and /m1 has an empty subdirectory /p1: /m1 +-- aModule.py contains 'from p1.p2 import aClass' +-- __init__.py empty +-- /p1 empty directory Now 'import m1.aModule' with the embedded 'from p1.p2 import aClass' fails, while a plain 'from p1.p2 import aClass' succeeds. There is a unittest attached (blocking_import.py) which exposes exactly this situation. In order to run it, please copy javac.py from the /Tools/jythonc directory to the /Lib directory. I expect it to fail with standard jython 2.1 (ImportError: No module named p2), while it should succeed with the fixes to PyJavaPackage.java described below. However, I have no experience in importing java classes from sys.path, so this might break some of your tests ? PyJavaPackage.java ( 'Release_2_1' = revision 2.17 ) ---------------------------------------------------- in method __findattr__(), replace: if (__mgr__.packageExists(__name__,name)) { __mgr__.notifyPackageImport(__name__,name); return addPackage(name); } with if (__mgr__.packageExists(__name__,name)) { //check if it really is a java package String testPackage = ""; if (__name__ != null && __name__.length() > 0) testPackage = __name__ + "." + name; else testPackage = name; if (imp.isJavaPackage(testPackage)) { __mgr__.notifyPackageImport(__name__,name); return addPackage(name); } else { Py.writeDebug("import", "'" + testPackage + "' is not a java package."); } } __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Samuele P. <pe...@in...> - 2002-05-29 21:53:36
|
From: Oti <oh...@ya...> > Hello Samuele, > > please find below my second approach, hopefully closer to your > requirements. > I'd like to hear your comments before I flush the SF package manager > with more code. > > This approach: > - keeps the precedence 'python over java' > - does not load any classes > - IMHO is at the highest level possible [sad] this kind of patch should go at the lowest possible level. I remember to have written that it should probably go at the PackageManager level or just a level above. The kind of hack to check the exception kind is a good signal that it is not the right level to do this, it is too late in the game. Nothing personal. I'm really sorry. I will work on this and maybe other import improvements before EuroPython. Is the least I can do... > - passes test/test_import.py from the CPython 2.1.3 distribution > - passes test/dynamic_import.py > - allows package imports, too > - enables fixing a bug > > The idea is still the same: > If (for whatever reasons) a java package was neither scanned nor added > with sys.add_package(), we add it dynamically, after all other imports > failed. > > There is a unittest attached (dynamic_import.py) which I expect to fail > with standard jython 2.1 (ImportError: no module named dynamic), while > it should succeed with the changes to imp.java and __builtin__.java > attached and described below. > In order to run this test, please add dynamic_import.jar to the > classpath, but do not add dynamic_extension.jar. Both jars have to be > in the same directory, though. > > As a second step, you could disable the package scan (patch No. 525092; > safely leave the .py files untouched) and delete the cachedir. Again > the test should pass! > > Thank you very much for your time reviewing this. > Best wishes, > Oti. > > > > imp.java ( 'Release_2_1' = revision 2.59 ) > ------------------------------------------ > > - add the constant: > String NO_MODULE_NAMED = "no module named "; > - replace the two "N/no module named" strings with this constant: > throw Py.ImportError(NO_MODULE_NAMED + name); > - add the two methods isJavaClass() and isJavaPackage() > > > __builtin__.java ( 'Release_2_1' = revision 2.41 ) > -------------------------------------------------- > > There are only changes to class ImportFunctions: > - in method __call__(), replace load() with dynamicLoad() > - add the methods: > dynamicLoad(), > findJavaPackage(), > getFirstFrom(), > eliminateNoneModules() > > > > > While developing the above I was able to fix a funny bug. Consider the > following situation: > > 1) somewhere on the classpath, > there is aClass.class in package p1.p2: > /p1 > +-- /p2 > +- aClass.class > > 2) somewhere on sys.path, > there is aModule.py in directory /m1, > and /m1 has an empty subdirectory /p1: > /m1 > +-- aModule.py contains 'from p1.p2 import aClass' > +-- __init__.py empty > +-- /p1 empty directory > > Now 'import m1.aModule' with the embedded 'from p1.p2 import aClass' > fails, while a plain 'from p1.p2 import aClass' succeeds. > There is a unittest attached (blocking_import.py) which exposes exactly > this situation. In order to run it, please copy javac.py from the > /Tools/jythonc directory to the /Lib directory. I expect it to fail > with standard jython 2.1 (ImportError: No module named p2), while it > should succeed with the fixes to PyJavaPackage.java described below. > However, I have no experience in importing java classes from sys.path, > so this might break some of your tests ? > > > > PyJavaPackage.java ( 'Release_2_1' = revision 2.17 ) > ---------------------------------------------------- > > in method __findattr__(), replace: > > if (__mgr__.packageExists(__name__,name)) { > __mgr__.notifyPackageImport(__name__,name); > return addPackage(name); > } > > with > > if (__mgr__.packageExists(__name__,name)) { > //check if it really is a java package > String testPackage = ""; > if (__name__ != null && __name__.length() > 0) > testPackage = __name__ + "." + name; > else > testPackage = name; > if (imp.isJavaPackage(testPackage)) { > __mgr__.notifyPackageImport(__name__,name); > return addPackage(name); > } else { > Py.writeDebug("import", > "'" + testPackage + "' is not a java package."); > } > } > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com |
From: Kevin J. B. <kev...@bi...> - 2002-05-29 22:13:36
|
Samuele Pedroni wrote: > I will work on this and maybe other import > improvements before EuroPython. > Is the least I can do... While you're thinking about import... :-) I was wondering if it would be possible to integrate Jython's import with jreload. Specifically, if we could divorce sys.path from the Java classpath & default class loader, and make classes loaded via a Jython import reloadable (if they're not on the Java classpath, etc.). Haven't looked into implementation yet, but it would seem really useful, if it is possible. Thoughts? kb |
From: Samuele P. <pe...@in...> - 2002-05-30 11:51:55
|
From: Kevin J. Butler <kev...@bi...> > Samuele Pedroni wrote: > > I will work on this and maybe other import > > improvements before EuroPython. > > Is the least I can do... > > While you're thinking about import... :-) > > I was wondering if it would be possible to integrate Jython's import with > jreload. Specifically, if we could divorce sys.path from the Java classpath & > default class loader, and make classes loaded via a Jython import reloadable > (if they're not on the Java classpath, etc.). > > Haven't looked into implementation yet, but it would seem really useful, if it > is possible. > > Thoughts? > java classes reloading requires that all the classes from a classloader are reloaded together, it is too different from the Python module reload way, so allowing it for sys.path is confusing. Even more confusing if sys.path intersects with classpath. 2nd a more likely evolution for sys.path is to allow classloaders there (likely wrapped in some way), people would have expectations (people have always expectations :)) about reloading from them, but you cannot reload from a classloader, you need a way to hava a virgin copy of it: other rules, other exceptions Jreload makes clear that Java reloading has different rules wrt to Python reloading. What is true it that jreload should be more natural use, that means it should have some mechanims to installl a jreload package hierarchy insinde the global java package hierarchy or sys.modules, which concretely means that one does not have to start jreload imports with the LoadSet as in LoadSet.foo.bar.baz vs. foo.bar.baz. There are issues about intersections here too between reloadable hiearchies and not , but probably they are solvable with some rules and checking. So IMHO the path would be trying to improve jreload regards. What is true is that jreload should be a bit more natural to use, that means |
From: Kevin J. B. <kev...@bi...> - 2002-05-30 17:37:28
|
Samuele Pedroni wrote: > java classes reloading requires that all the classes from a classloader > are reloaded together, it is too different from the Python module > reload way, so allowing it for sys.path is confusing. I'm not sure how much of an issue the different behavior between reload( pythonmodule ) vs. reload( javamodule ) would be. Right now, we have multiple different behaviors: reload( pythonmodule ) == re-execute the python module code reload( javaclass ) == no-op, returning the Java class jreload.reload( pythonmodule ) == TypeError jreload.reload( javaclass ) == no-op? jreload.reload( loadset ) == reload the load set Only the first & last do anything useful. (Note also that in all cases, reloading a Java "package" fails with a TypeError) I think it would be simpler and more useful to say that: reload( pythonmodule ) == re-execute the python module code reload( javaclass/package ) == jreload behavior for loadset that includes javaclass I think it falls into the category of "there should be one obvious way to do it" - reload() would seem to be the Pythonic "one way", and Java class reloading users will have to learn the Java reload behavior regardless of whether they spell it reload(X) or jreload.reload(X) We'd still want to provide the explicit jreload.makeLoadSet behavior to allow reloading at specific granularity, etc. > Even more confusing if sys.path intersects with classpath. So we make the failure very explicit: reload( "java.lang.System" ) would raise: SomeException: "Unable to reload java.lang.System because it is loaded by the Java classloader (from the classpath, bootclasspath, or ext.dirs)" > 2nd a more likely evolution for sys.path is to allow > classloaders there (likely wrapped in some way), > people would have expectations > (people have always expectations :)) about reloading from > them, but you cannot reload from a classloader, > you need a way to hava a virgin copy of it: > other rules, other exceptions It just seems like we could provide a "default loadset" that loads Java classes from the files & paths in sys.path. This would seem to still work nicely with the inclusion of wrapped classloaders in sys.path. > So IMHO the path would be trying to improve > jreload. Agreed - but I think (hope? wish?) we can integrate an improved version very effectively with the standard Python import & reload. I guess this really becomes two proposals: - make reload( javathing ) == jreload.reload( loadSetOf( javathing )), with useful failure characteristics - have a reloadable default loadset for javathings loaded from sys.path kb |
From: Samuele P. <pe...@in...> - 2002-05-30 18:56:04
|
> Samuele Pedroni wrote: > > java classes reloading requires that all the classes from a classloader > > are reloaded together, it is too different from the Python module > > reload way, so allowing it for sys.path is confusing. > > I'm not sure how much of an issue the different behavior between > reload( pythonmodule ) vs. reload( javamodule ) would be. see below. > Right now, we have multiple different behaviors: > > reload( pythonmodule ) == re-execute the python module code > reload( javaclass ) == no-op, returning the Java class > jreload.reload( pythonmodule ) == TypeError > jreload.reload( javaclass ) == no-op? > jreload.reload( loadset ) == reload the load set > > Only the first & last do anything useful. the first nop should be an error, it is the way it is for "backward compatibility" (?). Now we have warnings, it should produce one, I agree it is a confusing behavior. > > (Note also that in all cases, reloading a Java "package" fails with a TypeError) > I think it would be simpler and more useful to say that: > > reload( pythonmodule ) == re-execute the python module code > reload( javaclass/package ) == jreload behavior for loadset that includes > javaclass it has one plus that means a polymorphic code that operate both on java packages, and python modules could trigger reload on them. Is a kind of code that someone write often: no (at least IMHO). Does the possibility two ignore the difference bring something? > I think it falls into the category of "there should be one obvious way to do > it" - reload() would seem to be the Pythonic "one way", and Java class > reloading users will have to learn the Java reload behavior regardless of > whether they spell it reload(X) or jreload.reload(X) 1. java reloading is not an "obvious" thing (see below) 2. the two operation you want too subsume under reload are different, so it is far from clear that the python rethoric produce something useful here. (see below) 3. you are assuming that people read the manual and then ask questions, it is not that way, java reloading should not be easely accessible before reading the fine points, that is at least my opinion. > > Even more confusing if sys.path intersects with classpath. > > So we make the failure very explicit: > > reload( "java.lang.System" ) you mean reload(java.lang.System) > > would raise: > > SomeException: "Unable to reload java.lang.System because it is loaded by the > Java classloader (from the classpath, bootclasspath, or ext.dirs)" it is not the way things fail for the unaware, it is just that one for example has some classes loaded from somewhere that is both on the classpath and sys.path, and some that are only on the sys.path he reloads believes everything (but in reality only the classes just on sys.path) and now some classes do not interoperate anymore. He did'nt read the fine points. [Granularity and interoperability (because reload java classes create new classes, and java linking and execution check for classes (types)) are awful with java reloading, no way to make it shine.] > > 2nd a more likely evolution for sys.path is to allow > > classloaders there (likely wrapped in some way), > > people would have expectations > > (people have always expectations :)) about reloading from > > them, but you cannot reload from a classloader, > > you need a way to hava a virgin copy of it: > > other rules, other exceptions > > It just seems like we could provide a "default loadset" that loads Java > classes from the files & paths in sys.path. This would seem to still work > nicely with the inclusion of wrapped classloaders in sys.path. other fine point to introduce which will puzzle people. Let's summarize my point: this is an advanced feature where clarity is more imporant IMHO than convenience. > > So IMHO the path would be trying to improve > > jreload. > > Agreed - but I think (hope? wish?) we can integrate an improved version very > effectively with the standard Python import & reload. is far from clear that your wish is a win :). > I guess this really becomes two proposals: > > - make reload( javathing ) == jreload.reload( loadSetOf( javathing )), with > useful failure characteristics > > - have a reloadable default loadset for javathings loaded from sys.path > Btw it is probably more tricky to implement that it seems, but I'm not arguing that this is a good reason to for not trying, is more a situation where you can only decide what kind of questions people will ask [argument pattern (c) Tim Peters] the question "how do I reload Java classes? can I?" is fine for me, the answer being "read about jreload", I like far less the questions "I tried reload(javaclass), it seemed to work but ..." I repeat that jreload should allow the option to import things without the LoadSet "prefix", OTOH I don't see the possibility to use the builtin reload on java classes/packages as a clear win. Btw, before I implemented jreload we thought about this and then and now we came to the same conclusions (you can check the jython-dev archives). i-know-i'm-a-kind-of-obscurantist-ly y'rs - Samuele Pedroni. |
From: Samuele P. <pe...@in...> - 2002-05-30 19:58:16
|
[me] > > it is not the way things fail for the unaware, > it is just that one for example has some classes loaded from > somewhere that is both on the classpath and sys.path, > and some that are only on the sys.path > he reloads believes everything (but in reality only > the classes just on sys.path) and > now some classes do not interoperate anymore. > He did'nt read the fine points. > oh, my bad this is FALSE, one cannot trigger such kind of problem. The fact that reload(javaclass) would hide for the unaware the reloading of ALL classes is still true. is a explicit vs. implicit issue. regards. |
From: Oti <oh...@ya...> - 2002-05-31 05:23:49
|
[ Samuele Pedroni ] > [sad] this kind of patch should go at the lowest possible > level. I remember to have written that it should probably go > at the PackageManager level or just a level above. Yes, you did, and I tried hard to find the correct spot there. But I was not able to sort it out without breaking existing code (my shortcoming). > The kind of hack to check the exception kind > is a good signal that it is not the right level to do this, > it is too late in the game. While it definitely won't win a price for beauty and elegance, it is nonetheless an existing solution for: (1) intuitive java imports (2) no need of package scan any more (R.I.P.) (3) no need of sys.add_package() any more I think I was able to show this providing the tests. > Nothing personal. I'm really sorry. > > I will work on this and maybe other import > improvements before EuroPython. > Is the least I can do... Glad to hear! If nothing else, maybe the tests are useful ... Best wishes, Oti. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Oti <oh...@ya...> - 2002-07-04 06:56:40
|
Hello developers, Motivation: ----------- if a java class X implements methods __add__() __sub__(), ... these methods are invoked if i use x = X() x + 10 x - 10 in the interpreter. Similarly, if X implements methods __eq__(), __lt__(), ... these methods are invoked if i use x = X() x == 10 x < 10 in the interpreter. This is cool, pretty cool i'd say ! In both cases it is the java class' responsibility to do and/or return something useful. Idea / Question: ---------------- Now it would be even cooler if methods __getattr__() __setattr__() would be invoked if i use x = X() x.undefinedAttribute x.undefinedAttribute = 10 x.undefinedMethod() Again it would be the java class' responsibility to do and/or return something useful. What do you think of this idea ? It can be done: --------------- The following two little changes (against the 2.1 codebase) enable the above. I am using this extensively for much closer Jython/Java integration. Is it worth opening a patch ? 1) File /core/PyJavaInstance.java: Old method: protected void noField(String name, PyObject value) { throw Py.TypeError("can't set arbitrary attribute in java instance: "+ name); } replaced with: protected void noField(String name, PyObject value) { PyObject method = __class__.lookup("__setattr__", false); if ( method == null ) { throw Py.TypeError("can't set arbitrary attribute in java instance: " + name); } else { method.__call__(this, new PyString(name), value); } } 2) File /core/PyInstance.java: Old method: protected PyObject ifindfunction(String name) { PyObject getter = __class__.__getattr__; if (getter == null) return null; try { return getter.__call__(this, new PyString(name)); } catch (PyException exc) { if (Py.matchException(exc, Py.AttributeError)) return null; throw exc; } } replaced with: protected PyObject ifindfunction(String name) { PyObject getter = __class__.__getattr__; if ( getter == null && __class__.getProxyClass() != null ) { getter = __class__.lookup("__getattr__", false); } if ( getter == null ) { return null; } try { return getter.__call__(this, new PyString(name)); } catch (PyException exc) { if (Py.matchException(exc, Py.AttributeError)) return null; throw exc; } } Many thanks for your feedback. Always-trying-to-make-jython-even-more-useful-ly yours Oti. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
From: Jim A. <ji...@tr...> - 2002-07-08 07:48:20
|
[Oti wrote:] >Now it would be even cooler if methods > __getattr__() > __setattr__() >would be invoked if i use > x =3D X() > x.undefinedAttribute > x.undefinedAttribute =3D 10 > x.undefinedMethod() >Again it would be the java class' responsibility to do and/or return >something useful. >What do you think of this idea ? Nice ! I, for one, would be able to use this. I add Java classes into= Jython for my scripting users; for these classes I would just implement= the 'standard Python' behavior of setting arbitrary attributes (with a= HashMap, I suppose...). In other cases I might use something more complex. Currently I 'wrap' the Java classes with Jython classes to get this= behavior. I suppose there is a good reason why the 'standard python' behavior can't= be done for Java objects as a default ? In any case, using the= 'getattr/setattr' is easy enough... Thanks for all the great work ! - Jim Adrig |
From: Oti <oh...@ya...> - 2002-07-09 06:36:29
|
[ Jim Adrig ] > [Oti wrote:] > > >Now it would be even cooler if methods > > __getattr__() > > __setattr__() > >would be invoked if i use > > x = X() > > x.undefinedAttribute > > x.undefinedAttribute = 10 > > x.undefinedMethod() > >Again it would be the java class' responsibility to do and/or return > >something useful. > >What do you think of this idea ? > > > Nice ! I, for one, would be able to use this. Pleased to hear. > I add Java classes into > Jython for my scripting users; for these classes I would just > implement the 'standard Python' behavior of setting arbitrary > attributes (with a HashMap, I suppose...). In other cases I might use > something more complex. > > Currently I 'wrap' the Java classes with Jython classes to get this > behavior. My aim is exactly the same: enable easy scripting for my users. My java classes are very dynamic: they contain data and metadata. So the first attempt was to write a jython wrapper (like you did), but as I pass these objects several times forth and back between jython and java, it is much more elegant to have the above syntax available on the java object itself. > > I suppose there is a good reason why the 'standard python' behavior > can't be done for Java objects as a default ? In any case, using the > 'getattr/setattr' is easy enough... > > Thanks for all the great work ! You are welcome (my part being not so great :-) Best wishes, Oti. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
From: Oti <oh...@ya...> - 2002-10-25 21:26:13
Attachments:
string_javatests.py
string.py.diff
|
Hello, the functions in /Lib/string.py currently do not accept java.lang.String as arguments. Should they ? string_javatests.py shows what can go wrong. string.py.diff (simple diff) gives an idea what i've done to make string_javatests.py pass. Is this worth opening a patch, or am i the only one who needs it ? Thanks for feedback, and best wishes! Oti. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ |
From: Oti <oh...@ya...> - 2002-10-25 21:44:39
|
Hello, the example below demonstrates that it is necessary to use self.super__ to call a final protected method of a java superclass. Is this a feature or a bug ? If the latter, do you have a pointer where to try to fix it ? Many thanks, and best wishes ! Oti. Sup.java: --------- package CH.obj.Test; public class Sup { final protected String getProtected() { return "i am final and protected"; } } Sub.py: ------- from CH.obj.Test import Sup class Sub( Sup ): def test( self ): print self.super__getProtected() # works print self.getProtected() # AttributeError: getProtected sub = Sub() sub.test() calling 'jython Sub.py': ------------------------ i am final and protected Traceback (innermost last): File "Sub.py", line 9, in ? File "Sub.py", line 6, in test AttributeError: getProtected __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ |
From: Oti <oh...@ya...> - 2002-10-28 05:26:37
|
[ me ] > the example below demonstrates that it is necessary to use > self.super__ > to call a final protected method of a java superclass. Is this a > feature or a bug ? I was so confused I did not check the docs: http://www.jython.org/docs/subclassing.html SORRY. Oti. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ |
From: Samuele P. <ped...@bl...> - 2002-10-25 22:10:15
|
From: "Oti" <oh...@ya...> > Hello, > > the functions in /Lib/string.py currently do not accept > java.lang.String as arguments. Should they ? very likely no [we already had this discussion] > string_javatests.py shows what can go wrong. > string.py.diff (simple diff) gives an idea what i've done > to make string_javatests.py pass. > Is this worth opening a patch, or am i the only one who needs it ? my question is why you need to manipulate Java strings on the jython side in the first place, apart as result from the constructor you should not see them. Why, how do you get them? string.py is going to be very likely slowly deprecated in CPython, see PEP 283 because its functionality is mostly offered by string methods, so I don't see why we should add features to it. regards. |
From: Oti <oh...@ya...> - 2002-10-25 23:04:10
|
[ Samuele Pedroni ] > From: "Oti" <oh...@ya...> > > Hello, > > > > the functions in /Lib/string.py currently do not accept > > java.lang.String as arguments. Should they ? > > very likely no [we already had this discussion] sorry to have forgotten/missed it. > my question is why you need to manipulate Java strings on the jython > side in > the first place, > apart as result from the constructor you should not see them. Why, > how do you > get them? We are writing JUnit tests in Jython. If a method returns a byte or char array, it is convenient to use a java.lang.String constructor and then use string.find() or similar to inspect it. And it is from time to time confusing for users (including me:-) to have the same 'string handling' code running for the result of a java method returning java.lang.String, but failing for a just instantiated java.lang.String > string.py is going to be very likely slowly deprecated in CPython, > see PEP 283 > > because its functionality is mostly offered by string methods, so I > don't see > why we should add features to it. Ok, no problem with that. Thanks very much for the quick response ! Oti. PS. Could you then please remove patch [ 529629 ] string.replace( java.lang.String ) from SF? It was a poor attempt to fix the most hitting feature. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ |
From: Samuele P. <ped...@bl...> - 2002-10-25 23:25:29
|
From: "Oti" <oh...@ya...> > > We are writing JUnit tests in Jython. If a method returns a byte or > char array, it is convenient to use a java.lang.String constructor and > then use string.find() or similar to inspect it. > > And it is from time to time confusing for users (including me:-) to > have the same 'string handling' code running for the result of a java > method returning java.lang.String, but failing for a just instantiated > java.lang.String > if I understand correctly you have a method returning byte/char arrays: obj.meth() and you do s = java.lang.String(obj.meth()) You could use tostring (the jython char/byte array wrapper method): ar = obj.method() s = ar.tostring() # produces a Python string regards. |
From: Ype K. <yk...@xs...> - 2002-10-26 18:19:24
|
On Saturday 26 October 2002 01:17, Samuele Pedroni wrote: > From: "Oti" <oh...@ya...> > > > We are writing JUnit tests in Jython. If a method returns a byte or > > char array, it is convenient to use a java.lang.String constructor an= d > > then use string.find() or similar to inspect it. > > > > And it is from time to time confusing for users (including me:-) to > > have the same 'string handling' code running for the result of a java > > method returning java.lang.String, but failing for a just instantiate= d > > java.lang.String > > if I understand correctly you have a method returning byte/char array= s: > > obj.meth() > > and you do > > s =3D java.lang.String(obj.meth()) > > You could use tostring (the jython char/byte array wrapper method): > > ar =3D obj.method() > s =3D ar.tostring() # produces a Python string When I needed tostring() I had to consult the sources to find it. Can I suggest to add it to the the java array documentation on jython.org= ? Alternatively it might be worthwhile to implement str() on java arrays. In case that takes not much more than implementing PyJava.__str__() in ja= va, I'd be willing to give it a try. Regards, Ype P.S. In case you know that know that PyArray implements module jarray this is helps somewhat: http://www.jython.org/docs/javadoc/org/python/core/PyArray.html#tostring(= ) =46rom there one still has to deduce from the return type and the java/jy= thon=20 type conversion that it works to produce a Python string when called from= =20 python. |
From: Oti <oh...@ya...> - 2002-10-28 05:50:10
|
[ Samuele Pedroni ] > > > > We are writing JUnit tests in Jython. If a method returns a byte or > > char array, it is convenient to use a java.lang.String constructor > and > > then use string.find() or similar to inspect it. > > > > And it is from time to time confusing for users (including me:-) to > > have the same 'string handling' code running for the result of a > java > > method returning java.lang.String, but failing for a just > instantiated > > java.lang.String > > > > if I understand correctly you have a method returning byte/char > arrays: > > obj.meth() > > and you do > > s = java.lang.String(obj.meth()) exactly. > You could use tostring (the jython char/byte array wrapper method): > > ar = obj.method() > s = ar.tostring() # produces a Python string yes, this works. Thanks ! Oti. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ |
From: <no...@so...> - 2002-09-25 20:04:00
|
Patches item #614598, was opened at 2002-09-25 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Otmar Humbel (otmarhumbel) Assigned to: Nobody/Anonymous (nobody) Summary: __tojava__() in PyJavaInstance Initial Comment: Because a PyJavaInstance knows about its java counterpart, i suggest adding the following convenience method: public Object __tojava__() { return super.__tojava__( __class__.proxyClass ); } to PyJavaInstance.java. Example usage: In an embedding situation where you don't know what eval() will return, it would be nice if a PyJavaInstance result simply could be turned into a java object. Many thanks, and best wishes, Oti. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 |
From: <no...@so...> - 2002-10-29 12:15:35
|
Patches item #614598, was opened at 2002-09-25 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Otmar Humbel (otmarhumbel) Assigned to: Nobody/Anonymous (nobody) Summary: __tojava__() in PyJavaInstance Initial Comment: Because a PyJavaInstance knows about its java counterpart, i suggest adding the following convenience method: public Object __tojava__() { return super.__tojava__( __class__.proxyClass ); } to PyJavaInstance.java. Example usage: In an embedding situation where you don't know what eval() will return, it would be nice if a PyJavaInstance result simply could be turned into a java object. Many thanks, and best wishes, Oti. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2002-10-29 13:15 Message: Logged In: YES user_id=4201 I'll reject this patch because you can the proxy instance by calling the method __tojava__(Object.class) on the instance. If a convinience method should be added at all, it must be added to PyObject as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 |
From: <no...@so...> - 2002-10-29 14:43:11
|
Patches item #614598, was opened at 2002-09-25 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Otmar Humbel (otmarhumbel) Assigned to: Nobody/Anonymous (nobody) Summary: __tojava__() in PyJavaInstance Initial Comment: Because a PyJavaInstance knows about its java counterpart, i suggest adding the following convenience method: public Object __tojava__() { return super.__tojava__( __class__.proxyClass ); } to PyJavaInstance.java. Example usage: In an embedding situation where you don't know what eval() will return, it would be nice if a PyJavaInstance result simply could be turned into a java object. Many thanks, and best wishes, Oti. ---------------------------------------------------------------------- >Comment By: Otmar Humbel (otmarhumbel) Date: 2002-10-29 15:43 Message: Logged In: YES user_id=105844 Thank you for the response ! The Object.class trick is cool - nonetheless I wouldn't have a problem if you added a convenience method to PyObject. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2002-10-29 13:15 Message: Logged In: YES user_id=4201 I'll reject this patch because you can the proxy instance by calling the method __tojava__(Object.class) on the instance. If a convinience method should be added at all, it must be added to PyObject as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=614598&group_id=12867 |