orbit-python-list

[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.

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

[Christian R. R. <ki...@as...>]

On 3 Apr 2001, Jason Tackaberry wrote:

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

And this is definitely news. Congratulations Jason, Roland, and everybody
else that worked on orbit-python during the period.

>    * 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.

I believe the spec is important to a certain point, and beyond that, it's
nonsense. The spec is there to guarantee portability between ORBs, but if
you care very little about it, there's good reason to implement convenient
mechanisms as options.

My personal opinion is that there should be a 'strict' mode and a 'o-p'
mode, and implementing as far as it's possible both options in the
codebase. I understand this does elevate complexity in the sense that
methods will have dual behaviour, but it's not undoable, and the benefits
are certainly important. The two points mentioned are very important, IMO:

- Transparent Accessors
- Any Coercion

to acheive the 'total' transparency feature. Python's dynamic nature is
tied nicely to Any coercion, since you can really take advantage of the
flexibility types give us. And accessors.. well, do we really want to
keep calling underscored methods? ;-)

AFAIC the spec is broken if it doesn't take into account these aspects. I
could, of course, be completely wrong.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

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

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

> I believe the spec is important to a certain point, and beyond that, it's
> nonsense. The spec is there to guarantee portability between ORBs, but if
> you care very little about it, there's good reason to implement convenient
> mechanisms as options.

As you know, I'm not opposed to implementing extensions where they make
sense.  And the mapping spec certainly doesn't say implemenations can't
add their own extensions.  In fact, most of them do, I think.

The spec defines a base, so that all code written in compliance will be
portable between any compliant implementation.  So this is a good thing.
The trick is implementing extensions so they don't break the spec, and
that making sure programmers who use the extensions know they're
non-compliant.  This is one point that'll have to be worked out first.

> My personal opinion is that there should be a 'strict' mode and a 'o-p'
> mode, and implementing as far as it's possible both options in the
[...]
> to acheive the 'total' transparency feature. Python's dynamic nature is
> tied nicely to Any coercion, since you can really take advantage of the

Well, coercing Any is a little different than the transparent accessors.
With the transparent accessors you can use them, but you don't have to.
Your code works fine either way.  If you coerce _from_ Any to a Python
object (e.g. any myfoo() return the value itself instead of a CORBA.Any
object), then code that expects CORBA.Any will break. Coercing to Any
will work fine, mind you.

So I can see 3 different modes: strict, which forces you to comply with
the mapping spec; extended, which implements stuff like transparent
accessors, type coercion where it doesn't break the spec; and enhanced,
which implements all the fancy features we want.  (These names are up
for debate.)

"Extended" mode is a strict superset of "strict" mode, so that code
that's spec-compliant will work properly under Extended mode, but maybe
not vice versa.  "Enhanced" mode would contain stuff like coercion
_from_ CORBA.Any, where code that comes from another ORB _probably_
won't work without modification.  Extended mode would be the default.
The programmer can manually change the mode.  So if he wants to make
sure the code is easily portable to a different ORB, he'll turn on
"strict" mode.  ('course the interface to enable strict mode won't be
portable, but we can't have everything. :D)  If he wants to take
advantage of all the goodies, such as in your case, he'll enable
enhanced mode.

I'm mostly thinking aloud here.  Please everyone chime in with comments.
Once I organize my thoughts a bit better I'll consult the gurus on
Python do-sig and gather their input.

> flexibility types give us. And accessors.. well, do we really want to
> keep calling underscored methods? ;-)


Duncan Grisby gave some pretty compelling arguments in favor of using
the accessor functions in an email last August or September.  Basically
he said with:

   object.value = 1
   object.value = object.value + 2

By reading that code you'd assume object.value must be 3.  But it's
possible for the server implementation to override object._set_value (or
the __setattr__ method) to do something completely arbitrary.  It's also
possible for another client to modify object.value in between the first
two transparent method invocations.
object._set_value(object._get_value() + 2) is a little uglier but also a
little more explicit.  In some ways, it's more readable.  So it's not as
if the accessor methods are pointless in the face of the transparent
ones.  But I think the choice should be there for ORBit-Python because
nothing is sacrificed by providing it.

Jason.

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

[Christian R. R. <ki...@as...>]

On 4 Apr 2001, Jason Tackaberry wrote:

> So I can see 3 different modes: strict, which forces you to comply with
> the mapping spec; extended, which implements stuff like transparent
> accessors, type coercion where it doesn't break the spec; and enhanced,
> which implements all the fancy features we want.  (These names are up
> for debate.)

The names and theory are okay with me. 

> I'm mostly thinking aloud here.  Please everyone chime in with comments.
> Once I organize my thoughts a bit better I'll consult the gurus on
> Python do-sig and gather their input.

So how did they react to the idea?

> object._set_value(object._get_value() + 2) is a little uglier but also a
> little more explicit.  In some ways, it's more readable.  So it's not as
> if the accessor methods are pointless in the face of the transparent
> ones.  But I think the choice should be there for ORBit-Python because
> nothing is sacrificed by providing it.

After 2000 lines of _get_value and _set_value the transparent accessors
look nice, you know? :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

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

[Roland M. <lo...@de...>]

Jason Tackaberry (2001-04-03 00:29:29 -0400) :

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

For those of you out there running Debian...  I packaged and uploaded
this new version a few hours ago.  It should reach the "unstable"
distribution in another few hours, and "testing" in some days
(maybe).

Roland.
-- 
Roland Mas

C'est dans la boue la plus nauséeuse que plongent les racines de
l'étincelante fleur de lotus. -- in Sri Raoul le petit yogi (Gaudelette)