Why tuple with one item is no tuple

[Antoon Pardon]

Op 2005-03-17, Diez B. Roggisch schreef <deetsNOSPAM at web.de>:
>> 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.

We talked about the confusion that could arrise if a number could be
interpreted as a tuple because the '+' operator has a different
kind of result depending on whether the operands are numbers or
tuples. However if adding tuples would have been defined as
above their would have been a confusion because the result
would have been equivallent. 4 + 5 would have been 9 and
(4,) + (5,) would have been (9,)

And having chosen such a design wouldn't have made python
any less dynamic. So saying that the problem is the result
of python being dynamic as you once did is nonsense.

> 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. 

That could very well have been left to the users themselves. They
only needed to have used a different character for concatenation
instead of the "+".

> 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.)

You claimed it was pythons dynamic nature that makes it difficult
to use items and one-item tuples as equivallent. I say
it has little to do with tha dynamic nature but more with the
design to use the same characters for sequence and number operations.
If these operations would have been indicated by different characters
no such problem would arrise with doing such unification.

>> 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.

No it is not. It is part of a counter argument to your claim
that python's dynamic nature is in the way.

> 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.

I didn't say I want that. I was just wondering if unification between
numbers and one number tuples wouldn't have been a good solution with
the confusion people have about (1) not being a tuple.

> 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.

It has litte to do with statically typing. But when I explain that
and show what will cause a problem with such unification in current
python you say I'm altering the subject.

>>> 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.

I was wondering about the merrits of (8) behaving as (8,) that is
not the same as wanting it. May be you shouldn't read thing that
are not there.

-- 
Antoon Pardon