Eric Larson <larson.eri...@gmail.com> added the comment:
> Why? This is a resource like any other and it requires proper resource > management. Would you also put a big warning on "open()" stating that opening > a file requires either using a context manager or ensure a manual close()? One potential reason would be that the consequences of bad resource management in this case are different than in the open() case, i.e., here the interpreter hangs -- or Travis runs for your repo (SciPy) get stuck with over-50-minute errors, which is how we started looking for how to track it down. > > the first Python 2.7 example in the docs > Python 2.7 is not supported and the pool has changed *a lot* since Python 2. Indeed, my point is more about potential prevalence: this (now incorrect) problematic usage pattern was the first example in the docs for multiprocessing for a long time, indicating that there might be a lot of code in the wild that might (still) make use of it. > Yeah, and CPython does not promise that the __del__ method of any object will > be called, so is not assured that the finalized will call close(): Ahh, I didn't know that. This might be another good reason to add a warning about the risks of not ensuring closure yourself: others might have the same gap in knowledge I had, and assume the docs are saying that things will be taken care of by garbage collection on exit when they will not. But you of course cannot document every possible problematic situation users could put themselves in, so I leave it up to your judgment whether or not it's worth it in this case. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38501> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
