Issue 3714: Python: Alternate Mappings (python-ftf) Source: SAP AG (Mr. David Frankel, david.frankel@sap.com) Nature: Uncategorized Issue Severity: 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. Resolution: Duplicate, close issue Revised Text: Actions taken: December 3, 2001: closed issue Discussion: End of Annotations:===== Date: Thu, 16 Mar 2000 18:56:23 +0100 Message-Id: <200003161756.SAA11661@pandora> From: Martin von Loewis To: issues@omg.org CC: python-ftf@omg.org Subject: Python-FTF: Mapping of toplevel modules User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII X-UIDL: m,dd9PANe9$69!!K![!! 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. Example: An ORB vendor X might provide the modules CORBA and CosNaming as X.CORBA and X.CosNaming, respectively, to allow coexistance with other implementations of the module CORBA. To fulfill the above requirement, vendor X could also offer a module CORBA which is implemented as from X.CORBA import * which is installed as a configuration option. Regards, Martin Date: Wed, 29 Mar 2000 19:31:33 +0200 Message-Id: <200003291731.TAA26426@pandora> From: Martin von Loewis To: python-ftf@omg.org Subject: Issue 3430: Mapping of toplevel modules User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII X-UIDL: j=_d9WJ?!!2BUd9d=E!! This issue was filed into the issues list after I sent the draft resolutions week; it asks for a ruling whether an API requiring from Fnorb.orb import CORBA is conforming or not. I believe both Fnorb and omniORBpy put the CORBA module into a package, ILU provides a toplevel CORBA module. While I like the ability to have different installations on a system, it is a portability problem, since applications will need to know what CORBA implementation they use (even though only on a single line). To balance these needs, I propose that the spec encourages packaging CORBA into a non non-toplevel module, but provides a configuration mechanism so that one implementation can be selected as default; ideally this would happen by putting an incarnation of module CORBA into the PYTHONPATH. If the true CORBA lives somewhere else, that module could look like # CORBA.py from Fnorb.orb.CORBA import * Comments? Martin To: Martin von Loewis cc: python-ftf@omg.org Subject: Re: Issue 3430: Mapping of toplevel modules In-Reply-To: Your message of "Wed, 29 Mar 2000 09:31:43 PST." <200003291731.TAA26426@pandora> From: Bill Janssen Message-Id: <00Mar29.175531pst."3426"@watson.parc.xerox.com> Date: Wed, 29 Mar 2000 17:55:48 PST Content-Type: text X-UIDL: Am^d9jVWd9F<+!!9n?e9 > To balance these needs, I propose that the spec encourages packaging > CORBA into a non non-toplevel module, but provides a configuration > mechanism so that one implementation can be selected as default; > ideally this would happen by putting an incarnation of module CORBA > into the PYTHONPATH. If the true CORBA lives somewhere else, that > module could look like > > # CORBA.py > from Fnorb.orb.CORBA import * Almost. I'd be happy with that if instead of ``one implementation can be selected as default'' it said ``one implementation must be selected as default''. That is, "import CORBA" must always work, but "from Fnorb.orb import CORBA" could also work. Bill