I don't know if you have noticed it, but recently we have been working more on improving the code base
rather than improving the output of the program.
So specifically, we used functions.
We integrated functions in our code, even though the code was also working without functions.
The program was working because it's relatively a small program.
But if the program gets bigger, then you really have to use functions to be able to keep your code
organized.
So whenever you want to create a process, just put it in a function.
And in this video, we will go and work even further improving our codes.
So let's you remember the example of the barista and the coffee.
So let's talk about that again.
So I have a question for you.
When you ordered the coffee to the barista, where does the barista make the coffee?
Does he or she make the coffee in your table?
In the table you're sitting?
Or does the barista have a separate space where they prepare the coffee?
And the answer is, of course, they have a separate.
Place for that.
Otherwise things would get messy.
And that's what we want to do here in our court as well.
We want to separate the processes in a separate file.
So currently we are in Maine.
That pie, which is this file in here.
What I'll do now is I will right click over the project directory, which is the same directory where
main that p y is located.
So I will right click here and create a new python file.
You can name this file, anything you want.
I would like to name it just.
Functions on my charm.
I don't have to supply the dot pie extension because Pie chan will add it by default.
So that is a function that p y file and I'll just go to my main dot pie file and just cut these two
functions.
And pays them in functions that p one.
And I would like to open this file to the right side so you can see both files so main that P were here
functions that P in here.
I'll close all these.
No, I get all these red underlined.
Elements such as the function call here.
So it says are resolved to reference get to dos because this script now doesn't know anymore.
What get to do is same for right to dos.
So they are defined somewhere else and not in this script.
We can fix that by.
Saying from.
Functions.
Import.
Get to dos.
Comma.
Write to dos.
And now the red lines are gone.
So if I run the script, it will behave exactly the same as it did before.
Just show that to dos.
And here they are.
So why did I place the functions in another file?
Well, this is just a common practice.
It's a good practice to do because you want to organize the code when it gets bigger.
So it's better to have logical parts of the code in separate files so that the code doesn't get extremely
long.
So in this case, it's it's logical to put functions so procedures and processes in one file and that
simply import them in here.
That is the syntax to import.
Elements from another file to another file.
Now, this will work.
This syntax will work only when main that P and functions that P are in the same directory because they
are in the same directory.
This file.
Everybody knows where to find this functions.
So that is the name I gave to my dad's P file.
So that has to reflect that file.
And of course, these also have to reflect the names of the functions in here.
So those from an import are keywords which are part of this syntax.
Now, this is not the only way to import.
Functions.
Another way is to just say, Well, let me comment this.
So another way.
Is to say import functions.
And then you see that these are again in underlines.
Because these names, again, are not defined in the script.
They are not mentioned anywhere.
When we had that line, which is now commented out, so it's not recognised by Python, when we had
that line that meant that these were available, they became available in the script.
But now we have to follow a different approach.
If you do here import functions than here, you want to say functions don't get to dos.
And I guess now this also becomes a bit familiar, this syntax.
It becomes familiar to you.
So that's like the same syntax that you use.
To call methods, for example, user action that strip where user action is a string and strip is the
method which removes the spaces from this string.
The difference here is that this is a string and this is a module.
So it is it is this script.
But when you import the scripts here, then you call it a module.
That's the terminology.
So.
In other words, when we are in this mean that P word scripts and we import that other scripts, we
refer to that as the module.
Same thing like in the coffee example.
Where the clients could refer to the area where the coffee is made with another name and.
The body store itself with their colleagues, they can refer to that place using their own name.
So here in this may not be why we are in our table and we refer to that functions as the module.
Where something happens and this group is not interested about what happens there.
The script is only interested about getting the outputs of that.
Of those procedures, those functions.
So we get the outputs from there by calling that space.
So we can get now functions.
We can call functions from that space there.
So similarly, we want to mention functions.
That's right.
To do here.
Functions that get juice in there wherever you have this break lines.
There and here as well.
So now we don't have any more red lines.
The question is which way should you use this or that?
And that's a hard question, and it's not always easy to answer.
It depends how many functions you have in the module here.
So in our case, we only have two.
But if we had more, then you'd have to write all the names of the functions there and so on, divided
by commas.
So if that was the case, then it would definitely be better to just import the functions module and
then just refer to the functions of that module using functions as the first name separated by a dot.
So that would avoid us having to import all the functions one by one.
We could forget one of them, or it could become a long list here.
So that's why we have this other simpler way to import a module and then refer to them as here.
So if you have very few functions like we have here, you could use that.
But this is also fine to use.
And this can also make the codes more readable because by just looking at this parts here, you'll know
that get to dos comes from the functions module, so that gives you some extra information.
Whereas if you had only that without the.
Comments.
So you'd have something like that.
In that case, it's not easy to tell if get to dos was defined in the script or in another script.
Of course, you can look at the script and see if get to do is there, but it's easy to just tell.
Immediately if this is from the script or from another script.
So that's why I would suggest to use this syntax.
Lastly, it could happen that you may have more and more files, and in that case you may want to create
a directory.
Let's call this modules.
So this directory, which is in the same directory with main PI.
Now if I drag functions that's pi and drop it in modules, Python will ask me if I want to refactor.
So I refactor here in that case.
Pie chart change this from input functions to from modules input functions.
So this is the new syntax now.
And so as you see modules reflects the name of the directory here and functions reflects the name of
the module.
So if you ever have directories where you place files, then you want to follow these syntax points
to the directory name and then to the module.
In our case, this is not necessary, so I'll drag this back to the main directory and this will you
be used as just functions?
So that's about creating modules and importing them.
So this is both a script, as I mentioned.
From.
It's own perspective versus a script from the perspective of the other file where this is important,
this function is a module.
So I hope that makes sense.
We will run a few experiments in the next video to understand some things better.
So I'll see you there.