On Wed, 16 Feb 2000, Guido van Rossum wrote:
> > I've been using my HTTP/1.1 httplib for quite a while now. It seems quite
> > stable in everything that I've tried. I need to port over the recent
> > changes for SSL stuff, but it is ready to go.
> >
> > The library contains a deprecated, backwards-compat class (HTTP), and its
> > replacement: HTTPConnection. Responses are now handled through
> > HTTPResponse class.
> >
> > Doc for the new class will also be needed, but (of course) the old doc
> > still applies.
> >
> > Any comments on the module and/or its inclusion into 1.6?
>
> Doesn't Jeremy have one too?
Yes, we talked about it at IPC7. As I recall, Jeremy wasn't happy with the
result... it was request/response based with a lot of helper classes. My
httplib is connection-oriented (like the current httplib), and I think
Jeremy had said that was good (empirically, after his prototype).
But that's just let my memory... Jeremy?
> I would suggest putting the new classes in a new module,
> e.g. httplib2.py, and leaving the old httplib unchanged.
Why? The compatibility class exports the same attributes, the same
methods, the same constructor, etc. Creating a new module is needless
duplication and confusing for users ("which one do I use?" "how is that
one different?" "do I have to switch modules to use HTTP/1.1?")
A single module that reuses code is going to be much more maintainable
than two, possibly diverging, modules. I also feel having one module will
help to gently prod people towards using HTTP/1.1 and the new
HTTPConnection class (which I think is *subjectively* a nice goal).
> BTW, where can we look at this code?
Oops. Sorry about that... As usual, it is with the rest of my Python code
at http://www.lyra.org/greg/python/
(the davlib is there, too)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4