This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jjlee
Recipients amak, facundobatista, jjlee
Date 2008-03-30.16:28:20
SpamBayes Score 0.0006033574
Marked as misclassified No
Message-id <1206894509.94.0.171092132579.issue2451@psf.upfronthosting.co.za>
In-reply-to
Content
I've attached a patch.

My patch introduces one minor issue: it's an inconvenience when wrapping
objects if special default values like socket._GLOBAL_DEFAULT_TIMEOUT
are not public.  However, I think it's not worth making that special
value public in this case, because it's not needed by code that does not
support the socket.getdefaulttimeout() global default timeout.


Patch description
-----------------

 * Change the timeout arguments that were introduced with Facundo's 2.6
timeout changes so that they have the same meaning as the argument of
socket.socket.settimeout() .  Specifically, None means "no timeout"
(previously, there was no way to request that), and there is no special
public timeout value meaning "use the global default
socket.getdefaulttimeout() value" (previously, you could pass None to
request that).  This affects socket, urllib2, urllib (only
urllib.ftpwrapper, for urllib2's benefit, urllib public interface and
behaviour is unchanged), httplib, ftplib, telnetlib, poplib, and smtplib.

 * Fix a test bug: test_urllib2net changed global state by calling
urllib2.install_opener(), which interfered with other tests.

 * In tests, where possible, close sockets by calling high-level methods
(e.g. call ftplib.FTP.close(), rather than poking into the object's
internals to .close() the socket directly).

 * Inconsistent defaulting behaviour in telnetlib was introduced with
the timeout changes (r54608).  Made timeout behave like port in terms of
defaulting behaviour.

 * Improve socket.create_connection() documentation.  Some of these
changes need to be propagated to the individual protocol modules that
call this function (e.g. httplib).

  - Document return value

  - Be more PEP 8-compliant ("Connect to...", not "Connects to...")

  - Remove this sentence, since it seems out of place in API
documentation and unlikely to be true: "Especially useful for
higher-level protocols, it is not normally used directly from
application-level code."

  - Reword to remove any doubt that the timeout applies to (almost) all
blocking operations, not just .connect()

  - Rephrase timeout parameter description for better English style.

  - Note that create_connection() is a convenience function (rather than
part of the thin wrapper around the C API).

  - Make the docstring for create_connection() match the official reST
API docs.


Unresolved issues with the new 2.6 timeout functionality
--------------------------------------------------------

 * http://bugs.python.org/issue2452

 * I did not propagate the changes to socket.create_connection() docs to
all the protocol modules (httplib, etc.).  Probably this change should
be committed separately -- I ran out of time.

 * References in the docs to "the global default timeout setting" are
vague.  They should specifically refer to socket.getdefaulttimeout() . 
This should be done in such a way as to also fix the lack of
documentation of the None special value in the protocol modules
documentation (httplib, etc.).  I should have fixed that as part of this
patch, but ran out of time -- sorry!

 * Inconsistency: CacheFTPHandler has per-handler timeout, per-request
timeout is ignored!  Doc/library/urllib2.rst says (in two places):

"""This actually only work for HTTP, HTTPS, FTP and FTPS connections."""

That's not true. (What about CacheFTPHandler, for instance?)  It's also
unclear why it refers to *connections* rather than URL schemes, handler
classes, and the network operations they perform.  (there's also a
little grammatical error here -- s/work/works/)

 * API weirdness: Only some, special, urllib2.Request objects may be
passed to handlers, because the constructor does not create objects with
a .timeout.  Should it really be per-request anyway (I'm not sure)?
History
Date User Action Args
2008-03-30 16:28:30jjleesetspambayes_score: 0.000603357 -> 0.0006033574
recipients: + jjlee, facundobatista, amak
2008-03-30 16:28:30jjleesetspambayes_score: 0.000603357 -> 0.000603357
messageid: <1206894509.94.0.171092132579.issue2451@psf.upfronthosting.co.za>
2008-03-30 16:28:28jjleelinkissue2451 messages
2008-03-30 16:28:26jjleecreate