 So Seema, what do we mean by productivity tools? What kind of productivity? Yeah. So throughout the day, you have run many of the exercises already on examples, and you have encountered probably many errors. You have encountered many, like when you have a run code, you get an error or something in your code. Of course, when we are talking about, for example, exercises in this course, there are these are small programs that you run. But when you start to write your own program, we'll talk about scripts tomorrow. So a bit more about how do you write, and also about modules and libraries, how do you write bigger programs? When it comes to this, regarding these bigger programs, you usually have this situation where it's a big thing, and you can have errors in multiple places. And we are all humans, so we don't write perfect code. Like nobody writes perfect code, and that's completely normal. And for that, programmers and people who write programs, they have written things that help with the tool, help with dealing these problems. And well, the most common is if you have an editor that has syntax highlighting, like Jupiter has. So basically, it's tools that make your human effort more effective. Yes. So let's say you have a VS code or something, and it can give you autocompletion or something. Like these are already productivity tools. They improve your productivity when you code. But there's different colors of productivity tools, or different types of productivity tools, and these are the most common ones, of course. But then there's other tools that are specifically designed to fix certain things about your programs or help you fix certain things about your programs. So for example, let's think about what the Python language is. So if you want to give a terminal, or Python terminal, and run the first example that we have there in the code. So if you try to run what we have in the... A terminal or Jupiter notebook? You can take a notebook or something. Okay. Sure. Yeah. I have to set it in name. If this is a follow-along, you don't need to type it this, by the way. So each language has a syntax. So like program language has a syntax. And sometimes you might do something that is not permitted in that language. So for example, here you cannot assign true to be one, because you're not allowed to change the true value. So you have to get a syntax error. So you have a problem in the syntax of what you have been writing. Like the program language doesn't understand what they're doing. Of course, in these cases, it's like a trivial problem. But if you have a big program and you forget to write one extra bracket or one extra comma somewhere or something, you get the same syntax error and it can be really tedious to find out this... ...better not. Yeah, especially if it's at the end of your program. I guess it's better to know right away, rather than have to save it and write it in. For this reason, people have written these linters. So they can move like lint. I think that's the name, like why they have been written. So they can move like extra stuff and bad stuff from the code. And they can spot these syntax errors. So some popular linters are this rough, pylint and flake8. But for this example, let's try with pylint, which should be installed in the example. Okay, so I'll type. So in order to open the script, so we'll talk more about this tomorrow. Here's what I can write, click and copy the link. And in JupyterLab, go to File, open from URL and paste the link. Okay, I have to use Control-V and click Open. And here it is. So it's both saved the file and has opened it in the JupyterLab here. Yeah, and this program, usually when you get programs on the internet, when you use code by other people, or if you write a code, you might write it as a script. But in this case, it's an example script. And by quick glance, it looks like Python code. So what's the problem? But let's try to use pylint to check if there's any problems here. So the examples here use the command line. So there is possibility of getting these linters working in JupyterLab, but unfortunately, well, you need to install specific packages for that. And for this example, let's try with the terminal. So we're showing from the command line, we think we've made this where if you're using the anaconda that should work on all operating systems, but if not, then take a step back, watch us, and don't worry. Yeah, you don't need to run these examples while we are. So I've made a new terminal here and I can scoot this out here. So it shows I've been, oh, I wanted this to open in the terminal. If I click plus here, okay. So opening it this way has put me at the right place where my Python stuff is. Okay, so what do I do? I try running the linters. Yeah, let's try running pylint and run the example. Oh, pylint, lint example. So I push tab, it filled out the name. I push enter. And, okay. So now we get like an error. So we say, we see that there's like a, like first the name of the file, like lintexample.py, then we get a line number four and then we get a 31. I'm not certain what the 31 actually is. I think it's called like, yeah, column 31. And then we get an error code, like E something, like an error, 0, 0, 0, 1, passing failed on a matched bracket. So if we now look at the line four of the code and scroll down, we noticed that there's an extra bracket there. Well, actually the Jupyter lab highlights it for us. It marks it as red already, but which is nice. And we probably would help you not make this error, but it's easy to like see that, okay, like there's a, now that we see it, we can remove it. So let's remove that and save the file. I remove that. I save, how do I save here? File, save all, I guess, we're good. And then we rerun the linter. Yeah, let's rerun it and see what happens. So here in this terminal, I can push the up arrow key instead of typing the whole thing again. Yeah. So now we, it's running again. Why is it so slow? Yeah, I don't know. And we got plenty of other errors. And let's look at these one by one. So maybe if you can close the tab on the left side. Yes. Okay. So at the top, we see that, okay, on the line one, we get this C something missing module doc string. So, okay, now this is like a, like a code style warning that you should have in your module, you should have a documentation string there, but okay, this is not an error. It's just good practice. So let's not look at that too much. Yeah. On line four, we see, and also on line four, column four, line four, column 19, and line five, column four, we see it's undefined variable NP. So the linter doesn't understand what NP is. It hasn't been defined yet. And this, like, this is explained by the last line in the error message, which is that on line one, we have an unused import numpy. So we imported numpy, just import numpy, instead of import numpy as NP. So that's why we got this error, but it was hard to spot because it was valid code. Like it looked valid, but we had a, had a mistake in the code because we did the import wrong. Should I fix it? Yes, let's fix it. If you look at also the end of the output for the pile-inter, you see that it gave a code rating, and the code rating was zero because it knows that, okay, this code won't run. So let's give it the zero rating, like it's zero out of 10 bad code. And now that we have fixed it, let's try running the linter again. Okay, I save all and push up arrow key again. So now we see that it shows me, that it shows that it's still missing the module doc string. So it gives a code warning on it, but the other problems have been solved. So now it rates it as 8.33 out of 10. And it shows the previous run. So what was the improvement? And this is to me like the most fun part of linter because it like gamifies the coding. Like how high can your score go? Like how can you get the 10 out of 10 for the linter? And basically the idea behind the linter is that it allows you to spot the errors and fix these kind of like coding style and coding problems that you might have in your code before you even run the code. So you might get like, you get coding done faster and you get a better result out of it. So let's try... So should we go to the first exercise already, maybe? Or do we have any questions in there? There's a good question. Why can't the linter show all errors to begin with? So why does it only show the syntax error first? Yeah, so that's a good question. And I think that is related to... Yeah, that's a good question. That's probably how the linter has been designed internally. Like there's different kinds of like syntax errors. There's like egregious ones, like for example the true equals one or the brackets. Like if it doesn't know how to pass the input, like basically in the first example, we had the extra bracket. So the linter didn't know that, okay, like how should I pass this, like even this text, because like I don't understand what's happening here because suddenly we get an extra bracket and I don't understand like is this valid code. Like it doesn't understand the input. In the second example, there's something wrong in the input. So it's like there's a first kind of an error which is like, okay. Yeah, it doesn't understand what... Like in the context of the language, it doesn't understand that, okay, what is non-py? Like this hasn't been said before to me. But of course like linter doesn't capture all errors because like we said at the beginning of the day, Python is strongly typed, it's not enforced. So you might modify the things when the program is running in a way that the linter doesn't know about and it might like not spot those errors. But it will spot a lot of errors, like the most annoying ones, the trivial errors. The ones that you are like, okay, I should have noticed this, like it will spot those. So for our time progress, so we've got 25 minutes left. Should we combine two exercises together? Or... Yeah, maybe we can... Or the second exercise is more of a demo, I would say anyways. So maybe we should go to exercise one and then go to the format. Okay. So exercise one and how long do we have? So should we... Yeah, should we take 10 minutes? It's not that long of an exercise. 45, okay. Great, so see you in 10 minutes. Okay, bye. Hello, welcome back. So there's some good questions there, but I think they're being answered well enough. So maybe we should go on and have a discussion at the end. So Simo, what's next? Yeah. So I'll quickly mention that in the exercise, there's like... In the exercise, there's an error that the linter doesn't spot. We can point it out if you show the exercise code. Okay. And this is for by design, this is an example of an error that the linter doesn't spot. So if you look at the code here, it's fairly normal code, but it's so complex that it's hard to say where the errors are. But the error that the linter doesn't spot is in the axe scatter, where you have one T instead of two T's in that line. And the reason why the linter doesn't spot this error is that the linter doesn't actually import anything when it runs. Like when it runs, it just checks the code. It doesn't actually like import on this. It doesn't import much like anything like that. So it doesn't spot that, okay, the object that has this attribute that is wrongly named. So it's... Yeah. It doesn't import anything or doesn't go fully deep? Well, yeah. It usually checks like module level. Like the module level. Yeah, some stuff. Yeah. But usually it doesn't go that deep. So of course, there's other linters that might spot this, but there are various tools that you can use. Various linters you can use. Yeah. But this is like an example. Linters on no means perfect, but the thing is that they spot a vast majority of the kind of things that humans might not spot. Like these kind of like KVL things. I guess it's... Yeah. Go around him. I was going to say... No, I wasn't... It's like it works well with a human. Like you spot some things easily, but not others and the computer spots some things that you don't see well. Yeah. And it's a tool. It's a tool that you can use or not use. If you don't like linters, you don't have to, but then you might encounter errors a bit more. Yeah. Okay, but let's move forward to another kind of like productivity tool that you can use. And this is about style enforcement. So Python is very flexible when it comes to like, what sort of programming styles should you use? Like what sort of naming should you use? So here's like few examples. Like you can use different variable naming styles and that you can... And these are all valid Python, but they are for the reason that like it's flexible. It doesn't enforce it, but at the same time it recommends certain like standards, Python developers, because like then it makes coding easier to read for other people as well. And these major standards are these like Python enhancement protocols, or I don't know what these are called, like this PEP. Yeah, I think it's PEP protocols. Yeah, they're like recommendations for the community. And the PEP aid is one of the most popular ones, which is like standards of how like, okay, like your code should look like this. And then there's like a doc string standard to how the documentation strings should be written. And different people have different standards. For example, like for the documentation strings, NumPy has its own standard and Google has its own standard and different places have their own standards. But what is usually like nice is that you can use these different kinds of like formatters and linters to enforce a certain standard for your code. So like I personally, like I don't have that many opinions on my code. I would rather my code be readable than like something like, there's this talk about like, why don't people, if in the, if they are in the, like in a courtroom and they are asked to tell in your own words, like what happened in the situation? Like nobody just like invents their own words. They use the same words that everybody else uses. Like they don't just like start gobbling up random words. They use the words that other people use and it's the same thing. So if you use standards that other people use, it makes other people easier to read your code and easier to write your code. And it's much easier to let the like a formator or linter determine the standard than write like and then fix it yourself. So in the example, let's do the example here. So we'll use this. So do right here. Yeah. So if you download the code here. So this code looks pretty awful, right? Like it's by design. It's supposed to like look awful. It works. Like it's completely working code, but like I don't like it. Like it doesn't look pretty to me. There's like weird spacing, weird variable names and all sorts of things. Like it's not pretty. And that. Okay. So let's do it. Yeah. I'm going to copy the link, go to file, open from URL, paste link and open. Okay. I'm going to move this to the top here. Yeah. So, yeah, it works and it calculates this Pi estimate using this target throwing method, but it's, it's, and it gives like the examples there, but it looks pretty awful. Should I try to run it? Yeah. You can try to run it. Yes. Maybe try it from the comment line. Yeah. So it gives like. We'll see more how these scripts work tomorrow. So this doesn't make sense. Don't worry. Yeah. Okay. But the main thing is like, how can we make it better? So let's try first running like Pi linked on it. Yeah. Sorry. Flake eight on it. Flake eight is this kind of like Linta and code syntax, like checker. And if you look at what sort of things it gives, it gives various of these like, okay, like you should fix this. Yeah. And, and what we can do of course is we can manually fix these and it's, it makes the code better, but we can also use a format. So one of the most common formaters is this black by Python software foundation, which is like this opinionated format. So it has its own style and it wants to enforce that style. So it's, it's a play on the Henry Ford's like, you can have the model T. That's where the game comes from. Yeah. In any color as long as it's black, like, like that, that famous quote. So, so it tries to enforce its own style. So let's try to run black on this code example. Okay. So, and I think it's black, but it should. It's in the, in the environment. In the, it's in the code environment. If you have, if you haven't stopped them. Yeah. Okay. Yeah. So now it's reformatted. Yeah. So you probably need to open the file again or reload it or is there a reload and file from this. So now we see that like things happened. So, so if we compare what's at the bottom and what's here, like suddenly the, the, for example, between the brackets, like all of the extra spacing, spacing is gone. Like some of the spacings are gone and, and like the things have been organized in a, in a bit better way. If you, if you now run the flake eight again, let's, let's ask it what it says about this. So I just pushed the up arrow key twice there. Okay. So one line too long. Yeah. So it, yeah. Line five. So, so it says that, okay, like, like usually there's this character limit of 80 characters so that it can fit into a terminal, like, but it's, it can, like, you don't have to go, you don't have to enforce any standard, but, but that's common when, when people do. If you would have like, you, in your environment, you probably don't have this pet eight naming package that is in the example and in the example environments, but it doesn't really matter. But it would give, if you scroll a bit up, it's up like there, it would give those warnings. So, so the name of the package is, it's a bit above, but it's, but those are warnings. It would, it would give those warnings. So you can install into flake eight, these additional, like style guides, there's a huge amount of these extensions. And one of these extensions gives warnings about variable names that don't abide by the pet eight convention. So for example, it would say that the function name should be lowercase and the variable should be lowercase. So that those pine numbers there, because like those are basically the standards. But it doesn't really, it doesn't really matter. Like you can, you can go by the standards that you want to, like you, all of these tools are meant for, for you to enforce what you think is good code. But of course, they're also to like help others read your code, but you don't have to use any of these tools. But usually, like, at least for me, it, it like gives me a piece of mind that like I haven't, I haven't written like code that looks bad for other people to read because like then it makes harder for them to use the code that I've written because it's a collaborative effort. And that's why people use these formators and, and linters. So here, well, do we have more? Should I ask a philosophical question? Good. This is, so my problem with things like code formators. So for example, to me, how is all of these spaces, I would, if I was writing this myself, to me, this is clearly easier to read. Yes. And like the way that things, so like I like the idea, but the implementation, if I'm running black on my own code, it's usually making it easier to read in places I don't care about and harder to read other places. So what I think, and I tend to use this white space a lot to like group things so I can mentally understand what's going on or align things vertically. But my proposed solution to this dilemma is if it's a small, if it's my own project, I know I'm formatting it well myself anyway. But whenever it's someone else's project, if it's a big project, a random contribution coming in is probably worse than I would want. So there it's better to make it uniform even if the uniform is not exactly what I would want. Do you have any thoughts on this? Yeah, yeah, I completely agree. And I will also mention that there's like, like what I usually myself do is that I usually pick the tools I want to use, like the linters or format as I want to use. And then you can follow these tools. You can specify different like things that they want to do. There's different flags and configuration parameters. And usually they're like, like black RSE or black, like some configuration file that you can specify that, okay, don't care about these things. I want you to worry about these things and not these things. And then you can enforce like throughout the project like a consistent style. But leading your own like things there. There's also like alternative linters that for example, fix, like Google has its own linter that fixes these, like this multiple case and things. But I agree. Like the code, the formaters, like it's the same with chat GPT or something like that. The chat GPT has seen code and it writes code, but of course it doesn't understand code in the sense that humans do. So for us, we might have a different kind of like perception of the code and see some code better, like to be better than the other one. And more visually pleasing or something like the pattern is, it looks nicer or something. Yeah. There's, I don't know how much more time we have. There's a really good question number 71. Do linter spot type mismatches? Should we go to the notes now? Are we done with the lesson? Yeah, I think we're done with the lesson. Like this is just a quick demo. There's other like in the lesson, there's also like mention about how you can like automatically integrate into this to Git. And whenever you like run a commit, it will automatically run these linters and it will say to you that okay, like you have a problem in your commit or something. But yeah, let's go to the, we can go to the like the cool down of that. Okay. But the idea behind this, like there's huge amount of these linters and huge amount of these productivity tools, but there are these tools. Like that's the most important things. And like if you don't know, if you feel unsure about your code and if you don't know how you should write your code and that sort of things, the formaters and linters can make you write better code because you, like you can, they can help you with the like the hard decisions of how should I, how should I write my like my code. And like you don't have to worry about code style that you're using. You just follow what the lint says and I personally do that a lot because I don't want to like think about, I don't have that many opinions. So I would rather, like somebody else has decided the thing already. So it's better to follow their lead. They probably have good reasons for it. Like, like I usually follow that sort of background. Yeah. Okay. Sorry. I was looking at other things and adding the feedback to the notes. Did we already answer the do linters detect type mismatches? Yes. I'll mention that. So like Python, for example, it's not strongly, it's not strongly typed. So the types can change throughout the code runtime, but they are like type hints that you can put into your code. And various programs, for example, or various libraries like NumPy and mutplotlib and everything, they do this in the code. So then you can, if you write your type hints into your code, you can run the static code checkers that basically like go through your code. They run the code and then they like check whether, if their type suddenly changes or if they're incompatible types or whatever. There are tools for this. And it just depends on like how production code you want to write. Like normally when we write like scientific code, it's not necessarily like very like, you don't have to worry about types that much. But if you write like a core library, if you want to write the library that other people are using, then it might be a good idea to add the type hints sort of like. Yeah, it becomes more easy for other people to use that. But yeah, like on a normal small program, I don't know if it's necessary to use the type hints. It depends on the size of the program. I'm out of collaborators as well. Like if you have thousands, like I think somewhere in Black's website, they said there's 20 million lines of codes formatted with Black. 20 million? Yeah. Formatted or? Formatted, yeah. Yeah. So there's so many big projects that are using it. Like no human like would want to do that code formatting for the job. Basically like I wouldn't want to do it. Like I wouldn't want to be like a type checker in a big company checking like is the code looking good. But there's tools for that. Okay. Any other comments or things to discuss here? So this question 73. I think you can configure many of the linters for own preferences like what to ignore and so on. Also, Simo, I think you hinted at this. Can Black be configured to not do certain formats? Or? Yeah. I think all of them have like huge amount of flags. So. Okay. Like it's like, like usually what you do is you start from the basic configuration and then you drop out certain things. So yeah, it's usually like you can, you can skip various like things. Yeah. Okay. And this question 74. Is it possible to use X with tool Y? The answer is usually yes, but the person you asked usually won't know because there's so many combinations. So do your own web searches and probably you can figure out how to. But if you're using any of the popular things like in the question, the spy charm, but if you're using VS Code, Veeam or whatever, there's like a million extensions. Like that combine like Richard said tool X with tool Y. And usually you get like a button that like, like if you press this button, this lintel or whatever for your code. And usually many IDEs, they already come with some of these tools. Like they, they will automatically flag you, syntax errors and that sort of thing. But it's important to know that like these tools exist and you can utilize them. And it's not like cheating. Like, like, who cares? Not like, like, it isn't like, you did it the hard way. Okay. Now you like won a medal. Like coding isn't like a, like a competitive video game or something like it's like coding is a, yeah, it's, you can go the easy way. Your main work isn't a homework assignment where if you don't do it yourself, it's plagiarism. Your real work is. Yeah. Like, like for example, like, like one would think that for example, like, it's, we're, we're past the time now. So if like we are done with everything for today, we might still hang out talking for a little bit, but thank you for coming. And if you have more, please, please fill out this feedback for today. It is very important. And we always look at it before preparing the next year. Okay. So what were, what were you saying before? I was just saying that like, like, if you think about like, let's say like the fresco and Sistine Chapel or something like, like Michelangelo didn't paint the whole thing. Like he had a huge amount of like helpers like planning and, and like doing that painting or like, like David, like he had people, people helping with, with the initial steps of the work, like, like, like applying like a low level, low layer paint. So coding is a similar kind of thing. Like if you, you can, the hard things are what you really want to do with the code, the, the easier things of, okay, how do I write this? You can use chat tbt or whatever, like linters and formatters to help you with that. Getting the idea across and the, the, you can, you can get the art out of the marble block. But like, yeah, yeah, it's, it's not cheating to use like helper tools. It's, it's just a way of improving the product. Yeah. Okay. Hello, Radovan. Any comments on today before we hang up? Yeah, I really like this productivity tool session. It was good to add it. So I love you things. And these are tools I use. Yeah. Yeah. The only thing I would want to, like next year, we have to figure out how do we add it into the Jupiter? Because, yeah, like just, we maybe need to make the environment. So it's already there or something because it's possible to add these into Jupiter as well. So, so the exercise will be easier to run without scripts. Yeah. But it's also a good preview for tomorrow since tomorrow we need to do the script stuff. Yeah. Tomorrow we'll have a lot of talk about like scripts and also libraries and, and that sort of stuff. And, and also there was mentioned about software architecture in the chat. So we'll be talking about that as well. And these, these productivity tools are, yeah, like rigid, tight to that. So, but yeah, so should we close out today? Great. Let's close up. See you tomorrow. So remember to prepare for day three. There's some news here, which you probably already read. Remember to give feedback. This, this session, for example, was a new session. So it would be nice to hear like what can we improve and what would you like to hear more in the upcoming years? Yeah. Okay. Thanks a lot. See you tomorrow. Same time. Bye.