Reinventing the basic calculator functions
Let's say you have this situation:

if ...:
    ...
    return ...
else:
    return ...


What if the if condition is True?  Some statements will be executed, and then the function will return.  In other words, if the condition is True, execution never leaves the if block.  Therefore, you really don't need the else.  Just put the return directly under the if:

if ...:
    ...
    return ...
return ...




It is generally a bad idea to use the pattern type(...) == ....  Usually, we use isinstance(..., ...).  That way, subclasses are allowed.  Of course, you might keep it if you don't want subclasses to be allowed, but I don't see a reason to restrict the user.  I'm assuming you want only integers because only integers can be passed to range, but subclasses of integers can indeed also be passed.  For example, booleans are integers.  range(False, True) is perfectly valid.  Also, True + False + False is valid, so it won't mess up your arithmetic.  That makes your is_positive_int function look like this:

def is_positive_int(x):
    if isinstance(x, int) and x &gt;= 0:
        return True
    return False


But what do you see?  If a condition is True, we return True.  If it is False, we return False.  In other words, we are really just returning the condition, so why not do it like this:

def is_positive_int(x):
    return isinstance(x, int) and x &gt;= 0




I see a very similar pattern in all of your functions:

if is_positive_int(x) and is_positive_int(y):
    ...
else:
    return False


First of all, we can remember what I mentioned earlier about not leaving the if block unless the condition is False.  Therefore, I would actually switch the if and else:

if not is_positive_int(x) or not is_positive_int(y):
    return False
...


We remove a level of nesting that way.  The problem is that we use the same code in a bunch of different functions, so we can make a decorator.  A decorator is a function which, when given another function (a) to wrap, returns a wrapper function (b) for a.  b overrides a and does its special thing, but it usually calls a later.  This is my idea:

def guarantee_positive(function):
    # Each function takes two arguments
    def wrapper(x, y):
        if is_positive_int(x) and is_positive_int(y):
            # Deal with it normally
            return function(x, y)
        return False
    # Now wrapper(x, y) will be called instead of function(x, y)
    return wrapper


To use it, add @guarantee_positive before each function definition.  For example:

@guarantee_positive
def divide(x, y):
    floor = 0
    remainder = 0
    for i in range(x):
        remainder += 1
        if remainder == y:
            floor += 1
            remainder = 0
    return {'floor': floor, 'modulus': remainder}


That makes for a much cleaner function.  Of course, subtract has an extra condition, but I'll get to that later.



With all that about function decorators, why do you need them both to be positive?  I can see why you might want y to be positive: because range doesn't work the same with negative numbers, but you aren't using i most of the time, so just use the absolute value of y.  I'll give an example:

def multiply(x, y):
    m = 0
    function = add if y &gt; 0 else subtract
    for _ in range(abs(y)):
        m = function(m, x)
    return m


It doesn't require a decorator, and it is capable of more.  You can now use it with any combination of negative and positive:

-3,  3 -&gt; -9
-3, -3 -&gt;  9
 3, -3 -&gt; -9
 3,  3 -&gt;  9


Your add function would be like this:

def add(x, y):
    # Add 1 if y is positive; subtract 1 if it is negative
    y_add = (1 if y &gt;= 0 else -1)
    for _ in range(abs(y)):
        x += y_add
    return x


Again, it's shorter than the original, and it does more.

There are some functions where it isn't quite that easy.  For example, power() would be difficult to implement a negative y (x doesn't need to be positive even with the current implementation), but most of the others don't need the decorator.  I won't tell you all of them, but I have given examples of the more common hangups.



Back to the decorator, I think it is better to raise an exception when something is wrong than to return False.  After all, they are called exceptions for a reason.  Normally, the function does one thing, but there are exceptions (or there should be).



I see a lot of for i in range(y) when i isn't used.  The common way of signifying that i is just a place holder is using _ as the variable name.



It looks like you cheated with divide() :)  You don't actually have division, you have divmod.  I think a name similar to that would be more appropriate.  another thing is that you return a dictionary.  I prefer something closer to how the built-in function does it:

return floor, remainder


That way, you can do:

floor, remainder = divide(...)


Instead of the equivalent:

result = divide(...)
floor, remainder = result['float'], result['modulus']


Either one should have a doc string that explains what the return value is.  If I called divide(...) when it had a doc string of just x / y, I would assume that I would get x / y, not a dictionary with the floored result and the remainder.  Your floor and modulus functions would then be:

def floor(x, y):
    """a // b"""
    return divide(x, y)[0]

def modulus(x, y):
    """x % y"""
    return divide(x, y)[1]


Except that divide will hopefully have a more descriptive name.

I did notice that floor is inside of divide(), but I am assuming that is just a typo.



You seem to be following PEP 8 fairly well, but I noticed that you don't have any whitespace between the key-value pairs in your dictionary.  PEP 8 recommends that you put a space between the colon and the value.  I don't see it in the PEP, but I think you should put a space between a comma and the following object.  For example:

def divide(x, y):


not

def divide(x,y):


Without the space, it feels smooshed, like you're golfing (code golfing, not with a golf club).