Instructing operating system - Knowing it's functionalities
There are many possible OSes, each one with its own design philosophy and technical conventions. Here's a rough, but reasonably common design for an OS.
Beware that, for brevity, I had to simplify things a bit and cut some corners. OS design is a huge topic (we have whole university courses covering that!), so don't expect this to be comprehensive.

First, we exploit some hardware support to separate the OS from the userland processes. At any time, a bit register inside the CPU tells whether the CPU is executing in "OS mode" (AKA supervisor mode) or "user mode". 

In OS mode, the CPU runs unrestricted, and can read/write everywhere in RAM, modify any register of the CPU, send messages to devices ("To video card: make pixel at 542,234 black"), and so on. In user mode, the CPU can only read/write at some RAM address, and use only some CPU registers. It can not directly send messages to devices.

Crucially, it can not flip the bit which turns the CPU into OS mode, otherwise a process could bypass the protection and pretend to be the OS.

Well, almost. The CPU actually allows executing a kind of magic instruction -- let's call it help! -- which precisely flips that bit and put the CPU in OS mode. There is a big catch, though: help! also acts as a jump to a special address in RAM where OS code lies. So, a process can not go in OS mode and still execute its code, but it has to jump to a specific location, causing a part of the OS code to be executed.

Usually, before asking help!, the process writes some numbers in the CPU registers.

After help! is called, the OS reads those CPU registers, and interprets those numbers as a request from the process. For example, if in register r1 there is number 0, this could be a request to change a pixel in the screen (the pixel having coordinates in registers r2 and r3 and the new color in r4). 
The OS then runs the code to ask the video card to change that pixel. Since every card likely requires a different message to be sent for that, the OS first calls a device driver with an hardware-independent message (color pixed X,Y as C) and that driver will then craft and send the message to the video card. Note that the driver is run in OS mode -- it is a component of the OS (in this basic design, at least).

If instead register r1 there is number 1, this could request a file to be opened (the file name being specified by r2). This could involve asking the disk diver to access the disk.

And so on. When the OS is done, it flips the CPU mode back to "user mode" and jumps to the process code, so that it can continue.

There are usually many possible requests from a process to the OS, usually specified by an ABI (application binary interface) which describes what registers to write and with what. Sometimes there's no public ABI, but programmers are supposed to call instead a usermode library, typically written in the C programming language. That library has a public API (in C), and will provide a bridge from that to the internal OS unpublished ABI.

There requests are known as "system calls" or "syscalls", by the way.

If you want to do a syscall in python, without relying on absolutely any library, you can not. This is because bare python does not give you a way to control the registers, or to run the help! instruction. Python is not special here, bare C also does not allow that, as with most programming languages.

Usually, though, one exploits some library. Or, if one really wants to go low-level, one can write a small module directly in assembly, and then call that from C or python (or anything else). That could require to use a "foreign function interface", so to link the assembly module with the language. In C it's usually very easy to do, since the language is low level. In python, calling assembly could be harder to do, but it's surely doable.

I strongly recommend you try to read an OS textbook. It should cover these topic in much more detail than we can do here.