Introduction - Intermediate Python Programming p. 1

Key Takeaways

what is going on everybody and welcome to an intermediate Python Programming tutorial series or maybe better called python fundamentals that aren't Basics anymore okay so uh in this tutorial series we're just going to be talking about stuff that I just don't feel like fits anymore in the Python 3 Basics tutorial Series in the past I've just kind of added on to that over time but we're getting to the point where I just don't think it's Basics so first of all like my definition of Basics is at least how I felt when I was doing Basics and that would be like let's just make this work right that was my goal whenever I was first starting out so I just didn't care that much about uh efficiency and scaling and stuff like that I was just trying to learn about the language and make it work now with intermediate Python Programming I kind of break these down and there's kind of like three Hallmarks or trademarks of intermediate Python Programming and that is one it's efficient and it scales well because as you grow a project and if the project is successful it needs to be able to scale otherwise you're going to have to go back and pay off a bunch of what's called technical debt basically uh so you want to be able to scale really well also along those lines the second thing is just maintainability so a lot of this is just readability and how easily we can understand it but also just how well you write your functions and classes and methods and stuff like this that allows you to actually grow over time and improve it because a lot of times you're just going to get to the point where as the project grows and you want to add new things or change things it can become just a huge spiderweb mess nastiness then finally the third thing is just modularity and so the idea here is that when you you make something your goal should be that maybe you want to use this in other projects of your own or maybe other people can make use of the code that you're writing so you want to make something that's extremely gener generalizable uh that should be the goal and that's actually really hard to do and if you're not always thinking about that it's really easy to take the short route and sacrifice modularity but also sacrifice uh maintainability and even efficiency but for the most part scaling and efficiency is more of like a knowledge thing you just need to know how to do it as opposed to maintainability and modularity that's more of like a mindset that you really need to have so one thing I always like to show I've shown this picture a few times before but I think it's a really good one is this kind of comic and the idea is that you know you start with a clean slate and then you build your first project and that's just the simple house and then over time as the project grows you want to add these other little things to it and as time goes on it just gets way out of hand everything's just kind of pieced together there was no thought about I mean obviously I guess this is kind of modular um but it's really difficult for this Pro this kind of kind of project to scale when you're just kind of gluing things together and again it's more of like a mindset when you're writing things especially we're going to be talking um basically this series will start with just some standard library and standard functionality of python that again just isn't basic and then we're going to get into object-oriented programming uh and so as you build let's say uh your classes and stuff like that it's like a it's more of like a mindset when you have to think about okay how could I use this in the future and how can I grow this in the future and so um a good test of that is just to basically have it in a separate file so I'm usually not somebody who's a big fan of making these huge packages but at least the first time you're building uh a class that can actually help out but we'll talk more on that as we go also in terms of maintainability I will just point to pep 8 pep 8 is a style guide it's not Style by for python code it's not it's not dogmatic it's just a it's more of like a suggestion more than anything else if you don't feel very strongly about something use whatever pep eight says or if uh a lot of times you might work in teams like for example Google has their own style guide so if you go to work for Google you're there's some differences between Google's version of styling and pep8 but for the a large part uh people generally follow the same practices and we'll try to adhere uh a decent amount to pep eight but there are certain things I just fundamentally disagree with uh with pep Aon uh just for one quick example will be line length 79 characters just feels unbelievably arbitrary and it encourages you to have like really short or uh like a short function names and short variable names that aren't descriptive aren't readable and also to uh neglect some times having like if especially like when you've got a function and you're actually going to use that function um sometimes it's not clear what that parameter is just by the variables name so you kind of want to have the parameters name equals variable name but if you're trying to not not exceed 79 characters it's really easy oh we'll just chop off the parameter and equals and boom we're good that's that's pep eight that's right right um I don't I disagree with that and there's a few other things in Pepe I just I I just feel like come on guys but anyway um we'll we'll do a lot of things like the naming conventions we're going to follow and stuff like that so pep eight read through it uh it's it's a good read regardless it's something to think about next uh we're going to bring up uh python shell uh let me make it large and probably in my opinion more important than pep8 is the Zen of python you should just always kind of have this in your mind so you can just do import this and this is kind of the the Zen of python um and basically just kind of always be thinking of these things so you know I'm not going to read this all to you but beautiful is better than ugly is one that pretty much everybody violates uh simple is better than complex is one that has unbelievably um complicated ramifications um so maybe we'll show some examples of that flat is better than nested is also usually very complex Andor complicated so a lot of these things are are contradictory in practice practice but um it is something to always kind of think about and try to make your code adhere I would say adhere more to the Zen of python uh at least a line in the Zen of python than pep eight but anyways keep that in mind it's kind of a nice thing to have so uh as this uh tutorial series progresses you can make uh suggestions or recommendations or if I do something that you have a better method of doing it or you think you have something that's more it's going to scale better it's more easily readable and it can scale better because we're going to talk about how scale and readability often come into conflict with each other um but if you've got a better idea or whatever feel free to contribute to the series so uh like I said before the next few videos are just going to be more of kind of built-in things like generators and list comprehension that kind of stuff then we're going to talk a little bit about standard libraries we're going to be talking about multiprocessing and a few others like AR pars and stuff uh and then we'll hop into object-oriented programming uh because objectoriented programming is one of the best ways to make modular code you don't have to use object-oriented programming but it is one of the best ways and it's certainly better than scripting which is most of what we do on the channel so anyways if you have questions comments concerns whatever feel free to leave them below otherwise stay tuned in the next tutorial thanks for watching