On 12/15/2011 3:51 PM, Antoine Pitrou wrote:
On Thu, 15 Dec 2011 15:42:42 -0500 Ned Batchelderned@nedbatchelder.com wrote:
On 12/15/2011 3:24 PM, Georg Brandl wrote:
On 12/13/2011 03:44 AM, Stephen J. Turnbull wrote:
Greg Ewing writes:
FWIW, Haskell does not have a literal singleton (the standard defines "unit" `()` and 2-tuple through 15-tuple)
That's because, due to its static typing, there is no reason you would ever need to use a 1-tuple rather than a bare value. We're not that lucky in Python, though.
I think you have misstated your point? That's not due to static typing, that's because you may *always* identify 1-factor products with the only factor, and Haskell made a deliberate decision to consistently represent the isomorphism class by the factor rather than the product.
Well, I would say the reason is that the type "tuple of any length" does not exist in Haskell. So there's no way you will have to pass a 1-tuple to a function that operates on tuples only.
But of course, if we all used tuples as tuples only, we wouldn't have to do that either. It's only because we use tuples as sequences every so often.
This is another place where Python is inconsistent. We're told, "lists are for homogenous sequences of varying length, like a C array; tuples are for heterogenous aggregations of known length, like a C struct." Then we define a function foo(*args), and Python gives us a tuple! :-(
How is it inconsistent? Function signatures generally have a fixed (or mostly fixed) number of heterogenous arguments.
What? The whole point of the "def foo(*args)" syntax is so a function can take an unknown-length list of arguments, which will be treated uniformly.
Python-ideas mailing list Pythonemail@example.com http://mail.python.org/mailman/listinfo/python-ideas