Offside Rule Quiz using Python’s turtle. I scored 10 out of 10. No need for VAR if I’m the referee, then?!

Article coming soon*

small print:
*soon is a relative term


Do you know the offside rule? Sure? To have some fun, I’m writing a quiz using Python’s turtle

This is what it looks like so far (and no, I’m not bothering with fancy graphics – life’s too short)

In this video:

  • you can see direction in which team is attacking from the arrows
  • each snapshot shows when player with the ball kicks the ball forward
  • program (hopefully) detects whether it’s offside or not
  • there are 15 (random) scenarios in this video

Still to do:

  • deal with when forward player is in own half (no offside)
  • deal with when forward player is the one with the ball (no offside)
  • turn into a quiz
  • write article for The Python Coding Book blog about it to document the code - there are some interesting aspects I’m using in the code that hopefully some will find useful.

Work in progress - An Offside Rule Quiz using Python’s turtle

Will aim to get it done in the next few days… (will write it up as an article, too)

For those who don’t follow football (that’s soccer for some around the world), the offside rule is one of those “notorious” rules that not everyone gets.

Here’s a “from-the-archives” post

I’ve been recently having more and more conversations – some privately and some publicly – on using the turtle module for more than just drawing circles and patterns!

Some of you may know this is one of my favourite topics – in this example, we’re using it to visualise how sines and cosines are linked to the motion in a circle

How many children (and adults) learn about sines and cosines but don’t know what they really are?

I’ll be mostly posting about in the data analysis and science and related domains here…

…but for those learning to code, whatever the final aim, it’s good to get a broad perspective

So here’s something different to learn about or consolidate the key data structures in Python - lists, tuples, dictionaries, and sets

Here’s the link to the article for those who want a “diversion” from more serious-looking exercises!

Here’s the code for the plot in the previous post - put in your own image file, of course!

You can get the text from the images’s ALT text

Show thread

Have you used subplot_mosaic() in ’s yet?

Or are you a dinosaur like me and still use older functions? After all, subplot_mosaic() was only introduced in 2020 in version 3.3

Recently, I decided to finally explore subplot_mosaic() and I know I’ll never go back to whatever I did before to plot these types of figures!


My favourite textbook of all time – had been in storage for a while as we did a long, convoluted, house move…

It’s back, safe and sound, nicely weathered and thumbed from all those years of use…

PS: just realised it’s my wife’s copy, not mine. I Want My One Back! (It’s still in a box, somewhere…)

– 5 –

greet_person(number=10, person="Stephen”)

Since you’re using these arguments as named arguments, you no longer need to stick to the order in which they’re defined in the function signature

Python no longer uses position to assign the arguments to the parameter names. This is particularly useful in functions which can take many parameters

In this example, the programmer calling the greet_person() function has a choice on whether to use positional arguments, named arguments, or a mixture of both (as long as the positional arguments come before the named ones)

There are ways in which the programmer who defines the function can force the user to use positional-only or keyword-only arguments

But we’ll leave that discussion for another day…


Show thread

– 4 –

greet_person(person="Stephen", number=10)

In this case, you’ve used both arguments as named or keyword arguments. You’re no longer relying on the position of the arguments. What matters now is the keyword you use when calling the function.

This leads us nicely to number 5…


Show thread

– 3 –

greet_person(person="Stephen", 10)

This seems identical to the case in the second example, but we come across one of the rules when using positional and keyword parameters

See the description of the SyntaxError. It says positional argument follows keyword argument

When using a mixture of positional and keyword arguments, the positional arguments must come first

And this makes perfect sense, since Python is relying on the position of these arguments within the function call to know which parameter name to assign them to


Show thread

– 2 –

greet_person("Ishaan", number=3)

In the second call, the first argument, "Ishaan", is a positional argument as in the first example

However, the second argument is a named argument or a keyword argument

The argument is matched to the parameter by naming it. You’re using the parameter name with an equals before the argument in the function call

Therefore, in this second example, you have one positional argument and one keyword (or named) argument


Show thread

Let’s look at all five function calls in this example:

– 1 –

greet_person("Elizabeth", 5)

This is the most commonly used function call. The arguments are positional arguments

This means that the values "Elizabeth" and 5 are matched to the parameter names person and number depending on the their position in the function call

The first argument is assigned to the first parameter; the second argument to the second parameter…


Show thread

Day 2 of diving into Python functions — today we’ll look at:

positional arguments
named (or keyword) arguments

I don’t have a preference on which term to use for the latter!

Here’s a simple function – see attached image

—> Which of the five function calls will not work?

While you think about the answer, you can refresh your memory about the terms with yesterdays toot thread!

The parameters in the code above are person and number

The arguments are the strings with names and the integers used in the function calls


I used PyCharm’s Darcula and IntelliJ Light themes on a 27” screen — PyCharm was in full screen mode. iMac was on 75% brightness (usual setting)

I stood in my normal position—arm’s length from screen—and looked at the middle of the screen…

Here’s my eye pupil as I switch from dark mode to light mode

Video quality not great (don’t view in full screen!!)—but this is just a rough experiment, so it will do nicely

And you can see stills, with a very rough estimate of the relative pupil sizes, in the first toot…

On the right you’ll see the small pupil from the light mode scenario shown in red and superimposed on the black “dark mode” pupil


Show thread

There’s plenty of disagreement and controversy at the moment, so let me stoke things a bit more:

Light Mode is better than Dark Mode (for me)

Here’s why, with some science behind it, too. Yes, I have a justification as well just a preference…

Let’s start with what we know:
The pupil of the eye shrinks when there’s a lot of light and dilates when it’s darker

The question is: how much difference will it make between viewing a screen in dark mode and light mode?

Here’s a very rough, crude experiment (emphasis on “rough” and “crude”, and use of “experiment” is very loose here!)

Details in next toot


Its value is no longer what matters now.

We both had a £5 note.

What matters is whether this is the actual physical note that was in my pocket or yours.

Luckily, we’re both geeks and we keep a record of the serial numbers of all the notes we carry with us on our phone.

I know, that’s quite sad.

And quite unlikely, too.

But bear with me.

So, we both get our phones out to check the serial numbers on record against the serial number on the £5 note on the floor.

You can see the serial number in two places on the £5 note.


Show thread

Have you heard the one about `is`, `==`, and the £5 note that it’s your pocket?

You may have already come across the fact that `is` and `==` are not the same in Python and cannot be used interchangeably… if you haven’t, you heard it now!

But why? Let’s see what the £5 note has got to do with this story

Let’s assume you and I both have a £5 note in our pocket

[replace with currency of choice]
[read “bill” instead of “note” if you wish]

We meet up and go to a coffee shop nearby to buy two coffees which cost £5 altogether

Does it matter which £5 note we use to pay?


[this is like a Netflix series you can binge on, no need to wait until next week for the next episode, read on in the next toot in this thread…]

Functions in Python—easy or hard to learn & master?

This week I’ll be looking at aspects of functions which can be tricky for those who know basics and want to move to next level. If you’ve learnt about functions in Python are keen to take the next step, then hopefully this series of toots will help…

Let’s start with the unexciting but important—terms


Here’s the code we’ll use as an example which you can also get from the ALT text of the image in this toot:

def greet_person(person):
print(f"Hello {person}! How are you doing today?")


You can follow this thread in the replies (unlisted)


Show more
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.