quadratic complexity

The "in" test is expensive. It would be appropriate to keep a set() on the side, in order to more rapidly determine if we just rolled a duplicate number, if we want to produce significantly more than 10 distinct integers.

permutation

10 appears to be a "large" or "significant" fraction of 50. If that pattern holds when you scale up to a larger list, you might consider simply doing an assignment like

xs = list(range(50))

Then use the standard random.shuffle() library routine to produce a random permutation of the list. At that point you could conveniently slice off an xs[:10] result of the required size. By construction, both the original list and its permutation contain only distinct integers, satisfying your requirements.

quadratic complexity

The in nums test is expensive, linear with the size of nums. It would be appropriate to keep a set() on the side, in order to more rapidly determine if we just rolled a duplicate number, if we want to produce significantly more than 10 distinct integers.

helper

Please do break out a def roll_distinct_ints() helper function. Leaving the logic at the module's top-level means that you, or a subsequent maintenance engineer who works on this project, cannot conveniently write automated unit tests for that functionality.

permutation

10 appears to be a "large" or "significant" fraction of 50. If that pattern holds when you scale up to a larger list, you might consider simply doing an assignment like

xs = list(range(50))

Then use the standard random.shuffle() library routine to produce a random permutation of the list. At that point you could conveniently slice off an xs[:10] result of the required size. By construction, both the original list and its permutation contain only distinct integers, satisfying your requirements.

f-string

 memory.append(str(str(a)+" <-- "+str(b)) +str(nums))

Prefer f"{a} <-- {b} {nums}".

dead store

Twice we conditionally assign null = 0. But nothing ever reads that variable, so just elide the relevant else: clauses.