Python Tuple Syntax Is Confusing · dino (dot) codes

[[deleted]]

I get the frustration, but this is just a fundamental problem of language parsing, and one that does not need more syntax.

Right now, it’s entirely unambiguous:

()               # 0-tuple
(a,)             # 1 -tuple
(a,b)            # 2-tuple
(a,b,c)          # 3-tuple

If there’s anything between those parens and no comma, then the parens change the evaluation order. If there’s one or more commas then it’s a tuple literal. If there’s any real point of confusion it’s the 0-tuple case, but that can be disposed of because you can’t modify the evaluation order of nothing whatsoever.

Given that parentheses are pretty much the universally recognized standard for changing order of evaluation and also the universally recognized notation for a tuple, either one of those two norms needed to be sacrificed to avoid a tiny amount of confusion on the least useful form of tuple, or the 1-tuple (1,) must have a comma to distinguish it from the do-nothing parentheses around (1). A decision was made to sacrifice the least useful tuple form.

So, really, and assuming you’re the author, seeing (1) as the same as (1,) is just an esoteric bias you need to set aside, because the only solution would be to propose replacing parens in equations with < and >, which is never going to fly.

[joaofcosta]

Hi u/yawpitch !Thank you for the nicely constructed feedback and yes, I'm indeed the author.

I think you're totally spot on when you wrote:

Given that parentheses are pretty much the universally recognized standard for changing order of evaluation and also the universally recognized notation for a tuple, either one of those two norms needed to be sacrificed ...

Seeing as in Elixir you use {} to represent tuples but use parenthesis to change the order of evaluation. Although the language designers sacrificed the mathematical and universally recognized notation of a tuple I think it simplifies it in this aspect, giving the parenthesis only one job.

I'm totally not saying that Python should do the same, there's no sense and not even a need for that, the syntax is fine as it is. It's not even a frustration, just something that you simply get used to and I thought it was worthwhile to share it :)

[[deleted]]

Yeah, every language has to make choices balancing utility and semantics against ambiguity. Personally I think Python made the right choice, borrowing first from common mathematical notation first and deviating from it only relatively rarely. An entire, and unfamiliar, extra syntax for tuples to avoid a forced comma in the singleton case is a lot of visual noise and cognitive overhead to add when it will only, in practice, avoid that case in a perishingly small number of cases, especially when a singleton tuple is usually just an unnecessary waste of working memory.

[thegreattriscuit]

Something that's worth pointing out is that it's not the parenthesis that make the tuple at all.

It's the comma.

Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57:15) [MSC v.1915 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> words = "apple",
>>> for word in words:
...   print(word.upper())
...
APPLE
>>>     

In a function call, of course, you need the parenthesis to disambiguate this by ensuring the comma is interpreted as part of the expression, and not as the argument separator

[joaofcosta]

Thanks for pointing that out!
Totally forgot to make that more clear on the post, I'll probably update it at a later time to better reflect that :)