Why allocating memory mid-loop is dangerous
Every time a program asks for a new chunk of memory while it's running, whether in C++, Python, or any other language, that request has to be handled by an allocator that searches for free space and hands it back. That search doesn't always take the same amount of time. It can be quick, or, depending on how fragmented memory has become or what bookkeeping the allocator needs to do, it can take noticeably longer on some calls than others. That variability is a well-known and well-documented source of unpredictable timing in software generally.
Inside a tight control loop running at a fixed rate, that variability is exactly the kind of surprise a real-time system can't tolerate. A loop that normally finishes its work in a fraction of a millisecond can occasionally run long simply because one iteration happened to trigger a slower-than-usual memory allocation. From the outside, that looks identical to any other missed deadline: a late or dropped command to hardware that was expecting it on schedule.