Comments on Wardrobe strength: Java integration in future Jython

Decorators or not, I'd quite like to see a Java mo...

2010-02-11T01:40:16.222+01:00

Decorators or not, I'd quite like to see a Java module that worked in CPython.

Kay Schluehr also suggested allowing decorators on...

2009-08-14T08:31:39.949+02:00

Kay Schluehr also suggested allowing decorators on assignments, to be able to support annotations on fields. I don't really have an opinion on this. Since I don't think fields should be exported in any public API anyway it's a bit useless

The purpose of adding all the boilerplate to Python classes is to lift the Python interface to Java providing a complete description. This doesn't mean that the fields have to be public. Annotating private fields is very common in Java, just look at examples using persistence annotations in JEE. Those are unrelated to DI but provide information to the ORM.

About Python DSL syntax for defining Java interfaces / annotations in Python. This is useless since the most succinct way to define them is to state the interfaces directly in Java. The definitions might be inlined in Python and compiled dynamically. One doesn't have to leave the script.

I'd personally lean towards always having the load...

2009-08-14T08:11:02.840+02:00

I'd personally lean towards always having the loader hook present and having an option which disables it.

I'm not sure a zero-effort integration of Jython/IronPython code with CPython is even a realistic goal.

I don't think system configuration should not be handled on module level but using a command line option instead. This would require a bit of an architectural supplement which had to be PEP-ed. I'd suggest writing one if the problem was really pressing.

Otherwise a root package might define an "import java" statement which can be omitted for Jython which has different preferences/defaults than CPython or IronPython.

In IronPython "import clr" isn't actually required...

2009-08-14T03:05:33.859+02:00

In IronPython "import clr" isn't actually required for all access to .NET functionality. You can still do "import System" or pick your .NET namespace of choice and get those namespaces w/o doing import clr. And "import System" will actually have the same result as import clr: .NET members of shared typed (int, str, object, long, complex, etc...) will become available on the Python objects. So before one of these imports you get an error doing object().ToString(). Afterwards it works.

But we'll probably need to change that as 3.x rolls on: the importer will be written in Python and we won't be able to mark the calling module when we resolve one of these imports. And furthermore we'll need to use a real import hook for resolving the .NET namespaces and types. So we'll probably end up making "import clr" work like from __future__ imports and recognize it and only it at compile time.

I'd personally lean towards always having the loader hook present and having an option which disables it. The odd thing about doing it when you encounter "import java" is that it'll globally alter other modules - so it seems like it may as well be a global option from the start.

We're added a new __clrtype__ feature in 2.6 for supporting defining .NET classes from Python. But it's just a very primitive tool requiring the user to actually create the .NET type via Python code. We hope to plumb the Python side out later or have some ambitious user come up w/ something really cool. After we find the right API it'll probably end up like yours as a bunch of helpers in the clr module.

This sounds great.. a common java api for all pyth...

2009-08-13T17:01:40.255+02:00

This sounds great.. a common java api for all pythons would mean more eyes on the code.. the other integration ideas sound good too :)

The decorators look good too (although time would tell)

Also looking forward to ctypes working in jython, this is good stuff and will hopefully unlock some more libraries.