Refactor Results object

[Shane Maloney]

Currently the results object is a custom UserList which made complete sense when it was just a list of paths but now it has associated urls and errors and these are aren't supported e.g. res = res1 + res2 the path will add as expected but the url/error won't same for other dunder methods.

It might make sense to come up with a a good Result object which could be store in a ResultList or implement the necessary methods?

Just some initial thoughts, could also help address #130

class Result
    def __init__(self, * path, url, error=None, retry_count=None, last_retry=None):


class ResultList(UserList)
    ...

[Stuart Mumford]

I don't think a list of Result objects is the best idea, currently results[0] gives you a path (like a list of paths), and that's a property I would be keen to keep. I agree with the rest of it though, Results is becoming more and more structured.

[Shane Maloney]

That specific aspect could be implemented via the __getitem__? I'm never sure when it's good to have a list of custom objects or an object with lists. I guess I figured it should easier to ensure the path, url and what ever all match up if they are in same object.

[Stuart Mumford]

Yeah, I guess that's true, you could probably make sure most of the API Stoll worked even if the internal representation was list of things. I think I would want that to be almost invisible to the user though.