[EMAIL PROTECTED] wrote: > Jim> This seems outdated. My impression, in part from time spent > Jim> working with the Python Labs guys, is that it is fine to have > Jim> public data sttributes even for non-"record" types. In fact, I > Jim> would argue that any time you would be tempted to provide > Jim> "getFoo()" and "setFoo(v)" for some "private attribute _foo", it > Jim> would be better to make it public. I certainly find "blah.foo" and > Jim> "blah.foo = v" to be much better than "blah.getFoo()" and > Jim> blah.setFoo(v)". > > Presuming the foo attribute provides some element of the API that you are > willing to support forever. If it is just an implementation detail you > should use accessor methods or properties.
If foo is an implementation detail, then it shoudln't be exposed at all, even with accessors. Using attribute syntax makes no more of a commitment than accessor functions. The decision about wither to implement foo as a key in the instance dictionary *is* an implementation detail that can be hidden by a property. If the initial decision, following the rule of "do the simplest thing that works", is to use an instance dictionary item, then I wouldn't bother with a property until you change your mind. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
