On Sat, Mar 16, 2013 at 7:52 AM, Jonathan Jacobs <jonathan+twisted@jsphere.com> wrote:

On Sat, Mar 16, 2013 at 3:49 PM, <exarkun@twistedmatrix.com> wrote:

However, there's no reason we can't have an object that
represents an IRI *without* writing a parser for all those forms. Agent
only needs minimal functionality of being able to figure out the
hostname, port number, and whatever makes up the rest.

Isn't this currently called twisted.web.client._URL? (Although _URL still needs some more data to fill this role.)

I do like this idea, although I keep coming back to wondering how we provide this to Request initially, an additional parameter was not received with much enthusiasm on IRC. It would be unfortunate if Request.uri is going to mean "the relative URI" forever.

An additional attribute is not ideal... but it's better than changing an existing attribute's contents, which is *really* backwards incompatible. It's probably too late for the ideal solution anyway, let's just get a decent one done.

And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?

Or just IRI.fromString() or something.

Why don't you start coding, and we can then talk about actual implementation details? It's going to be pretty short, so any review comments should hopefully not take too long to address.