Not an issue.

Here, I help you to "picture" it :-)

Breakdown by levels:

 level 1      level 2      level 3     level 4     level 5

()()()()()    ()()()()      ()()()       ()()        ()
 ()()()()      ()()()        ()()         ()
  ()()()        ()()          ()
   ()()          ()
    ()

 15 balls  +  10 balls  +  6 balls  +  3 balls  +  1 ball  =  35 balls

I would suggest evading divison and using 'Fraction' from 'fractions' module.

I faced the same problem while trying to solve with elixir. It turns out that the precision of floats in elixir and erlang cannot handle the size of the input.

Source: https://github.com/elixir-lang/elixir/issues/2872

Elixir:

234002979492340039680```

Ruby:

```irb(main):001:0> 2340029794923400297949 / 10
=> 234002979492340029794```

As you can see the result of `x` is different.

It's been long since I've thought about this problem, but your approach is probably somehow different entirely :) Think linear equations.

Functionally, there is no difference. However, using maketrans in the encode and decode methods will perform the computation every time something is encoded or decoded (or perform an additional check on whether it has been), whereas using it in the instantiation will perform the computation only during instantiation.

So performing the calculation during instantiation is better performance-wise if you're doing a lot of encoding and decoding.

Ya, I kind of go back and forth with the import styles. I think something like zip_longest is obvious that it is from itertools so I might just use: from itertools import zip_longest. But, for example, load could come from cPickle, pickle, json, etc so I might lean towards import json.

This is probably a good case of where using import re and re.split() would have been more explicit.

Thanks @AntraxMiope, I appreciate your comment. I have learned a lot from other solutions on Codewars too. Just to clarify, I did use re.split not str.split, maybe I should have just imported re like this: import re

I just took a brief look at the other solutions for this kata and saw a few which I think are better than mine. For example, the solution by @Disy. No extra imports and very readable. Only two minor adjustments I can think of when looking at @Disy's solution:

• I would change the variable name string to something else (in my solution it's s) because of the built-in library called string

• As I did in my solution, I would change the type of delimiters to an empty tuple (immutable) because, in PyCharm, I get this warning when delimiters is a list:

  Default argument is mutable

  Default argument values are evaluated only once at function definition time,
  which means that modifying the default value of the argument will affect
  all subsequent calls of the function.

Although you could argue that re.sub could be used in place of @Disy's looping over delimiters and repeatedly using replace for each delimiter, I still think it is a nice solution because of the simplicity.

About your solution, maybe having temp as a list would be better? Each string concatentation creates a new string (since strings are immutable) so for a potentially long string you could be creating quite a few new ones. With a list you could just append char to the list and reset it with temp = [].

You should read about nested functions and 'closures' in python. I'm sure you'll find something useful on some blogs to solve this kata :)

You have to compare indices of lhs and rhs in tuple greek_alphabet using built-in comparator

;)

just add *args to pair_zeroes() ;)

It uses Fermat's litte theorem.

The theorem states that for any prime p, and a number a not divisible by p, pow(a, p-1) % p == 1.

Of course, it doesn't mean that just because pow(a, n-1) % n == 1 for some n, it must be a prime.

But checking a few(7) random numbers and getting 1 remainder everytime gives a reasonable probability of the number being a prime.

This solution will fail if the tests specifically tested for numbers which fool this primality check.