[Python-Dev] PEP 218 update questions

[Alex Martelli]

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