Why tuple with one item is no tuple

[Antoon Pardon]

Op 2005-03-16, Diez B. Roggisch schreef <deetsNOSPAM at web.de>:
>> That ambiguity is only caused because python uses the same characters
>> for very different operations and to be honest I don't like that.
>
> As I said: show me which parentheses to use - and keep in mind that:
>
>  - < and > are for comparisions and the same ambiguity troubles arise 
>  - unicode surely features some usable characters (e.g. the quotation markes
> that look like <<, but are one char). But for one that complains that
> typing and additional comma is too much already, I doubt that having to
> press some weird multi key stroke is a viable option.

Complaints about typing an extra character are not all the same.
One can complain about the extra character that is needed on
the screen and one can complain about the extra finger work
that is needed to get a specific character on the screen.

Besides I don't remember complaining about typing an extra character.

> To me neither, as I
> prefer my parentheses to be accessed easily, even on a vi running in a
> console from a tn3270 terminal
>
>> 
>> for instance I have written once somekind of vector class where
>> it was natural for these vectors to be added as well as te be
>> concatenated. Unfortunately python uses "+" for both so I had
>> no way to have both operators in a natural way in python.
>
> And no way in mathematics or any other language either - if you want the
> same function symbol on the same operators to have _different_ semantics,
> you're getting pretty non-deterministic.

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.

>> So that a <*> would create an ambiguity if items would be silently
>> transformed in a one-item tuple when appropiate is IMO more caused
>> by the design decision to use <*> for two totally diffent operations
>> then because of the dynamic nature of python.
>
> Your opinion is wrong. It's because you seem to not have understood the
> example: The expression (5 + 4) could be understood as 9 or as (9,). In
> python (and each and every other dynamically typed language) you can't
> decide which version to take. So you have to decide on _one_, and as every
> kid in school learns that (5+4) * 5 is 45, it was a reasonable decision to
> use the semantics we have today.

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

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

>>> Soooooo, in the end it boils down to some explicitness - where IMHO an
>>> additional comma is pretty much no problem at all. Another option would
>>> of course be the introduction of different parentheses for tuples - but I
>>> can't find some on my keyboard.
>> 
>> Well I can't find braille on my keyboard, but if I wanted to, it
>> wouldn't be difficult to get it on my screen. So is it with
>> different parentheses. That python can't use these parentheses
>> is again a design decision.
>
> 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.

> But you showed that strange sense of reasoning before - I remember you
> wanting to shave off microseconds by optimising constant expressions like
> 5*4,

AFAIR I was just exploring ideas.

> whilst at the same time arguing in another thread that you'd like to
> have mutable keys for dicts that needed copying the very same keys - at
> much greater costs, per case and even more so in general as using dicts is
> common where pure constant arithmetic expressions aren't.

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.

-- 
Antoon Pardon