Monday, October 30, 2006

Striking a balance

Sometime while I was writing version 0.5 of JPype, I realized I was writing a lot of C++ code, so I could enoy writing in Python ... not a very intelligent thing to do I think.

So in version 0.6 I decided to move as much "logic" from the C++ layer, up to the python layer or down into the Java layer, depending on the actual functionality.

0.6 is well under way, and so far thigns seem to be holding up. The upshot od that both Pythona nd Java are a LOT easier to work with than C++, so development velocity is greatly enhanced.

There are 2 caveats though. Hence the "striking a balance" title of this post.

The first is that with logic moved outside of C++, the interface between Python/C++ and Java/C++ becomes that much more complex. Handling all that by hand would mean a lot boilerplate code, and a lot of potential mistakes. So to ease that burden, I've written two tools : one called JNILayer is for the Java/C++ interface, the other for the Python/C++ layer is called PNIH (Python Native Interface Header). I'll probabl talk about them in a later post.

The other caveat, also related to the more complex interfaces, is performance. JNI is known as a performance bottleneck, and I can't imagine that the Reference wrapping I've had to do helps anything. Hopefully, performance will not be abysmal, and with a few tweaks will be good enough to be often by the other benefits.

I guess only time will tell :)

Tuesday, October 17, 2006

Shelving PNI for now

I realized that PNI, while a good idea, will require a lot of time and effort to realize. So for now I have decided to concentrate on JPype. The work I did on PNI has already impacted the release of the next version of JPype, and I don't want to impact it more.

I am still developing JPype with PNI in mind. The only non-pni-compliant code in JPype is auto-generated. So if PNI ever comes to be, I can simply change the code generator (and of course adjust the rest of the code to whatever final form PNI has).

If PNI never sees the light of day ... Well then it'll simply be a abstraction layer that JPype uses :).

Tuesday, October 10, 2006

Is the python community unable to see it's own weaknesses?

Over a week and a half ago, I posted a proposal on the Python mailing list/newsgroup. If you've seen my previous blog entry you already know what it was about. For the others, it is a proposal to remedy one of python's weaknesses : native extensions must be compiled for a specific Python version using the same compiler used to compile that python version. I've seen over time many people call this a nightmare, especially on windows.

Fast-forward one week, and I haven't had a single response. Not one! People on the mailing list wax poetic on trivial issues such as being more polite toward Perl.

Is this a case of blindness? Are extension writers so comfortable with this situation that they don't care? I mean I don't expect my proposal to be accepted as is, but I was hoping it would at least spark a discussion.

I will assume the answer is different, and that it is a simple case of bad timing. I will prepare a shorter, easier to digest proposal and post it again. Then we'll see.

In the meantime .. Feel free to tell me how receptive the python community at large has been to your ideas so far.