> But when you want to make Nim very similar to Python, as Crystal did it with > Ruby some years ago, then traditional OOP is the largest obstacle. Some > syntax differences really do not matter. But most Python code uses OOP style, > which is not recommended by most Nim devs. So Python people would have to > learn this new non OOP style, and would have to redesign legacy Python code.
Excellent points. I didn't mean that Nim should mirror Cython (or Crystal's example with Ruby) exactly. Note that in my original post I said: "Can the Nim community make the case that Nim is the best Python companion? Which future Nim development goals would increase this appeal?" Nim definitely improves on Cython a great deal. I love Nim's approach of optional and trim OOP, including UFCS, optional parenthesis, etc. I even prefer Nim's style guidelines (despite coding Python since before Y2K). But there are differences which I cannot call an improvement that **annoy Pythoneers for no reason** , like: * The redundant chanting of `let` / `var`. Python users are used to just saying `b = 2` for let. (If Nim did it the other way, making let default and var required, that would still be an improvement.) * Writing `from blah import nil` for every module [instead of](https://forum.nim-lang.org/t/3061) `use module1, module2, module3`. (This isn't exactly like Python, but you can get the same behavior by just using a different keyword.) * Maybe the json module could be made more approachable for people coming from Python and looking for an easy analogue to dictionaries.
