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

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