On Thu, Apr 07, 2011 at 01:12:46AM +0000, R. David Murray wrote:
> [...] should be sufficient.

It is sufficient to fix the resource warning.
Having a completely dynamic language is a nice thing.
I would not do it like that.

Instead i would even consider to provide at least ProxyFile 
publically (i.e. in I/O), because it is a nifty thing which may 
be useful for a number of applications. 
(PartialFile is probably too complicated in respect to SMP and FD 
sharing to be public as a generic (non-abstract) class.) 

I don't want to come up with a C++ lib again, but there Device-s 
are doubly-linked (spinlock protected), and each has a list of 
attached Stream-s, and upon program exit the list(s) is/are 
walked:

    open:
	"IO::Device::open(): already open!!%@"
		"\tI'll fail with Errno::ebusy now.%@"
    close:
	"IO::Device::close(): device *not* open!!%@"
		"\tThis may break non-debug enabled code...%@"
		"\tI'll fail with Errno::enodev now.%@"

	"IO::Device::close(): error occurred while closing one%@"
		"\tof the still attached streams!%@"
    ~Device:
	"IO::Device::~Device(): still isOpen()!%@"
		"\tEither subclass::close() does not call Device::close(),%@"
		"\tor it's destructor does not check the open state.%@"
		"\tI'll clean up anyway. Expect crashes soon.%@"

Stream somewhat likewhat.  The Issues #11767, #11466, #11701, to 
name a few, would never happen there if at least one test uses at 
least one of the involved classes once.

Now this is not true for Python's I/O, but i think that the 
interface should at least be complete and act as documented, 
so saying "file-like object" implies raising of ValueError if 
an object is closed etc. 
Even if the class is a somewhat hidden implementation detail. 

So of course hasattr() could be used instead of a special member 
to test for is_open().  (I hope it's slower than the latter.) 
There is no IOXY.open(), so, well, ok.

By the way, mailbox.py also has some other pitfalls as far as 
i remember; i think i've even seen calls to _lock_file() for 
a successful is_locked() (self._locked or so) state, which results 
in unlocking because of cleanup due to lock-taking failure; 
it was a shallow look only. 
(That is, because: rescue me from here!!!)

I'll attach 11700.yeah.diff, which inherits from RawIOBase; 
it's test adds some stuff naively. 
Note this is a few-hours hack in an area i haven't touched that 
much yet; it's a bit mysterious which I/O base class implements 
which functions or expects which function to be present in 
a subclass ...  And which raises what and when. 
That is - i would need to regulary review that at least once 
before i would ship that out for real. 
And i'll attach 11700.sigh.diff, which does only what is 
necessary, following your suggestions.

Now this: choose the right diff and i'll implement #11783. 
:)