[Orbit-python-list] ORBit-Python 0.2.0 released

[Jason T. <ta...@li...>]

After a year of off-and-on development, I have finally released version
0.2.0.

Quite a bit has changed since the last release (0.1.3).  ORBit-Python
(and since I'm lazy, I've been starting to call it O-P for short) has
taken the dynamic IDL approach to another level by dynamically
preprocessing IDL modules and interfaces at load (import) time.  Now not
only is a separate IDL compilation step unnecessary, but in most cases
you also needn't specify _which_ IDL files need to be loaded.

With the new release comes a newly designed website
(http://orbit-python.sault.org/) where you can find the what might
actually resemble documentation.  Right now documentation is sparse, but
please suggest improvements and other topics.  I'd like to thank Roland
Mas, Christian Reis, and Johan Dahlin for helping out with testing, bug
reporting, suggestions, and so forth.  We have an IRC channel on the
OpenProjects Network called #orbit-python if you'd care to join in on
development discussions (although we mostly idle :)).

My original vision for ORBit-Python was _seamless_ bindings.  That is,
from the user's perspective, I wanted remote objects to work as close to
local Python objects as possible.  The Python mapping specification was
not formalized at the time I started the project, and so originally I
used it more as inspiration and guidelines than gospel.  Duncan Grisby
(omniORBpy) has since convinced me of the mapping spec's merits.  Since
0.1.3, quite a bit of work has been done to make O-P more compliant to
what is now the formalized Python mapping specification.  It's still not
perfect, but it's certainly come a long way since 0.1.3.

So, I can identify what I see to be my two main goals for ORBit-Python:

   * Seamless Python <-> CORBA bindings
   * Python mapping spec compliant

These two goals often seem to work against each other.  For example, I
want transparent accessor functions (i.e. obj.myint = 1 instead of
obj._set_myint(1)), but the mapping spec requires that the accessor
pairs be available.  O-P supports both approaches, but it should be made
clear to the programmer that choosing the transparent accessors is going
to result in non-compliant code.  I've also been considering coersion
between CORBA.Any and Python objects, but this too would break the spec.
These sorts of issues will need to be worked out; expect discussions
here and on the Python dosig list.

There are currently no known critical bugs with O-P, but there are a few
small memory leaks and some rough edges that need to be sorted out in
future versions.  As always, please report bugs and suggest
improvements.

Cheers,
Jason.