On 4/18/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > [...] > > class C: > > x = property(._get_x, ._set_x, ._del_x, > > "This is the x property") > > [...] > > > This is slightly more Pythonic, and unambiguous, but I'd rather > > reserve leading dot for a more powerful feature, perhaps .foo as an > > abbreviation for self.foo, or some other scope-ish operator. (I also > > note that in a proportional font the . is easily missed.) > > Does that conflict? Wouldn't self._get_x fall through to > self.__class__._get_x, which is exactly what you want? (Except that > you *might* the ability to override methods on a per-instance basis.)
Not in this context. When the expression "property(._get_x, ._set_x, ...)" is evaluated, there is no self yet (unless it is an unrelated outer self). > > So this begs the question: would the following assertion pass or fail? > > > > assert .foo == "foo" > > > > What about this one? > > > > assert type(.foo) == str > > If .foo is a syntactic change, it might not require that an object be > created (for the name) at all. We may be misunderstanding each other, but I don't see how, if ".foo" is used as an expression, it can not return some object. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
