On Tue, 29 Jan 2013 01:17:35 +0100 Ralf Schmitt <r...@systemexit.de> wrote: > Guido van Rossum <gu...@python.org> writes: > > > > > On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt <r...@systemexit.de> wrote: > > > >> Guido van Rossum <gu...@python.org> writes: > >> > >> > Yeah, so the answer to all this is that 3rd party libraries know better > >> > than to mess with global settings. > >> > >> Right. But why make it configurable at runtime then? If you're changing > >> the value, then you're the one probably breaking third party code. > > > > Sigh. This is getting exasperating. There's other code that might want to > > change this besides 3rd party library code. E.g. app configuration code. > > So, third party library code should know better, while at the same time > it's fine to mess with global settings from app configuration code.
Yes, it's fine, because an application developer can often control (or at least study) the behaviour of all the code involved. It's the same story as with logging configuration and similar process-wide settings. Libraries shouldn't mess with it but the top-level application definitely can (and should, even). (and if you think many third-party libraries call fork()+exec() as part as their normal duty, then I've got a bridge to sell you) Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
