Oleg Broytmann schrieb: > HTTP is one of the most widely known and used protocol. Would you better > have big httplib and small abstract urllib? so abstract it doesn't allow a > user to change protocol-specific handling?
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). For compatibility, urllib* can't drop features, and we'd need contributors who contribute such a refactoring, but IMO that would be the right way. If applications use urllib *only* for http, and *only* because it has these multi-request, implicit headers features, something is wrong with the abstractions. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
