On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman <v+pyt...@g.nevcal.com> wrote: > On 3/24/2011 4:25 PM, Nick Coghlan wrote: > > As an example of the last point, perhaps rather than modifying all the > *clients* of the socket module, it may make more sense to have tools > in the socket module itself to temporarily customise the socket > creation process in the current thread. The advantage of such an > approach is that it would then work for 3rd party libraries that > create sockets, without requiring any further modification. > > Would be easier to implement that way, not requiring changes to every client > of the socket library, but in some circles that would be called "action at a > distance", and harder to understand.
Oh, it is definitely action at a distance, and quite deliberately so. My model for the suggestion is the context objects in the decimal module. They offer a constrained way to affect the way the entire decimal module goes about its business, and through judicious use of thread local storage and context managers, allow this to be done without distorting the public API of the decimal objects themselves. There's no reason a solution along those lines wouldn't work for the socket module, or any other API that would similarly benefit from providing a mechanism for applications to indirectly control library behaviour without resorting to monkey-patching. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
