Show more

@freemo Is there a reason why toots using markdown do not appear as raw markdown for those on servers who don’t support markdown and instead appear as plain text with all the markdown ignored?

It makes it tricky to decide whether to use markdown, or to use plain text and put the markdown symbols as plain text so everyone gets the same version

Some are confused about the terms “mutable” and “immutable” in or in general.

A Toot could be a good example but it seems that this is not the same for everyone (in the process of changing?)

For me, at the moment, a Toot is “immutable” –> Once it’s published, it cannot be changed. I can delete it and replace it with a new one, but I cannot change the actual Toot

But for others (and from what I gather, for all of us in the near future?), a Toot is “mutable” if they can change the same toot, not just replace it with a new one

Let’s say you have a string, an immutable type in Python:

name = "Stephen"

You change your mind and want it to be upper case:

name = name.upper()

You’re creating a copy of the string which is uppercase and replacing the old string (which is binned) with the new one

That’s not the case for a list, for example, which is mutable:

numbers = [2, 5, 9]

You change the same list, not create a new one

Will Toots change from being an immutable type to a mutable type for all of us soon?

The principal component analysis in 6 steps is the most popular post on my blog. Here's the Python version – without warranty ...

... but for sure also with Ethiopian coffee :o)

…but he won’t stay there long. Monty finds the name print in the built-in red booklet which gives him directions to the print Function Room which is elsewhere in Python City.

He’ll leave the Main Room to go to the print Function Room, taking the integer 13 with him.

When Monty finishes from the print Function Room, he’ll return to the Main Room and carry on with whatever instructions come next.

Usual caveat: analogies are not perfect. So don’t take them literally. Literally!

But, our brains react better to narratives rather than random facts. So I find that these ‘stories’ help me understand and remember this stuff so much better…

Hopefully it will help others, too.

If you want to read more on this analogy, you can read this:


Show thread

However, if the function call was just:

do_something_clever(5, 8)

then Monty doesn’t know what to do with the data he’s holding. So he’ll throw it away in the garbage bin so he can carry on with his work.

What if you write:

print(do_something_clever(5, 8))

Monty will go to the do_something_clever Function Room, do what he needs to do, and return to the Main Room holding the integer 13


Show thread

However, he won’t go empty handed. He’ll take some data with him—the arguments you use when you call the function.

In the example in the previous tweet, Monty will take the integers 5 and 8 when he goes from the Main Room to the Function Room.

As Monty enters the Function Room, he’ll find two empty boxes at the entrance labelled first and second — these are the parameters from the function definition.

He’ll place the integer 5 inside the box labelled first and the integer 8 in the box labelled second. He will then place these boxes on the Function Room shelves.

Monty will then do whatever he needs to do in the Function Room.

When he’s done, he’ll return to the Main Room.

But once again, he won’t return empty-handed. He’ll take the contents of the box labelled output with him since this is what you wrote in the return statement.

Note that Monty does _not_ take the whole box labelled output with him but only its contents. In the example above, this is the integer 13

What will Monty do with this integer as he returns to the Main Room and shuts the Function Room door behind him?

If the function was called like this:

result = do_something_clever(5, 8)

then he’ll bring another empty cardboard box, place the integer 13 inside it, and label the box result. He places this box on the shelves in the Main Room.


Show thread

Anyway, let’s get to defining a function:

def do_something_clever(first, second):
"""do some stuff"""
output = first + second
return output

A function is a mini-program within a program.

So, in my mental image of how computer programming works, a function is another room…

When you define a function, you’re creating a new Function Room that’s adjacent to the Main Room.

There’s a door connecting the Main Room to the Function Room.

The label on the door says do_something_clever, the name of the function.

So, when you use the name do_something_clever, Monty will look around the Main Room and see the name as a label on a door leading to another room.

If you’ve called the function by adding parentheses, do_something_clever(5, 8), Monty will open the Function Room door and go through it.


Show thread

At the start of the program, if you use a word that’s in the red booklet, Monty will know what to do.

keywords like while, built-in functions like print, these are the things in this booklet.

When you create a variable, such as:

day = "Monday"

Monty gets an empty cardboard box, puts the string "Monday" inside the box and puts a label on the outside of the box which says day

Monty puts this box on a shelf in the Main Room

From now on, if you write day in your program, when Monty looks around the room he’ll find a box labelled day and he’ll get its contents—the string "Monday"


Show thread

Understanding Functions using the “Function Room” narrative

I use narratives to learn stuff… and to teach, too

What’s a narrative? It’s a way of connecting events or facts in a form of a story

But I promised to talk about The Function Room

so read on…

My mental image of a computer program is that of a small creature working in a room.

When you start writing a program, the Main Room is empty except for some shelves and a small red booklet called “built-in”

Monty — that’s the name of the little creature doing all the hard work — will look around the room whenever you use any name.

more in the next toot


Here's a post with #python in the hashtags so I can connect with more Python people. ;)

Hey everyone. I made it over here on Fosstodon. Happy to be here with you. ;)

I've released Textual version 0.4.0, which now has smoother animation!

See the blog post for details...

In case you want to go back to Day 1 of this series on Intermediate Python functions, here’s the link:

Show thread

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…


Show thread

– 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


Show more
Qoto Mastodon

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