101–110 of 173 posts
A “dict” operator would be vague because there is more than one way to combine dictionaries. Why should I have to guess whether duplicate keys are being skipped or replaced by a symbol, when two different well-named functions will always make it clear?
Earlier quoted context omitted.
The even more sensible thing is to take an optional argument: a function that is passed the conflicting keys and their values, and must resolve the conflict. If `None` is passed, then a documented default is taken.
It’s an operator, there are no optional arguments. Though it’s OK to also have a function like you propose.
I mean, it's right there in front of your eyes. He talks about the convenience of using a visually commutative operator like "+" for commutative operations, and then a few lines later he says that it is a convenient notation for string concatenation. What. The. Fuck.
Earlier quoted context omitted.
What? Have you never had two dicts and wanted vals from one dict override the other?
That’s semantically not an “add”, it’s a “merge” or “update”
Earlier quoted context omitted.
> it is amazing to me this guy is the creator of one of the most popular languages today when he is such a poor thinker. This is unnecessary and a huge stretch given one blog post.
Possibly gp was referring to other, well known writing by the author? I assume all have seen GVR on tail call optimization.
Earlier quoted context omitted.
What? Have you never had two dicts and wanted vals from one dict override the other?
That’s semantically not an “add”, it’s a “merge” or “update”
My point: don’t just pick words, explain why those words were chosen.
I'm amazed (and horrified) how come such an intelligent mathematician and designer of a beautiful programming language made such an obvious fuckup of using a commutative operator for string concatenation. Really, I hate python just for this single idiotic notation. I mean, it's right there in front of your eyes. He talks about the convenience of using a visually commutative operator like "+" for commutative operation…
Does it cause any problems beyond that? For example, does it interfere with some elegant patterns, or result in some bug prone code, etc?
FWIW, the single main annoyance I've had with python was its treatment of strings as iterables of single character strings. While not wrong in any obvious theoretical sense, it conflicts with the mental model of many developers (both new and experienced) and has probably caused more bugs than any other feature of Python (and even more ugly type checks to avoid such bugs). When people realized it was a problem and discussed removing this feature, Guido said he had tried but (a) it was too much work and (b) he felt the benefits are too great to give up (https://mail.python.org/pipermail/python-3000/2006-April/000...).
Earlier quoted context omitted.
We do have f(x, y) in mathematics notation, as well as notations like { a, b, c }, ( 1, 2 ). The inventor of vector and matrix notation finally had the brilliant idea of dropping the silly commas [ i j k ]. Think of how ugly matrices would look with commas. Now in mathematics, there is no equivalent of a 200,000 line piece of software. The number of identifiers a mathematician works with in any given work is small, e…
> goes to the trouble of professional typesetting Calling people’s use of LaTeX to type their homework “professional typesetting” seems like a stretch. Professional typesetting would be something like: send your hand-written manuscript to a full-time typesetter, and wait for them to do the work. A better description would be “goes to the trouble of using math typesetting software designed by experts”. But is this rea…
I'm amazed (and horrified) how come such an intelligent mathematician and designer of a beautiful programming language made such an obvious fuckup of using a commutative operator for string concatenation. Really, I hate python just for this single idiotic notation. I mean, it's right there in front of your eyes. He talks about the convenience of using a visually commutative operator like "+" for commutative operation…
Also, to the best of my knowledge there is no place in the bible of maths that defines + to be commutative. In particular, addition of (infinite) ordinals is not commutative.
But, this argument defeats itself. At least, in practice. If I look at how 'operator overloading' is used in practice, _rarely_ do you get commutativity, or even anticommutativity, associativity, or distributivity. Take list addition, where operator overloading often shows up: someList += someElement is shorthand for: someList.add(someElement) add is not commutative; the elements used in the operation aren't even the…
In my opinion, requiring commutativity from a +-operator is maybe too much. Associativity and a neutral element seem to be enough (i.e. forming a monoid).