[Python-Dev] PEP 218 update questions (original) (raw)

Alex Martelli aleaxit@yahoo.com
Mon, 14 Oct 2002 00:05:44 +0200

On Sunday 13 October 2002 23:43, Brett Cannon wrote:

[A.M. Kuchling]

> How would instances of a built-in immutable set type be created? > Would there be a second immutableset() built-in, or would the set() > function take an additional argument: set(iterable, immutable=True)? I say have a single set() with an argument flag. Mutable or not, they are both subsets of BaseSet and thus should be reflected in the constructor function.

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. This, in turn, suggests exposing type ImmutableSet too.

That is, if we want such built-ins at all. If (e.g.) types such as array and mmap can stay in modules, why not sets, for now?

> 2) > The PEP proposes {1,2,3} as the set notation and {-} for the empty > set. Would there be different syntax for an immutable and a mutable > set?

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(mutableset, 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.

Alex