Fix Local behaviour with asyncio Task.

[spanezz]

Reproduce issue #473 in asgiref's test suite

Fixes #473

[carltongibson]

@spanezz That looks like a good port of the test 👍

[carltongibson]

Thanks @spanezz 👍

The type hints need adjusting to keep mypy happy. (See CI)

I had a glance at the different commits, but will try and reason them through this week.

[carltongibson]

@spanezz I had a quick look. Both of these make sense. Not sure if I prefer one or the other. Option 1 is less of a change.

Can you fix the CI, and perhaps squash the last two commits together so that option 1 and option 2 are obvious for @andrewgodwin to look at?

[spanezz]

@spanezz I had a quick look. Both of these make sense. Not sure if I prefer one or the other. Option 1 is less of a change.

Can you fix the CI, and perhaps squash the last two commits together so that option 1 and option 2 are obvious for @andrewgodwin to look at?

I made an attempt. I don't seem to be able to run the CI myself, so hopefully it won't take too many iterations to get right.

I'd defer fixing things like Local being changed from a class to a function, until it's decided if that's what's wanted

[carltongibson]

@spanezz You can run the type checker locally by doing (e.g.) tox -e py311-mypy.

OK, everything passes with 16d4ae2 Option 1. Can I ask you to pull 7b3ce47 Option 2 into a separate PR (after this one, I guess).

I think we should go with Option 1 now, and release a v3.8.2 to fix the issue, and then we can consider whether Option 2 is worth adopting for a v3.9 at a more leisurely pace. //cc @andrewgodwin

I closed #477 which had the self._data.set({**self._data.get({}), key: value}) option.

[spanezz]

@spanezz You can run the type checker locally by doing (e.g.) tox -e py311-mypy.

Thank you for the pointer! I am uncomfortable running code randomly downloaded off the internet on my devel machine, and I'm unfortunately not equipped with a suitably containerized alternative.

OK, everything passes with 16d4ae2 Option 1. Can I ask you to pull 7b3ce47 Option 2 into a separate PR (after this one, I guess).

I think we should go with Option 1 now, and release a v3.8.2 to fix the issue, and then we can consider whether Option 2 is worth adopting for a v3.9 at a more leisurely pace. //cc @andrewgodwin

I closed #477 which had the self._data.set({**self._data.get({}), key: value}) option.

Done (I removed the simplification commit from this PR and opened #481)

[andrewgodwin]

This definitely seems like a pretty clean change and easier to understand than the bigger rewrite, so let's get this in.

I removed the python 3.8 tests from main - if you want to rebase on top of that so we get a clean sweep, I'm happy to merge this.

[spanezz]

This definitely seems like a pretty clean change and easier to understand than the bigger rewrite, so let's get this in.

I removed the python 3.8 tests from main - if you want to rebase on top of that so we get a clean sweep, I'm happy to merge this.

Thanks, and done!

[andrewgodwin]

Thanks!

[andersk]

This seems to have caused a regression:

• RuntimeError: CurrentThreadExecutor already quit or is broken #491

[codingcatgirl]

It looks to me like the implementation of __delattr__ in this change now deletes the key from all contexts and not just the currently active one. This does not seem to be the intended behavior to me?