# Summary: positional arguments and named (keyword) arguments
In summary, arguments can be positional arguments or named (keyword) arguments
When using positional arguments, the arguments are matched to parameter names depending on their position
Named (keyword) arguments include the parameter name in the function call
Tomorrow, we’ll look at optional arguments which have a default value…
/7
– 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…
/6
– 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…
/5
– 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
/4
– 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
/3
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…
/2
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 <code in ALT text>
—> 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
/1
@laurentabbal is it possible to schedule for future, too? I suspect yes for Twitter but no for Mastodon (via the API, at least, there's always using delays/dates-times on the Python side, of course)
@folkerschamel redefining `print()` could be one way. Redefining `__add__()` another, there are probably more…
@anmomu92 that's in part the point of my thread. Different people _need_ different modes, there's no one size fits all
@skanman to answer your question: No! Life’s too short!!
@Santiag0 it doesn’t mean it applies to all, though. We all have different levels of higher-order aberrations, and our pupil sizes change by different amounts
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
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_
/1
#Python #programming #darkmode #lightmode #IDE #codingeditor #coding
@folkerschamel if using CPython, as most do. Also, you’ll get a different result if you that in a script rather than the shell/REPL
• Rethinking how to teach programming – I prefer the friendly, relaxed approach when communicating about Python programming
• I write about Python on The Python Coding Book blog and on Real Python
• Former Physicist
• Expect posts on scientific and numerical programming –> NumPy, Matplotlib and friends!