On Sat, Feb 7, 2009 at 9:41 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote: > On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum <guido at python.org> wrote: >> On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher <curt at 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4