On Fri, Mar 25, 2011 at 11:29 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: >> 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). Ah, true - and, as you say, libraries are far more likely to farm networking operations out to threads than they are decimal calculations. Such situations also cause problems for any approaches based on temporary monkey-patching. Still, exploring such ideas and their downsides would be one of the purposes of writing a PEP on this topic. Sprinkling factory function pixie dust everywhere may turn out to be the right thing to do, but the various options should be explored before settling specifically on that one. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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