Alex Waygood comments

Results 861 comments of


                                            Alex Waygood

require Generator for `contextmanager`

> the case I had would not have been detected by that -- it returned an iterable from another function call. I think this really needs type checkers to do...

Use Callable[..., Any] instead of Callable[..., object] in unittest

Thanks for the PR. I'd like to know what other maintainers think here, but I'm somewhat unhappy with this change tbh, and I'd like to sink some time into trying...

Use Callable[..., Any] instead of Callable[..., object] in unittest

I am fine with merging this, since none of us has yet managed to find a mypy fix, and given that this now only changes the unittest functions.

Use Callable[..., Any] instead of Callable[..., object] in unittest

> What makes unittest special here? Well, the ones in unittest _have_ caused a known problem for somebody. That hasn't been shown for any of the other stdlib functions.

Use Callable[..., Any] instead of Callable[..., object] in unittest

> I'm still opposed to this. At this point I don't think we should regress our stubs due to type checker bugs that can be worked around with "# type:...

Use Callable[..., Any] instead of Callable[..., object] in unittest

> > regress our stubs > > Can you explain how this would be a regression? IIUC Any and object are functionally identical here. Reintroducing `Any` instead of `object` _would_...

Use Callable[..., Any] instead of Callable[..., object] in unittest

I don't think we'll be merging this — @srittau opposes it, and I don't think any other maintainers are going to come forward to argue in favour of it. Sorry...

Use Callable[..., Any] instead of Callable[..., object] in unittest

> One idea I have is to merge this and just create the reverting PR already, marking it as "deferred". This would mean that there's less chance we forget if...

Use Callable[..., Any] instead of Callable[..., object] in unittest

Merged! PR to revert is here: #8779. Thanks for your patience @ShaneHarvey :)

Is there a good reason why `Mapping.contains` expects `object`, but `Mapping.get` expects a strict type?

This is a similar issue to #6597, though it comes at it from the opposite direction