Not at all. I documented them in the README, actually:
Dragon is now abandoned, due to a number of problems:
- The complexity of implementing some Python features (such as generators and generator functions)
- The vast array of built-in Python functions that need to be re-implemented (eg. itertools)
- Lack of code completion (unless you wrap Haxe natives in Python classes)
- The end-result is not “Python”-like – you can’t put it into the REPL and poke it.
I conducted a thought experiment: what if I finished Dragon? What would the final user experience be for a Python/Haxe developer?
That’s where the last two issues came about – to get code-complete, I probably need to create Python versions that wrap Haxe classes. This is tedious, because HaxeFlixel updates quite often. I might be able to automate it, using the
xml target and auto-generating the Python code. But that’s a big undertaking.
Similarly, I would also probably have to reimplement a lot of the Python library in Haxe; unless I could use something like the source of PyPy and run Dragon through it to generate Haxe code.
Even if I accomplished all that, the final result is not Python. You can’t throw it into the REPL, you can’t run
dir(x) on some variable to see methods, and so on. And I’m not even touching on the complexity of implementing generators, local/global/nonlocal scope, etc. in Haxe – I don’t have a clue how to do that.
So while there aren’t any good cross-platform Python game development libraries out there, using Haxe as a back-end is not a great idea in my view. I’d rather write raw Haxe, and focus my time on libraries that I can use to get stuff done faster.
Does that make sense?