[Patches] httplib.HTTP.connect raises wrong exception

[Guido van Rossum]

>     Guido> I'm wondering, what mistake were you debugging?  There must be an
>     Guido> actual anecdote associated with your patch.
> 
> Actually, I noticed it while doing a big paste into my own code.  I wanted
> to use the timeout_socket module with httplib.HTTP.  Unfortunately, there's
> no clean way to do that.  If you would like me to modify httplib to make it
> easier to plug in alternatives to the socket module, I'll take a crack at
> it.

Hm...  it seems that there should be an architecture for providing
alternatives to the socket module.  I've never even heard of the
timeout_socket module...

Hacking httplib seems the wrong place to approach this.  What are the requirements?

>     Guido> I would support adding the actual value of the port string to the
>     Guido> error message.  I don't support raising ValueError.
> 
> That's fine (it's an incorrect value, so in my mind is a ValueError, but I
> won't quibble), but I still maintain that if you're not going to raise
> ValueError, httplib should raise its own exception (httplib.error or some
> such), not socket.error.  In particular, at the point in coonect() at which
> the current implementation raises socket.error, no socket module calls have
> even been made.  (Same for the hasattr function later that I originally
> missed.)
> 
> The os module went through a similary change a couple years ago.  If I
> remember correctly, the os module originally did nothing to define its own
> exceptions, so programmers had to catch posix.error on Unix systems and
> something different on other platforms, sort of nixing much of the os
> module's platform independence.  Then you modified it so that the os module
> set its own error object to refer to the underlying module's error object.
> That allowed people to catch os.error and not worry about the underlying
> implementation.  Now I see you've gone one step further and defined an
> OSError standard exception.
> 
> As a compromise, I propose the following change near the top of httplib
> somewhere after socket has been imported:
> 
>     error = socket.error
> 
> Then anywhere httplib raises an error, that should be what it raises.  No
> code that currently catches socket.error will break, and httplib.error can
> be the documented exception used for transmitting errors out of that module.

And all this because you believe that raising some other module's
error is a sin?  I don't have a problem with such behavior -- what's
the reason?

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