Order of courses

I’m just starting self-teaching Python. I’m looking for guidance as to what order the following learning paths in “Real Python” should be taken? I’m older so reinforcement is not a bad thing if some repeats things already covered.

Functional Programming with Python

Intro to python

Python Basic Book

Python Basics: Introduction to Python

Write more pythonic code

Object-Oriented Programming with Python

I’d rather do things in order, it’s easier for me to learn it then.

Thanks. Lots of concepts to learn.

Sorry Leonard, your question has a lot of assumptions behind it that I don’t know.

What are these “learning paths in “Real Python””? Is “Real Python” a book you are reading?

If it is a book, I suggest you follow the book. Or have you finished the book and looking for something new to go on with?

I learned Python from:

  • reading, and following, “Learning Python” by Mark Lutz;

  • reading other people’s code and listening to their advice;

  • writing code, and sometimes even remembering to run it to see if it works wink

  • and reading lots of blogs about programming, not necessarily just about Python.

(The third point is important: there is no substitute for actually writing code, and if you are like me, it is easy to fall into the trap of “write only code” that gets written but you never actually run.)

There is no One True Path for learning Python. Certain topics are clearly more advanced than others (e.g. metaclasses, descriptors) but beyond that there is no rule that says you have to learn classes before functional style or vice versa.

Most often, the topics don’t have anywhere near a clear division. Functional style programming is more of a philosophy than a specific set of tools:

  • put your code in self-contained functions;

  • functions should avoid having side-effects: all actions should be performed by explicit input arguments and an output return value;

  • avoid mutating state (that’s a side-effect);

  • especially global variables;

  • pass explicit arguments rather than rely on implicit variables;

etc, although there are a handful of FP tools in Python (map(), filter(), functools.reduce()). You can follow this style without “doing functional programming”.

Let’s make it concrete. I want to open a file, read a list of strings (one string per line) into a list, having removed blank lines and leading/trailing spaces, and sort the list.

Here is one solution:


strings = []

with open('myfile.txt') as f:

    for line in f:

        line = line.strip()

        if line:

            strings.append(line)



strings.sort()

print(strings)

We can make it a bit more functional style like this:


def read_strings(filename):

    strings = []

    with open('myfile.txt') as f:

        for line in f:

            line = line.strip()

            if line:

                strings.append(line)

    strings.sort()

    return strings



strings = read_strings('myfile.txt')

print(strings)

For a one-of job, it’s not clear that there is much difference between

the two. But if you have many files to read, and you need to do

further processing on them (say, merge the files and write them out

to another file), the second is better.

We can turn the “functional style” up a few notchs:


def read_strings(filename):

    with open('myfile.txt') as f:

        strings = sorted(filter(None, map(str.strip, f)))

    return strings



def process(filename):

    print(read_strings(filename))



process('myfile.txt')

Some people may say that when it comes to functional programming, you can have too much of a good thing. I find that last version perfectly readable, but I acknowldge it is an acquired taste.

Let’s turn it down a notch:


def read_strings(filename):

    with open('myfile.txt') as f:

        strings = [string.strip() for string in f]

        strings = [s for s in strings if s]

        strings.sort()

    return strings



def process(filename):

    print(read_strings(filename))



process('myfile.txt')

At some point, coding style becomes a matter of personal taste.

I don’t know if I have answered your question or just confused you more, but I hope it has helped :slight_smile:

Yes, you have helped. I’m reading about imperative programing, today. It seems to me that programming styles have more to do with the problem trying to be solved than following one way or the other. If I were to go to work and they used ‘OOP’ I would have to change to their style.

Thank again, I’m learning!