Andrey Petrov

Yea sounds like a decent low-level interface, we can always add more abstractions on top of it.

> (A side note: we can also handle trailers, which are headers that come after a chunked body has been received. Right now they're just transparently merged with the original...

So they would not be combined? I guess that can work. On Aug 11, 2014 11:30 AM, "Ian Cordasco" [email protected] wrote: > Maybe combined headers live in .headers, and then...

How does excluding work if there are duplicates? I'd keep them separate. Maybe have a combined one in addition, either way. On Aug 11, 2014 12:52 PM, "Ian Cordasco" [email protected]...

There will always be that one edge case where having the original format is meaningful. Be careful mangling the returned data too much, lest your code turns into httplib. :p...

+1, have higher level libs merge them. On Tue, Aug 12, 2014 at 8:30 AM, Ian Cordasco [email protected] wrote: > I think that API seems best. > > — >...

From my experience dealing with threads (largely with workerpool and urllib3's dummyserver), it's nothing short of a disaster. It's almost impossible to make a Python _library_ spawn its own thread...

We talked about `hyper` having a layer which acts as a drop-in replacement for `httplib`. That would be easiest to transition with. If I recall the scope for `hyper` right...

> The drop-in replacement layer is on the table, and is the interface I would expect urllib3 to use. Would be neat if this compatibility layer automagically chose whether to...

Yea, not sure how much work/complexity this kind of abstraction would involve. If you'd like a more incremental approach, I'd be open to having a separate (or configurable) non-default `PoolManager`...