pathlib.Path-alike no longer works in 3.9.0 for web.FileResponse about aiohttp HOT 4 OPEN

If you'd like to make a PR to revert that section and include a test that exhibits the problem, we can probably include it.
I'm still not entirely clear why this fails though, I'm curious what the subclass does that breaks when converting to a Path.

from aiohttp.

If you'd like to make a PR to revert that section and include a test that exhibits the problem, we can probably include it.

I created a draft PR. It needs some more thought and work. It just reverts the change, but that is not right solution because it also reverts support for all os.PathLike. It would need to create a pathlib.Path for those that are os.PathLike, but not already compatible with pathlib.Path.

I'll probably add @runtime_checkable to the PathlibPathLike or some hasattr calls to see if the passed object has required pathlib.Path attributes before using it as is.

I'm still not entirely clear why this fails though, I'm curious what the subclass does that breaks when converting to a Path.

The subclass of pathlib.Path replaces stat and open such that it can make the response without the file being on filesystem. The file is created in-memory and having to write it to filesystem just to make a response is pointless. pathlib.Path fails since it can not find it on the filesystem.

from aiohttp.

I use web.FileResponse to respond with a file that is not really on the disk. This is done with a Path instance that implements the pathlib.Path interface.

What's the actual data? Are you opening a file and just want to keep it open? It would not be terribly difficult to allow the constructor to also accept a file object, in particular an instance of BufferedIOBase. The user would just also have to provide the content type since that is guessed from the file extension.

from aiohttp.

What's the actual data? Are you opening a file and just want to keep it open? It would not be terribly difficult to allow the constructor to also accept a file object, in particular an instance of BufferedIOBase. The user would just also have to provide the content type since that is guessed from the file extension.

It is not a file at all. It is in-memory generated media data that changes infrequently and has timestamp and content-type from the extension. I like to use the implementation of RFC 7232 and RFC 7233 that is in FileResponse.

from aiohttp.