On Sat, Feb 7, 2009 at 9:41 AM, Curt Hagenlocher <c...@hagenlocher.org> wrote: > On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum <gu...@python.org> wrote: >> On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher <c...@hagenlocher.org> >> wrote: >>> ...because they're not quite :). Should I file this as a bug report? >> >> No, this is just how it works. I hope they aren't documented as immuable? > > Not that I know of :). But the individual properties of the > descriptor are all read-only and that the implementations of setter, > getter and deleter return new objects instead of mutating and > returning the old descriptor. So it seemed a little odd that there > was just one way remaining in which the object could be mutated.
You're basically using an "API" that wasn't meant to be invoked directly. I don't particularly care that properties can be mutated, but I don't really care that they should be 100% immutable either. IMO it's enough that the APIs that exist to be used explicitly don't modify the property in place; getter and friends return a new object so that you can override or extend a property in a subclass, and there obviously you don't want to mutate the base class. In the balance I'd say that the "backdoor" you found is probably harmless, and perhaps someone can find a good use for it, so I'm disinclined to "fix" this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
