On 7/8/06, Nick Coghlan <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
