LocalFS.open() uses blocking open() inside async def — intentional design or oversight?

[Joaquinriosheredia]

Hi,

While analyzing asyncssh with python-vibe-guard, I noticed that
LocalFS.open() in asyncssh/sftp.py is defined as async def
but uses the synchronous open() builtin internally:

@async_context_manager
async def open(self, path: bytes, mode: str,
               block_size: int = -1) -> LocalFile:
    file_obj = open(_to_local_path(path), mode)
    ...
    return LocalFile(file_obj)

In a server handling multiple concurrent SFTP clients on the same
event loop, each call to LocalFS.open() blocks the loop for the
duration of the file open syscall — particularly noticeable on slow
or network-mounted storage.

I wanted to ask before assuming this is a bug: was this a deliberate
design decision (e.g. LocalFS is not intended for high-concurrency
scenarios), or would a fix using asyncio.get_event_loop().run_in_executor()
or aiofiles be welcome?

Tool used: python-vibe-guard —
AST-based runtime anti-pattern scanner validated on 902 real repositories.

[ronf]

This was a deliberate decision, as one of the original goals of AsyncSSH was to handle a much larger number of simultaneous sessions by taking advanced of coroutines rather than using threads the way many other packages do. There is limited support in AsyncSSH already for aiofiles, but the application developer has to choose whether to use synchronous file objects or an aiofiles object when doing something like IO redirection. That support hasn't been extended to SFTP yet, but if I did add SFTP support I'd want it to be something that had to be specifically requested by the caller, defaulting to synchronous.

In my experience, the open() calls (and even read() and write()) don't really block the event loop for long enough to matter, and the overhead of something like an executor would probably do more harm than good, at least when dealing with locally mounted filesystems. Are you doing something with network volumes that is triggering a significant delay?