Basic user input -Lewandowski and his goals as example

The INPUT function is used to gather input from the user. So you can ask the user to give the program some information, data, etc. (=input).

If you want the user to enter a value or a string and store it to a variable you can do it in this way:

In this Blog I already talked about different data types. So what we can do with the INPPUT function is to determine a wished data type for our input, because for example if you want the user to input the average number of goals from Robert Lewandowski per game, which probably might be a float number (Go to the end of this post to see the solution) . You can do it like this:

So the value for Lewagoals will be stores as a float number in this example.

In case you want the user to assign multiple values to variables you can add the split () function. It breaks the given input by the specified separator. If the separator is not provided then any white space is a separator. If you want to determine the amount of goals that Robert Lewandowski scored angainst the last 3 opponents you can do it like this:

For more information on splits go to this website:

Furthermore, I can recommend this guy, who provides high quality output:

As promised above here the solution: Lewandowski scores 1.29 goals per game during the creation of this post.

#Mastery 06

Basic Types in Python

This article deals with the basic data types of Python. Every value in Python has a datatype. Since everything is an object in Python programming, data types are actually classes and variables are instance (object) of these classes. In soccer there are different types of players as well. Furthermore, the skillsets of the players differ so that the coach uses them when he needs them. You do the same in Python, you need the right data type to be able to code the way you want it.

Some of the important types are listed below:

Data types:

  • int (integer, whole numbers)
  • float (floating point numbers, decimal numbers)
  • complex
  • str (strings)
  • bool (truth values)
  • tuple
  • list
  • set
  • dictionary

How to use them in Python? We will deal with int, floats, lists, tuples & strings

Most important points here:
– You can get the type of a variable with the first print statement (#Showing which type a variable
– A list starts counting at zero
– With the print statement you can ask for certain elements in the list or an intervall of elements
– The difference between a list and a tuple is that the order of the tuples can’t be changed
For Strings it can be kind of useless to ask for the position of the letter, but I wanted to show it to you here

#mastery04 #mastery05

Zen of Python – Are the rules adaptable to soccer?

So no matter if in soccer or in Python there are some principles you should follow to become successful. Of course, they don’t always fit 100% to every game and to every style of coding, but they can serve as a good reference point. But we should definetly take a look at them. We start with the Zen of Python.

The Zen of Python is a collection of 19 “guiding principles” for writing computer programs that influence the design of the Pythonprogramming language – Wikipedia.

Here we go:

  1. Beautiful is better than ugly.
  2. Explicit is better than implicit.
  3. Simple is better than complex.
  4. Complex is better than complicated.
  5. Flat is better than nested.
  6. Sparse is better than dense.
  7. Readability counts.
  8. Special cases aren’t special enough to break the rules.
  9. Although practicality beats purity.
  10. Errors should never pass silently.
  11. Unless explicitly silenced.
  12. In the face of ambiguity, refuse the temptation to guess.
  13. There should be one—and preferably only one—obvious way to do it.
  14. Although that way may not be obvious at first unless you’re Dutch.
  15. Now is better than never.
  16. Although never is often better than right now.
  17. If the implementation is hard to explain, it’s a bad idea.
  18. If the implementation is easy to explain, it may be a good idea.
  19. Namespaces are one honking great idea—let’s do more of those!

I admit that they appear a bit too clever at the beginning, but they are important, so keep in mind to refer to them again and again during your work.

Do those concepts fit for soccer as well? Lets try:

  1. No, playing beautiful but losing every game is the last thing you should do in soccer.
  2. Yes, being explicit in Python means being concrete and specific instead of abstract and general. It also means not to hide the behavior of a function. In soccer the coach should explicitly tell you what to do and not give misunderstandable instructions too.
  3. Yes, playing simple when you can is a good idea.
  4. Yes, although complex and complicated sound alike, they do not mean the same in this context. It is okay to build very complex applications, as long as the need for it is reasonable. So in soccer you should play complex only if you need to as well.
  5. Yes, flat usually refers to how data is organized, but can also refer to things like if statements. Nested “ifs” are where you check one if, then inside that, check another if, etc. instead just check both variables. Same in soccer: flat play, high win.
  6. No, code that is spread out over multiple lines is often easier to read than dense one-liners. I can’t see a connection to soccer here.
  7. No, nobody cares about readability in soccer.
  8. Yes, don’t break the rules in soccer even if the game goes crazy.
  9. Yes, walking the line between number 8 and 9 becomes easier with experience. And in time, you’ll not only learn the rules, but also learn when to break them. I mean in soccer sometimes it is fair to operate on the edge you know. Imagine Diego Maradonna would have tell everybody that his goal with the hand against England 1986 during the world cup shouldn’t count. He was experienced enough to just keep silent, because he knew the positive implications.
  10. Yes, it’s better for a program to fail fast and crash than to silence the error and continue running the program. The bugs that inevitably happen later on will be harder to debug since they are far removed from the original cause. In soccer that means better see and face the weaknesses of your team during the preparation phase then in the season.
  11. Yes, you can always choose to explicitly ignore the errors your programs cause, just be sure you are making the conscious choice to do so. Same in soccer. If you igonore something make sure you won’t regret it in the future. E.g. don’t ignore to train both feet, because there will be situations, where you have to shoot with the weaker one.
  12. Yes, if your code isn’t working, there is a reason and only careful, critical thinking will solve it. Same in soccer. If you loose 10 games in a row there seems to be a real challenge. Don’t just go in the 11th game and hope this time you are going to win without analyzing and solving the problems of the other games.
  13. No, in soccer you have many ways to score a goal and to win a game but they aren’t always obvious and unique.
  14. No, this line is a joke. Guido van Rossum, the creator and BDFL (Benevolent Dictator for Life) of Python, is Dutch. However, not even this aphorism prevented Python from incorporating three different ways of formatting strings. As a german I can’t comment anything realted to Dutch soccer here :-P.
  15. Yes, like Nike would say: Just do it.
  16. Yes, it’s almost certainly better to wait for your program to finish than to have it finish too early with incorrect results. So don’t go to a championsleague game unless you are not well enough prepaired as the result will not be good then.
  17. No, if a coach wants to implement a complex tactic it may need some time until the players internalise it but thats okay.
  18. No, thats not always right, sometimes you need a more complex system e.g. to play against Barcelona and to restrict their game and Leo Messi especially.
  19. No, as great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization. I don’t see a connection to soccer here.

Note: Some explanations of the principles come from


Comments – A way to analyze a soccer game and your code in Python

The aim of this post is to show you how to create comments in Python.

There are several ways to create them. But first, why should we actually use comments while programming? I mean you don’t have to. But coding without any comments is like playing soccer without any tactics or analyzation of the game. As if you and your teammates would never speak and analyze your aims and intentions behind certain actions on the soccer field. Not a good idea right? Going back to programming the main aims of comments are that they help to:

  • Make code maintenance much easier
  • Make finding bugs faster
  • Write functions that other people will use

Creating comments in Python works like this:

  1. Use a “#” before writing down your code – the part after the Hashtag will not be compiled, but only shown as a text.
  2. Use obvious names for variables so if anybody else checks your code, can’t fail to understand the meaning of it.
  3. Last but not least you can use multiline comments by using the ”’ at the beginning and ”’ at the end of a comment.

How can option 1-3 look like in Python?

That’s pretty straightforward and I don’t want to overcomplicate it. What I still want to mention is that you and your coding team can think about “Documentation Standards”, which means that you define how to best write the documentation so that it helps you the most at the end.

After a soccer game a lot of players have to explain their thoughts and several situations about the game. So they leave a comment. To complete the article I will show you a selection of my favourite comments/quotes of soccer players:

  • “If you’re attacking, you don’t get as tired as when you’re chasing” – Kyle Rote, Jr.
  • “We lost because we didn’t win.” – Ronaldo
  • “It was like the ref had a brand new yellow card and wanted to see if 
    it worked.” – Richard Rufus
  • “I’d like to play for an Italian club, like Barcelona.” – Mark Draper
  • “Eggs, we need Eggs” – Oliver Kahn

Somebody who has a comment for hardly everything: Zlatan Ibrahimović


Introduction and Vision of this Blog


..I am a masters student in Management and Technology from TU Munich in Germany, passionate about soccer and interested in learning Python. I was working really hard during my youth to become a professional soccer player, but because of some injuries I couldn’t follow my dream anymore and switched my carrer plans.

The Vision of this Blog

It hardly doesn’t matter in which sector and in which position you want to work, a generell understanding about programming and the logic behind it will increase your employability and makes you even more ready for our digital future.

So I want to share with you my learning experience in Python in combination with some analogies to my favourite sport soccer, to make this whole thing even more fun! Let’s give Python a chance to become our second passion besides soccer guys. We are going to use the integrated development environment “Thonny” for it – please just download it from the internet, before continuing reading.


In soccer its all about numbers – let’s see how Python can help us there

Dies ist die Kurzfassung des Beitrags.

In this Post I want to explain to you guys how we can calculate in Python:

  1. The sum of the yearly earnings (in Mio.) from Leo Messi (126) and Christiano Ronald0 (94)
  2. The difference of their yearly earnings
  3. The product of their yearly earnings
  4. The integer based division of the two earnings (so no decimal point). First divided by second. –> So we will divide Messis earnings with Ronaldos
  5. The remainder of integer division of the two numbers. –> So we will divide Messis earnings with Ronaldos and see what remains

Lets go:

The sum of the yearly earnings (in Mio.) from Leo Messi (126) and Christiano Ronald0 (94)

  • I’ll explain the scheme one time and it is hardly always the same:
  • First of all the earnings are integer values so we define them like this (“int”) (if datatypes don’t tell you anything yet, now its the time to google them it takes you 5 Minutes to get a glance)
  • With the function “input” I give you the opportunity to write down the earnings of the two players. We do this because the earnings always change. Another option would have been to already define them with e.g. “Messisearnings = int(126), but thats not flexible enough for us
  • After we defined the earnings the next step is to sum them up
  • Note: Everything we write in “” will be compiled as a string

The difference of their yearly earnings

The product of their yearly earnings

The integer based division of the two earnings (so no decimal point). First divided by second. –> So we will divide Messis earnings with Ronaldos

Note the “//” for integer based divison!

The remainder of integer division of the two numbers. –> So we will divide Messis earnings with Ronaldos and see what remains

Obviously, you will receive the same number by just subtracting the two numbers –> so the results of 2. and 5. have to be the same.