On Fri, 25 Mar 2011 21:10:08 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: > On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman <v+python at 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. Making an API TLS-based means your code breaks mysteriously if you start offloading tasks to separate threads (which is quite common with network-related tasks). Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4