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. 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 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.
In a statically typed language, (5+4) _could_ be the tuple if the expression
is used in a typing context that makes that determinable. An example would
be
list((5+4))
as the list constructor needs a iterable to work, so it would be declared
like this:
list _ : [ iterable[alpha] ] -> list[alpha]
But then you'd have to forbid overloading of operators, or someone could
declare a list like this:
list _ : [ num ] -> list[int]
to create lists of zeros of type int. Which would reintroduce the ambiguity
again.
And if the static typed language allows operator overloading, it could
very well be that someone creates a overloading for
<*> : [tuple[num], tuple[num]] -> <whatever>
which would reintroduce the ambiguity.
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....
But you showed that strange sense of reasoning before - I remember you
wanting to shave off microseconds by optimising constant expressions like
5*4 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.
