Python Language Mapping Avatar
  1. OMG Specification

Python Language Mapping — Closed Issues

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

Issues Descriptions

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

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