Provide flush() and close() functions

[mgeier]

I think both actions should be easily available to the user.

Currently this is done in __del__() which might not be that obvious (and flushing cannot be done on its own).

__del__() and __exit__() could then just simply call close().

I don't know if __del__() is a bad thing because I don't understand all this circular-reference-business described there: http://docs.python.org/3.3/reference/datamodel.html#object.__del__

[mgeier]

close() should probably also delete all attributes:

vars(self).clear()

[bastibe]

I am kind of on the fence about this idea. It seems to me that in every case where you would use close, it would be more pythonic to use the context manager or del instead. Instead of soundfile.close(), why not soundfile=None? It has the same effect, without introducing a SoundFile zombie that still exists even though it is closed and therefore perfectly useless. What do you think about this?

Flush certainly wouldn't hurt, though.

If I understand the circular-reference-business correctly, it would only happen if one SoundFile referenced another SoundFile, which itself referenced the first one. Not a particularly likely scenario.

[mgeier]

To get a little more concrete, I've created a pull request: #14.

Standard file objects have a close() method, so it is kind of Pythonic ... at least people are used to it.

I agree that a context manager would be the best choice, but sometimes it's impossible (e.g. interactive sessions).

The problem with soundfile=None is that it's not guaranteed that __del__() is called at all.
It's the current behavior of CPython to call it as soon as the reference count goes to zero, but other implementations don't have to do it like that.

The SoundFile zombie is definitely a problem, but to avoid usage afterwards, I removed all attributes in my example implementation. So no matter what you try to do, you will get some error message.
It would be possible to check for the _file attribute in each and every function, but I think that's too much.

BTW, there is a little bug in the current implementation: If there is an error in sf_close(), the exception will prevent self._file = None from being executed and if the exception is caught, self._file will remain in a non-None state.
Or am I missing something?

[bastibe]

This is continued in #14