> r.pop(random.randrange(0, len(r)))

So seq[random.randrange(0, len(seq))] suddenly makes random.choice(seq) obsolete? There is no functional reasoning here, it's convenience for a common operation.

> Not all the sequences have a .pop() method.

Not all sequences support indexing or item assignment either:

>>> random.choice({1, 2})
TypeError: 'set' object does not support indexing
>>> random.shuffle("abc")
TypeError: 'str' object does not support item assignment
...

> I'd rather see random.choice support sets: ...
> But that's another (rejected) issue; see issue 7522.

So the implicit requirement for random.choice() is support for indexing.
The implicit requirement for random.shuffle() is support for indexing and item assignment. The implicit requirement for random.pop() is support for seq.pop()...

I don't think random's convenience functions should validate (or even worse, convert) input. It's actually great that they are thin wrappers without magic, resulting in the same behaviour as if done without them.

> self.assertIn(pop([25, 75]), [25, 75])
> These should also verify that the element is not in the list anymore.
> Also other test with different (and possibly wrong) input types should be added.

This is true for many convenience functions in random. I've considered doing that at first and came to the conclusion that the tests for random should test the behaviour specific to random, not that of the underlying functionality?

So seq[random] should test for random behaviour, not that indexing of seq itself works correctly. Similarly, seq.pop(random) should test for random behaviour and not for a working seq.pop()?

All we would do here is duplicate tests not related to random.

Please correct me if I'm wrong. I'm glad that this started a discussion.