[Python-3000] No Container Literals

[Calvin Spealman]

On 7/8/06, Georg Brandl <g.brandl at gmx.net> wrote:
> Calvin Spealman wrote:
> > On 7/8/06, Georg Brandl <g.brandl at gmx.net> wrote:
> >> Calvin Spealman wrote:
> >> > Just throwing this out there, but I would love to see a complete
> >> > dropping of container literals from Python. That is why I proposed the
> >> > coercion syntax (ex: list from something) because it would allow
> >> > things like list(1, 2, 3) and we can already do dict(ten=10,
> >> > eleven=11), so what is the real need for literals as they are? With
> >> > some proper compiler optimization we can deduce if list, dict, and
> >> > such are in fact bound to the builtins we know, and build literals
> >> > from these expressions just the same, but I feel they seem much more
> >> > readable, and allow better addition of more literal compilations (set
> >> > literals are fixed then, for example). I know no one will like this,
> >> > but I have to make the idea known anyway.
> >>
> >> -1. List and dict displays are a great feature of the language. Why throw
> >> them out just because of purism?
> >>
> >> How would you spell {1: 2} with your syntax?
> >
> > dict(1=2) could be allowed, with additional syntax rules.
>
> So dict() would be special-cased. What's the difference to {}, then?
>
> Or do you propose to allow arbitrary objects as keyword argument *names*
> for *every function*?
>
> If so, how would one distinguish
>      dict(a=1) as in {"a": 1}
> and
>      dict(a=1) as in {a: 1}
> ?
>
> Georg

Not objects, names. 'foo(bar=baz)' can parse where bar is any valid
identifier (alphanumerical) and would not be ambigous. Objects _could_
be allowed with some syntax like 'dict((a)=1)' or 'dict(*a=1)' where
the baz(*foo=bar) syntax would parse *foo as the object named foo,
rather than the name foo itself. Of course, that isn't needed because
you can just do dict((foo, bar), (a, 1))

Maybe it isn't a perfect solution, but I think its worthy for
consideration is all.