Better error messages for accidentally adding/forgetting an "async"?

[njsmith]

We should go through our (async) context managers and (async) iterators and make sure they give helpful error messages if you accidentally write async where you shouldn't or vice-versa.

[njsmith]

Hmm, I'm not sure whether I still agree with this. It hasn't been something people have complained about much (for whatever that's worth – we don't always hear when people have trouble with something, but sometimes we do). And there is a potential downside, because defining a protocol just so you can raise an error can still confuse tools like MyPy or attempts to sniff out protocol support using hasattr.

Also, you can only do this when you implement the (async) context manager or iterator protocol manually, rather than using the idiomatic @(async)contextmanager or (async) generators. And usually it's good to use idiomatic tools! You wouldn't want to avoid using those just for this. And probably people will encounter lots of objects that are defined using those tools, so will have to learn how to cope with forgetting async anyway.

I did a quick look. Of our manually-defined context managers:

• trio._util.ConflictDetector, trio.testing._check_streams._ForceCloseBoth are internal so don't matter here
• CancelScope doesn't give a nice error on __aenter__... maybe it should?
• NurseryManager does have an __enter__ that gives a nice error... probably worth it, since we don't want people to get confused by this when they're first getting started and trying to wrap their head around the nursery concept
• AsyncResource doesn't have __enter__... I guess it could?
• SocketType doesn't have __aenter__... this seems like overkill for a low-level API like this
• the stuff in trio._sync (Lock, Semaphore, etc.) doesn't have __enter__... could be overkill again maybe
• MultiErrorCatcher doesn't have __aenter__... meh, I don't care

For iterators: we have several manually defined async iterators (AsyncFileWrapper, ReceiveChannel, SignalReceiver). None of them have helpful __iter__ methods that raise an error. I guess they could?

Anyone want to weigh in? And I'll remove the good-first-issue while we discuss... (though thanks @bengartner for reminding us about this :-)).

[smurfix]

FWIW, I generally prefer __aenter__/__aiter__to die with an explicit warning when __enter__/__iter__ should be used (and vice versa) rather than relying on Python's built-in errors.

It's generally easier, that way, to figure out quickly what the actual problem is. Otherwise Python complains that there's no __iter__ method on what feels like some random object and you stare at the thing, scratching your head.