[Python-Dev] SocketServer and UserDict patches

Guido van Rossum guido@digicool.com
Tue, 10 Apr 2001 09:19:33 -0500


> I'd like to call your attention to two small patches that i would
> like to check in for the 2.1 RC.  They're small, but they correct
> breakages that i think are worth fixing.
> 
> 1.  UserDict.get(), .update(), and .setdefault()
> 
> https://sourceforge.net/tracker/?func=detail&aid=413171&group_id=5470&atid=305470
> 
>     These three methods are currently implemented by calling the
>     underlying object's .get(), .update(), or .setdefault() method.
>     This is bad because a UserDict that overrides __getitem__ now
>     will have an inconsistent or failing get() method.

I agree with the gist of this -- it should have been done the way you
propose.

>     A glaring example of this is cgi.SvFormContentDict.  For such
>     an object x, x['spam'] returns a single item but x.get('spam')
>     returns a list of one item!

But can you guarantee that fixing this so late in the release cycle
won't break anybody's code?

>     Instead, these three methods should be implemented in terms of
>     the object's own __getitem__, __setitem__, and has_key methods.
>     This patch makes this change.

I'm reluctant (-0) to making this change now.

> 
> 2.  SocketServer.StreamRequestHandler
> 
> https://sourceforge.net/tracker/?func=detail&aid=415111&group_id=5470&atid=305470
> 
>     The setup() method here duplicates the socket twice (once to
>     make a read-only file, once to make a write-only file).  That
>     yields three descriptors, but finish() closes only two.  This
>     causes my browser to hang indefinitely waiting for the socket
>     to close when SimpleHTTPServer is used to deliver a small page.
> 
>     This patch adds self.connection.close() to setup() so that
>     there are just two descriptors to worry about.

I don't think this is the right solution.  A principle I like very
much to keep my head clear about closing files is "whoever opens it
closes it".  The request/connection socket is created by a different
class, so should really be closed there.

--Guido van Rossum (home page: http://www.python.org/~guido/)