> 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. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
