I don’t understand when you are saying that `b = 2` means `let b = 2` in Python. Python has neither an equivalent of `var`, nor an equivalent of `let`. When you write `b = 2`, you simply bind the object `2` to the name `b`. And that doesn't prevent you to write afterwards `b += 1`, so it certainly doesn’t make `b` read-only.
In fact, I don’t see why we should worry about the way Python users see the need to declare variables either with `let` or `var`, as there is no similar concept in Python. I don’t think we should try to match syntax of languages, based on supposed analogies. For me, it is certainly a recipe for a lot of future problems as, actually, the language are quite different. Furthermore, even being a long time user of Python, I appreciate the use of `var` and `let` in Nim. In Python, the location of the first binding of a name (which we could consider to be its “declaration”) is frequently lost somewhere in the code. This is the reason why I tried to put all these first bindings at a common place with adequate comments (same thing for attributes in classes). And this is one of the reasons, too, why Python 3.7 has introduced data classes. As regards the equivalent for Python dictionaries, the _tables_ module is satisfying for me, even if it is less easy to use, for Nim is statically typed. And I will certainly don’t use JSON to simulate Python dictionaries. In fact, the most important thing for Python users when they use Nim tables is that they expect good performances (Python dictionaries are very efficient) and I have encountered some surprises when using tables (for instance, extremely slow performances when using _clear_ which I expected to be more efficient than creating a new table). There are certainly some possible improvements to make in order to attract some Python users, but I’m not sure it would be worth it. I have of course searched equivalences when using Nim, especially when converting Python code to Nim code. For now, for me two things have been an annoyance (due to the nature of the code I was converting): * lack of big integers, but, fortunately, there is the _bignum_ module (and also _bigint_ ), so this not really a big limitation; * no generators; iterators are a good substitute, but they cannot be recursive; so you have to use a proc which returns a list and it makes the code more complicated and less readable; so, I certainly would like recursive iterators. Now, I doubt that all Python users writing some program in Nim have the same requirements as me.
