A lossy encryption algorithm ?!?

With key "hi", given the ciphertext, you can't know if the first character of the plaintext is 'H' or 'I'.

As an author, you have a lot of leeway in designing your kata, but this is ridiculous.

Note: If the process is done but the other characters in the password are not used, encrypt the remaining characters in the password by adding its index and its ascii decimal then add 40 and divide it by 2 and convert the result into a character. Ex. ((index+decimal)+40)/2. Concatenate it to the first encrypted string.

Given a key and a ciphertext, how will you know where the plaintext ends and the trailing garbage begins? Trailing garbage might look like perfectly valid plaintext ( for medium high indices, you'll get digits ).

It is even possible to run out of ASCII for longer key values ( note that standard ASCII only goes up to 127 ).

Please don't make any contributions to OpenSSL just yet. :S

The handling of messages shorter than keys is explained terribly. Why does key length affect encryption in such a dumb way in the first place?

get the decimal of a character

There's no such thing as "decimal of a characater".

If the answer is not a whole number, only get the whole number

How?

"decimal of a character" -> "ascii code"

Trivial map/filter/reduce is not a novel idea.

• Arbritrary remove 0 and 1 from perfect squares
• Fake gods aren't well explained
• Return multiple types
• No random tests
• Incorrect tests (I have a test with 3 36 where it should be a real god)
• Description is hard to read
• n is not a good name for an array
• Reference solution is so wrong I don't feel like correcting everything but here are a few:
  • list.remove only removes the first match
  • Don't iterate and modify at the same time
  • if i != 0:i-=3 Why? This does nothing at all in your solution

So 0 and 1 aren't perfect squares?
And you should explain what you consider a fake god.