@23, sorry, but just because someone knows how to make audio games doesn't mean they necessarily know what they're talking about. In this instance, post 14 was claiming that Python was slow because their slow (poorly-written, I'm guessing) algorithms were slow. That's not a fault of Python. Even if you wrote a poorly-written algorithm in assembly it would be slow. The key takeaway is that development is [not] all about performance and speed -- its also about readability and productivity. You can make something ultra-fast, but in the process you risk making it illegible by anyone but you (and even that's debatable). Even my OS has some places where I sacrificed performance for readability, legibility and productivity. You can balance performance, readability and productivity, but its not easy to do.
@25, we wouldn't be so rude to the OP if the guy hadn't literally admitted that he wanted to take stolen source code and rewrite it in Python to somehow un-steal it. The term Plagiarism, I think, would apply here; yes, its not theft of writing, but plagiarism is generally the theft of someone elses work and claiming it as your own. Even if you modify the work, there's still enough of it to identify it as not yours. The only way to eliminate that is to make it from the beginnings. Also... @14, why weren't you just using tensorflow and other well-developed ML libraries out there? What was your incentive for creating a custom neural network algorithm? If its for educational purposes, wonderful. But that doesn't mean you can use your algorithm as some kind of benchmark. (Side note: do not trust benchmarks for your measurements of speed. Though they can give you general ideas of how fast something is, there are far too many variables to consider for them to be 100-percent reliable. At most I'd say a benchmark is about 50-50.)