miguel's latest

Add pythonic version.
Add test_submission next_num_output_depends_on_tick_position
Add test_submission raises on lists of different size
Jonathan: whitespace only, PEP8 conformance.

Add space after commas.
Remove inconstantly used blank lines.
Put test for normal (non exception) behaviour first.
convert function comments to docstrings.

See the resulting output of 'pydoc submission.RandomSequence'
rename RF to random_function
don't use multi-statements on one line.

In this specific example, it makes it trickier to be certain
what is being assigned to LV, say, at a glance. Our source will
be read by others many more times than it is written. We
strive therefore to write it in the way that best supports
ease-of-reading.
eliminate intermediate variables LV and LP.

I contend they aren't needed. This makes the resulting 'if' statements
that use LV and LP more readable, because we can see 'in situ'
precisely what is being compared, rather than having to dereference
the values of LF and LP by looking to the lines above to see what
they were assigned to.

I have introduced the redundancy of duplicating the expressions
'len(_values)' and 'len(_probabilities)'. If these expressions were
any more complex than this, then I would extract them as a new function
with a meaningful name. But because they are so simple, practically
actually atomic, I don't mind duplicating them. The performance
implications of duplicating the call to 'len' should be ignored until
we have measured that is makes any difference (which it won't -
reading this python file from disk to run it will take millions of
times longer than calling 'len'.)
Put assertions about correct inputs first.

Removing the intermediate variables LV & LP meant we no longer
are constrained in how we order the statements in __init__.
Hence we can now put the assertions about correct inputs at
the start of __init__, where they conceptually belong.
Fiddle error messages to make then fit in 80 chars.

Also, note that I moved the check for different lengths to be first.
I consider this most fundamental, in that one could imagine the
other checks to be optional, e.g. we might decide that with empty
arrays we just return and empty sequence or something (I don't think
that would be wise, but one might have need for it.) Whereas with
arrays of different lengths, I don't think there is any sane way
we could proceed.

Interestingly, now that the check for lengths is first, the second
check, for zero lengths, could be simplified because we now only need
to test one of them. I considered not simplifying it, because it means
the second 'if' is not dependent on the first 'if' in order to
correctly work. (i.e. if future edits, done by another developer
who hasn't had time to think through all the nuances, changes or
moves or deletes the first 'if', then the second 'if' will again
need to check both len(_values) AND len(_probabilities). So it's
nice if the second if  contains both checks, so that it stands
by itself, removing any dependency on the behaviour or ordering
with respect to the first 'if'.

However, then I thought, if a future developer did make that mistake,
(i.e. removed or changed or moved the first 'if', without adding
both len checks to the second 'if', then the tests would catch it
and alert them to their mistake. So it's OK if I remove one of
the checks now, to simplify the code.

However however, then I noticed there are not tests for values
or probabilities being empty. So I added some.
convert 'if' checks to asserts.

The construct:
  if cond: raise AssertionError(message)
is identical to:
  assert \!cond, message
I prefer the second because it's slightly shorter and easier to read.
(by being less flexible than a general purpose 'if', the reader
instantly knows what an line starting 'assert ...' does, at even the
quickest of glances.)

I considered converting the third 'if' too, switching out the
ArithmeticError for another AssertionError, but decided against
it.
self._probabilities, not used
self.total -> total.

Not used outside __init__, so can be made local.
introduce 'cumulative' function.

Now that 'total' is a local variable, and hence evidently not used
elsewhere, it have become very clear that the for loop in '__init__'
is an example of the common 'accumulate' pattern. In Python3, I would
replace it with the function 'accumulate'
https://docs.python.org/dev/library/itertools.html#itertools.accumulate
However since we are in Python2, I'm going to write my own version
'cumulative' (so called because it isn't as general purpose as
accumulate, it takes no combining function argument, but assumes
addition.)

This now lets us look at the code in __init__  and consider it from
a highler level of abstraction, needing to read less code in order
to understand what's going on. Cumulative can be tested by itself
(meaning smaller, simpler unit tests) and can be re-used elsewhere
without needing to be tested again, thus reducing total volumes of
code in use.
remove needless parenthesis