How is the stance of the community on this?
Is it feasible? Planned? Wished? Are there any obstacles?
Besides the obvious development effort.
Have you had a look at nimpy? Lets you compile Nim code to a python module, and lets you call python modules from Nim.
That's about as good as anything is going to get, prove me wrong!
I mean, Haxe transpiles to python, but it's about as readable as Nim-compiled c.
If you mean compiling from python, there's https://github.com/metacraft-labs/py2nim_deprecated/ which has gained "deprecated" in its name since I last looked at it.
It's not very complete though.
If you compiling to python, there's https://github.com/juancarlospaco/nim-new-backend which is also incomplete.
The biggest question is why. If you want to use Python from nim, or the other way around, then nimpy and nimporter might be better choices than trying to fit everything into the same language runtime.
I created the repo because people were asking for an Example on how to do that, it is an example it was not meant to be complete.
...but if people are interested on making a real working one, we can team-up or whatever.
:)
I think part of the "sales pitch" for Nim out in the world, for good or ill, is "sorta like Python but compiled with static types". It isn't so strange that people show up asking how to automate "sorta like" into "more so". ;-)
The vast majority of Python code that I have seen uses precious little of Python's very dynamic nature. So, doing a half-baked py2nim with a slew of caveats might have some value. It's not like c2nim is perfect, either. The questions are more A) if the caveats are beyond the grasp of the typical person porting such code and B) if the rather open-ended nature (ever changing Py3) would leave it half-done forever. @juancarlospaco may be right that a group effort here could yield the best results.
It isn't my question to answer, but as to "why?", it is likely "easier good performance". Python unassisted by C/Cython/Pythran/etc. or Pypy is one of the slowest programming languages around. Combined with piles and piles of Python code out there doing xyz useful thing that could be safer/faster/etc. with Nim. Nim just invoking/calling that code is one way to access functionality. If it was too slow to begin with, it won't help. People may have misplaced expectations about how little they have to think in order to improve performance, of course.
I love Python, and as one of the most popular programming languages in the world, if not the most popular, other people apparently love it too. But I have hit its limits.
If it was possible to get reasonably maintainable Nim code from Python source, even if it required extensive editing, I think that would be huge. It's not like we're talking about converting some niche language like OCaml, Scala, Haskell, Erlang, Elixir, etc. to Nim. That would be a waste of time. But when you're talking about converting the most popular programming language on the planet, I think that would justify a lot of effort.
While it is possible to use Nim like a Cython replacement to speed up certain slow parts of a Python program, and that may be the best way forward for an individual or small team, it has limitations similar to multiprocessing: you still may have to take a lot of Python data, convert it to native Nim structures, do something with them, then convert it all back to Python, and that won't be fast. I haven't tried it, so can't say whether it's worthwhile or not.
One way to see how reasonable it is to do a real Python to Nim transpiler would be to start manually converting small Python programs, like at https://rosettacode.org/wiki/Category:Python. The advantage of starting with real programs vs a grammar is that you'd be putting effort into converting things that people use all the time rather than beating your head against a wall trying to figure out how to convert some esoteric Python OO construction that maybe only a few people actually use. If a transpiler converted 75% of the code and left the other 25% of "weird" stuff to be done by hand, that would be huge. Someone there wrote the weird Python, someone there can convert it by hand.
This would also be a great tool for Python programmers to learn Nim. If a person is already familiar with their Python program, seeing a decent Nim translation would be a great way for them to map the Python concepts they already understand, to Nim.
And it isn't just about performance. Have you ever tried to do a static build of a Python program that uses C extensions (not the ones that come with Python), Cython modules, and needs an updated OpenSSL, for 3 platforms? Try it. It ain't fun.
Or if you have a C library you'd like to use, like the new Blake3 hash function, that doesn't have a Python binding yet. Ever seen those C-to-Python modules, with refcounts all over the place? What if you forget a few and your program starts crashing regularly. How do you debug that? Again, not fun.
Those are some of my reasons for looking at Nim. I looked at Go, and while it's much more mature and stable because of Google, it doesn't do much for me. Rust is way too fussy (Nim is too sometimes) and Rust is starting to look like APL. Compared to C++, which is a mess I never even wanted to learn, Rust might be wonderful, but they're too much "kitchen, bathroom, and laundry sink" for me.
How would I translate 200_000 lines of Python to Nim? Though nut. I probably would write a Python lexer/parser in Nim and translate a Python AST to Nim by constructing Nim's AST much like c2nim does it. Inside py2nim I would try to detect project specific patterns to make the Nim more correct until it's close enough that manual editing of the remaining glitches becomes feasible.
"I don't see Nim and Python as being very similar, except at a syntactic level."
And that's the level that matters for source to source compilation
And that's the level that matters for source to source compilation
no?
No, and the syntax is what got them interested into the language in the first place.
While I guess it is always more easy and performant, to just translate Nim into C and call that from Python.
Hnn, maybe it is enough to demonstrate such an example on Youtube, so that the Python people can see, how effective that is?
Since I dont see anything on Youtube or anything.
Nim provides whatever it can from 1 while still being a static language, especially with INim - it's as easy as Python for anyone with previous programming experience (although I think the chasm for absolute beginners is still to big to cross from python to Nim, and possibly always will be).
The thing about 2 is that "translating to Python" or "translating from Python" is not helpful. PyPy spent a decade of work, after perfectly speeding up Python, to get access to the "heavy lifted" C extensions, and it is still experimental and incomplete.
I think the best way to, by far, to leverage the huge and useful Python ecosystem for Nim is with Nimpy and Nimporter. Any language features that could make using them more seamless would be a win, IMHO; But they already do an excellent job and I can't think of any general feature that would make them more seamless or more useful.
I mean a transpiler for Nim to Python, like it already exists for C, C++ and ObjectiveC
The Nim compiler is a compiler, not a transpiler. I realize that many people don't understand the difference between a compiler for language A that generates code in language B, and a transpiler from language A to language B, but there's a large one.
Anyway, I think it's a bad idea.