"your application is using more memory than what is available in the system." 

Well, it alone may not be using more memory, but the cumulative usage on the system is "too high" by whatever metric the OOM killer is using (IIRC the default rule is that actual committed memory must be less than swap size + 50% of RAM). The OOM killer is a strange and terrible beast, and the behavior varies based on configuration, relative memory usage of each process grouping, minimizing number of processes killed, etc.

You can find deep implementation details on it (including how to disable a given process for consideration) here: https://linux-mm.org/OOM_Killer

The real solution to problems like this usually amounts to:

1. Install more RAM.

2. Increase the size of your swap partition. Doesn't "fix" being shy of memory if you're actually using more memory than you have RAM, but allows you to handle overcommit (particularly for fork+exec scenarios where the forked process's memory will be freed momentarily) without the OOM killer getting involved, and to limp along slowly, without actually failing, if you actually allocate and use more memory than you have RAM.

3. Tweak the overcommit heuristics to allow more overcommit before invoking the OOM killer.

4. Disable overcommit entirely, so memory allocations fail immediately if sufficient backing storage is not available, rather than succeeding, only to invoke the OOM killer when the allocated memory gets used and the shortage is discovered. This is a good solution if the program(s) in question aren't poorly designed such that they try to allocate many GBs of memory up front even when they're unlikely to need it; unfortunately, there are commonly used programs that overallocate like this and render this solution non-viable if they're part of your setup.

Regardless, this isn't a bug in Python itself. Any process that uses a lot of memory (Apache, MySQL) and hasn't explicitly removed itself from OOM killer consideration is going to look tasty when an OOM scenario occurs.