Back to dark and light modes.

For someone with high higher-order aberrations (like me), dark mode pushes the pupil size well above the ideal pupil size, therefore vision is worse.

This will not be the case for everyone, of course.

But, dark mode is not for everyone…

If, like me, you prefer light mode, ignore all those who snigger because “pros use dark mode”

/6

So, in the human eye, there is an optimum pupil size. If the pupil is very small, diffraction leads to lower resolution…

If the pupil is too large, higher-order aberrations lead to lower resolution.

The sweet spot varies from person to person (it’s roughly around 3-5mm — the pupil typically can vary between 2-8mm in an average eye)

/5

How about diffraction?

Diffraction is something completely different… It’s a fundamental optical phenomenon

All optical systems suffer from this, even ones that have no aberrations (imperfections)

Small pupils lead to more diffraction which reduces resolution.

Large pupils have less diffraction and therefore have less of an effect on resolution.

This is why telescopes have large diameters and professional photographers have lenses with larger diameters.

/4

Every eye has aberrations, or imperfections…

…and these are not just the ones we correct using glasses or contact lenses.

Those are just the main ones.

The others are called higher-order aberrations.

The larger the pupil of the eye, the more higher-order aberrations there are.

Therefore, in bright lights, when the pupils are small, there aren’t many higher order aberrations…

But when the light levels are low and the pupils large, there are significantly more.

Everyone has higher-order aberrations, but not everyone has the same amount.

So this is worse for some people.

I happen to know that I have reasonably high higher-order aberrations (How do I know this: from my previous work as a scientist when I often measured these)

More aberrations = lower resolution and lower contrast = poorer vision.

/3

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

/2

But, there are times when you want to know that an object is exactly the same object and not just equal in value.

In these cases, you’ll need to use `is`.

As a general rule, use `==` by default unless you know you need `is`.

But now can we stop squabbling about who the £5 note belongs to?!

/5

Sorry, the serial number of the note shows it’s _mine_!

This *is* my note. In this case, it wasn’t `==` that matters but `is`

With a #Python object, the built-in `id()` function gives you the “serial number”, which is unique for each object, just as the serial number on a bank note is unique.

In #programming, as in the case with bank notes, you often care more about the value of an object rather than its identity.

So, you’ll often need `==` just like the barista in the coffee shop didn’t care about the £5 note’s serial number.

/4

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.

/3

So, does it matter which £5 note we use to pay?

No, all the barista cares about is that `our_payment == 5`

So _you_ can pay. Thank you!

In this case, the *value* of the £5 note is what matters, not which actual physical note we use.

But let’s assume we’re chatting and we spot a £5 note on the floor.

We both check our pockets and we realise we’ve both lost our £5 note.

Is the note on the floor mine or yours?

/2

“What’s in a name?”, one might argue? And there’s a point. What matters most is knowing how to use concepts rather than knowing the precise definitions

Still, these terms are used everywhere-in documentation, in tutorials, when talking to other programmers

So, knowing the terminology is important. It shouldn’t be the first thing someone learns, but eventually, everyone should become familiar with the right terms for the right things

/6

— Argument —

An argument is the actual information you send to a function when you call it

You called the function twice in the example above

The first time you called greet_person() you used the argument "Ishaan" and the second time "Elizabeth"

When you call the function, the information (the argument) is stored in a variable named person inside the function

Don’t worry too much if you confuse parameters and arguments. Many programmers confuse them, too!

/5

— Parameter —

A parameter is the name you choose for information that’s needed by the function

You add parameters inside the brackets in the function signature which is the line which includes def

In this example, the parameter is person

This is the name of the “storage box” which is ready to hold any information you send into the function

However, when you define the function, this “box” is still empty…

/4

— Call —

You call a function when you use it

You’re calling a function when you write its name followed by parenthesis (the round brackets)…

The code in the function definition will run when you call a function

In the example above, you’re calling the function twice on the last two lines of the code

/3

— Define —

You define the function when you use the def keyword

The first line of the definition is the function signature and the code after the colon is the code you want the function to perform…

However, this code does not run when you define a function

For this, we need to call the function…

/2