From: Charlie G. <cha...@gm...> - 2007-12-27 00:47:05
|
I'm planning on merging the exposed_annotation branch to trunk this weekend. It allows types written in Java to be exposed to Python using annotations on the methods and fields to be made visible rather than with the *exposed templates in src/templates. I've written up the basics for using it at http://wiki.python.org/jython/PythonTypesInJava I figured it was worth bringing up since it changes how the core classes are represented, and could cause some slight breakage that I'm missing. I merged from trunk to it a couple days ago and all of regrtest passes, so if it is broken, it's not broken terribly. I'd like to merge it fairly soon to allow new types being written using this system rather than forcing new developers to learn the templating system. I'd also like to set up some Google Highly Open Participation tasks to convert the remaining classes to the annotations: I've only converted PyBuiltinFunction, PyInteger, PyNone, PyObject, PyString, PyType and PyUnicode. I've already got a couple other GHOP tasks available for students to take, and I'd like to put a couple more up and this seems like an ideal candidate. The implementation has reached a point where it can do everything the templates can, so now seems like a good time. Charlie |
From: Samuele P. <ped...@op...> - 2007-12-28 20:44:23
|
Charlie Groves wrote: > I'm planning on merging the exposed_annotation branch to trunk this > weekend. It allows types written in Java to be exposed to Python > using annotations on the methods and fields to be made visible rather > than with the *exposed templates in src/templates. I've written up > the basics for using it at > http://wiki.python.org/jython/PythonTypesInJava I figured it was > worth bringing up since it changes how the core classes are > represented, and could cause some slight breakage that I'm missing. I > merged from trunk to it a couple days ago and all of regrtest passes, > so if it is broken, it's not broken terribly. > > I'd like to merge it fairly soon to allow new types being written > using this system rather than forcing new developers to learn the > templating system. I'd also like to set up some Google Highly Open > Participation tasks to convert the remaining classes to the > annotations: I've only converted PyBuiltinFunction, PyInteger, PyNone, > PyObject, PyString, PyType and PyUnicode. I've already got a couple > other GHOP tasks available for students to take, and I'd like to put a > couple more up and this seems like an ideal candidate. The > implementation has reached a point where it can do everything the > templates can, so now seems like a good time. > > I would say go ahead, although as I feared the with the new code is more cryptic to know what the generated code does, it is very positively less code than the old approach and doesn't involve maintaining a full obscure Java parser and is using techniques that should be more familiar and documented for Java programmers. Merging is probably the best way to hammer out the last problems. Samuele |
From: Philip J. <pj...@gr...> - 2007-12-30 00:53:39
|
On Dec 26, 2007, at 4:47 PM, Charlie Groves wrote: > I'm planning on merging the exposed_annotation branch to trunk this > weekend. It allows types written in Java to be exposed to Python > using annotations on the methods and fields to be made visible rather > than with the *exposed templates in src/templates. I've written up > the basics for using it at > http://wiki.python.org/jython/PythonTypesInJava I figured it was > worth bringing up since it changes how the core classes are > represented, and could cause some slight breakage that I'm missing. I > merged from trunk to it a couple days ago and all of regrtest passes, > so if it is broken, it's not broken terribly. > > I'd like to merge it fairly soon to allow new types being written > using this system rather than forcing new developers to learn the > templating system. I'd also like to set up some Google Highly Open > Participation tasks to convert the remaining classes to the > annotations: I've only converted PyBuiltinFunction, PyInteger, PyNone, > PyObject, PyString, PyType and PyUnicode. I've already got a couple > other GHOP tasks available for students to take, and I'd like to put a > couple more up and this seems like an ideal candidate. The > implementation has reached a point where it can do everything the > templates can, so now seems like a good time. > Great! We should probably kill the old gexpose/derived template files for the classes that are now exposed. Also, a couple nitpicks about coding standards: Could we standardize on a space in between if/else blocks and their parens? i.e. if ( instead of if( ? Also class variables should be declared at the top of the class, at least that's what our coding standards example shows and is what most jython code does. Converting classes over will be good GHOP tasks, but I'm definitely going to have to convert some over myself ASAP. It's just so much nicer, thanks for doing this. -- Philip Jenvey |
From: Philip J. <pj...@gr...> - 2007-12-30 02:04:18
|
On Dec 29, 2007, at 4:53 PM, Philip Jenvey wrote: > > We should probably kill the old gexpose/derived template files for > the classes that are now exposed. > Er, we still need these for the derived classes, don't we? Can we nuke the expose entry in mappings, or does gderived.py need that as well? Running gexpose.py without an argument right now crashes when it hits an exposed file without the magic gexpose comment. That could be confusing for a newer developer is my only worry. -- Philip Jenvey |
From: Charlie G. <cha...@gm...> - 2007-12-30 02:30:50
|
On Dec 29, 2007 6:04 PM, Philip Jenvey <pj...@gr...> wrote: > > On Dec 29, 2007, at 4:53 PM, Philip Jenvey wrote: > > > > We should probably kill the old gexpose/derived template files for > > the classes that are now exposed. > > > > Er, we still need these for the derived classes, don't we? Can we > nuke the expose entry in mappings, or does gderived.py need that as > well? > > Running gexpose.py without an argument right now crashes when it hits > an exposed file without the magic gexpose comment. That could be > confusing for a newer developer is my only worry. Right, I've only added something to take care of what gexpose does. gderived is still needed for the time being, but it doesn't need the expose mappings. I removed the mappings and expose files for the types I've converted on the exposed branch, and gexpose and gderived run to completion now. Thanks for catching this! Charlie |
From: Samuele P. <ped...@op...> - 2007-12-30 15:30:09
|
Philip Jenvey wrote: > On Dec 29, 2007, at 4:53 PM, Philip Jenvey wrote: > >> We should probably kill the old gexpose/derived template files for >> the classes that are now exposed. >> >> > > Er, we still need these for the derived classes, don't we? > I suppose the same techniques could be applied to those, although maybe in that case it could be better to generate a dummy derived class from a .java file with javac and then write code that would manipulate and edit the bytecode, instead of writing code to generate the all thing from scratch. One of the reason I went for the templates - apart that I was targetting a pre annotation world -, is that they were far easier to change quickly when I was still trying to understand what they had to do exactly. That issue is hopefully not present anymore now. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Charlie G. <cha...@gm...> - 2007-12-30 02:28:23
|
On Dec 29, 2007 4:53 PM, Philip Jenvey <pj...@gr...> wrote: > Also, a couple nitpicks about coding standards: > > Could we standardize on a space in between if/else blocks and their > parens? i.e. if ( instead of if( ? > > Also class variables should be declared at the top of the class, at > least that's what our coding standards example shows and is what most > jython code does. Added both of these to the wiki page. > Converting classes over will be good GHOP tasks, but I'm definitely > going to have to convert some over myself ASAP. Just let me know which ones you want to do, or do it in the next couple of days before I write up the task. Charlie |