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

Do not require running loop with CookieJar constructor? #3724

Closed
blueyed opened this issue May 2, 2019 · 2 comments
Closed

Do not require running loop with CookieJar constructor? #3724

blueyed opened this issue May 2, 2019 · 2 comments

Comments

@blueyed
Copy link
Contributor

blueyed commented May 2, 2019

CookieJar.__init__ requires a running loop in the constructor, but that is only needed/used for expiration.

I think the loop should still get passed in, but not required to be running (checked via get_running_loop in AbstractCookieJar), and only retrieved when during expiration (via a property maybe?).

This would make it less difficult to debug issues with it / prototyping - where getting a loop is always a bit cumbersome.

Code reference:

def __init__(self, *, unsafe: bool=False,
loop: Optional[asyncio.AbstractEventLoop]=None) -> None:
super().__init__(loop=loop)
self._cookies = defaultdict(SimpleCookie) #type: DefaultDict[str, SimpleCookie] # noqa
self._host_only_cookies = set() # type: Set[Tuple[str, str]]
self._unsafe = unsafe
self._next_expiration = ceil(self._loop.time())
self._expirations = {} # type: Dict[Tuple[str, str], int]

@asvetlov
Copy link
Member

asvetlov commented May 2, 2019

What is your real use case?

@blueyed
Copy link
Contributor Author

blueyed commented May 2, 2019

Prototyping to look how it (mis)behaves (#2502 (comment)).
So not really a real-world use case, but thought it could be made simpler to use in this regard.

Feel free to close this though - I can also see that using a property etc would make it more complicated code-wise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants