Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Results object #152

Open
samaloney opened this issue Apr 8, 2024 · 3 comments
Open

Refactor Results object #152

samaloney opened this issue Apr 8, 2024 · 3 comments
Labels
enhancement A new feature or other enhancement to the library good first issue help wanted

Comments

@samaloney
Copy link
Contributor

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)
    ...
@Cadair
Copy link
Owner

Cadair commented Apr 8, 2024

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.

@samaloney
Copy link
Contributor Author

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.

@Cadair
Copy link
Owner

Cadair commented Apr 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A new feature or other enhancement to the library good first issue help wanted
Projects
None yet
Development

No branches or pull requests

2 participants