You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, while trying out the ftpfs, I've noticed that to open a binary file-like object for writing by some third-party packages I have to do this:
with open_fs("ftp://anonymous:anonymous@localhost:8021") as fs:
with fs.openbin("test.bin", "wb") as f:
...
Note in the above the mode param used in openbin includes b: Looking at the docs for the mode param it suggests the b is implied via openbin, but b isn't implicitly added to the mode of the file-like that is returned by openbin - this means that, unless b is explicitly provided as above, third-party packages that inspect the mode of the file-like may complain that it is not opened in binary mode.
Should openbin not reflect the implied b by implicitly adding b to the mode?
Yes, I was thinking of mentioning use of to_platform_bin in a similar manner.
I guess another way of putting the question is that, given the "b is implied by openbin" in the docs, then for a file f opened via it should "b" in f.mode hold true? Sounds almost like a unit test...
The base class only guarantees that openbin will return a BinaryIO, which doesn't contain a "mode" attribute. Only the io.FileIO class can be sure of having mode.
So it would be a mistake to assume that all file-like objects have a "mode" attribute. But people do write broken code because they make reasonable assumptions and the specifications are too difficult to understand, so perhaps it would be a good idea for ftp files to add a mode attribute.
so perhaps it would be a good idea for ftp files to add a mode attribute.
The FTPFile object does have a mode attribute - the issue I'm bringing up is that if the FTPFile instance comes from a call to openbin then the mode within it will not contain b, unlessb was explicitly supplied in the call to openbin.
I think a solution to this, similar to the previous note about osfs, would be to have the final two lines of openbin look more akin to this:
Actually, it is reasonable to expect FS.openbin to return an object with a mode attribute (containing a "b" flag), since it all filesystems are doing it but FTPFile and _MemoryFile. I patched them in #435
Activity
lurch commentedon Jun 24, 2020
Yeah, perhaps FTPFS should also be doing this? https://github.com/PyFilesystem/pyfilesystem2/blob/master/fs/osfs.py#L360
al8ba commentedon Jun 24, 2020
Yes, I was thinking of mentioning use of
to_platform_binin a similar manner.I guess another way of putting the question is that, given the "
bis implied byopenbin" in the docs, then for a filefopened via it should"b" in f.modehold true? Sounds almost like a unit test...willmcgugan commentedon Jun 24, 2020
The base class only guarantees that
openbinwill return a BinaryIO, which doesn't contain a "mode" attribute. Only theio.FileIOclass can be sure of having mode.So it would be a mistake to assume that all file-like objects have a "mode" attribute. But people do write broken code because they make reasonable assumptions and the specifications are too difficult to understand, so perhaps it would be a good idea for ftp files to add a mode attribute.
al8ba commentedon Jun 24, 2020
The
FTPFileobject does have a mode attribute - the issue I'm bringing up is that if theFTPFileinstance comes from a call toopenbinthen the mode within it will not containb, unlessbwas explicitly supplied in the call toopenbin.I think a solution to this, similar to the previous note about osfs, would be to have the final two lines of
openbinlook more akin to this:althonos commentedon Oct 13, 2020
Actually, it is reasonable to expect
FS.openbinto return an object with amodeattribute (containing a "b" flag), since it all filesystems are doing it butFTPFileand_MemoryFile. I patched them in #435