OmniOrbPy2DevelopmentStatus

omniORBpy 2

omniORBpy 2 is the current major release of omniORBpy. This page started out as documentation of new features available when omniORBpy 2 was in development, but it still contains useful information.

Snapshots of changes since the release are available at http://omniorb.sourceforge.net/snapshots/ .

omniORBpy 2 only works with omniORB 4.0. Many of the new features are actually new features of omniORB 4.0, so you should look at OmniOrb4DevelopmentStatus. We try to keep omniORBpy 2 in step with the changes in omniORB 4.0, but updates to the omniORB 4.0 tree may occasionally break omniORBpy. Now omniORB 4.0 and omniORBpy 2.0 are stable releases, updates should no longer break anything, but it is still always best to keep up to date with both packages.

Implemented New Features

omniORBpy 2 supports the majority of the new features in omniORB 4.0, described in OmniOrb4DevelopmentStatus, plus...

wchar, wstring and codeset support

wchar and wstring are supported provided you are using Python 2.0 or later. wchar and wstring are mapped to the Python Unicode type, so the native wchar code set is always UTF-16. You can choose your native char code set with the -ORBnativeCharCodeSet <code set> command line argument, or the omniORB.nativeCharCodeSet() function.

Better multi-threading behaviour

The Python interpreter lock is released whenever doing a potentially blocking call. This means that heavily multi-threaded programs will perform better.

Fast in-process calls to/from C++

In omniORB 3.0 / omniORBpy 1, CORBA calls between Python and C++ in the same process went via the TCP loopback interface. They now use an in-memory transport for an order-of-magnitude performance increase.

Docstrings

As an extension to the CORBA Python mapping, omniORBpy 2 handles pseudo-docstrings in IDL, turning them into Python docstrings. You specify a docstring in IDL using a string constant with the suffix doc. If there is a corresponding declaration in the same scope, the docstring is attached to the generated Python class/method. Alternatively, with modules and interfaces, the "docstring" constant can appear inside the module/interface. e.g.

   module Foo {
     const string Foo__doc__ = "This is the Foo module";
     interface Test {
       void wibble();
       const string wibble__doc__ = "The wibble operation is pretty useless";
     };
     const string Test__doc__ = "The test interface is just a demo";
   };

Now in Python, you can access the docstrings as usual:

   >>> import Foo
   >>> print Foo.__doc__
   This is the Foo module
   >>> print Foo.Test.__doc__
   The test interface is just a demo
   >>> obj = # acquire a Foo reference from somewhere
   >>> print obj.__doc__
   The test interface is just a demo
   >>> print obj.wibble.__doc__
   The wibble operation is pretty useless

The string constants are still available under the names required by the Python language mapping (Foo.Foo__doc__ for example), so this extension is fully compliant with the spec.