I'd like to point out some errors in the Python Language Mapping
document, ftp://ftp.omg.org/pub/docs/formal/01-02-66.pdf,
section 1.3.9 "Mapping for an Any".

The example which accompanies the text for this section
is vague, contains errors, and is confusing to someone who
is trying to learn how to use Anys in the Python Language Mapping.
For discussion of some of the errors in this example, refer to
the following messages on the omniORB mailing list:
http://www.uk.research.att.com/omniORB/archives/2001-04/0139.html
http://www.uk.research.att.com/omniORB/archives/2001-04/0140.html

I believe the example is broken in many ways, and should
be re-written to more clearly illustrate how to use Anys
with the Python Language Mapping.

I have re-written the example as follows:

========================================================================
import CORBA
import M

1. Create a value of type M.S
   v = M.S(1, CORBA.TRUE)
2. obtain type code
   tc=CORBA.TypeCode( CORBA.id(M.S) )
3. could also use: tc1=CORBA.TypeCode("IDL:M/S:1.0")

1. Create any containing an M.S object
   any1 = CORBA.Any(tc, v)

1. 1. the TypeCodes for the basic CORBA types are defined
   2. in the CORBA 2.4 standard, section 10.7.2 "TypeCode Constants"

1. Create any containing CORBA Long
   any2 = CORBA.Any(CORBA.TC_long, 1)
2. Create any containing CORBA Float
   any3 = CORBA.Any(CORBA.TC_float, 3.14)
3. Create any containing CORBA Float
   any4 = CORBA.Any(CORBA.TC_short, 5)
4. Create any containing CORBA unsigned
   any5 = CORBA.Any(CORBA.TC_ushort, 6)
5. Create any containing CORBA String
   any6 = CORBA.Any(CORBA.TC_string, "some string")

o = something() # somehow obtain reference to object of type M.foo

o.operate( any1 )
o.operate( any2 )
o.operate( any3 )
.
.
.

========================================================================

I believe that it is imperative that this example be changed in
Section 1.3.9 of the Python Language Mapping.

Duplicate of issue # 4315

Section 1.4.3 describes the mapping for CORBA.Context and states that a
"delete" operation is provided to delete child contexts. This introduces an
implementation detail that most likely requires circular references which is
not good with python.

Can the "delete" operation be deleted from the document? It is not needed
because there is no way to "lookup" child contexts – most of the other
language mappings do not have this method anymore.

Duplicate.

On page I-2 of ptc/00-04-08, the mentioning of alternate mappings
is a serious issue, since it means that scripts may not be portable
across implementations of this specification.

Duplicate, close issue

As far as I can tell, the language binding is silent on the
subject of attribute mapping. If an IDL interface specified an
attribute, how is this mapped into Python? Is this mapped to
a python attribute or to accessor functions?

withdrawn by submitter

The Python mapping for fixed point types is slightly unclear, and
could benefit from a few of the facilities from other language
mappings.

Below, I've written a proposed specification to replace the existing
section on fixed point. The changes are:

• replace "foo" and "bar" with "digits" and "scale"
• clarify meaning of integers used in constructor and value() method
• add a constructor taking a string
• correct "loss of precision" to be "overflow"
• add requirement for string conversion with str()
• add round() and truncate() methods
• clarify usage of CORBA.fixed() and add string-based versions
• relax the requirement that certain entities are classes

Here is the suggested replacement text:

------
IDL of the form

typedef fixed<digits,scale> MyFixed;

is mapped as follows:

• A constructor MyFixed() expecting either a string representing the
  fixed point value, or an integer type representing the digits of
  the value.

The string form of the constructor accepts a string representation
of a fixed point literal, with the trailing 'd' or 'D' optional.
The value is truncated if too many digits are given after the
decimal point. If there are too many digits before the decimal
point, or the string is not a valid fixed point value, a
CORBA.DATA_CONVERSION exception is raised.

The integer form of the constructor accepts a Python integer or
long integer, representing the digits of the fixed point value.
The integer is numerically the fixed point value * 10 ** scale.
If the integer has too many digits, CORBA.DATA_CONVERSION is
raised.

e.g. given IDL:

typedef fixed<5,2> MyFixed;

the following is true:

MyFixed("123.45") == MyFixed(12345)

• To facilitate the use of anonymous fixed point values, a generic
  CORBA.fixed() constructor is provided. Its arguments take three
  possible forms:

• A single string representing the fixed point value, with a
  trailing 'd' or 'D' optional. The resulting fixed point value
  derives its digits and scale from the string. Raises
  DATA_CONVERSION if the value exceeds the size of CORBA fixed,
  or the string is invalid.

• The digits and scale values, followed by a conforming string.
  The string is treated as with named types described above.

• The digits and scale values, followed by a conforming integer or
  long integer. The integer is treated as with named types
  described above.

e.g.

a = CORBA.fixed("123.45")
b = CORBA.fixed(5, 2, "123.45")
c = CORBA.fixed(5, 2, 12345)
assert(a == b)
assert(b == c)

The result of calling either kind of constructor is an object with the
following properties:

• Numeric operators for addition, subtraction, multiplication, and
  division, both of two fixed point numbers, and in combination with
  integers. A DATA_CONVERSION exception is raised if the operation
  results in an overflow.

• Operations as follows:

• value() returns an integer or long integer representing the
  digits of the fixed point number, in the form accepted by the
  constructors.

• precision() returns the number of digits.

• decimals() returns the scale.

• round(scale) returns a new fixed point number containing the
  original number rounded to the specified scale.

• truncate(scale) returns a new fixed point number containing the
  original number truncated to the specified scale.

• When a fixed point number is passed to the standard str()
  function, a string representing the fixed point value is returned.
  The string does not contain a trailing 'd'.

Accept the suggested changes

I'd like to point out some errors in the Python Language Mapping
document, ftp://ftp.omg.org/pub/docs/formal/01-02-66.pdf,
section 1.3.9 "Mapping for an Any".

The example which accompanies the text for this section
is vague, contains errors, and is confusing to someone who
is trying to learn how to use Anys in the Python Language Mapping.
For discussion of some of the errors in this example, refer to
the following messages on the omniORB mailing list:
http://www.uk.research.att.com/omniORB/archives/2001-04/0139.html
http://www.uk.research.att.com/omniORB/archives/2001-04/0140.html

I believe the example is broken in many ways, and should
be re-written to more clearly illustrate how to use Anys
with the Python Language Mapping.

I have re-written the example as follows:

========================================================================
import CORBA
import M

1. Create a value of type M.S
   v = M.S(1, CORBA.TRUE)
2. obtain type code
   tc=CORBA.TypeCode( CORBA.id(M.S) )
3. could also use: tc1=CORBA.TypeCode("IDL:M/S:1.0")

1. Create any containing an M.S object
   any1 = CORBA.Any(tc, v)

1. 1. the TypeCodes for the basic CORBA types are defined
   2. in the CORBA 2.4 standard, section 10.7.2 "TypeCode Constants"

1. Create any containing CORBA Long
   any2 = CORBA.Any(CORBA.TC_long, 1)
2. Create any containing CORBA Float
   any3 = CORBA.Any(CORBA.TC_float, 3.14)
3. Create any containing CORBA Float
   any4 = CORBA.Any(CORBA.TC_short, 5)
4. Create any containing CORBA unsigned
   any5 = CORBA.Any(CORBA.TC_ushort, 6)
5. Create any containing CORBA String
   any6 = CORBA.Any(CORBA.TC_string, "some string")

o = something() # somehow obtain reference to object of type M.foo

o.operate( any1 )
o.operate( any2 )
o.operate( any3 )
.
.
.

========================================================================

I believe that it is imperative that this example be changed in
Section 1.3.9 of the Python Language Mapping.

Accept the suggested rewrite of the examples

I suggest a change to the mapping for value boxes, that makes them
much more convenient to use. I believe that none of the Python ORBs
implement the currently specified mapping, so changing the mapping at
this point will not affect any ORB implementations or application
code.

I suggest that the new mapping is:

------
Value boxes are mapped to the normal mapping of the boxed type, or
None for null value boxes. For example, given IDL

valuetype BoxedString string;
interface I

;

the operation could be called as:

obj.example("Hello", None)

------

Discussion: this mapping has one limitation, in that in a boxed object
reference type it is impossible to distinguish a null value box from a
non-null value box containing a nil object reference. This is
considered acceptable since the IDL to Java mapping has the same
property; there is a clear precedent for this kind of mapping.

Accept the proposed changes

The ValueFactory mapping is slightly unclear. I suggest the following
revised text for the third paragraph of section 1.3.10:

For a given value type, the ValueFactory maps to a class instance
with a _call_ method taking no arguments. When it is called, it
returns a new instance of the value type. Initialiser operations of
the value type map to methods of the factory object. The registry
for value factories can be accessed using the standard ORB
operations register_value_factory, unregister_value_factory, and
lookup_value_factory. For value types without operations, a default
factory is registered automatically.

Accept the proposed changes

The Python mapping for context arguments is slightly unclear. I
suggest adding the following paragraph at the end of section 1.4.1:

If an operation in an OMG IDL specification has a context
specification, then a Context parameter follows all
operation-specific in and inout arguments. The caller must pass a
CORBA.Context object; if the object has the incorrect type, a
BAD_PARAM system exception is raised.

Accept the proposed changes

The adopted specification says that IDL modules map to Python modules,
and seems to imply that global modules are mapped to global modules
(without explicitly saying so). Is it conforming if the generated
module appear in an implementation-defined package? For example, to
access the CORBA module in ORB X, a number of implementations require
to write

from X import CORBA

instead of

import CORBA

With this approach, it is possible to have multiple implementations of
CORBA installed, but it requires applications to specify which one
they want to use.

Proposed resolution: In the section 1.2 (Scoped Names), add a
paragraph

An implementation can chose to map top-level definitions (including
the module CORBA) to modules in an implementation-defined package,
to allow concurrent installations of different CORBA runtime
libraries. In that case, the implementation must provide a
configuration option so that toplevel modules can be used without
without importing them from a package.

Supporting multiple implementations is desirable, however, one of them must be selected as the defau

There is an issue with widening object references using the CORBA.Any.value
method. The current spec. states that the value method returns a suitable type
of object for the accompanying type of the any. This is an issue when one
process sends an object reference which is not staticaly known to the
receiving ORB.

Since there it is not possible to find out anything about the embedded object in the general case, t

Section 1.5.1 describes the _default_POA operation as returning the value of
ORB.resolve_initial_reference ("RootPOA").

What ORB is used for this call (assumed static implementation-defined)? What
if no ORB has been initialized yet? What exceptions are raised if there is no
ORB?

Also, the _this operation needs a POA – which post likely implies that it
calls _default_POA by default. Are the same exceptions raised in this case?

The _default_POA operation assumes the default ORB. Any exceptions raised as a result are not specif

Section 14.4.4 describes the create_request method on CORBA.Object as taking:
the operation name, parameters and the opt. keyword arguments context, flags
and repository id.

Later on in section 1.6 the signature for create_request is shown as:
create_request (context, op_name, arg_list, result, flags)

Which definition is correct?

Also, shouldn't the name of this operation be "_create_request" to avoid name
clashes with user-defined operations?

It should be spelled _created_request; this is an editorial change. Also, the definition of that ope

Section 1.3.2 describes how wide strings (and wide chars) are mapped to an
implementation defined type.

It says that this type supports being passed to the std. python "len"
function – is the returned value of this supposed to be the length in wchars
or octets?

It says that CORBA.wstr returns a wide character with the code point "c" in
an implementation defined encoding. What happens if "c" not a valid code
point?

It says that "CORBA.word (CORBA.wstr (c)) == c". Does this also imply that
"len (CORBA.wstr (c)) == 1" and that CORBA.word only takes a wide string with
a length of one? What exceptions are raised if this is not true?

Since the len function always returns the number of elements in a sequence, it must return the numbe

The example in Section 1.2 "Using Scoped Names" states that:
module M

;
"would introduce a module M.py, which contains the following definitions:"

This section never describes how the programmer gets at those names, I assume
that if you want the definitions from module M, then you say: "import M".
This introduces a disgusting and serious flaw in the mapping in that IDL
compilers need to fake out the python module system and "update" IDL files.

rejected, issue closed

Section 1.4.3 describes the mapping for CORBA.Context and states that a
"delete" operation is provided to delete child contexts. This introduces an
implementation detail that most likely requires circular references which is
not good with python.

Can the "delete" operation be deleted from the document? It is not needed
because there is no way to "lookup" child contexts – most of the other
language mappings do not have this method anymore.

That operation can be deleted

Are type code constants generated by the IDL compiler, and if so are they
available for use by developers (ie, not implementation specific)?

If type code constants are not available, then developers have to rememeber
the repository ids of certain IDL declarations (python-noops like typedef) in
order to get a typecode from CORBA.TypeCode (since CORBA.id is most likely no
help in this instance).

I propose that type code constants be made available to developers using some
standardized naming scheme (_tc_XXX?).

see above

In document ptc/00-04-07, my issue, number 3237, is resolved in a
rather bizarre manner. The specification as it now stands states that
to name skeleton classes:

'For the POA, the first element of the fully-scoped name of the
interface is suffixed with "__POA".'

The section no longer contradicts itself, but I object to the
resolution to call the class M__POA, rather than POA_M. Here is a
summary of how other language mappings name their skeleton classes
for an interface I in module M:

Ada: M.I.Impl
C: POA_M_I
C++: POA_M::I
COBOL: POA-M-I
Java: M.IPOA
Smalltalk: seems not to have a skeleton mapping at all

see above

Is there any protection against the value being changed?

see above

On p. I-7 of ptc/00-04-08, what is the 17 in the example?

It is the discriminator value. Add a comment into the specification.

On page I-2 of ptc/00-04-08, the mentioning of alternate mappings
is a serious issue, since it means that scripts may not be portable
across implementations of this specification.

The statement in the specification is incorrect, there are no alternative mappings.

Section 1.5.2 describes the "repository_id" parameter passed to
PortableServer.DynamicImplementation.invoke as specifying the interface type
for which the operation was called.

How is the ORB able to deterimine this information? Does this really make
sense anyway? Is it the repository id of the most derived interface or for
the current call?

There is no document describing what (if any) operations are ORB provided on
PortableServer.DynamicImplementation. For example, it makes sense to provide
default implementations of the following operations:

• _is_a
• _get_interface
• _get_domain_managers

Also, does it make sense to have the programmer over-ride a "_repository_id"
or "_most_derived_interface" operation on this class in order to generate
object references which don't require the client to invoke "_is_a" on (in
order to narrow the reference)? Otherwise most calls to a python
DynamicImplementation would result in the client always invoking _is_a in
order to narrow.

The observation is correct, the ORB cannot supply the repository_id. Specifying that the servant mus

In the third paragraph of Section 14.4.4 states that "The application may
specify the repository id of the target object.".

I assume that this is done in order for the ORB to lookup the operation in
the given interface in and be determine parameter type/direction and return
value information.

This raises the following issues:

• What exception is raised if the repository id is invalid (ie, can't be
  looked up in the IFR, etc...)
• "Standard" operations (ie, _is_a, _interface, etc...) are not defined in
  the IFR so these need to be handled separately than other operations

Should we also provide a "standard" operation (similar to C++) which takes
something like a NamedValuePair sequence (or better yet a
CORBA::OperationDescription)?

issue rejected, closed

The current python mapping (second paragraph of section 1.3.8) describes that
the "CORBA.TypeCode" function can be used to create type codes by passing in
a repository ID. The example that follows that paragraph then goes on to pass
the CosNaming.NamingContext class to CORBA.TypeCode.

Does CORBA.TypeCode expect a class or repository ID (or both)?
What exceptions does CORBA.TypeCode raise if it fails to create a type code?

The example is wrong and needs to be corrected. The exception is BAD_PARAM

In 00-01-12, Python language mapping:

On page 2, under the section headed 'Alignment with CORBA', the Python
mapping itself is not mentioned!

On page 4, under 'Acknowledgements' Humboldt and DSTC are on the one line
when they are indeed separate organisations.

Editorial Change, close issue

On page 1-3 of 00-01-12

module M example code maps IDL 'import' method to the Python method
'import_', ie

def import_(self,what): ...

this is then contradicted by the next paragraph

"To avoid conflicts, IDL names that are also Python
identifiers are prefixed with an underscore."
~~~~~~~~

To avoid conflicts with legal IDL names, keywords are prefixed

I also think that there is an error in the enum mapping section, which
says that

module M {
interface O {
enum Farbe

;
};
};

maps to M.O_rot, M.O_gruen and M.O_blau. It makes much more sense for
them to map to M.O.rot, etc.

The example needs to be corrected

In section 1.3.8 of the Python Language Mapping the second paragraph states:
"The repositroy ID of a type can be obtained with the function CORBA.id,
passing the object representing the type."

Which "object representing the type" are supposed to be supported here?

• struct/exception, union, interface, enum, etc... make sense
• but what about int, long, string, sequence types?

What exception is to be raised if an invalid object is passed to CORBA.id?

Every type that has an IDL name is supported. This specifically excludes constants, since the object

On page 13 (page 18 in 99-08-02), it says that module M results in a
Python package M__POA containing the skeletons. In the next paragraph,
it refers to the package POA_M. They can't both be right. In omniORBpy
I use POA_M, since that is what the C++ mapping does.

The specification is correct, the example is wrong

The Python language binding says that IDL attributes are mapped
to Python accessor functions with leading '_'s in their names:

"If an interface defines an attribute name, the attribute is mapped into an
operation _get_name, as defined If the attribute is not readonly, there is an
additional operation _set_name, as defined in chapter 3.11 of CORBA 2.2."

Traditionally, Python attributes and methods with leading '_'s in their
names are considered to be private. The language enforces this in some cases.
For example, names with leading '_'s are not automatically exported from
modules and names used in class definitions are mangled to prevent
external access if they begin with double '_'s and don't end in double
'_'s.

I feel strongly that the language mapping should be
changed to get accessor method names without leading underscore,
as in get_name(), or even just name(), as in the C++ mapping.

close issue, see above

Section 1.5.1 starts with "One approach". What is the other approach?

see above

On page I-9 of ptc/00-04-08: Are the declarations (not the
implementations) of CORBA.Any, CORBA.ValueBase etc. just built into
the environment, or are they explicitly declared somewhere?

see above, close issue

Is ServantLocator mapped to a predefined Python type?

see above, close issue

On p. I-13 of ptc/00-04-08, it says the base class of all servant
classes is PortableServer.Servant. I'm missing somewhat here: I
thought the base class is M__POA.

see above, close issue

Where are the classes CORBA.UserException and CORBA.SystemException
declared?

see above, close issue