Top layer safety standards for "functional safety" like IEC 61508 (industrial), ISO 26262 (automotive) or DO-178 (aerospace) etc come with a software part (for example IEC 61508-3), where they list a number of suitable programming languages. These are exclusively old languages proven in use for a long time, where all flaws and poorly-defined behavior is regarded as well-known and execution can be regarded as predictable.

In practice, for the highest safety levels it means that you are pretty much restricted to C with safe subset (MISRA C) or Ada with safe subset (SPARK). A bunch of other old languages like Modula-2, Pascal and Fortran are also mentioned, but the tool support for these in the context of modern safety MCUs is non-existent. As is support for Python for such MCUs.

Languages like Python and C++ are not even mentioned for the lowest safety levels, so between the lines they are dismissed as entirely unsuitable. Even less so than pure assembler, which is actually mentioned as something that may used for the lower safety levels.

It is possible depending on the safety case and governing standards body to use Python in a safety critical system.

Technical - Availability and Real time

However, for continuous safety, there are always time demands. For example an anti-lock breaking system must always be ready to perform. Ie, high availability. It will also have timing guarantees. It is no good if the anti-skid mechanism engages after a fish tail has started. This would be a real-time gaurentee.

Many higher level languages such as python include garbage collection. If the garbage collector is not incremental or controllable (when the garbage collection happens), it is impossible to fulfill the timing guarantees. It is difficult to have timing demands meant in Python.

Some systems are not continuous, such as a Covid assay (do I have Covid-19 yes/no). It is more important to be reliable, meaning do I get the correct results all the time.

Standards

Some standards such as IEC 62304 (medical software) are goal oriented, but allow the use of the prescriptive IEC 61508. A safety case must be made through technical arguments that Python was a good technology choice for the use case. This can be very difficult, so defaulting to the prescriptive standard is the norm.

Frankly, I believe that Rust would probably be a better choice than Python for a wider variety of cases. Some regulatory bodies allow you to have your safety case previewed before large scale development gets underway. If you have a goal oriented standard, it would be very prudent to get some acceptance of your argument for the language from an auditing body.

Reality

Entrenched languages will have tools and pre-certification. For example you can get TUV-Sud certified compilers. Not only the code, but all aspects that are used in development must be analyzed for a safety case. This include static checkers, revision control tools, code review tools, CIT systems, etc. Depending on the 'safety level', you many need all of these elements to be certified. Ie, Level C pace maker or ASIL-4 automotive component. If the language was never used in a safety standard before, it can be difficult to find certified tools, an OS or run-time libraries.

As well, it can be fairly expensive to make the arguments that a new technology is safe. This means there will be added cost to the company that initially undertakes this exercise. A product that succeeds, makes it to market and helps to save lives is better than an intellectual exercise that fails.

It will be hard to find guidance for Python in safety critical software development because there are too many things that make Python no option for really critical applications. You could never entrust a piece of Python code your life. See a few reasons why:

The memory model in Python is much different then the one in languages for embedded software. Python uses massively the Heap, while safety critical software normally uses global data and the Stack. For dynamic memory it is just too complicated to perform a safety assessment. You have phenomenon like memory fragmentation, garbage collection, memory leaks. The algorithms in Python, that prevents these things, have never been qualified.

In Python you normally don't care for dependencies, cyclic dependencies. As everything is interpreted at runtime, it just works. But safety critical applications normally require that you have a Top-Down design with abstraction levels and dependencies in a tree structure. Because this is, what the V-Model wants. That is the reason why Python code most of the times is not compliant to safety standards.

Python developers prefer a defensive style of programming, so that the code is immune against adverse unexpected situations. But in safety critical code all situations must be taken into account in advance. Defensive programming prevents the detection of design errors early in the development.

For things like lambda expressions and closures it is hard to use test coverage metrics. But these are required in safety critical software development. You at least need to cover each Python statement once because without static typing, testing is extreme important. Otherwise you would not reliably identify type errors.

I understand that you don't expect that level of safety and that you just want to have certain (the best possible) level of safety. It would indeed be interesting to have guidance what features of Python can be considered as safe and what programming techniques are recommended. Unfortunately there seems to be no guidance available, yet. Perhaps people are worried too much about the run time environment and the concepts of Python not been mature enough or adecuate for safety critical applications.

A good book for reading is "Developing Safety-Critical Software - A Practical Guide for Aviation Software and DO-178C Compliance" by Leanna Rierson. It gives very interesting insights about what you have to care when developing safety critical software. It covers even things like Object Oriented Programming. When it comes to C# or Java it is said, that these languages are just not mature enough. And it can be supposed that the same is the case for Python.