Python Language Mapping Avatar
  1. OMG Specification

Python Language Mapping — All Issues

  • Acronym: PYTH
  • Issues Count: 6
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Problem with Python Language Mapping

  • Key: PYTH12-9
  • Legacy Issue Number: 4316
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

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

  • Reported: PYTH 1.1 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Duplicate or Merged — PYTH 1.2
  • Disposition Summary:

    Duplicate of issue # 4315

  • Updated: Sat, 7 Mar 2015 06:07 GMT

Python mapping issue: value boxes

  • Key: PYTH12-8
  • Legacy Issue Number: 4661
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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

    { void example(in BoxedString a, in BoxedString b); }

    ;

    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.

  • Reported: PYTH 1.1 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — PYTH 1.2
  • Disposition Summary:

    Accept the proposed changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Python mapping issue: ValueFactory

  • Key: PYTH12-7
  • Legacy Issue Number: 4660
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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.

  • Reported: PYTH 1.1 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — PYTH 1.2
  • Disposition Summary:

    Accept the proposed changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Python mapping issue: context

  • Key: PYTH12-6
  • Legacy Issue Number: 4659
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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.

  • Reported: PYTH 1.1 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — PYTH 1.2
  • Disposition Summary:

    Accept the proposed changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Python mapping issue: fixed point

  • Key: PYTH12-5
  • Legacy Issue Number: 4658
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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'.
  • Reported: PYTH 1.1 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — PYTH 1.2
  • Disposition Summary:

    Accept the suggested changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with Python Language Mapping

  • Key: PYTH12-4
  • Legacy Issue Number: 4315
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

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

  • Reported: PYTH 1.1 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — PYTH 1.2
  • Disposition Summary:

    Accept the suggested rewrite of the examples

  • Updated: Fri, 6 Mar 2015 20:58 GMT