 Can anybody hear me? Yes? Great. Hello, everybody. Thanks for being here. And welcome to the part of the conference where there's a pep talk. My name is Juan Manuel Santos. My IRC nickname is Godlike. You can find me on Freenote. And there's my Twitter if you want to contact me or anything. I work as a principal technical support engineer at Rehat. I love Linux and I love Python. That's pretty much it presenting myself. I am also a member of the Argentinian system and community, system administrators in Argentina. It's called Cisarmi. And since 2013, we organized an event called Ner de Arla, which is kind of like nerd out, but in Spanish. It's a technical conference. It's held in Buenos Aires every year. A couple of years ago, it has surpassed the 1,000 attendees mark. So we're very proud about that. This year, it's taking place in October. So you're all invited to come and submit a talk. We have lovely weather in October in Argentina. Now, I'm not sure if I'll have time for questions, but don't worry because time is actually a social construct and it doesn't exist. Anyway, if there's no time for questions, you can find me later just outside the room and ask me whatever you want. Before we begin, I just want to ask you something. With a show of hands, people in the room, let me know who actually reads peps. Mark, put your hand down. Nobody believes you. Liars. Anyway, as an engineer, I always like standards. So we can think of peps as the Python standards. I like them so much that I use actual RFCs, requests for comments, for replies. This is just not how DNS works. I also think standards are a way of moving things forward in the community, although that does not always come out for the best, right? By the way, thank you Randall Monroe for enlightening us through the years. But most importantly, I believe standards are a way of communicating an idea. They serve to improve or refine an idea that somebody already has, and then you can put it in a box so you can share it with others. By the way, I found out there's tiny, cardboard people on the internet. That's lovely. These others can then improve it some more, or maybe totally burn it down. The cycle continues until you seal and stamp the box, making it final. And that's how we essentially get 15 different standards for anything. So when I got the idea for this talk, I needed help, actually, because I love Python, but I'm not an all-knowing expert on Python. I also love open source, and that's when I had my aha moment. Let's ask somebody else. So I treated this out, and because I'm no Twitch start, I actually had to specifically ask others, like manually shouting at them, like if I'm a peasant. And so I got some great, great input and feedback on this, gave me many ideas for this. So what is a pep? For those of you who don't know, peps are Python enhancement proposals. They are design documents that are meant to provide information to the community on new features, Python processes, its environments, whatever. Most importantly, they are the primary mechanisms for proposing major new features, collecting community input or documenting design decisions. They are effectively, as I said before, Python RFCs, Python standards. Most importantly, like RFCs, they are made for and implemented by the community. A new Python talk would actually be complete without a Monty Python reference, so here we go. It's actually a good thing that we have peps, and that the community participates in that. So peps allow us to enhance Python and implement new features, among many other things. This all translates, most importantly, to a better language, and a better language translates to more people in the Python community. So let's first talk about some general purpose peps, and because I saw many hands raised before, we are going to make it more interesting. We're going to be playing some pep bingo, so I just put the number and we'll see if you can tell which pep it is. So first one should be easy enough, right? Which pep is it? Good. Style guide. This one was actually the whole reason I started this talk. This pep covers a lot of things on how to write Python code so that we can all agree on that. And I actually pretty much agree with everything, indentation, how to name your variables and your functions, how to write your imports and even writing code with other Python implementations in mind. So this is all good. But the one thing that always kind of gives me the most, the one I did not fully understand why line length, which the pep8 states that should be 79 characters max. I always found it kind of odd. The reasoning behind this in the pep itself is to have multiple files opened side by side. Which from a technical standpoint makes sense, but you know, it kind of never landed on me, even though I still use a pep8 and train my lines. And another thing about line length, although you can change the color by default many IDEs will put this horrible red bar at the 79 character mark. That bar means disapproval. That bar means unworthiness. You shame family with that bar if you go over it. By the way, interestingly enough, this code is actually from the standard library, it's the anti-gravity module. This code is not pep8 compliant because it's missing well, that's a bar, it's missing a blank line right before the definition and it's missing a blank line at the end of the file and the imports are not in order, so funny thing. So another way of looking at the line length thing, I learned from a great article by a guy called Trey Hunter. He wrote a book called craft your python like poetry in the article which I encourage you to look up and read. It was amazing. Trey argues that this is actually not a technical limitation but rather a human imposed limitation. We read shorter lines better and easier than longer lines and if you don't agree with this think newspaper articles. You have columns, very short columns. And finally his states the most amazing point of the article that python isn't pros python is actually poetry and because it's poetry you should craft it as such not write, craft. He then goes over several examples I'm just going to show you a couple so take this unworthy shaming line has gone over this approval the thing about line length is that most ideas already have a way of automatically wrapping the lines before the 79 character mark they are actually quite intelligent like they won't break your python code just trim it right at the correct place so problem solved, right? Not exactly okay so this is essentially better than this but it's not quite good we could actually make this a little better if we think about it like so which actually follows most of the questions on line wrapping like the brackets are different lines at the end so if you think about it for a minute, for a little bit you can actually make your code much easier and more beautiful to read and take another unworthy line for example and this one is actually harder because we cannot just wrap wherever we like but our auto-pepe will wrap it like how this is worse but if we had for example if we take care and a parenthesis we have implicit line continuation and we can wrap it in a beautiful way we can even align the dots or we could do something like this you know each one on its own line whichever one you use this one or this one it's up to you but we can all agree that these two we can use things right so that's it for pepeit next one in the bingo 257 who can tell me which one's 257 very well, dock strings so one phrase that keeps coming to mind whenever I hear documentation and dock strings specifically is one from the agile manifesto I don't know if anybody in the room okay I see some like shy nods I don't want to admit it so one of those phrases from the agile manifesto is working software over comprehensive documentation and to this I say no, there is no good reason why you should not document your code then again pep itself is not helping me getting this point across because there's this phrase in the beginning if you violate these conventions the worst you'll get is some dirty looks so in order to make it more convincing I have to be a little bit more graphic to have the impact that I need so there, disapproving seal disapproves you so what is a docksring? it's essentially the dock attribute the pep states that all modules exported functions and classes from a module and all public methods have a docksring and the best part is that if you do this correctly your docksring can turn into actual documentation using any documentation generation tool as to how a docksring looks like it's just a string that goes right up to the definition of a function or a method or a class convention states that you should use triple quoting for this string it is important also that the string be not a signature of the function or method because we can already tell from the death line and it shouldn't be also a description it should be a phrase describing the effect as a command and a docksring can be either a single line like this or if you want more verbosity it can be a multiline like this in the case of a multiline docksring there should be a summary line followed by a blank line followed by a more detailed description and in some cases if you're using multiline it is also useful to paste an example of the function usage straight from what it would look like on the Python shell if you need more examples on how to write your docksrings you have the whole standard library to look at you just need the doc attribute for any entity that you might want like so these two are modules but this one is a function there's a docksring if you want to dig more on the subject there's also a pep for using restructured text in your docksrings if you want to have more fancy things and additionally there's the Napoleon project to make your docksrings more readable both in text and render form finally, remember good programmers write code that humans can understand and to code a more local celebrity if there's something developers respect it's code and I would add documentation but don't be a child next one 3099, who can tell me which 3099 is see you don't read that many peps so 3099 is things that will not change in Python 3 Python 3000 was the codename by that time these are all the things that will stay the same that will not change moving from 2 to 3 there's a phrase right at the beginning that states the ultimate purpose of this pep basically don't have any of these ideas they've all been tried don't try to push them through better people have tried and failed although no specifically a technical pep it's very interesting to read this one in order to know how Python 3 came to be because every item in the pep has a related rationale behind it it's always explained and if it's not explained it's because it has a link to a long mailing list and some of the more interesting points in here are that Python wouldn't be case insensitive and slices are here to stay, so yay and the maximum line length will stay at 80 characters but I got friends with that but I think that in my view the best of them all is the one that gives us some insight into our former BDFL's personal feelings so see how happy he is that's because of the interpreter now for some fun peps those were the more general ones let's look at some more fun ones again, 202 who can tell me which one's this ah, 202 is the list comprehension's pep which I'm sure many of you have used this one describes a way in which you can generate a list in one line no indentation, no multiline for required, just one line of code but it's also faster than generating your list in the declared list and go into a four and start appending because you're not actually calling a pen one at a time, it doesn't have to resize the list it's all generated in one go and the basic idea for this is to take an variable and generate a list so like so very easy because at the beginning when I was learning comprehension's quite grassy know how to write it there's a basic rule how to start, so first you think of the type of comprehension that you want the destination, it's going to be a list so we add the square brackets and then you think about the source iterable that you'll be using you'll be iterating from yes, you'll need a four but it's just a very tiny one and finally whatever you want to actually put your actual comprehension and that's it, well in this case we're not doing anything that's actually not it because comprehension's can have filtering using the if syntax they can also apply a transformation to all the elements because filtering will rule some out so you could do it like so, so now we know which the odd ones are and you're also not just limited to one source iterable, you could use several there's another example in the PEP that shows just this so it would be like doing a zip but in a more fun way and finally there's a younger brother of this that came along after list comprehension dictionary comprehension and all the same rules apply the only thing is that we need to change the brackets because we're not talking about a list, we're talking about a dictionary so we replace the brackets with braces and because we're talking about a target dictionary we have to use key value syntax other than that functionality is exactly the same oh by the way sorry for this the only caveat with the ifs is that if you're filtering the if goes at the end but if you're playing a transformation if else syntax it goes in the middle between the element and the source iterable now that's done going back PEP 234 I think I might just go ahead and say it iterators iterators are a way to have controlled for loops or basically just getting one object at a time from a collection the basic way this is done is that first a method produces an iterator object that object has a special method called next and in order to get one element from the iterable at a time we call next which will return one at a time until there are no more elements in the collection at which point it returns stop iteration an exception yes this is by design there's nothing to worry about here actually because the iteration interface has already been implemented in all for loops so for loops actually look for stop iteration to know that they're done this interface also it's the one that allows you to go over the lines of the file because it's a file object well now it's and it also allows you to go over the keys of a dictionary which is actually the fastest way to go over a dictionary so one example of when you would use iterators is if you had an infinite collection if you had an infinite collection of something you simply cannot fetch the entire collection because it's infinite right so for example if you let idletools.count run long enough it turns into this so next we have 255 generators second to last in our line of funpabs the best way to explain generators is to say resumable functions which I think it's pretty cool it introduces the yield statement which will later be used on async and also makes use of the iterator protocol and the basic way this whole thing works is somebody calls next then the generator will run until it matches yield line when it encounters the yield it will stop it will return whatever it needs to return with yield and the good thing is that execution is frozen at that point the controller is returned to the caller but all the local state is retained so resumable functions will continue when we call next again will continue right where we call the yield right where we left off in practice a generator function looks like this this actually generates the Fibonacci sequence and you'll notice that there's a yield B so whenever we call it we will get the element of B and the way we call this is actually in a 4 because of the iterator protocol and you just go over in a 4 in the example before that generator never stops so we actually have to put a break condition generators and iterators are two topics that can go on for a while if you want to know more there's a great talk by Malcolm Treadenek you can I encourage you to check out PEP 498 describes F strings what we have come to know as F strings they are the one true god sorry way of doing strings in python 3.6 and onwards so why do we have them because before as F strings if we wanted to include variables in our strings we had percentage formatting which is horrible in itself and then we also had string that format which it is an improvement don't get me wrong but still doesn't feel quite right and if we have a long string with a lot of variables it can turn quite messy and my favorite most horrible of all that should never be used I of course have never used it and I will deny everything is concatenation with plus I'm sure nobody in the room has ever used this of course but if you ever think of using this in your code let me remind you this approving seal this approves you so in order to solve all this we now got F strings and they're as easy as prepending an F to your string that's it in F strings the magic is that you can use braces to insert any variable into your string well actually not just any variable you can pretty much insert any python expression that you like so now you can show everybody just how smart you are and you also have a format of course like for previous string.format so you could ask for say 100 digits of pi of course to available precision a couple of caveats in the F strings well they're great and all they cannot be used on duck strings sadly and they cannot be used with katext so yeah, sad panda face on this but these are only the only two major drawbacks the rest is just paradise finally our three final peps more advanced pep484 type hints it is important to note as stated in the pep python will remain a dynamically type language there is no desire to ever make this mandatory but right off the bat this pep enables static code analysis if you just would want to or someday run time type checking of course optional not enforced and it's also useful for documentation purposes and this pep uses makes use of pep3107 style annotations like so you annotate the type of the parameters that your function receives and the type of return value and there are many more things you can do with type hints the pep is huge you can create type leases and a lot of other things that unfortunately we won't have time to see but I do encourage you to go out and check it out it also provides the building blocks to many things in the years to come and it also provides the building blocks to pep557 data classes second to last the best description for data classes is mutable name tuples with defaults this peps allows you to define class attributes and types in return it will generate just for you because data classes are so good in it wrapper and all the comparison methods so quick example you just decorate with data class and do it like so notice that we're using type hints and pretty straightforward and in return data classes will create these methods and they will also create these methods and they will also create these methods so saves a lot of boilerplate code that's the main advantage it has another thing that Bear's mentioning here which if he neck is in the room I'm sure he's going to start clapping data classes does not replace others others provides many more things like validation, converters, slotted classes and much more so it's another placement if you're interested the following article by Flavio Curella states when do you use data classes or others so final one controversial I know assignment expressions basically it means starting with Python 3.8 it will be possible to name the result of an expression this is of course outside our normal way we do that with statements nowadays and the reasoning behind this pep is that after doing some research it was found that programmers value writing fewer lines of code over shorter but possibly indented lines of code and by the way this is the entire point we have comprehensions fewer lines etc the syntax for assignment expressions look like this that's called in the middle let's call the waros operator because it looks like a waros well actually a rotated waros but what does this look in practice consider those if something I just did is not none situations well they're now turning to this which is much more readable you can also use assignment expressions with any and all and you can also use them in list comprehensions which is quite magical instead of using some for example because maybe you cannot based on the list you can do it like so it turns out it's quite easy to get used to it parts of the standard library can thus be rewritten so for example take this side.py code it turns now into this I think that's pretty good another example would be copy.py which changes this chunk of code that actually I have no idea what it does into this still have no idea but it's more readable so to recap on this last pep less indentation less lines happy programmer so we get happy CEO and that's it that concludes the talk thank you we have four minutes for questions can you did you consider pep7 for this talk? no pep7 actually wasn't suggested by all the people I pinged on twitter I'm gonna have to look that up anyone? thank you