On Sun, 12 Aug 2018 at 00:50, Stefan Behnel <stefan...@behnel.de> wrote: > > Petr Viktorin schrieb am 10.08.2018 um 13:48: > > Would this be better than a flag + raising an error on init? > > Ok, I've implemented this in Cython for now, to finally move the PEP-489 > support forward. The somewhat annoying drawback is that module reloading > previously *seemed* to work, simply because it didn't actually do anything. > Now, people will get an exception in cases that previously worked silently. > An exception would probably have been better from the beginning, because it > clearly tells people that what they are trying is not supported. Now it's a > bit of a breaking change. I'll see what it gives.
If the breakage turns out to cause problems, some potential ways to mitigate it would be: 1. Emulate the old "extension modules are singletons" behaviour in the module creation slot, and only emit a deprecation warning when it gets called multiple times rather than failing outright. 2. As for 1, but error out when the active interpreter changes (that will let a module support reloading, while explicitly erroring out if you attempt to load it from multiple subinterpreters) Both of those would need some level of PEP 3121 support to clear out the singleton state when the module gets outright destroyed, but they'd still provide a middle ground between the ill-defined behaviour of single-phase initialisation and full-fledged support multiple concurrently loaded independent copies of the same extension module. Under that interpretation, the required clarification in PEP 489 would be to replace the term "supports" with "has clearly defined and documented behaviour", and then make it clear that that defined behaviour is allowed to be "Fails with an exception explaining the limitation", or "manages some internal state as a process-level singleton". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
