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.

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

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