[Python-3000] Immutable lists (was: Re: Type annotations: annotating generators)

[Collin Winter]

On 5/22/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> "Guido van Rossum" <guido at python.org> wrote:
> > On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > > One thing I've run into several times in this process is the use of
> > > *args as a dict key. As several others have mentioned, the "tuple ==
> > > fixed-length, list == arbitrary-length" distinction means we now need
> > > a way to create hashable lists. I propose a new, hashable frozenlist
> > > built-in type to fill this niche.
> > >
> > > This type would subclass from list, overriding __getitem__,
> > > __delitem__, __hash__ and other methods as appropriate.
> > >
> > > Thoughts? Does this need to go through a full PEP process?
> >
> > No, no, no!
>
> Or to clarify Guido: use a tuple.  Tuples are also arbitrary-length, and
> serve the same purposes that any 'frozen list' equivalent would.

In Python 2, sure, but if Python 3 introduces the idea that tuples
should be used for fixed-length structures (since Guido has said that
tuple[Number, Number] should be a 2-tuple of Numbers), then something
else needs to fill the "hashable, arbitrary-length ordered container"
niche.

The main use case I'm thinking of is parameterizing mapping types. Say
I wanted a set of Number lists: in Python 2, I'd just convert the
lists to tuples before adding them to the set. However, in Python 3,
converting the lists to tuples will cause any annotations like
set[list[Number]] to reject the candidate set. I'd like to avoid
having annotations like set[tuple & EveryElementIs(Number)]. Also,
before anyone proposes it, I don't think "just remove the offending
annotations" is a viable solution.

Collin Winter