Re: [Python-Dev] Proposal for Python 3.3: dependence injection
On Fri, Mar 25, 2011 at 7:22 PM, Simon Cross hodgestar+python...@gmail.com wrote: On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan ncogh...@gmail.com 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. -2. That wouldn't allow one to use normal sockets in one 3rd party library and special sockets in another 3rd party library. Uh, yes it would. One possible implementation is to use exactly the same techniques that are used to implement contexts in the decimal module. 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
Re: [Python-Dev] Proposal for Python 3.3: dependence injection
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
Re: [Python-Dev] Proposal for Python 3.3: dependence injection
On Fri, 25 Mar 2011 21:10:08 +1000 Nick Coghlan ncogh...@gmail.com wrote: 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. 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. ___ 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
Re: [Python-Dev] Proposal for Python 3.3: dependence injection
On Fri, Mar 25, 2011 at 11:29 PM, Antoine Pitrou solip...@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 | 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
