[Web-SIG] Pre-PEP: Python Web Container Interface v1.0

[Phillip J. Eby]

At 10:05 AM 12/8/03 -0500, A.M. Kuchling wrote:
>On Mon, Dec 08, 2003 at 09:55:02AM -0500, Phillip J. Eby wrote:
> > For example, suppose that a threaded container wishes to configure, 
> instead
> > of one application object, a factory for returning new application 
> objects,
> > so that there is no threading problem?  I think that a premature attempt to
>
>Only the application knows if it can handle threads, though; if there's some
>unthreaded global cache, creating new application objects is not going to
>make everything threadsafe.

My point is that no matter what, if you use a container, you have to 
configure it with a bunch of other facts about your application.  So, you 
might as well explicitly configure any threading-related settings in their 
*native form*.  That is, whatever threading settings the *container* has, 
whatever they might be.  Making the app or framework declare their safety 
through a narrow interface on the application object seen by the container 
incurs needlessly "lossy" transfer of information.

So, IMO, threading configuration should be part of container configuration, 
not part of the application interface.


>   I don't use threads and think their use is
>brain-damaged 95% of the time,

+1.


>so I don't really care if there's a
>thread-safety mechanism in the spec or not.

And I actively *don't* want it, because it will interfere with the ability 
of container authors to add support for this interface, especially if they 
*do* support threading now.