${taskforce.name} Avatar
  1. OMG Task Force

Python Mapping FTF — Closed Issues

  • Key: PYTH
  • Issues Count: 18
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
PYTH-21 Python Issue: Context.delete PYTH 1.0b1 PYTH 1.0 Duplicate or Merged closed
PYTH-20 Issue: Python language bidning January 2000 Draft PYTH 1.0b1 PYTH 1.0 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
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

Issues Descriptions

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

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