Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Jim Jewett wrote: > > That said, I'm not sure the benefit is enough to justify the > > extra complications, and your suggestion of allowing strings > > for method names may be close enough. I agree that the > > use of strings is awkward, but ... probably no worse than > > using them with __dict__ today. > > An idea that was kicked around on c.l.p a long while back was "statement > local > variables", where you could define some extra names just for a single simple > statement: > > x = property(get, set, delete, doc) given: > doc = "Property x (must be less than 5)" > def get(self): > try: > return self._x > except AttributeError: > self._x = 0 > return 0 > def set(self, value): > if value >= 5: raise ValueError("value too big") > self._x = x > def delete(self): > del self._x > > As I recall, the idea died due to problems with figuring out how to allow the > simple statement to both see the names from the nested block and modify the > surrounding namespace, but prevent the names from the nested block from > affecting the surrounding namespace after the statement was completed.
You wouldn't be able to write to the surrounding namespace, but a closure would work fine for this. def Property(fcn): ns = fcn() return property(ns.get('get'), ns.get('set'), ns.get('delete'), ns.get('doc')) class foo(object): @Property def x(): doc = "Property x (must be less than 5)" def get(self): try: return self._x except AttributeError: self._x = 0 return 0 def set(self, value): if value >= 5: raise ValueError("value too big") self._x = value def delete(self): del self._x return locals() In an actual 'given:' statement, one could create a local function namespace with the proper func_closure attribute (which is automatically executed), then execute the lookup of the arguments to the statement in the 'given:' line from this closure, but assign to surrounding scope. Then again, maybe the above function and decorator approach are better. An unfortunate side-effect of with statement early-binding of 'as VAR' is that unless one works quite hard at mucking about with frames, the following has a wholly ugly implementation (whether or not one cares about the persistance of the variables defined within the block, you still need to modify x when you are done, which may as well cause a cleanup of the objects defined within the block...if such things are possible)... with Property as x: ... > Another option would be to allow attribute reference targets when binding > function names: *shivers at the proposal* That's scary. It took me a few minutes just to figure out what the heck that was supposed to do. - Josiah _______________________________________________ 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