I'm not clear on what in my comment you're saying "no" to. isinstance(tuple, ("foo")) being True is not a "rough edge" (or if it is anything people are ever confused by is a rough edge). If it were True, that would also mean you couldn't use parentheses to set the order of operations, since items inside parentheses would be tuples. That would be nuts.
IMO this is just an educational issue where people aren't taught that the comma is the tuple operator (e.g. `x = 3,4` is perfectly legal) and parentheses just come along for the ride to disambiguate other uses of commas. If I were king tuples wouldn't have the same syntax as argument lists (`f((3,2))` is pretty ugly), but both Python tuples and Python argument lists conform to a lot of people's expectations of how both those things should look.
The fact that duck typing makes tuples and literals (temporarily) indistinguishable to the interpreter is more of a rough edge of duck typing itself. Duck typing can result in tricky bugs in many scenarios well beyond singleton tuples.
Sorry to belabor the point, but this is exactly what parent was saying.
> changing something like
> ("foo",
> "bar",
> "baz")
> to
> ("foo")
> actually breaks the code.
Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.
No, he's saying that the operation you perform to truncate the former to the latter is the operation you would logically expect to perform (i.e. removing the trailing comma), which makes the thing a string.
He's not actually proposing that a string be a tuple. He's just saying that a single element enclosed in parentheses doesn't work the way you'd expect it.
> 4 * (3+2)
should throw:
> TypeError: unsupported operand type(s) for *: 'int' and 'tuple'
???
I beg to differ.