On 02:52 pm, 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.)
Something like it, yea. Although please do not expose a tuple subclass publicly (in fact, if you could get rid of that tuple subclass while working on this, I don't think it would hurt. :)
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.
Yes. I wish the API had been more well considered before being exposed publicly.
And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?
The object we expose now should be forward compatible with the future perfect IRI object so that we can replace it with the IRI object when that is ready. Jean-Paul