 The next, so the next talk is by Vijay Kumar and his topic, okay, you got the tablet. Awesome, round of applause. Excuse me, what is your name? Thank you Ashok. Okay, so once more, okay. Okay, so the next talk is by Vijay Kumar and his topic is written by Python. This talk is going to be a beginners talk and I hope there is something to learn for the advanced users too. Let's get in the talk. So all of you know that Python is fun, but I had this question is Python a fun language, right? Let's try to answer this question. Now I started using Python when I was back in college and I used to primary for scripting, my date to activities and for some of my engineering assignments, it was fun language to program in. Most of the scripts I wrote was like 100 lines and less maybe and it simplified most of my work. So it was a fun language, yes. Now after a graduation I joined a company and my first day at work I had to, there was an issue that the people were facing there. There was a field issue that they wanted to debug and they had to parse the log file that was coming out from the system and the existing tool did not provide sufficient support to do that. So I said, oh, I'll do that for you. I know Python, I can do this in X, Y, Z, R's and I wrote a code to actually do what they want and it worked. We tested it and then when the script went to the field and people who really wanted to use the script, it blew up in the field and I felt bad how things turned out, right? It was the first day in office, I wanted to prove myself and then things turned out to be bad. So I checked out the code and saw what was the problem. Now this was the code I wanted, right? It was like some condition, do some statements and then I would say if block is another statement. Now after all this testing, I have this thing to make things perfect and I write comments, add documentation, was trying to clean up the code and paid compliance, spiling compliance and then what I found was in the actual code that actually was shipped to the customer and this was how it looked like. So in the act of actually trying to make the code perfect, I accidentally inserted a tab over here. So the thing that was supposed to be outside this block, went inside this block and then the code failed. Now this was back somewhere when Git did not exist, we had only CVS and you can't even do CVS on a desktop. So you could identify it and this kind of problems occur frequently. I think even experienced programmers sometimes come across these problems. And there were other problems also I faced with Python. For example, this is another problem I generally come across. So there is this class where you have this init function, where you're trying to set up three attributes, server, username, password and inside this reconnect, you are setting up this attribute again, you're saying this value to attribute and then you can see there's a spelling mistake over there and this has been creating a separate different attribute. And this is another problem that's very, very hard to debug. You have to spend hours wasting time debugging where you make the spelling mistake. Then there's another problem that I generally come across even in production-ready code is this. So let's say there's a function to read a file and you open the file, you find, read it and then you have an exception handling, very good. You're checking for errors, fine. And then once you're done with the code, you close the file. But in the exception handling part, you are trying to print the log message, right? And when you're logging to this, you specify the file name and the variable you're specifying is incorrect. Now when you're testing this manually, it will always go to the proper nice path and you won't get this error scenario at all and this never triggers. But at some point, let's say in your code running production, it will go to this path and then if this is server program, the server will crash. So this is something very dangerous because that path is something that will occur very rarely and if there's a typo over there, then things can go bad in production code. Now problems with these made me question whether Python is really useful for really complex, large team sizes. So when the team size increases, can Python scale to accommodate multiple members in a single team? Or is it really required to have a safety net of a compiler? These kind of issues can be easily found out by compilers like the Java compiler. If you're writing in Java, the compiler itself will report such issues to you. But with Python, you don't have a safety net of a compiler. So I had these questions deep down within me. Is really Python safe? Is it scalable? Will it scale with team size? Or will it fall flat on its face? Python has too much power. It gives you too much power. It gives you too much flexibility and power. And like Uncle Ben said to Peter Parker, with great powers comes great responsibility. So what's the responsibility that we need to have when you write Python code? It gives us power. But what's the responsibility that we had to give back? Unit testing. The testing that we generally do with code is what people call integration testing. You run your program, give inputs manually, see if it works, and if it works, it's fine. That kind of testing is what we call integration. The entire application has a hole and tested as a hole. But that's not sufficient in Python. Like you've seen earlier, there are problems that can go unnoticed when you're doing integration testing. So unit testing is, you test each and every module, people know what is unit testing. The important thing about unit testing is you mark out all the external dependencies, networks, databases, serial ports, all marked out, and then you only test your code in memory, no external accesses whatsoever. And since it runs in memory, it's blazing fast. To implement unit testing, your code should not look like this. It should not be a maze. It should be written like this. You should have one layer at the bottom, a layer of modules, and top of that, another layer of modules that access the layer below it, and so on. So if you've written your code this way, it's well and good for unit testing. All this writing code like this will make it really hard to write unit test cases. But there are lots of myths about unit testing. I'll just mention a few of them over here, and I'll give links to where you can find more information about them. When it's like people say that when you're interfacing in serial ports and things like that, you can't do unit testing. You can do unit testing with them. There is a model called mark, which is now within the Python 3 standard library itself. And this is the link if you want to go and get more information about it. So when you're accessing serial ports, reading data from serial ports, parsing them, and so on, you can mark the serial port and then inject data into your program, rather than having to actually read code from the serial port. Similarly, if you're doing filer, some people think filer cannot be unit tested. For these kinds of scenarios, you can actually use a Python class called string.io to do this. So if you want more information, it's over here. Then another thing is like file system access. Your listing directories, changing permissions, moving files, all those can also be unit tested. There's a wonderful library from Google called PyFakeFS. So you can fake a file system in memory itself. So for more information, you can check out this link. And another thing is like, suppose there's a function that actually has infinite loop. You call the function, it will never return. Even such functions can be unit tested. There's a blog article over here. You can check out this article. They have given you ideas of how you can write the unit test for such functions. And GUI programs can also be unit tested. But there's another blog article in this link. You can go and check. So there are lots of myths surrounding your testing. This can be done with you and testing. That can't be done with you. It's not true. There are a lot of ways we come up with to solve those kinds of problems. So the conclusion is yes. Python is fun. Unit testing makes it even more so. Right? And I'll be publishing slides and links on my Twitter handle. I'll also include PyCon in the unit. Thank you.