> > IMHO, it is not any framework's job to check for this. It is a > programmer error.
Not clearing the memory is a programmer error either but a gc helps. Not closing a file either but using `with` help. Not passing the proper type is a programmer error but we have type hints. We even have assert that we can be disabled to check that the arguments of a function match a test when debugging. You don't need to babysit programmers so much. Helping to debug is not babysitting. It's a important part of the user experience, and it's especially needed on asyncio, one of the hardest part of the stdlib to code with. Not if the cost is adding new APIs. The cost of bugs is greater than the cost of API. The current API gives no sane way to prevent the bug. You can't expect anyone to check if the policy / loop / task factory has changed every single time in the code you depend on it. > > I agree with Andrew, if we open this precedent, next thing we know, > Python has to provide callbacks for any internal state changes. It's not internal, it's a public API. Why not > callbacks for when modules are imported? Good example. We have import hooks to run code every time a module is imported : https://www.python.org/dev/peps/pep-0302/#specification-part-2-registering-hooks Etc. etc. It leads to API > noise. Every features is either useful or noise. I argue that this one is useful. Doesn't seem to be justified in this case, since I would guess > almost all applications only change event loop policy once, during > startup, and never again. Yes, but when is start up ? E.G: I'm currently working on a large QT api on an old 2.7 code base. It has threads to avoid blocking the UI, qt events loops of course and the tornado events loop providing a web API. The orchestration of that very complex app requires careful initialization for a start up time of about 7s, and we had to code some wrapper and document it as the only entry point to make sure that if a junior breaks things the error message is very clear. RuntimeError('The event loop should not be set when...') is way easier to debug than an obscure down the road error on some data structure that is incorrectly accessed. What I'm proposing is to make that easy to implement by just letting anyone put a check in there. Overriding policy, loops or tasks factories are usually down for critical parts of the system. The errors emerging from a bug in there are very cryptic. Asyncio design made the choice to expose very low level things. You literally don't have this problem in languages like JS because nobody can change those. Now it's here, it's a footgun, and it would be nice to provide a way to put it in a holster. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
