Your apparmor denials would suggest this is a problem with the use of the /dev/shm folder.
The default policy is that files created in /dev/shm must be namespaced to the snap, such that any temporary files follow the pattern of SNAP.$SNAPNAME.* (or something similar, I can’t 100% remember it 
).
There’s a proposal for these kind of issues that might remove this restriction in the future, take a look here, but none of this is available to use yet.
Your options are likely to either use the snapcraft-preload library which can fix this in some situations (by mapping transparently renaming files so they work), but it may be the case that whatever is making this call in Python is actually avoiding the standard shm_open() calls. E.G, Joblib in Python tests if /dev/shm/ exists first by just placing any random file in it, which fails and causes issues. If it’s a case similar to this, you might need to patch the Python file causing the issue (e.g, with sed or patch).