Natasha15030003 / pyfilesystem

Automatically exported from code.google.com/p/pyfilesystem
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

memoryfs.MemoryFile doesn't respect open mode #113

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
After doing:
"from fs.memoryfs import MemoryFS
memfs = MemoryFS()
memfs.open('test', 'w').write('contents')"
either of these one-line examples will work:
"memfs.open('test', 'r').write('more')"

"memfs.open('test2', 'w').read()"

What is the expected output? What do you see instead?
I'd expect them to raise an exception - you shouldn't be able to write to files 
opened in 'r' mode, or read from files opened in 'w' mode. No exception is 
currently raised, even though MemoryFile /does/ store the file's open mode.

Please use labels and text to provide additional information.
Maybe I'm missing something obvious, and there's a reason for it working this 
way?

Original issue reported on code.google.com by gc...@loowis.durge.org on 10 Apr 2012 at 12:55

GoogleCodeExporter commented 8 years ago
I've never really enforced any kind of semantics on the file object returned by 
open, since for most implementations the file-like object isn't defined in 
PyFilesystem. I wouldn't be surprised if some of the other implementations were 
similarly lax in their handling of this.

I concur it should throw an exception though. But what kind? An IOError would 
be consistent with Python file objects, but seems misnamed for memory files. If 
we define an exception hierarchy for file like objects, we have the problem of 
retro-fitting other file-like objects with the new exceptions -- and that might 
require hacking it in with some kind of proxy object...

I'm open to suggestions. Might be worth bringing it up on the mailing list.

Original comment by willmcgugan on 10 Apr 2012 at 1:23

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r762.

Original comment by gc...@loowis.durge.org on 10 Apr 2012 at 5:42