From: Brian Z. <bz...@zi...> - 2005-04-01 01:32:40
|
I created a pep302 branch and checked in my initial implementation of the PEP. There are a couple bugs related to JythonC which I need to fix but the rest of the tests pass. The biggest change with this implementation is Java classes are loaded first rather than last. I had to fix a method in the package managers to account for this change and there might be other side affects. If you have some spare cycles please give the branch a test run. thanks, brian |
From: Frank W. <fwi...@gm...> - 2005-04-01 03:16:00
|
Brian, Are bugs to be considered closed if there is a fix in the tip? For example, bug 1005593 concerns the use of "assert" in the Java code, which has been fixed in CVS (with a namechange to assert_ in Py.java). Should this bug be closed even though it is still a problem in the 2.1 release? Closing bugs, or marking them somehow, would make sifting through the open bugs a bit easier. Thanks, Frank |
From: Brian Z. <bz...@zi...> - 2005-04-01 12:51:44
|
Yes, all bugs confirmed fixed on tips should be closed. brian On Mar 31, 2005, at 09:15 PM, Frank Wierzbicki wrote: > Brian, > > Are bugs to be considered closed if there is a fix in the tip? For > example, bug 1005593 concerns the use of "assert" in the Java code, > which has been fixed in CVS (with a namechange to assert_ in Py.java). > Should this bug be closed even though it is still a problem in the > 2.1 release? Closing bugs, or marking them somehow, would make > sifting through the open bugs a bit easier. > > Thanks, > Frank > |
From: Samuele P. <ped...@st...> - 2005-04-02 15:05:27
|
Brian Zimmer wrote: > I created a pep302 branch and checked in my initial implementation of > the PEP. There are a couple bugs related to JythonC which I need to fix > but the rest of the tests pass. > > The biggest change with this implementation is Java classes are loaded > first rather than last. I had to fix a method in the package managers > to account for this change and there might be other side affects. > so far I have had no time to play with it. Anyway possible slightly different approach would be to use different methods instead of the PEP302 ones for java loading and call them scanning the meta_path after the all of python importing. If we want to let wrap classloaders in some wrappers that can be put on the meta_path we probably need to extend anyway the API to support is-java-package and dir on java packages operations. > If you have some spare cycles please give the branch a test run. > > thanks, > > brian > > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Brian Z. <bz...@zi...> - 2005-04-05 03:47:51
|
On Apr 2, 2005, at 09:07 AM, Samuele Pedroni wrote: > so far I have had no time to play with it. Anyway possible slightly > different approach would be to use different methods instead of the > PEP302 ones for java loading and call them scanning the meta_path > after > the all of python importing. If we want to let wrap classloaders in > some wrappers that can be put on the meta_path we probably need to > extend anyway the API to support is-java-package and dir on java > packages operations. > I'd really like to not deviate from the pep so I'll have to look at this more closely as I start to work custom classloading. I did just commit the final changes to the pep302 branch to pass all the bugtests and the test_importhooks test. I'm not using this branch and haven't seen any problems. I ended up adding two different meta_path importers, one for precompiled classes and one for all other Java classes. There is also a ZipFileImporter installed in the path_hooks. All three are extensively tested throughout the bugtests. I'm going to use this branch for a couple more days and then I'll probably merge it to tip. I was thinking of creating a new package 'importer' (or something) and moving the new importers there as well as all the support code such as PackageManagers, the imp in core and the classloaders. The core package is getting quite large and I think this is a fair break out. Any thoughts? thanks, brian |