You should change this line:
Input: a single string with player names first (alphabetic tokens), followed by signed integers (round scores).
It falsely leads the user to expect clean input.

Thanks!

Since this hasn't been updated in a year - I've gone ahead and change the parameter name to text.

Since this hasn't been updated in a year - I've gone ahead and added the example tests from the description.

if the first part evaluates to True the second part of an 'or' is not evaluated, either way the whole evaluates to

Yes, I was channeling Jessie's fashion tips from the Fast Show.
Well spotted.

Last line of the kata: The array will never be empty.

Also 8th kyu kata are introductory, so error handling would be too advanced for this kata.

?

I'm not sure what you are getting at here, but what I can say is:

1. Polydivisible numbers are by definition polydivisibile upto n-1 in base n, using the digits that form base n (0, 1, ..., n-2, n-1).
2. The claim is that a polydivisible number of a lower base is polydivisible in a higher base, but not vice versa.

So in your example, I see two issues:

1. You can't divide by 2 in base 2, as there isn't a single digit in base 2 for the numeral 2_b2, you have to use the next order of magnitude: 10_b2, so the second check below is invalid:
   • 3_b10 = 11_b2 -> 11_b2 / 1_b2 = 11_b2 -> 11_b2 == floor(11_b2)
   • 3_b10 = 11_b2 -> 11_b2 / 10_b2 = 1.1_b2 -> 1.1_b2 != floor(1.1_b2)
2. Moving from base 10 to base 2 and expecting the property to hold is invalid.

Please let me know if I have missed your point.

Nice kata, but I think the tests or perhaps the reference solution is broken, I'm seeing the following output (edited to improve readability):

Inputs - value: 93, coins: [4, 7, 19, 23, 30, 35, 40, 42, 43, 47, 51, 52, 56, 58, 65, 71, 74, 93, 97, 99]
Output - 
[
    [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 7, 7, 7], 
    [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 7, 7, 19], 
    ... removed for brevity ...
    [42, 51], 
    [93]
] 
should equal [
    [93]
]

Clearly there is more than one solution with this set of given inputs.

Can I also make a couple of suggestions:

1. The output is grouped so error messages don't use up all the buffer space on a failure, so that each elelemnt in the overall list is reduced to the coin and its count like so:
   • [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 7, 7, 7] -> [(4, 18), (7, 3)]
   • [42, 51] -> [(42, 1), (51, 1)]
   • [93] -> [(93, 1)]
2. You clarify expected order with concrete examples. To me lexographic order means conventional numerical ordering, but it seems you want to order to be based on both the number of coins in the answer and the order of the supplied coins, however all the examples have the coins in decreasing numerical order. Possible examples:
   • pennies(9, [5, 3, 2]) => [[5, 2, 2], [3, 3, 3], [3, 2, 2, 2]]
   • pennies(9, [2, 3, 5]) => [[2, 2, 5], [3, 3, 3], [2, 2, 2, 3]]

Keep up the good work! :)

Those two tests attempt to use one method first, then attempt to use the other. If the second attempt succeeded without raising an exception, then it is considered a test failure.

Two things worth noting here:

1. I have now changed the spec so that 'default message ad infinitum/nauseum' no longer applies to the Pythonic iteration style of usage
2. If you want to do stuff like this:

it = Dave...([0,1,2])
for a in it:
    for b in it:
         print(a,b) 

Given that it is an iterator on a data structure, rather than a data structure itself. Then both calls should be consuming the same iterator, so I would expect an output of (0, 1), (0, 2)
Anyway, if you write code like this, you're on your own buddy, and you should feel ashamed! :D

OK, I've updated the spec/tests, so now:

1. You have to support "Dave's way".
2. You have to support "Python's way".
3. You shouldn't support both at the samne time.

Just for the record, yes this is underspecified, it's a simulation of working for an idiot! :D

The point of the kata is implementation of conflicting requirements to do the same thing two different ways at once.

So, get_next is required because that is the poor spec that the boss Dave is supplying.

The __next__ and __iter__ are both required to support rest of the world who just want to use an iterable object in the same way as normal Python object and not do. things "Dave's way". :)