[Python-ideas] Python Users Aren't Perfect
ned at nedbatchelder.com
Thu Dec 15 22:00:03 CET 2011
On 12/15/2011 3:51 PM, Antoine Pitrou wrote:
> On Thu, 15 Dec 2011 15:42:42 -0500
> Ned Batchelder<ned at nedbatchelder.com>
>> On 12/15/2011 3:24 PM, Georg Brandl wrote:
>>> On 12/13/2011 03:44 AM, Stephen J. Turnbull wrote:
>>>> Greg Ewing writes:
>>>> > Masklinn wrote:
>>>> > > 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
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas