In addition to other answers here is a common way to avoid having too much code on top level:

def main(): fizz = int(input("Enter the number to Fizz: ")) buzz = int(input("Enter the number to Buzz: ")) maxNum = int(input("Enter the maximum number: ")) fizzbuzz(maxNum, fizz, buzz) if __name__ == '__main__': main() 

This patterns allows for your script to be called from the command line, and it also allows for use as an module, so that you reuse your fizzbuzz() function.

And whilst at it, even though this is a rather simple functions, please look into using docstrings to document your function and potentially your module.

In addition to previous answers:

It is considered more Pythonic to check if not num % fizz*buzz than if num % fizz*buzz == 0

Also you don't need to use elif if there is a return statement inside if, so I'd rewrite your get_string function like this:

def get_string(num, fizz, buzz) if not num % fizz*buzz: return "FizzBuzz" if not num % fizz: return "Fizz" if not num % buzz: return "Buzz" return str(n) 

I notice there is no error-checking, so my program would have problems with incorrect input

Lack of error checking, eg duck typing is generally approved of and preferred in python. Surely there are good cases to use input checking, but generally duck-typing is preferred.

I suspect this preference in python is mostly due to all the "primitives" actually being first class objects: int, str, bool. They all have values, methods, and identities.

Besides, type checking often just gets in the way of your users. Say I use a integer-like class that is tied to an active record or has other features that make it better to work with in my application; a type check is just a barrier to entry that maybe I don't care to hoop-jump for. I use my integer class in place of integers everywhere in my app just fine, without type checking; your code may/would have optimistically run with whatever given object and worked just fine too. Functions that quit just because say an input object doesn't identify as an integer are just plain annoying.

Of course other subtle and clever advantages could be leveraged too. A caller could cleverly integrate with your function in rich ways, passing an impersonated integer-compatible object with valuable performance/analytics tracking and/or whatever else might be needed for a proper unit test, or an object that just knows that when certain maths is applied, that it should update a progress bar. Whatever odd edge case matters, Python so often has an "in". The "we're all consenting adults" dogma that doesn't shield any part of the runtime from good (or bad) ideas, lets the analytics engineer harmlessly track the core components, and lets the performance engineer substitute in-place code with bootstrapping and wrappers that hold over until something can be re-architected.

If you are to pursue type checking I would at most suggest catching the kind of operational arithmetic error that incompatible types would cause and raise instead a type error, or a specific-to-your-module exception that probably extends TypeError, when the input has produced an apparent failure condition.

The value in extending a module-specific exception is that it gives any caller a sure way to catch errors only from your module, without giving up valuable semantics or messages.

Always take the "early exit"!

Try to dismiss simple (or error) cases early, "exiting" (returning, raising...) those first, so the rest of the function can avoid thinking about that case anymore.

In practice, it means each if with a return doesn't need an else, reducing the amount of indentation.

def getString(num, fizz, buzz): if num % (fizz * buzz) == 0: return "FizzBuzz" if num % fizz == 0: return "Fizz" if num % buzz == 0: return "Buzz" # Only possible if none of the above return num 

I have some observations that are mostly language-independent.

Document your functions

A clear description of functionality helps when you're considering re-using code in a new project. Get in the habit of writing good doc-comments early, so you're not caught out trying to unravel your logic when it matters!

Accept command-line arguments

It's tedious to test a program if you always need to supply inputs. Simple numbers are best provided as arguments when invoking the program (consider reading from the input stream as a fallback).

Validate inputs

Does it make sense to accept negative numbers? I don't think so; we should refuse to operate if any of the inputs are zero or less.

Separate computation and I/O

It's hard to unit-test code that produces output using print(). It's easier if we return an collection of values or if we write to a supplied iterator. Python helps us, because it allows us to write a generator simply by using yield to return each value.

Division is the most expensive of the basic arithmetic operations

getString() (which should be get_string() by PEP-8, but really needs to be something more informative) has no knowledge that it is being called with sequential values of num. That prevents a key optimisation that's possible if we inline the function. Then we're able to maintain variables to record the remainders without needing the % operator.

Modified code

Incorporating my suggestions, and some improvements from other answers:

#!/usr/bin/python3 import sys def fizzbuzz(max_num, fizz, buzz): ''' A generator that transforms the range [1..max_num], returning each number converted to string, unless it's an exact multiple of 'fizz' (when it returns the string "Fizz") or of 'buzz' (returns "Buzz") - or for multiples of both divisors, the combined string "FizzBuzz". >>> list(fizzbuzz(6, 2, 3)) ['1', 'Fizz', 'Buzz', 'Fizz', '5', 'FizzBuzz'] >>> list(fizzbuzz(6, 2, 4)) ['1', 'Fizz', '3', 'FizzBuzz', '5', 'Fizz'] ''' # accumulators tracking num % fizz and num % buzz fizz_acc = 0 buzz_acc = 0 for num in range(1, max_num + 1): fizz_acc += 1 buzz_acc += 1 result = "" if fizz_acc == fizz: fizz_acc = 0 result += "Fizz" if buzz_acc == buzz: buzz_acc = 0 result += "Buzz" yield result if result else str(num) def arg_or_input(argno, prompt): ''' Read a value from the 'argno'th command-line argument, or if there are fewer, use 'prompt' to input interactively. ''' try: return sys.argv[argno] except IndexError: return input(prompt) if __name__ == '__main__': import doctest if doctest.testmod()[0]: sys.exit(1) try: fizz = int(arg_or_input(1, "Enter the number to Fizz: ")) buzz = int(arg_or_input(2, "Enter the number to Buzz: ")) max_num = int(arg_or_input(3, "Enter the maximum number: ")) except ValueError: print("Inputs must be integers!", file=sys.stderr) sys.exit(1) if fizz <= 0 or buzz <= 0 or max_num <= 0: print("All inputs must be positive!", file=sys.stderr) sys.exit(1) for s in fizzbuzz(max_num, fizz, buzz): print(s)