Publicly expose `AsyncIOWrapper`

[CoolCat467]

This PR exposes _file_io.AsyncIOWrapper to the public. I was working on a project of mine that has to use trio.wrap_file and calls a few functions that needed to take the returned AsyncIOWrapper object as a parameter, but when typing arguments for said functions I found that AsyncIOWrapper is not exposed publicly and the only way to type it properly would be to manually reach in to trio._file_io and get it.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (05c5df2) 99.64% compared to head (f8f0018) 99.64%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2864   +/-   ##
=======================================
  Coverage   99.64%   99.64%           
=======================================
  Files         116      116           
  Lines       17503    17504    +1     
  Branches     3148     3149    +1     
=======================================
+ Hits        17441    17442    +1     
  Misses         43       43           
  Partials       19       19           

Files	Coverage Δ
src/trio/__init__.py	100.00% <100.00%> (ø)
src/trio/_file_io.py	100.00% <100.00%> (ø)

[CoolCat467]

How do I fix the errors test_static_tool_sees_class_members has? The big blob it prints out is of no help on resolving whatever the issue is and I keep getting confused when I encounter these sorts of issues and what to even do to attempt to fix said reported issues.

[A5rocks]

Probably similar to what you did for the dir thing!

[TeamSpen210]

Would it be a good idea to expose this? The way it works is kinda complicated, and I imagine we might need to change those hints at some point - exposing it means we're saying it's a more stable API. Also users using it as a type hint means they don't accept any "native" file classes. Like the synchronous IO, it'd be better to define a protocol at the place you use it, with the methods you need.

[CoolCat467]

Would it be a good idea to expose this? The way it works is kinda complicated, and I imagine we might need to change those hints at some point - exposing it means we're saying it's a more stable API. Also users using it as a type hint means they don't accept any "native" file classes. Like the synchronous IO, it'd be better to define a protocol at the place you use it, with the methods you need.

Did you read my usage case? I am trying to specifically handle asynchronous file objects in a function's arguments, and I have to resort to reaching into the internals of trio to type it properly, which I think is unacceptable. I am not intending on handling native synchronous file IO at all, only the async version.

[TeamSpen210]

Yep, what I mean is that you should define a protocol, only include the methods you need, then annotate the function as accepting that. Then a class that doesn't inherit from the wrapper but does define appropriate methods will work.

[CoolCat467]

Probably similar to what you did for the dir thing!

I'm blanking on this, not remembering what you are referring to by this

[A5rocks]

Sorry, I just misread https://github.com/python-trio/trio/pull/2864/commits/a0f58eaffbe46636716beea8b6f887dafc4e8a72