Why tuple with one item is no tuple

[Diez B. Roggisch]

> So python choose a non-deterministic direction. To me (2,3) + (4,5)
> equals (6,8). I don't dispute that having an operator to combine
> (2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
> used the "+" for that.

It certainly did not choose a nondeterministic action - that would mean that
it followed _both_ possibilities at the same time. Which clearly is not
happening.

And we didn't talk about (2,3) + (4,5) not being (6,8) - that's adding two
tuples, not having (9) beeing a tuple instead of a simple nine.

Of course one could have overloaded tuples that way - component wise
addition - but then people would want other kinds of vector algebraic stuff
working on them. But they are not vectors, they are tuples. 

And in general, that is an entirely new discussion about the overloading of
operators for tuples, not the syntax of how to create them (which is
legitimate, of course - but misleading for this thread.)

> No my opinion is not wrong, you just don't understand what I'm saying.

You alter the subject of discussion (see below), which caused that
confusion.

> No it was not reasonable to introduce the semantics that made 2 * (1,2)
> equal (1,2,1,2) IMO they should have used a differend operator for that
> and not the *.

Maybe - but thats an alltogether different discussion, as I said before.

The point that made me kick into this discussion was:

"""
> You really, really want (3 + 5) to be an integer, not a one-item tuple.

I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.
"""

So you wanted (8) to be a tuple, or even more so 3 + 5 being (3,) + (5,).
What has that to do with the operator overloading of tuples in general?
It's a syntactic question we're discussing, _not_ a semantic one.

As I stated before, it could become a question of type semantics if python
was statically typed, as then the context of a expression like (8) could
determine which type has to be created - tuple of one item, or simple 8.
But it's not doable in python.

>> For someone who expresses his disliking to type _one_ comma in the few
>> cases of single element tuples in thousands of lines of code, it strikes
>> me odd that you'd go an are willing to add extra trouble entering _each_
>> and _every_ tuple in your code by using some hitherto unknown character
>> that won't be enterable easily....
> 
> Where did I express this dislike. I'm not denying it because I know I
> forget such things, but I sure don't remember now.

I showed the quote above - you wanted to have (8) behave as (8,) - so I
concluded you either don't like typing that extra comma, or alternatively
want introduce a new pair of parentheses to express tuples.

> Well it seems you didn't follow that thread thorougly. If you had you
> would have known that if the objects one had to work with were at
> the same time mutable and usefull as keys, you have to turn them
> into an immutable now for use as a key. This is a copy operation.
> So compared to the situation now, no extra copying would be necessary
> and no extra costs would be needed.

I did follow it, and I didn't say that the copying was necessary all the
time, even for immutable keys. 

-- 
Regards,

Diez B. Roggisch