John Feuerstein <j...@feurix.com> added the comment:

> 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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12941>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to