| > The python people don't adhere to this principle It's harder to "not break user space" when you don't have a "kernel space". No, the C API does not count. > Those of us of a certain vintage will recall the tumult of python-2 to -3. Suddenly, production code needed significant re-writing. We got an arguably better python out of it, but oh! the pain. I have been using Python since 2005. I recall code that required minor edits, many of which could be and were automated using CPython's own provided tools. I remember the joy of getting text files that could trivially handle a file encoding and universal newline support at the same time, and binary files that were actually binary, supplying a fundamentally distinct type of data. I remember no longer having to worry about getting `UnicodeDecodeError` from an encoding operation (https://stackoverflow.com/questions/9644099) or vice-versa (https://stackoverflow.com/questions/5096776) and no longer having to explain that nonsense to people. I remember the realization that beginners would no longer be taught to introduce arbitrary code execution exploits into their programs on the first day of lessons. We got an inarguably, massively better Python out of it. > C and bash programs that I wrote 30 years ago still run. Because they are very nearly self-contained. Your life will be happier if you think of non-essential parts of the Python standard library (like `sys` and `os`) as if they were third-party. > the python developers decided to make 'forkserver' the default instead of 'fork' for the Process() method.... Why on earth break our code in such a wanton way? Everyone always seems to take this sort of thing extremely personally for some reason. The entire point of default arguments is to reflect what most users are most likely to want. Sometimes that changes. The same document you link clearly explains the reason for the change: > Changed in version 3.14: On POSIX platforms the default start method was changed from fork to forkserver to retain the performance but avoid common multithreaded process incompatibilities. See gh-84559. And there is a link to the bug tracker where the OP explains what's wrong with `fork` on POSIX: > By default, multiprocessing uses fork() without exec() on POSIX. For a variety of reasons this can lead to inconsistent state in subprocesses: module-level globals are copied, which can mess up logging, threads don't survive fork(), etc. and later: > Given people's general experience, I would not say that "fork" works on Linux either. More like "99% of the time it works, 1% it randomly breaks in mysterious way". Note that the discussion for this goes back to 2020. > Not with python - if you use it, buckle up and make sure your regression tests are thorough, it'll be a rough ride. You have not even attempted to explain how this broke your program. For many other users, it demonstrably fixed issues. In the time that you spend posting this, you could have trivially just added `multiprocessing.set_start_method("fork")` to your code; or taken more drastic action by for example vendoring the old standard library package (it's under a permissive license and is as far as I can tell pure Python, mainly layers of wrappers around `subprocess.Popen` and `os.fork` and such). Aside from which, if you have a proper reproducer for something that works with 'fork' but not with 'forkserver', the proper place for your complaint is the issue tracker. > buckle up and make sure your regression tests are thorough Good advice in every programming language. Especially if you want to avoid NIH. |