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

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.

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