4 ms·

Didn't realize this was a PEP but I'm glad it was deferred. I have a bit of PTSD from my foray into Haskell and trying to understand the internals of libraries

Didn't realize this was a PEP but I'm glad it was deferred. I have a bit of PTSD from my foray into Haskell and trying to understand the internals of libraries like attoparsec. The proposed `??` operator makes me think of things like the `<*>` operator for applicatives. The average person's intuitions don't serve them in guessing at the meaning of either. And extra syntaxey characters really disrupt the flow of things. But I guess that's just my opinion. In any case, this feels like something that belongs in Ruby more than Python. The designers of Python made the deliberate choice of sacrificing conciseness for readability in certain cases. If we give that up, I think Python will end up feeling like something that doesn't know what it wants to be.

eru 4y ago
Keep in mind that in Haskell all operators can be defined in user-level code. They can also be shadowed by your own code. If you don't like `<>`, you can also easily make your own function and use that instead: my_function a b = a <*> b I agree that (infix) operator syntax can make some code hard to read, but it can also make some code easier to read. I do feel strongly that allowing people to make up new operators is preferable to undisciplined overloading of existing operators: Eg in Haskell when you see `<>` at least you know that something unusual might be going on. In C++, when you see `>>` (or even `+`) you have no clue whether it's just plain old bit-shifting, or whether someone overloaded it to do IO or perhaps launch the missiles.