See all freeCodeCamp.org transcripts on Youtube

Speaker 1

14:00:00

Whether or not your code is adhering to your own type hints. And that program here is called MyPy. And it's just 1 of several. But this one's particularly popular and can be easily installed in the usual way with pip install MyPy.

Speaker 1

14:00:13

And its own documentation is at this URL here. But we'll use it quite simply to check whether or not our variables are indeed using the right types. So how can we go about doing this? All right, let me go back here to VS Code, clear my terminal window, and in fact, erase meows.py as it currently was.

Speaker 1

14:00:30

And let's implement a different version of meows that quite simply has a function called meow that does the actual meowing on the screen. And then I'm just going to go ahead and call that function down toward the bottom. I'm not going to bother with the main function just for simplicity so that we can focus, as always, only on what's new. So here we are defining a function called meow.

Speaker 1

14:00:47

It's going to take a number of times to meow, for instance, n for number. And inside of this function, I'm going to do my usual for underscore in the range of n, go ahead and print quote unquote meow. So based on our earlier code, I think this is correct. I've not bothered defining the variable as I.

Speaker 1

14:01:06

I'm instead using the underscore because I'm not using it anywhere. But I think I now have a working function whose purpose in life is to meow 0 or 1 or 2 or 3 or more times. Well, let's use this function. Again, not bothering with main.

Speaker 1

14:01:17

I'm just going to keep my function at the very top because there's only 1. And I'm going to write my code here on line 6. So I'm going to give myself, I'm going to ask the user for a number. And I'm going to go ahead and prompt them in the usual way for that number of times to meow.

Speaker 1

14:01:32

And now I'm going to go ahead and call meow on that number. Now, some of you might see what I've already done wrong. But perhaps I myself don't. So let me go into my terminal window and run Python of meows.py, the goal being to prompt me.

Speaker 1

14:01:47

This seems to be working. I'm going to type in 3. And I would expect now the meow function to print out meow 3 times. Enter.

Speaker 1

14:01:55

But no, there's some kind of type error here. Stir object cannot be interpreted as an integer. Why might that be? Why might that be?

Speaker 2

14:02:07

Because the input function returns a string instead of an integer.

Speaker 1

14:02:12

Exactly. The input function returns a string or a str, not an int. So in the past, of course, our solution to this problem has just been to convert the string to an int by using the int function. But now let me start programming more defensively so that, honestly, I don't even find myself in this situation at all.

Speaker 1

14:02:30

Let me go ahead and do this. Let me add what's called a type hint to my function that explicitly specifies for meow what type of variable should be passed in. I'm going to go ahead now and change the very first line of my code in my function to specify that n colon should be an int. And this is a type hint.

Speaker 1

14:02:50

The fact that I've added a colon, a space, and the word int is not creating another int or anything like that. It's just a hint, an annotation, so to speak, to Python that this variable on the left called n should be an int. Now, unfortunately, Python itself doesn't care. Because again, these type hints are not enforced by the language.

Speaker 1

14:03:12

And that's by design. The language itself in the community prefers that Python be dynamically typed, not so strongly typed, as to require these things to be true. But if I run meows.py type in 3 again, the same error is there. But let me go about trying this mypy program, an example of a program that understands type hints and, if I run it proactively myself, can find bugs like this in my code before I, or worse, a user, actually runs and encounters something cryptic like this type error here.

Speaker 1

14:03:43

Let me clear my terminal window and this time run mypy space meows.py. So I'm going to run mypy on my program, but I'm not running Python itself. When I hit Enter, we'll see this. All right, we see now that mypy found apparently an error on line 7.

Speaker 1

14:04:01

Error, argument 1 to meow has incompatible type str expected int. So it's still an error message. But MyPy is not a program that my users would use. This is a program that you and I, as programmers, would use.

Speaker 1

14:04:15

And because we have run this code now before we, for instance, released this program to the world, I can now see even before the code is called or run, oh, I seem to be using my argument to meow wrong. I had better fix this somehow. Well, I can actually go about hint adding type hints even to my own variables here so as to catch this another way, too. If I know on line 6 that I'm creating already a variable called number, and I know already that I'm assigning it equal to the return value of input, I could give mypy and toolslikeit another hint and say, you know what?

Speaker 1

14:04:51

This variable called number should also be an int. That is to say, if I now start getting into the habit of annotating all of my variables and arguments to functions, maybe mypy can actually help me find things quite quickly as well before I get to the point of running Python itself. Let's go ahead and try this again. Mypy of meows.py and hit Enter.

Speaker 1

14:05:13

And this time, notice that mypy actually found the mistake a little more quickly. Notice this time it found on line 6 that error, incompatible types in assignment, expression has type str, variable has type int. So before I even got to the point of calling meow, line 6, via this type int, When used and analyzed by mypy, has helped me find, oh, wait a minute. I shouldn't be assigning the return value of input to my variable called number in the first place.

Speaker 1

14:05:42

Why? Mypy has just pointed out to me that 1 returns a str. I'm expecting an int. Let me fix this now instead.

Speaker 1

14:05:48

All right, so let me clear my terminal window. And now let me do what most of you were probably thinking I should have done in the first place after all of these weeks. But now let me go ahead and convert the return value of input to an integer. For today's purposes, I'm not going to try to catch any exceptions or the like.

Speaker 1

14:06:03

We're just going to assume that the user types this in properly. And now let me go ahead and run mypy of meows.py, having not only added 2 type ints to my argument, to my function, to my variable down here on line 6. And I've also now fixed the problem itself. Let me go ahead and run mypy and success.

Speaker 1

14:06:23

No issues found in 1 source file. Now it's more reasonable for me to go and run something like Python of Meows And just trust that when I type in 3, at least I'm not going to get a type error. That is, I didn't mess up as a programmer with respect to the types of my variables. Why?

Speaker 1

14:06:40

Because when I wrote the code in the first place, I provided these annotations, these hints, that inform tools like MyPy that my intention had better line up with what the actual code does. Let me pause here and see if there's now any questions on type hints or MyPy.

Speaker 3

14:06:57

Is it common, or how common is it for those to be used? Or is it just that it's more used in more complex code, where it's more difficult to ensure that you're actually using the correct type in the way that you're using variables? DAVID MALAN HANSON-COPERNUCCI-HILLS

Speaker 1

14:07:13

It's a good question, and it's rather a matter of opinion. Python was designed to be a little more versatile and flexible when it comes to some of these details, partly for writeability, to make it easier and faster to write code, partly for performance, so that the program like Python doesn't have to bother checking these kinds of details. We can just get right into the code.

Speaker 1

14:07:31

The reality, though, is that strong type checks do tend to be a good thing for the correctness of your code. Why? Because programs like MyPy can find before your code is even run if there's already known to be an error. And it tends to be good for defensive programming.

Speaker 1

14:07:48

So the situation, essentially, is that within the Python ecosystem, you can annotate your types in this way. You can use tools to use those type hints. But to date, Python itself does not enforce or expect to enforce these conventions. In larger code bases, in professional code bases, commercial code bases, probably, depending on the project manager or depending on the engineering team, they may very well want themselves to be using type ints.

Speaker 1

14:08:15

Why? If it just decreases the probability of bugs. In fact, let me propose now that I imagine a situation where, instead of expecting that meow prints meow, meow, meow some number of times, suppose that I accidentally assume that the meow function just returns meow some number of times. We saw, for instance, when focusing on unit tests, that it tends to be a good thing to have functions that return values, be it an int or a string, rather than just having some side effect, like printing things out themselves.

Speaker 1

14:08:46

So perhaps I'm still in that mindset, and I've just assumed mistakenly for the moment that meow returns a value, like meow, or meow meow, or meow meow meow, a big string of some number of meows, rather than just printing it itself, as it clearly does at the moment on line 3. And therefore, suppose that I accidentally did something like this. Rather than just getting the number and passing it to meow, suppose I did this. Suppose I declared a new variable called meows, the type of which I think should be str.

Speaker 1

14:09:18

And suppose, again, I assume accidentally that meow returns to me a string of those meows so that I myself can then print them later. This would be a little more conducive, arguably, to testing my meow function. Why? Because I could expect that it's returning meow, or meow meow, or meow meow meow, separated by new lines, returning a str that I could then assert equals what I expect it to be in something like a unit test.

Speaker 1

14:09:43

I'm not going to bother writing any unit tests now, But let's just suppose that's the mindset I'm now in. And so on line 7, I'm assuming that I want to assign the return value of meow to a new variable called meows, which I've annotated with this type hint as being a str, just so we can see another variable. This one's not an int, but a str instead. Well, let me go ahead and run this code now.

Speaker 1

14:10:07

Python of meows.py, Enter, typing in 3. And you'll see a curious bug. Meow, meow, meow, none. Well, why is that?

Speaker 1

14:10:16

Well, it turns out at the moment, my meow function only has a side effect. It just prints out meow some number of times. It doesn't explicitly return a value, as it would if there were literally the return keyword there. By default, then, When a function in Python does not explicitly return a value, its implicit return value is, in effect, none.

Speaker 1

14:10:36

And so what we're seeing here is this. On line 8, because I'm assigning the return value of meow, which is none, to my meow's variable, line 3 is what's still printing meow, meow, meow. And line 8 is what's now incorrectly printing none, because I accidentally thought that meow returns a value, but it doesn't. So its return value is effectively none.

Speaker 1

14:11:02

So I'm printing, very weirdly, the word none at the bottom. So how could I go about catching this kind of mistake, too? Like, I might make this mistake, but maybe with less frequency if I'm in the habit of annotating my code with this new feature called type hints. What you can do here is this.

Speaker 1

14:11:20

Let me clear my terminal window to get rid of that artifact. And up here, let me additionally specify with some funny looking syntax that my meow function actually, by design, returns none. So you literally use this arrow notation in Python. When hinting what the return value of a function is, you would do this.

Speaker 1

14:11:41

After the parentheses, a space, a hyphen, a greater than symbol, like an arrow, and then another space, and then the type of the return value. For now, it's indeed going to return none. But now, at least, I can catch it like this. If I now run not Python, but MyPy on my code, which would be a habit I'm now getting into if using type hints.

Speaker 1

14:12:03

Check that I'm using all of my types correctly before I even run my program. We'll see that now mypy has found on line 7 that meow, quote unquote, does not return a value. And mypy knows that because I have proactively annotated my meow function as having none as its return value. So now mypy can detect that.

Speaker 1

14:12:23

I should now realize, oh, wait a minute. I'm being foolish here. Meow clearly does not return a value. I should not be treating it like it does on line 7.

Speaker 1

14:12:33

Let me go about actually fixing this now. So how do I go about fixing this? Well, let's practice what we preached in our focus on unit tests, having a function like meow not have side effects, like printing itself, but let's have it return the actual string. And I can actually do this kind of cleanly.

Speaker 1

14:12:48

Let me clear my error message in my terminal window here. Let me get rid of the loop here. Let me say this time that, OK, fine, meow is going to return a value, an actual str, or string. So I've changed none to str.

Speaker 1

14:13:02

And now I can implement this in any number of ways, maybe even using a loop. But recall that we have this syntax in Python, which will, I think, solve this problem for us. If I want to return a string of n meows, What I can actually do, recall, is this. Return quote unquote meow backslash n times that number n.

Speaker 1

14:13:23

So it's kind of a clever one-liner, avoids the need for a for loop or something more involved than that to just say, multiply meow backslash n against itself 3 times, or n times, in this case, in general, so that I get back a big string of 0 meows, 1, 2, 3, or many more meows instead. I think now my code on line 6 is actually Correct. Now I've changed meow to behave the way I was pretending to assume it always worked. So I'm storing in meows, plural, a variable that's of type str, because now meow does have a return value of type str itself per this type hint as well.

Speaker 1

14:14:04

All right, let me go ahead now and print meows. But because each of my meows comes with a trailing new line, the backslash n, I'm going to proactively fix what would be a minor aesthetic bug. And I'm just going to avoid outputting an extra new line at the end of those 3. So if I run Python of meows.py now, type in 3, there's my meow, meow, meow.

Speaker 1

14:14:25

And now, no mention of none. Questions now on type hints and these annotations in MyPy and using them to defensively write code that just decreases, hopefully, the probability of your own bugs.

Speaker 4

14:14:45

In the return, There is a double quotes that have meow slash n. Why the program don't take it as a string?

Speaker 5

14:14:53

DAVID MALAN

Speaker 1

14:14:54

Why does the program not take it as a string? So recall that Early on in the class, we looked at plus as a concatenation operator that allows you to join a string on the left and the right. Multiplication is also an overloaded operator for strings, whereby if you have a string on the left and an int on the right, it will multiply the string, so to speak, by concatenating or joining that many meows all together.

Speaker 1

14:15:22

So this is a feature of object-oriented programming, an operator overloading, as we saw it in the past. Other questions on type hints or MyPy? AUDIENCE 2 Can we not typecast this data type

Speaker 5

14:15:37

of this variable number? DAVID MALAN

Speaker 1

14:15:38

No, you still, and let me correct the terminology, it wouldn't be called typecasting in this context because it's not like C or C++ where there's an equivalence between these types, you're technically converting on line 5 a str to an int. You do still have to do this because mypy, for instance, would yell at you if you were trying to assign a str on the right to an int on the left. You must still use the int function.

Speaker 1

14:16:02

Int itself is still a function. It's not a type hint. But the word int is being used in another way now in these type hints. So this int is still a function call, as it always has been.

Speaker 1

14:16:14

This syntax on the left is another use of the keyword int, but in the form of these type hints. So you still have to do the conversion yourself. All right, let me propose that we transition to another feature of Python that's worth knowing, especially since it's 1 that you'll see in the wild when you see code or libraries that other folks have written, namely something known as a doc string or document strings. It turns out in the world of Python, there is a standardized way per another PEP, Python Enhancement Proposal, this 1 257, that essentially standardizes how you should document your functions, among other aspects of your code.

Speaker 1

14:16:51

And so for instance, let me go back to my meows.py file here. And let me propose that we now start documenting this code, too, so that I know what the meow function does. And in fact, the standard way of doing this using docstring notation would be as follows. To comment this function, not above it, as you might be in the habit of doing with code in general, but actually inside of it.

Speaker 1

14:17:15

But instead of commenting it like this with the usual hash comment sign, like meow n times, it turns out that when you're formally documenting a function, like meow in this case, you don't use regular inline comments, so to speak. You use this syntax instead. You use triple quotation marks, either double or single. Then you write out your comment, meow and times.

Speaker 1

14:17:42

And then you write the same again at the end. So either 3 double quotes at the start and the end, or 3 single quotes at the start and the end. And Python has built into it certain tools and certain assumptions that if it detects that there is a comment using this docstring format, triple quotes on the left and the right, it will assume that that's indeed the documentation for that function. And it turns out in the Python ecosystem, there's a lot of tools that you can then use to analyze your code automatically, extract all of these document strings for you, and even generate web pages or PDFs of documentation for your own function.

Speaker 1

14:18:20

So there's these conventions via which, if you adhere to them, you can start documenting your code as for other people by generating automatically the documentation from your own code without writing something up from scratch manually. Now, it turns out if your function does take arguments and perhaps does a bit more, there are multiple conventions for how you can document for the human programmers that might be using your function, whether it's you or a colleague or someone else on the internet to actually use these doc strings to standardize the information they're in. So you might see this instead. Using these same triple quotes above and below now, you might see your 1 sentence explanation of the function, meow n times.

Speaker 1

14:19:05

Sometimes, depending on the style and use, it might actually still be on the first line, but with a blank line below it. But I'll keep everything uniformly indented. And this is a convention used by some popular Python documentation tools as well. You would say syntax like this, param n colon, and then a description of what n is, number of times to meow.

Speaker 1

14:19:26

Then colon type n colon int, which just indicates that the type of n is an integer. Then if this function could actually raise an exception, you can document that too. And actually, it's not really, well, it's arguably my mistake here. If n comes in as an argument and is not, in fact, an int, Maybe it's a float or a string or something else.

Speaker 1

14:19:48

The multiplication sign here is not going to work. It's not going to multiply the string. It's going to trigger what I know from experience to be a type error. So I'm going to go ahead and proactively say in my own documentation that this function, technically, if you use it wrong, could raise a type error.

Speaker 1

14:20:04

Even though I'm hinting up here with this annotation that you should pass in an int, again, Python doesn't enforce that. So if you pass in a float, this might, in fact, raise this function a type error. And so that might happen if n is not an int. And then lastly, I might say, for clarity's sake, for other programmers, this function returns a string of n meows, 1 per line.

Speaker 1

14:20:28

And the return type of that value, rtype, is going to be str. Now, all of this syntax here, as I've used it, is not Python per se. This is a convention known as restructured text, which is a form of Markdown-like language that's used for documentation, for websites, for blogs, and even more. But it's 1 of the popular conventions within the world of Python to document your own functions.

Speaker 1

14:20:52

So this does not have anything to do fundamentally with type hints. Type hints are a feature of Python. What I'm doing here is just adhering to a third-party convention of putting, in between a Python doc string from the start to the end, a certain standard format so that these third-party tools can analyze my code for me, top to bottom, left to right, and ideally generate documentation for me. It can generate a PDF, a web page, or something else so that I or my colleagues don't need to not just only write code, but also manually create documentation for our code.

Speaker 1

14:21:29

We can keep everything together and use tools to generate the same for us. Any questions now on these doc strings, which, again, are a convention of documenting your own code, often following some standard syntax?

Speaker 6

14:21:45

Yeah, so when you say you would document it and put it in a PDF, is the purpose of doing this to publish it and share your function so other users can use it?

Speaker 1

14:21:56

Absolutely. In the past, when we have installed some third-party libraries, for instance, Cowsay a few weeks back, recall that I showed you what functions it had. But if you read the documentation, you might actually see that it was documented for us by the author of that program. Now, I don't believe they were using this particular syntax.

Speaker 1

14:22:13

But it was definitely useful for you and me to be able to read some web page or PDF telling us how to use the library, rather than wasting time reading through someone else's code and trying to infer what functions exist and how to use them. It just tends to be much more developer friendly to have proper documentation for our own code or libraries as well. Other questions?

Speaker 3

14:22:34

Yeah. When with doc strings, when it's used to generate a PDF or whatever, does it include any of the code? So if you're referencing in your comment, if you're referencing the code and the comment itself might not make sense without seeing the code. Do these include it?

Speaker 3

14:22:53

DAVID MALAN

Speaker 1

14:22:53

LANGSTORM Short answer, you can do that. Not in the convention I'm using here. But there's actually a clever way to write in your doc strings, sample inputs to your functions, and sample outputs for your functions.

Speaker 1

14:23:07

And if you use a different tool that we've not discussed, that tool will run your code using those sample inputs. It will check that your outputs match your sample outputs. And if not, the program will yell at you, saying you've got a bug somewhere. So this is just another way where you can use doc strings to not only document but even catch errors in your code.

Speaker 1

14:23:27

This has been a lot, and there's a bit more to go. Why don't we go ahead here and take a five-minute break? And when we resume, we'll take a look at yet another feature of Python, yet another library to write code faster. All right, suppose we want to modify this Meow's program to actually take its input not from the input function in the blinking prompt, but from the command line.

Speaker 1

14:23:46

Recall in our discussion of libraries that you could use something like sys.argv to get at command line arguments that a human has provided when you're running your program. So why don't we whip up a version of meow that uses command line arguments instead of, again, input. So I'm going to go ahead and delete what we've done here thus far. And let me propose that we import sys, as we've done in the past.

Speaker 1

14:24:05

And let's do this. How about if the user does not type any command line arguments, then my program will just meow once, just so that it does something visually interesting. Otherwise, let's also give the user an option to specify how many times I want the cat to meow. So let's start simple.

Speaker 1

14:24:24

Let's first of all go ahead and do this. If the length of sys.argv equals equals 1, That is, the user only typed the name of the program and nothing else in their command. Then let's go ahead and just print out 1 meow like this. Else, for now, let's go ahead and print out something like this.

Speaker 1

14:24:46

Else, go ahead and print out, let's say, usage for the program, which will be usage of meows.py, just so that the user knows that the program itself is called meows.py. All right, now let me go down to my terminal window and start to type python of meows.py. And at this point, notice that the length of sys.argv should indeed be 1. Why?

Speaker 1

14:25:05

Well, Python, the name, doesn't end up in sys.argv at all, ever. But meows.py, the name of the file, does. And it's going to go in sys.argv 0. But that's only 1 element.

Speaker 1

14:25:16

So the length of this thing is 1. There's nothing more to the right. So when I hit Enter now, we should see, indeed, 1 meow. If I don't cooperate, suppose I do something like meows 3, Enter, then I'm going to see a reminder that this is how you use the program.

Speaker 1

14:25:30

And this is a common convention to literally print out the word usage, a colon, then the name of the program, and maybe some explanation of how to use it. So I'm keeping it very simple. But let's be a little fancier. What if I really wanted the user to type in maybe not 3, but something more sophisticated?

Speaker 1

14:25:46

And in fact, when controlling programs from the command line, it's very common to provide what are often called switches or flags, whereby you pass in something like dash n, which semantically means this number of times, then often a space, and then something like the number 3. This still allows me to do other things at the command line if I want. But the fact that I've standardized on how I'm providing command line arguments to this program with dash n3 is just a more reliable way now of my program knowing what does the 3 mean. It's a little less obvious.

Speaker 1

14:26:21

If I just do meows.py space 3, well, what does the 3 mean? At least with syntax like dash n 3, especially if you've read the documentation for this program, Ultimately, oh, dash n means number of times. Got it. It's a way of passing in 2 additional arguments, but that have some relationship between them.

Speaker 1

14:26:37

So how do I modify my program to understand dash n 3? Well, if I'm using sys like this, I could do this. L if the length of sys.argv equals this time 3. Because notice, there's 1, 2, 3 things at my prompt.

Speaker 1

14:26:57

So sys.argv 0, 1, and 2, 3 things total separated by spaces. If it equals 3, and let's be safe, and sys.argv bracket 1 equals equals dash n, then let's go ahead and do this. Let's go ahead and convert sys.argv of 2 to an integer and assign it to a variable, for instance, called n. And then let's go ahead and do this.

Speaker 1

14:27:26

For underscore in the range of n, Let's go ahead and print out some of these meows. Now, there's still an opportunity maybe to consolidate my print lines with meow, but for now, I'm going to keep these ideas separate. So I'm going to handle the default case with no arguments up here as before. And now, more interestingly, I'm going to do this, to be clear.

Speaker 1

14:27:45

I'm going to check if the user gave me 3 command line arguments, the name of the program, dash n, and a number. If indeed the second thing they gave me in sys.argv of 1 equals equals dash n, then I'm going to assume that the next thing, sys.argv of 2, is going to be an integer. And I'll convert it to such and store it in this variable n. And now, just using a loop, I'm going to print out meow that many times.

Speaker 1

14:28:12

So it's kind of a combination of our earlier focus on loops, our earlier focus on command line arguments. Just creating a program that allow me to claim is representative of how a lot of command line programs work, even though we've typically not used many like this. But it's very common to configure a program, 1, you're about to run it in the command line, with something like these command line arguments, like dash n or dash something else. Now I'm going to go ahead and hit Enter.

Speaker 1

14:28:37

And I think I should see, indeed, 3 meows. By contrast, if I do 2 at the end, I should see 2 meows. If I do 1, I should see 1 meow. And frankly, if I just omit this altogether, I should see 1 meow as well, because that was my default case earlier.

Speaker 1

14:28:56

And now let me allow us to assume that this program eventually gets more complicated, right? Let's imagine a world where I don't want to support just dash n. Maybe I want to support dash a and dash b and dash c and dash d and a whole lot of others. Or heck, at that point, I should maybe give them words.

Speaker 1

14:29:14

So maybe it's dash dash number. It's indeed a convention in computing, typically, to use single dashes with a single letter, like n, but use double dashes if you're actually using a whole word, like number. So the command line argument might be dash n, or maybe it's dash, dash, number. But you can imagine just how complicated the code gets.

Speaker 1

14:29:34

If now you want to support dash n, dash a, dash b, dash c, and so forth, you're going to have to be checking all over the place. And what if they come in a different order? You're going to have to check, is dash n first, or is it second, or is it third, or is it fourth? I mean, this just becomes very painful very quickly just to do something relatively simple like allow the user to pass command line arguments into your program.

Speaker 1

14:29:55

Well, this is why, as always, there exist libraries. And Another library that comes with Python that's probably worth knowing something about is this 1 here called argpars. In fact, with a lot of the tools I, myself, or CS50's team writes in Python, we very frequently use argpars whenever they are more complicated than a lot of our class demos and a little more similar to this 1, where we want to allow the user to pass in configuration options at the command line. And by supporting things like dash n, or dash a, or dash b, or dash c, argpars is a library that, per its documentation, just handles all of this parsing, so to speak, this analysis of command line arguments for you automatically.

Speaker 1

14:30:37

So you can focus on writing the interesting parts of your program, not the command line arguments part. So how might we use this? Well, let me go back to VS code here. Let me clear my terminal window.

Speaker 1

14:30:47

And let me propose that I rewrite this using not sys, but actually using arg parse. And I'm going to start a little simple and then build back up. So let me throw all of this away for now and instead import arg parse. Arg parse stands for argument parser.

Speaker 1

14:31:01

To parse something means to read it, kind of pick it apart to analyze it. So this is indeed going to do just that for me. Now let me go ahead and do this. And for this library, it's helpful to know a little object-oriented programming like we all now do.

Speaker 1

14:31:14

I'm going to create a variable called parser. I could call it anything I want. I'm going to set it equal to the return value of argparse.argumentparser with a capital A and a capital P, a constructor for a class called argument parser that comes with Python itself within this library here. Now I'm going to configure this argument parser to know about the specific command line arguments that I myself want to support in my program.

Speaker 1

14:31:41

So I'm going to do this. Parser.add underscore argument. So that's apparently a method in the parser object, I'm going to add an argument of dash n. Easy enough.

Speaker 1

14:31:52

Now I'm going to go ahead and actually parse the command line arguments. I'm going to do args, or I could call the variable anything I want, parser.parseArgs. And by default, parseArgs is going to automatically look at sys.argv for me. I don't need to import sys myself.

Speaker 1

14:32:09

I can leave the argument parser its code to import sys, look at sys.argv, and figure out where dash n or anything else actually is. And what's nice now, because this line of code here results in the parser having parsed all of the command line arguments, I now have this object in this variable called args, inside of which are all of the values of those command line arguments, no matter what order they appeared in. Not such a big deal when I've only got 1, because it's only going to go in 1 place at the end. But if I've got dash n, dash a, dash b, dash c, you could imagine them being in all different orders.

Speaker 1

14:32:44

They definitely don't have to be alphabetical. The user should be able to type them in any order they want. That's better for usability. Arg parser is going to figure all of that out for me.

Speaker 1

14:32:53

And all I have to do now is this. If I want to iterate over that many numbers of arguments, and that many mouse, rather, I can do this, for underscore in the range of the int conversion of args.n. So dot is the syntax we kept using to access things like properties inside of an object. And that's what args is.

Speaker 1

14:33:15

It's an object returned by the parseArgs function for me. I'm going to go ahead now and print out quote unquote meow this many times. So it's not super simple. Like these are 3 new lines of code I need to write and rather understand.

Speaker 1

14:33:29

But it's already a little simpler and more compact than my if and my elif and my ors and my ands and all of that Boolean logic. It's handling a lot of this for me. So if I didn't make any mistakes, let me run Python now of meows.py, Enter. And I did make a mistake here.

Speaker 1

14:33:45

I did make a mistake. What's wrong here now? What's wrong? Well, I definitely didn't run it the way I intend.

Speaker 1

14:33:52

So dash n 3, Enter. So it does work. But if I don't cooperate, this actually seems to be a worse version. If I don't pass in dash n in a number, it just errors with a type error.

Speaker 1

14:34:04

Int must be a string. None is what came back. So there's clearly an error here. But the library is more flexible.

Speaker 1

14:34:11

I can actually provide some documentation on how to use this thing. So how do I know how to use this? Well, typically, it's conventional in Python and in a lot of programming environments to run a program with a special argument, dash h or dash dash help. And almost always, I will claim, you'll then see some kind of usage information.

Speaker 1

14:34:31

Indeed, that's what I'm looking at now. I just ran Python of meows.py space dash h. I'll do it again. Let me clear my screen and this time do dash dash help in English, Enter.

Speaker 1

14:34:41

And I see the same thing. It's not very useful at the moment. It just shows me what the usage is up here. And this is kind of interesting.

Speaker 1

14:34:49

This is a standard syntax in computing. And we've kind of seen it in Python's documentation before. This just means that the program's name is, of course, meows.py. Square brackets, as almost always in documentation, means it's optional.

Speaker 1

14:35:03

So I don't have to type dash h, but I can. I don't have to type dash n and another value, but I can. And then down here is some explanation of these options. And more verbosely, It's showing me that I can also do dash dash help and not just dash h.

Speaker 1

14:35:18

But this is so generic. This has nothing to do with my program. This is not going to help my users when I actually release this software for the world. So let me go ahead and improve it.

Speaker 1

14:35:26

Let me add a description to my argument parser that the humans will see. Meow like a cat, quote unquote, is going to be the value of this named parameter called description. And let me also add a help parameter to my dash n argument that just explains what dash n means, number of times to meow, quote unquote. I'm not going to change anything else.

Speaker 1

14:35:48

But I am going to go back to my terminal window and run Python of meow. I'm going to run Python of meows.py dash h, or equivalently, dash dash help. And now notice that this is a little more user friendly. If I scroll up, we still see the same usage, but there's a quick sentence in English of explanation that this program meows like a cat.

Speaker 1

14:36:08

And if I look at the options now, oh, that's what n means. It's the number of times to meow. And this capital N, a middle variable, if you will, is just indicating to me that I need to type a number by convention after the lowercase dash n. So it would be nice, though, all that said, if my program still didn't just break when I run it without any command line arguments, right?

Speaker 1

14:36:32

Ideally, my program would handle this just like my manual version did when I used sys.argv myself. So we just need to add a little more functionality to this library. And if I read the documentation, I'll see that add argument takes yet another named argument, if you want. You can specify a default value for dash n, for instance, 1.

Speaker 1

14:36:52

And I'll do that there. And you can further specify that it's got to be an int. And what this will additionally allow me to do is, if I tell arg parser to make sure that the value of dash n is an int, I don't need to do the conversion manually. I can just trust down on line 7 that when I access the property called n inside of my args object, it's going to be automatically an int for me.

Speaker 1

14:37:16

And again, this is the value of a library. It let it do all of the work for you so you can get back to focusing on the interesting project at hand, whatever problem it is you're trying to solve. Like in this case, granted, not that interesting, but meowing like a cat. Let me go ahead now and run Python of meows.py and hit Enter this time.

Speaker 1

14:37:35

No arguments, and now it meows. Why? Because I specified that if I don't, as a user, specify dash n, it's going to have a default value of 1, apparently. And I don't have to convert that value from a str to an int, because I told arg parser, please just make this an int for me.