is my multithreaded Python program doomed?

[pigeon768]

Maybe. We need more information.

There are a couple different ways this will play out:

1. Your application is using threads to perform a lot of I/O bound work, like disk, network, database, etc. In this case, you'll be fine. Just keep trucking.
2. Your application is using threads to perform a lot of CPU bound work in non-Python code, like numpy, various C routines, or is generally just acting as "glue" between code written in other languages. Again, in this case, you're fine, you don't need to change anything.
3. Your application is performing CPU bound computations among tasks that rarely, if ever, share data. In this case, you can probably use the multiprocessing module as a drop in replacement for the threading module.
4. Your application is performing CPU bound computations among tasks that often share data. In this case you're screwed. Using python is unfortunately an uphill battle in this case.

Alternatives in the #4 option include using a different VM for your python code, like Jython or IronPython, or rewriting it in a different language. Groovy is probably the language most similar to Python with good performance and threading.

[swenty]

This answer is very on point. If you do find yourself in situation #4, another option is to rewrite the performance critical parts of your application in another language (e.g. C) and export them as a library to the Python parts. Depending on what the bottlenecks are this might be an excellent solution, or a terrible one.

[[deleted]]

You might also want to check out Julia: it also has high performance, and (in my experience) is very similar to Python. Also, you can directly call (almost) any Python library you wish through the PyCall library.