Issue 3724: Issue: Python language binding January 2000 Draft (python-ftf) Source: Boeing (Mr. Jim Fulton, jim.fulton@boeing.com) Nature: Uncategorized Issue Severity: 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. Resolution: close issue, see above Revised Text: Actions taken: June 23, 2000: received issue December 3, 2001: closed issue Discussion: Close with no change. All of the proposed alternatives have draw-backs. Mapping an attribute XXX to get_XXX() may cause conflicts with an operation of the same name. Mapping it to XXX() would be possible, but the proposal does not include a name for the corresponding set operation. Following the C++ mapping, it could be XXX(new_value). In Python, that would be inconvenient to implement, as it requires an implementation of the form def XXX(self, new_value=missing): if new_value is not missing: self._XXX = new_value else: return self._XXX Here, missing cannot be None, as None might be a valid new value. Also, changing it in this way might break existing applications. Another possibility it to map IDL attributes to Python attributes. This has currently the draw-back that multiple implementations of __getattr__ (e.g. resulting from implementation inheritance) cannot be easily coordinated; also, implementing __getattr__ is error-prone. Therefore, experience in terms of implementations of a modified mapping should be gained before this aspect of the specification is changed. End of Annotations:===== Date: Fri, 23 Jun 2000 17:22:06 -0400 From: Jim Fulton X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: jim@digicool.com Subject: Issue: Python language binding January 2000 Draft Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 46^!!Qa)e9lI9e9V8S!! 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. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. Resent-From: Martin von Loewis Received: (from loewis@localhost) by punica.informatik.hu-berlin.de (8.9.3+Sun/8.9.1/SOLARIS-INF-2.0c) id RAA09454 for python-ftf@omg.org; Tue, 20 Feb 2001 17:06:22 +0100 (MET) Resent-Message-Id: <200102201606.RAA09454@punica.informatik.hu-berlin.de> Message-Id: <200102201606.RAA09454@punica.informatik.hu-berlin.de> X-Authentication-Warning: punica.informatik.hu-berlin.de: loewis set sender to loewis@informatik.hu-berlin.de using -f Resent-Date: 20 Feb 2001 17:06:22 +0100 Resent-To: python-ftf@omg.org Date: 19 Feb 2001 17:22:13 +0100 From: Martin von Loewis To: python-ftf@omg.org Subject: Issue 3724 User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (sparc-sun-solaris2.6) MULE/4.0 (HANANOEN) Content-Type: text/plain; charset=US-ASCII X-UIDL: \)@!!!\*e92DD!!LLLe9 Dear RTF members, I'd like to get some opinions on issue 3724. Basically, this is a request to change the mapping of attributes, since the submitter dislikes the _get_ and _set_ prefixes. Any comments appreciated. Regards, Martin Date: Mon, 5 Mar 2001 16:22:17 +0100 (MET) Message-Id: <200103051522.QAA05665@pandora.informatik.hu-berlin.de> X-Authentication-Warning: pandora.informatik.hu-berlin.de: loewis set sender to loewis@informatik.hu-berlin.de using -f From: Martin von Loewis To: python-ftf@omg.org Subject: Proposal for issue 3724 User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (sparc-sun-solaris2.6) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-UIDL: f`4e9oTW!!!'Vd9/Y0!! The submitter of this issue requests that the mapping for attributes is changed. After some discussion on do-sig@python.org, I propose to close it with no change. Discussion: All of the proposed alternatives have draw-backs. Mapping an attribute XXX to get_XXX() may cause conflicts with an operation of the same name. Mapping it to XXX() would be possible, but the proposal does not include a name for the corresponding set operation. Following the C++ mapping, it could be XXX(new_value). In Python, that would be inconvenient to implement, as it requires an implementation of the form def XXX(self, new_value=missing): if new_value is not missing: self._XXX = new_value else: return self._XXX Here, missing cannot be None, as None might be a valid new value. Also, changing it in this way might break existing applications. Another possibility it to map IDL attributes to Python attributes. This has currently the draw-back that multiple implementations of __getattr__ (e.g. resulting from implementation inheritance) cannot be easily coordinated; also, implementing __getattr__ is error-prone. Therefore, experience in terms of implementations of a modified mapping should be gained before this aspect of the specification is changed. Regards, Martin