Don't use len() in the virtual IO setup

[bastibe]

Currently, we have this:

def vio_get_filelen(user_data):
    # first try __len__(), if not available fall back to seek()/tell()
    try:
        size = len(file)
    except TypeError:
        curr = file.tell()
        file.seek(0, SEEK_END)
        size = file.tell()
        file.seek(curr, SEEK_SET)
    return size

I suspect that the use of len() is a now obsolete artifact from the development in #1.
It was added there to seemingly support "streaming", but it turned out that this is not supported by the virtual IO call anyway.

Every supported file-like object must have the methods seek() and tell() anyway, so I think its superfluous to check with len() first.

Can we get rid of this remnant from the past?

I guess the cleaned-up version would look like this:

def vio_get_filelen(user_data):
    curr = file.tell()
    file.seek(0, SEEK_END)
    size = file.tell()
    file.seek(curr, SEEK_SET)
    return size

I'm wondering why get_filelen is even part of libsndfile's API, since it can be easily implemented with seek and tell ...?

[bastibe]

There are cases where len actually does the right thing. I would like to keep len for that reason.

[mgeier]

There are cases where len actually does the right thing.

Sure, it might do the right thing, that's not the point.
The question rather is: Is there a conceivable situation where len() does something that cannot be equally well done with seek() and tell()?

Since seek() and tell() are always available, I don't see any necessity for __len__().

The only reason I could theoretically think of, is if __len__() is more efficient than seek() + tell().
But this only happens if the implementation of the file-like object is broken.

But there might be an error in my reasoning ...

[bastibe]

I'm not convinced. But it makes the code cleaner. If you want to change it, go ahead.

[bastibe]

Can we merge this?

[mgeier]

Yes, I rebased and merged.