Python Language Mapping Avatar
  1. OMG Specification

Python Language Mapping — Closed Issues

  • Acronym: PYTH
  • Issues Count: 35
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
PYTH12-9 Problem with Python Language Mapping PYTH 1.1 PYTH 1.2 Duplicate or Merged closed
PYTH-21 Python Issue: Context.delete PYTH 1.0b1 PYTH 1.0 Duplicate or Merged closed
PYTH11-14 Python: Alternate Mappings PYTH 1.0 PYTH 1.1 Duplicate or Merged closed
PYTH-20 Issue: Python language bidning January 2000 Draft PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH12-5 Python mapping issue: fixed point PYTH 1.1 PYTH 1.2 Resolved closed
PYTH12-4 Problem with Python Language Mapping PYTH 1.1 PYTH 1.2 Resolved closed
PYTH12-8 Python mapping issue: value boxes PYTH 1.1 PYTH 1.2 Resolved closed
PYTH12-7 Python mapping issue: ValueFactory PYTH 1.1 PYTH 1.2 Resolved closed
PYTH12-6 Python mapping issue: context PYTH 1.1 PYTH 1.2 Resolved closed
PYTH-19 Python-FTF: Mapping of toplevel modules PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-18 Python Issue: widening object references and CORBA.Any.value PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-16 Python Issue: PortableServer.Servant._default_POA and _this PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-15 Python Issue: Object.create_request PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-13 Python Issue: Wide strings PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-12 Python Issue: IDL generated module names PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-17 Python Issue: Context.delete PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-14 Python Issue: TypeCode constants? PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH11-4 Python mapping: skeleton class name PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-7 Python: Constant Mapping PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-6 Python: Union example PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-5 Python: Alternate Mappings PYTH 1.0 PYTH 1.1 Resolved closed
PYTH-11 Python Issue: Dynamic Skeleton Interface PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-10 Python Issue: Dynamic Invocation Interface PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-8 Python Issue: CORBA.TypeCode PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-7 00-01-12 python language mapping issue PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-6 00-01-12 python language mapping issue PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-5 Python: Mapping of enumerators PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-9 Python Issue: TypeCodes and CORBA.id PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH-4 Python: Naming of POA classes PYTH 1.0b1 PYTH 1.0 Resolved closed
PYTH11-13 Issue: Python language binding January 2000 Draft PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-10 Python: Alternatives to skeleton PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-9 Python: Classes in module CORBA PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-12 Python: Mapping of ServantLocator PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-11 Python: Servant base class PYTH 1.0 PYTH 1.1 Resolved closed
PYTH11-8 Python: Exception base classes PYTH 1.0 PYTH 1.1 Resolved closed

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 Issue: Context.delete

  • Key: PYTH-21
  • Legacy Issue Number: 3356
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — PYTH 1.0
  • Disposition Summary:

    Duplicate.

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

Python: Alternate Mappings

  • Key: PYTH11-14
  • Legacy Issue Number: 3714
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Duplicate or Merged — PYTH 1.1
  • Disposition Summary:

    Duplicate, close issue

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

Issue: Python language bidning January 2000 Draft

  • Key: PYTH-20
  • Legacy Issue Number: 3723
  • Status: closed  
  • Source: Boeing ( Jim Fulton)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Fri, 23 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:38 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

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-FTF: Mapping of toplevel modules

  • Key: PYTH-19
  • Legacy Issue Number: 3430
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    Supporting multiple implementations is desirable, however, one of them must be selected as the defau

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

Python Issue: widening object references and CORBA.Any.value

  • Key: PYTH-18
  • Legacy Issue Number: 3358
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Wed, 23 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    Since there it is not possible to find out anything about the embedded object in the general case, t

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

Python Issue: PortableServer.Servant._default_POA and _this

  • Key: PYTH-16
  • Legacy Issue Number: 3353
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    The _default_POA operation assumes the default ORB. Any exceptions raised as a result are not specif

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

Python Issue: Object.create_request

  • Key: PYTH-15
  • Legacy Issue Number: 3352
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    It should be spelled _created_request; this is an editorial change. Also, the definition of that ope

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

Python Issue: Wide strings

  • Key: PYTH-13
  • Legacy Issue Number: 3350
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    Since the len function always returns the number of elements in a sequence, it must return the numbe

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

Python Issue: IDL generated module names

  • Key: PYTH-12
  • Legacy Issue Number: 3349
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    The example in Section 1.2 "Using Scoped Names" states that:
    module M

    { <IDL-deleted> }

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

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    rejected, issue closed

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

Python Issue: Context.delete

  • Key: PYTH-17
  • Legacy Issue Number: 3354
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    That operation can be deleted

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

Python Issue: TypeCode constants?

  • Key: PYTH-14
  • Legacy Issue Number: 3351
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

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

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    see above

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

Python mapping: skeleton class name

  • Key: PYTH11-4
  • Legacy Issue Number: 3610
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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

  • Reported: PYTH 1.0 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above

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

Python: Constant Mapping

  • Key: PYTH11-7
  • Legacy Issue Number: 3716
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Is there any protection against the value being changed?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above

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

Python: Union example

  • Key: PYTH11-6
  • Legacy Issue Number: 3715
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    On p. I-7 of ptc/00-04-08, what is the 17 in the example?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    It is the discriminator value. Add a comment into the specification.

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

Python: Alternate Mappings

  • Key: PYTH11-5
  • Legacy Issue Number: 3713
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    The statement in the specification is incorrect, there are no alternative mappings.

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

Python Issue: Dynamic Skeleton Interface

  • Key: PYTH-11
  • Legacy Issue Number: 3348
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    The observation is correct, the ORB cannot supply the repository_id. Specifying that the servant mus

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

Python Issue: Dynamic Invocation Interface

  • Key: PYTH-10
  • Legacy Issue Number: 3347
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

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

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    issue rejected, closed

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

Python Issue: CORBA.TypeCode

  • Key: PYTH-8
  • Legacy Issue Number: 3345
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    The example is wrong and needs to be corrected. The exception is BAD_PARAM

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

00-01-12 python language mapping issue

  • Key: PYTH-7
  • Legacy Issue Number: 3334
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Sun, 20 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    Editorial Change, close issue

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

00-01-12 python language mapping issue

  • Key: PYTH-6
  • Legacy Issue Number: 3333
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: PYTH 1.0b1 — Sun, 20 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    To avoid conflicts with legal IDL names, keywords are prefixed

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

Python: Mapping of enumerators

  • Key: PYTH-5
  • Legacy Issue Number: 3238
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    I also think that there is an error in the enum mapping section, which
    says that

    module M {
    interface O {
    enum Farbe

    {rot, gruen, blau}

    ;
    };
    };

    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.

  • Reported: PYTH 1.0b1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    The example needs to be corrected

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

Python Issue: TypeCodes and CORBA.id

  • Key: PYTH-9
  • Legacy Issue Number: 3346
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    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?

  • Reported: PYTH 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    Every type that has an IDL name is supported. This specifically excludes constants, since the object

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

Python: Naming of POA classes

  • Key: PYTH-4
  • Legacy Issue Number: 3237
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    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.

  • Reported: PYTH 1.0b1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — PYTH 1.0
  • Disposition Summary:

    The specification is correct, the example is wrong

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

Issue: Python language binding January 2000 Draft

  • Key: PYTH11-13
  • Legacy Issue Number: 3724
  • Status: closed  
  • Source: Boeing ( Jim Fulton)
  • Summary:

    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.

  • Reported: PYTH 1.0 — Fri, 23 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    close issue, see above

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

Python: Alternatives to skeleton

  • Key: PYTH11-10
  • Legacy Issue Number: 3719
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Section 1.5.1 starts with "One approach". What is the other approach?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above

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

Python: Classes in module CORBA

  • Key: PYTH11-9
  • Legacy Issue Number: 3718
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above, close issue

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

Python: Mapping of ServantLocator

  • Key: PYTH11-12
  • Legacy Issue Number: 3721
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Is ServantLocator mapped to a predefined Python type?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above, close issue

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

Python: Servant base class

  • Key: PYTH11-11
  • Legacy Issue Number: 3720
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above, close issue

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

Python: Exception base classes

  • Key: PYTH11-8
  • Legacy Issue Number: 3717
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Where are the classes CORBA.UserException and CORBA.SystemException
    declared?

  • Reported: PYTH 1.0 — Tue, 20 Jun 2000 04:00 GMT
  • Disposition: Resolved — PYTH 1.1
  • Disposition Summary:

    see above, close issue

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