The lack of exactness (and possibility of platform-dependent results, including, e.g., when a single platform changes its math libraries) certainly works against it.

But I think Raymond is more bothered by that there's no apparently _compelling_ use case, in the sense of something frequent enough in real life to warrant including it in the standard library.

For example, there's really no problem right now if you have a giant iterable _and_ you know its length.  I had a case where I had to sample a few hundred doubles from giant binary files of floats.  The "obvious" solution worked great:

    for o in sorted(random.sample(range(0, file_size, 8), 1000)):
        seek to offset o and read up 8 bytes

Now random access to that kind of iterable is doable, but a similar approach works fine too if it's sequential-only access to a one-shot iterator of known length:  pick the indices in advance, and skip over the iterator until each index is hit in turn.

It doesn't score much points for being faster than materializing a set or dict into a sequence first, since that's a micro-optimization justified only by current CPython implementation accidents.

Where it's absolutely needed is when there's a possibly-giant iterable of unknown length. Unlike Raymond, I think that's possibly worth addressing (it's not hard to find people asking about it on the web). But it's not a problem I've had in real life, so, ya, it's hard to act enthusiastic ;-)

PS: you should also guard against W > 1.0. No high-quality math library will create such a thing given these inputs, but testing only for exact equality to 1.0 is no cheaper and so needlessly optimistic.