Syntax Error: invalid syntax in an unexpected spot

Sometimes you run into a Syntax Error: invalid syntax and the error message indicates there is a problem with a line that looks totally fine. This usually happens when you have syntax errors right above the line indicated. Some common causes include missing colons and incorrectly paired parentheses/quotation marks.

Errors in your testing code

For most assignments, you will be asked to write your own set of tests for the assignment you are writing (see assignment spec for details).

Common error messages

(Where X is the name of one of the methods you wrote for this assignment.)

False is not true : Did not call X
False is not true : Note: This can sometimes happen if your tests don't run.
Try running them yourself. Did not call X: encountered error [Errno 2]
No such file or directory: 'file.txt'

Usual cause for error

Our tests are making sure your test cases actually test all of your code. If your test cases don’t actually call some of your methods, or your tests encounter some error that prevents them from calling all of your methods, it will end up failing our test.

Common things to check for

  • Check if all of your test functions are called in the main() in the test file.
  • Check if your test function is actually calling the function you are testing.
  • Run your tests using python <test_file_name>.py or the Run button (if applicable) to see if your tests are passing locally. It means there should be no AssertionErrors in the terminal output.
  • If you get the second error (shown above) and have checked everything above, make sure that you are using absolute paths /home/file.txt in your test for file-processing related functions. This is because our tests run in a different directory and you need an absolute path so the runtime knows to look in your directory for the file!

Code Quality tests

We use flake8 to automatically assess some aspects of code quality. flake8 messages have the following format:

<file name>:<row num>:<col num>: <error code> <error description>

For example, you might see E703 statement ends with a semicolon

This means that in the file named, on line 8 of the file there was a problem in the 14th character on that line. The error description says it says something about a semicolon.

You can always look up the flake8 error code (in this example E703) in our flake8 reference to see a more detailed explanation of the error (with examples!).

[Quality] Contains all comments

This test is checking of all of the functions you wrote are documented as well as all of the modules (i.e., Python files) you submitted. Your doc-string comments should be under the function header and properly indented like the example below:

def add_two_numbers(a, b, return_zero=False):
    This function returns the sum of the two given numbers a, b
    if return_zero is False. Otherwise returns 0.
    return_zero has False as its default value.
    if return_zero:
        return 0
        return a + b

Your module comments should be a the top of each module.

Common things to look for

  • Make sure your doc-string comments are enclosed with triple quotes (''' or """).
  • Make sure the top of every Python file you submit has a doc-string describing the whole module (including the test file).
  • Make sure every function you wrote is documented with a doc-string.
  • (If applicable) Make sure any classes you write have a doc-string right under the class header.

Program ran for too long

If you get an error message saying that your program ran for too long, it means our tests have timed out while executing your code.

Common things to check for

  • Check for infinite loop in your program. Focus on while loops as they are the likely culprit since it’s possible to write a while loop that loops forever. Tip: add a print statement within the loop to see if you ever exited the loop.
  • Your code might be overly inefficient. Some common problems include:
    • Using redundant looping that processes the whole dataset multiple times while it is possible to combine operations within the same loop.
    • Using expensive operations (i.e., ones that require a lot of computation) repeatedly. For example, the following code block that counts the number of times a 'a' is in a str case-insensitively is overly inefficient since it has to make a lowercase version of the str for every iteration of the loop!


      # Has to remake the lower-case version of the string
      # many times!
      def count_as(text):
          count = 0
          for i in range(len(text)):
              if 'a' == text.lower()[i]:
                  count += 1
          return count


      # Only has to loop over the string to make lowercase
      # version once!
      def count_as(text):
          count = 0
          text = text.lower()  # Computed once outside loop!
          for i in range(len(text)):
              if 'a' == text[i]:
                  count += 1
          return count