On Wed, Nov 3, 2010 at 12:42 AM, Stefan Behnel <[email protected]> wrote: > Robert Bradshaw, 03.11.2010 08:25: >> On Tue, Nov 2, 2010 at 11:56 PM, Stefan Behnel wrote: >>> We could distinguish between normal and read-only properties, though, and >>> allow pretty much arbitrary expressions for the latter. Basically like a >>> lambda expression wrapped into a property descriptor. >> >> Yep, that's what I was thinking. Attribute access paths would probably >> be the most common, but no need to restrict ourselves for the getter. >> >>>> On that note, should we >>>> require an explicit self.obj.x, or is self implicit? (The latter makes >>>> it impossible to refer to non-attributes, and is bad according to the >>>> zen of Python...), so I'd lean against this one. >>> >>> That's a very good idea. Makes it more readable and a lot clearer what >>> happens. This also removes the link to C++ as you can access any attribute >>> of the type in one way or another. >>> >>> Would you actually require it to refer to "self", or would you allow >>> arbitrary global names? I wouldn't even mind the latter, although maybe >>> restricted to static cdef declared names (at least of we generate a setter). >> >> Hmm.... I would at least generate a warning if not assigning to a self >> attribute. > > Ok, then let's support arbitrary expressions for read-only properties and > self-attribute-only expressions for normal (getter+setter) properties. > > Should it be > > property x from readonly expr > > or > > property readonly x from expr > > ? I lean towards the first, once again due to the simpler grammar. > > Then we get > > property x from readonly anyexpr > > and > > property x from self.attribute > > (i.e. "from" followed by a dotted name, which may be "readonly", which > would then be followed by an arbitrary expression)
Sound good to me. It's possible that index expressions could support setters as well. > I don't think we need a "public" for the getter+setter case, "property" is > clear enough IMHO. Agreed. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
