OpaqueValue, a new native type introduced in Issue 2162 (void *
in DII Chapter) for add_arg, was never documented in any of the language
mappings. Language Mapping that claim that the DII interfaces map
according to regular rules need to provide mapping rules for OpaqueValue
and document it. The mapping would simply be OpaqueValue --> (void *) or
equivalent.

1. In the resolution of issue....

(a) The system exception that is raised is said to be BAD_PARAM. Since
it is a bad context that is being taken exception to, why is the
BAD_CONTEXT exception not used instead?

(b) It is better to also define a standard minor code with an associated
error description when a use of a standard system exception is
specified. This helps the user figure out what caused the system
exception to be triggered. This is missing in the resolution.

In the list of operations provided by the ORB object, the first is list_initial_references().

In the CORBA spec, there is no operation by that name in the PIDL, but there is a list_initial_services() operation.

This looks like a typo

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