[Python-3000] No Container Literals
Calvin Spealman
ironfroggy at gmail.com
Sun Jul 9 04:26:00 CEST 2006
On 7/8/06, Nick Coghlan <ncoghlan at gmail.com> 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.
>
> To turn the idea around a bit, could that *syntax* be a way to get rid of the
> plethora of parentheses in set literals?
>
> That is,
>
> NAME from TUPLE
>
> Would be equivalent to:
>
> NAME((TUPLE))
>
> To avoid the ambiguity problems suffered string % formatting, the item on the
> right would have to be a tuple (with a single value without a trailing comma
> being either implicitly converted to a singleton tuple or else raising a
> syntax error).
>
> So instead of 'set((1, 2, 3))' you could write 'set from 1, 2, 3'.
>
> This would be usable for any function that took an iterable as its sole
> required argument.
>
> Instead of writing:
>
> if any((a, b, c)):
> # Do something
>
> You could write:
>
> if any from a, b, c:
> # Do something
>
> I don't personally think there's sufficient payoff in readability to justify
> the duplication of functionality, but figured I'd put the idea out there anyway.
+1
More information about the Python-3000
mailing list