[MERGE][bug 147530] pycurl http implementation peeks under the covers

Vincent Ladeuil v.ladeuil+lp at free.fr
Mon Oct 1 16:40:02 BST 2007


>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:

    john> Vincent Ladeuil wrote:
    >> Old versions of pycurl didn't define symbols for error codes. Our
    >> pycurl http implementation worked around it by defining error
    >> codes copied from curl.h
    >> 
    >> New error codes have been added in recent version of curl and
    >> pycurl.
    >> 
    >> The associated patch provides a better way to define the error
    >> codes we care about while retaining compatibility with older
    >> versions.
    >> 
    >> Vincent
    >> 
    >> 
    >> 

    john> ...

    >> +
    >> +def _get_pycurl_errcode(symbol, default):
    >> +    """
    >> +    Returns the numerical error code for a symbol defined by pycurl.
    >> +
    >> +    Different pycurl implementations define different symbols for error
    >> +    codes. Old versions never define some symbols (wether they can return the
    >> +    corresponding error code or not). The following addresses the problem by
    >> +    defining the symbols we care about.  Note: this allows to define symbols
    >> +    for errors that older versions will never return, which is fine.
    >> +    """
    >> +    return pycurl.__dict__.get(symbol, default)
    >> +
    >> +CURLE_SSL_CACERT_BADFILE = _get_pycurl_errcode('E_SSL_CACERT_BADFILE', 77)
    >> +CURLE_COULDNT_CONNECT = _get_pycurl_errcode('E_COULDNT_CONNECT', 7)
    >> +CURLE_COULDNT_RESOLVE_HOST = _get_pycurl_errcode('E_COULDNT_RESOLVE_HOST', 6)
    >> +CURLE_COULDNT_RESOLVE_PROXY = _get_pycurl_errcode('E_COULDNT_RESOLVE_PROXY', 5)
    >> +CURLE_GOT_NOTHING = _get_pycurl_errcode('E_GOT_NOTHING', 52)
    >> +CURLE_PARTIAL_FILE = _get_pycurl_errcode('E_PARTIAL_FILE', 18)
    >> +
    >> +
    >> register_urlparse_netloc_protocol('http+pycurl')
    >> 

    john> I'm fine with using the _get_pycurl_errcode as you have done here. But I
    john> would rather see it done in a separate file.

    john> I would also think that error codes aren't something that you can change
    john> much. So having them hardcoded isn't a terrible thing.

    john> Anyway, you could probably put all of this into _pycurl_errors.py, and
    john> just use a simple regex substitution to turn them all into _get_* functions.

    john> Something like:

    john> s/CURL(E_.*) = (\d+)/CURL\1 = _get_pycurl_errcode('\1', \2)/

Well, I went that route for the following reasons:

- looking at http://cool.haxx.se/cvs.cgi/curl/include/curl/curl.h
  I realized more tweaking was to come (deletion of some error
  codes notably),

- from above, we can't have a unique fully-compliant-with curl.h
  definition (even with my proposed _get_pycurl_errcode),

- it's now a race between curl and when we drop pycurl support ;-)

- these errors codes should not be used outside of _pycurl.py
  (the abstraction level just above is HttpTransportBase), and
  indeed, so far they have been used only there. Why a different
  file ?

- keeping them in the same file and defining only those that are
  used seems to minimize the risks of another regression.

Thoughts ?

         Vincent



More information about the bazaar mailing list