[Python-Dev] PEP 218 update questions

[Brett Cannon]

[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.

> 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.

But tuple and lists do set a precedent for clearly separating a mutable
and immutable version of something.  Probably should stick with that
separation.

> > As long as mutable sets can be automatically converted to immutable, I
> > say keep only one syntax.  If the user wants to explicitly create an
> > immutable set, call set(mutable_set, immutable=True) or have a very
> > explicit way for mutable sets to turn themselves into immutable sets.  No
> > need to add more syntax for something that can automatically be done for
> > the user.
>
> Either via ImmutableSet, or the method currently private and named
> _as_immutable could be made public and named as_immutable or
> asImmutable.  I prefer the latter solution because it would give us a
> needed protocol -- "return an immutable snapshot of your current
> state" -- sets now do it, but it would be nice to have a way for all
> mutable types that are interested in cooperating in such "snapshot"
> operations to be able to (lists could return tuple(self), dicts could
> return 'frozendicts' if and when such beasts appear, etc) in such a
> uniform way.  One last possibility, there could instead be a builtin
> immutable(x) (or immutable_copy(x)) that knows about some builtin
> types (e.g. turns lists into tuples itself, returns already-immutable
> types unchanged) and tries to delegate to a new special method
> __as_immutable__ -- this would be at least as good as the second
> solution above and more in keeping with how several existing Python
> builtins already work.
>

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.

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.

-Brett