Is writing small Python scripts for Windows and macOS a good way to practice?

Yes, small tools that do something real are useful practice. The tricky parts are often the boundaries: what happens when a permission is missing, a file does not exist, or a system call returns an unexpected result. Try each failure case deliberately instead of only checking the happy path.

For the macOS code, step through it with a debugger and inspect the values returned by each call. If you cannot explain a line yet, isolate that call in a tiny experiment. That is more useful than adding comments you do not fully understand.

Don’t use a low-level interface just because it seems less likely to involve timing problems. First check whether Python already has a standard-library function for the task. A higher-level API is usually easier to understand and maintain, and low-level calls bring their own failure modes.

Also, keep platform-specific details behind a small function or module. Then the rest of your script can use one consistent interface, and you can test the Windows and macOS implementations separately.

A longer implementation is not automatically a problem, but make sure each bit earns its place. Repeated print statements can get noisy as the project grows. Python’s logging module lets users choose whether messages go to the screen or a file, and tests can check reported errors without relying on printed output.

For code paths that are intentionally unfinished, raising NotImplementedError is clearer than silently doing nothing. A couple of small tests for expected results and common failures would also give the project a solid next step.

This sounds like a worthwhile practice project, especially if you treat it as an investigation rather than a race to support every platform. Pick one operation, make sure you can explain how it works, and write down what assumptions it makes. If you get stuck on a system call, look up its inputs and outputs separately from the surrounding Python code.

You can also use platform.system() to choose platform-specific behavior, but keep unsupported systems explicit rather than letting them fail in a confusing way.