DEV Community

Cover image for 5 Common Beginner Python Mistakes
Jacob Baker
Jacob Baker

Posted on • Updated on

5 Common Beginner Python Mistakes

It seems like a lifetime ago I cobbled together some HTML, CSS, and PHP to build a website as my first foray into programming, soon after downloading Borland’s Turbo C++ and trying to teach myself (it didn’t go so well at the time– I was young!).

Lately I’ve been working with University students that are learning Python for the first time. For some of them it’s their first time programming full stop. It’s been an interesting insight into what can cause absolute beginners to trip up, using that to help improve material provided to them.

Over the various sessions a number of issues popped up, some I expected, and some I really didn’t. So, without further ado, these were the most common mistakes the beginner Python developers made.

Python 2.7 vs Python 3

This was a classic one. The University computers had two versions installed on each machine: 2.7 and 3.6. This led to a couple of situations that typified the kind issues you may come across when running two different versions in parallel.

One student had the classic case of “but it worked when I ran it yesterday!”…

After taking a look over their code it became apparent that they had accidentally opened it in Idle Python 2.7.

Shortly after, another exasperated student let out a cry of defeat. They had the exact same code as their neighbour and yet one worked correctly and the other gave an error. Yep, one was running the code on Python 2.7 and the other 3.6.

In both of these instances the actual issue was with the input function not working as they expected in Python 2.7.

As a quick aside: a common question from new programmers is what version should I learn? In my humble opinion you should go for 3.x and then check out the differences in 2.7 if (lets be honest, still when even now) you come across it in the wild.

No Indentation

Straight off the bat: officially, spaces not tabs. In practice: do whatever and let the IDE/linter handle converting it.

Unlike other languages that use curly braces to denote code blocks ( { } ), Python relies on whitespace.

for(i=0; i<10; i++) {
    printf("%d", i);
}

vs

for i in range(0, 10):
    print(i)

Indented lines typically follow statements that end with a colon.

Which brings us on to…

Missing Colons

Colons at the end of if/for/while/def/class/etc are required, but; aren’t really necessary to make grammatical sense, leading beginners to tend to omit them from the end of statements.

By that I mean that both:

if foo == bar
    print(foo)

and

if foo == bar:
    print(foo)

Both make grammatical sense but the latter of the two is a) right in Python and b) easier to read.

Having a colon also allows for one line statements:

if foo == bar: print(foo)

When followed with a blank line; not that I would advocate doing that.

Writing Sentences

This was a peculiar one. A fair number of the students would start all new lines with a capital letter, so something like:

should_end = False

while not should_end:
    an_input = input(Type something)

    if an_input == exit:
        should_end = True

became:

Should_end = False
While not should_end:
    An_input = input(Type something)

    If an_input == exit:
        Should_end = True

Which left them with a whole host of errors!

Can’t really explain that one to be honest.

The Python naming conventions for variables and the such can be found in PEP 8 and reserved words begin with a lower case letter.

Type Conversion

An interesting one for the students to get their heads around. Particularly if they have prior experience with more forgiving languages.

One of the tasks required the student to read in a number and then compare it to 1 to switch to a certain state. It looked something like this:

state = 0
a_number = input(Gimme a number: )

if a_number == 1:
    state = 1
else:
    exit()

Can you spot the problem?

The state never changed because the if statement is comparing a string with an integer, boiling down to:

if 1 == 1:

The solution to this being converting the variable to an integer first:

a_number = int(input(Gimme a number: ))

Note: validation not included.

Top comments (0)