On Monday 14 October 2002 01:11, Brett Cannon wrote: > [Alex Martelli] > > > Why expose a function rather than exposing the type directly? I think > > we should have Set, the type, rather than set, the function, as the > > built-in -- so it can be inherited from as well as being constructed. > > That is what I meant; function is a factory function like dict() and > friends are now. Sorry if that wasn't clear. I think of functions (including factory ones) and types (or classes) as separate, e.g. because I can subclass the latter but not the former. But the docs sometimes aren't crystal clear on that because what used to be factory functions (e.g. int) have recently become types. > > This, in turn, suggests exposing type ImmutableSet too. > > I don't see that as an automatic conclusion. I prefer to view > ImmutableSet as just as a Set with a property turned on. I think in Python that wouldn't work, because both Set and ImmutableSet have methods the other shouldn't have -- so if you inherit you'd better know which one you want, since removing methods during inheritance is near-unfeasible. > But tuple and lists do set a precedent for clearly separating a mutable > and immutable version of something. Probably should stick with that > separation. However tuples aren't "immutable lists" -- they don't have non-mutating methods that lists do have, for example. So the precedent's iffy. > I really like that idea. Being able to use practically anything as a > dict key would be rather nice. There doesn't need to be a guarantee that > the copy will keep up with the original, mutable object, just that it > corresponds at the immutable object's creation. That eliminates that > possible hornet's nest. The needed axiom is that the original and copy are == at creation time, and loosely speaking that apart from mutability they are more or less equivalent objects in some sense or other (e.g. a mutable one may be rebuilt from the immutable one later) > If we could come up with an immutable dict (I suspect just removing > __setitem__() doesn't cut it =) we could take that and be able > to create immutable object copies by just making a snapshot of the > object's __dict__, __bases__, and such. > > But the big use I see of an immutable_copy() function is being able to > take parameters and making sure you don't change them in-place. You can, > of course, just make sure you don't change them, but this could eliminate > having to watch out for that and let you worry about other things. For that you can use copy.copy or if need be copy.deepcopy -- i.e. you may not care if the function makes changes, as long as it's on a copy, not on the original. BTW this suggests that copy.immutablecopy, not a builtin, is the right place to put the new hypothetical functionality (still probably cooperating with an optional special method, like copy.copy and copy.deepcopy do). Would be weird if the function to make ordinary copies lived one place and the one to make immutable copies lived somewhere else, I think. BTW, I removed: "A.M. Kuchling" <amk@nyman.amk.ca> from the Cc since it's bouncing... Alex
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