On Wed, Dec 13, 2006 at 10:00:48PM +0100, "Martin v. L?wis" wrote:
> Personally, I think very elaborate support for HTTP in httplib, and very
> few generalizations and abstractions in urllib* would be the "right"
> way to do it, IMO. For example, there might be the notion of an
> "http session" object where a single application request can resolve
> to multiple http requests (with redirection, authentication negotiation,
> cookies, 100 continue, implicit headers, etc).
I see.
> For compatibility, urllib* can't drop features
Leave it for py3k, then.
> and we'd need
> contributors who contribute such a refactoring
That's the hardest part.
> If applications use urllib *only* for http, and
> *only* because it has these multi-request, implicit headers
> features, something is wrong with the abstractions.
I think I agree.
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
