On 17 Oct 2019, at 13:46, Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Oct 17, 2019 at 10:42 PM Anders Hovmöller <boxed@killingar.net> wrote:
On 17 Oct 2019, at 13:26, Chris Angelico <rosuav@gmail.com> wrote:
Equally subjective, of course, but I prefer to be able to use operators. There's a good reason that we use mathematical symbols for non-numeric data types already (adding tuples together, multiplying a list by an integer, etc), and it definitely makes code easier to read.
The multiply a list/string thing is a big mistake imo. You almost never use it so the cost of not having it is almost nothing while the cost of having type errors propagate beyond the point where they happened is big.
Actually, I use it often enough to be useful. Probably more often than numeric exponentiation, and I'm sure you'd agree that 3**7 is better than requiring math.pow(3,7). I don't understand your point about type errors; how does "="*79 cause type errors? Or initializing a list of zeroes with [0]*20 ?
Well obviously never with literals. But most cases of multiplication aren't with literals. So how can you get a type error when doing a*b is the real question. And the answer is now obvious: any time the programmer thinks a and b are numbers but they are not. That's a logical type error that now propagates and it's very hard to track down the offending line when you eventually end up with a crash in a different module because
baz = foo / bar Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: unsupported operand type(s) for /: 'str' and 'int'
And believe you me, the number of times I have *wished* for features like these when working in other languages (mainly SourcePawn) makes me definitely not see them as mistakes.
I strongly disagree. I have used it but I always feel dirty for having written code that is clever and not explicit. There just isn't a nice explicit way to do it in python so that's what I'm left with. The utility of the feature is not something I dispute. It is useful! But it would be just as useful as a method. /Anders