PEP yourself: 10 PEPs you should pay attention to
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 118 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44844 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 201927 / 118
2
7
8
15
20
30
33
36
39
40
45
49
51
55
57
58
63
64
66
68
69
71
74
77
78
80
82
96
98
105
107
108
110
113
115
00:00
TwitterPrincipal idealSystem administratorEvent horizonMereologyPauli exclusion principleGodOnlinecommunityMeeting/Interview
00:49
Standard deviationTelecommunicationExpert systemPauli exclusion principleInformationoutputDecision theoryMechanism designIntegrated development environmentProcess (computing)ImplementationMachine codeCodeCovering spaceLine (geometry)Revision controlText editorClique-widthMechanism designBitLengthLine (geometry)InformationAnalytic continuationPauli exclusion principleOnline helpPoint (geometry)MultiplicationLimit (category theory)Computer fileFlow separationOpen setMobile appGraph coloringoutputLibrary (computing)Goodness of fitTranslation (relic)WritingInternetworkingCodeStatistical dispersionCuboidImplementationCycle (graph theory)Different (Kate Ryan album)State of matterStandard deviationOpen sourceOrder (biology)Decision theoryMultiplication signIntegrated development environmentFeedbackDirect numerical simulationFunctional (mathematics)Expert systemFormal languageModule (mathematics)Right angleIntrusion detection systemDot productDefault (computer science)Moment (mathematics)FamilyExistenceElectronic program guideOptical disc driveTwitterComputer animation
09:02
Pauli exclusion principleSoftwareAttribute grammarModul <Datentyp>Function (mathematics)Social classRootDirectory serviceDefault (computer science)Form (programming)Complex (psychology)Module (mathematics)System programmingLink (knot theory)File formatCodeMathematicsComputerPatch (Unix)Grass (card game)CASE <Informatik>Fuzzy logicWitt algebraInterpreter (computing)Electronic mailing listRange (statistics)Letterpress printingElement (mathematics)Transformation (genetics)ProgrammschleifeString (computer science)Electronic mailing listElement (mathematics)Object (grammar)Sound effectModule (mathematics)Coefficient of determinationOrder (biology)Functional (mathematics)IterationMultiplication signGastropod shellSocial classCASE <Informatik>Line (geometry)Transformation (genetics)Electric generatorElectronic signatureDescriptive statisticsProgrammschleife1 (number)Type theoryBitMereologySoftwareCodePoint (geometry)Right angleAttribute grammarKey (cryptography)Interpreter (computing)Touch typingKnotSource codeData dictionaryProjective planeMaxima and minimaRule of inferenceLengthPoisson-Klammer2 (number)Link (knot theory)Internationalization and localizationForm (programming)FamilyProgram slicingSoftware developerCone penetration testMultiplicationException handlingView (database)Interface (computing)VolumenvisualisierungProgrammer (hardware)Library (computing)Pauli exclusion principleGoodness of fitEmailState of matterComputer animation
17:16
ProgrammschleifeIterationInfinityElectric generatorPauli exclusion principleFunction (mathematics)Statement (computer science)Communications protocolControl flowLocal ringFibonacci numberInterpolationString (computer science)File formatError messageMathematicsRootNumerical digitData typeFormal languageAerodynamicsFluid staticsMathematical analysisComputer virusComplex (psychology)Vector spaceScale (map)CAN busTupleSocial classDefault (computer science)Attribute grammarTrailExecution unitCodeBoilerplate (text)Analog-to-digital converterRegulärer Ausdruck <Textverarbeitung>Line (geometry)Pattern languageLetterpress printingLibrary (computing)Standard deviationPoint (geometry)State of matterDigitizingString (computer science)Pairwise comparisonIterationType theoryLine (geometry)Entire functionFile formatKey (cryptography)Electric generatorValidity (statistics)Descriptive statisticsBlock (periodic table)TupleElement (mathematics)Communications protocolGame controllerFunctional (mathematics)AliasingBuildingMultiplication signExpressionData conversionParameter (computer programming)Electronic mailing listRun time (program lifecycle phase)Social classFibonacci numberBoilerplate (text)Attribute grammarCodeMereologyOrder (biology)Operator (mathematics)Library (computing)Programmer (hardware)Statement (computer science)Default (computer science)Statistical dispersionGodPauli exclusion principleInfinityComputer fileResultantObject (grammar)Enumerated typeError messageControl flowSign (mathematics)Condition numberGenerating functionFormal languageMathematical analysisFluid staticsRight angleWrapper (data mining)Data dictionary2 (number)Computer animation
25:29
TwitterLecture/Conference
Transcript: English(auto-generated)
00:01
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 Freeno. There's my Twitter if you want to contact me or anything. I work
00:23
as a principal technical support engineer at Red Hat. I love Linux and I love Python. That's pretty much it, presenting myself. I am also a member of the Argentinian sysadmin community, system administrators in Argentina. It's called Sisarmi and since 2013 we organized an event called Nerderla
00:45
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 years ago has surpassed the thousand attendees mark, so we're very proud about that. This year it's taking place in October, so you are all invited to come and submit a talk.
01:03
We have lovely weather in October in Argentina. 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.
01:23
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
01:42
we can think of peps as the Python standards. I like them so much that I use actual RFCs, requests for comments, for replies, like 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?
02:04
By the way, thank you Randall Monroe for enlightening us through the years. 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 with others. By the way, I found out there's
02:24
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
02:45
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 tweeted this out, and because I'm no
03:04
tweet 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 input and feedback on this. It gave me many ideas for this. So what is a PEP?
03:20
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
03:44
before, Python RFCs, Python standards. And most importantly, like RFCs, they are made for and implemented by the community. No 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
04:07
PEPs allow us to enhance Python and implement new features, among many other things. This all translates, most importantly, into a better language, and a better language translates to more people in the Python community. So let's
04:24
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?
04:42
Good. Style guide. Style guide for Python code. 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
05:01
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 irked 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
05:24
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
05:41
a PEP8 and trim 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,
06:05
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 a blank line right before the definition, and it's
06:23
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. It's called Craft Your Python Like Poetry. In the article, which I encourage you to look up and read, it was
06:43
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, right? You have columns, very short columns. And finally, he states,
07:04
which is the most amazing point of the article, that Python isn't prose. 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, you know,
07:26
disapproval. The thing about line length is that most IDEs 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
07:41
right at the correct place. So problem solved, right? Not exactly. Okay, so this is essentially better than this, right? 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 PEP8 suggestions on line wrapping, like the, you know, the
08:07
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 name, for example, and this one is actually harder because we
08:20
cannot just wrap wherever we like. But our auto-PEP8 will wrap it, and somehow this is worse. But if we add, for example, if we take care and add parentheses, we have implicit line continuation and we can wrap it in a beautiful way. We can
08:41
even align the dots. Or we could do something like this, you know, each one is online. Whichever one you use, this one or this one, it's up to you. But we can all agree that these two are better than the previous things, right?
09:01
So that's it for PEP8. Next one in the bingo, 257. Who can tell me which one's 257? Very well, docstrings. So one phrase that keeps coming to mind whenever I hear documentation and docstrings specifically is one from the Agile manifesto. I don't know if anybody in the room works with Agile
09:22
workflow. Okay, I see some like shy nods, like I don't want to admit it. So one of those phrases from the Agile manifesto is working software over comprehensive documentation, right? And to this I say
09:40
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 right at the beginning, right? If you violate these conventions, the worst you'll get is some dirty looks. So in order to make it
10:00
more convincing, I have to be a little bit more graphic to have the impact that I need. So there, this approving seal disapproves you. So what is a docstring? It's essentially the doc attribute. The PEP states that all modules, exported functions and classes from a module and all public methods should have a docstring.
10:22
The best part is that if you do this correctly, your docstrings can turn into actual documentation using any documentation generation tool. As to how a docstring 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
10:41
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, you know, the def line. And it shouldn't be also a description. It should be a phrase describing the effect as a command. And
11:03
a docstring can be either single line like this or if you want more verbosity, it can be multi-line like this. In the case of a multi-line docstring, 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 multi-line,
11:21
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 docstrings, 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, right?
11:44
There's a docstring. There's an example. If you want to dig more on the subject, there's also a pep for using restructured text in your docstrings if you want to have more fancy things. And additionally, there's the Napoleon project to make your docstrings more readable both in text and render form.
12:02
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, so please document. Don't be a child. Next one, 3099. Who can tell me which 3099 is?
12:23
See, you don't read that many peps. So 3099 is things that will not change in Python 3. Python 3000 was the code name by that time. These are all the things that will stay the same, that will not change moving from two to three. There's a phrase right at the beginning
12:42
which states the ultimate purpose of this pep, basically don't have any of these ideas, don't try to push them through. Better people have tried and failed. Although not 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 the related rationale behind it.
13:03
It's always explained. And if it's not explained, it's because it has a link to a long mailing list where it has been extensively discussed. Some of the more interesting points in here are that Python wouldn't be case insensitive, and slices are here to stay, so yay.
13:21
The maximum line length will stay at 80 characters, so better get 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.
13:42
Let's look at some more fun ones. Again, 202, who can tell me which one's this? Ah, 202 is the list comprehensions 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.
14:01
No indentation, no multi-line for required, just one line of code. But it's also faster than generating your list in the, you know, declare a list and go into a for and start appending, because you're not actually calling append one at a time. It doesn't have to resize the list. It's all generated in one go.
14:20
And the basic idea for this is to take an irritable and generate a list. So, like so. Very easy, right? Because at the beginning when I was learning comprehensions, I found it quite hard to quite grasp the, you know, know how to write it. There's a basic rule how to start. So first you think of the type of
14:43
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 irritable that you'll be using, you'll be iterating from. Yes, you'll need a for, but it's just a very tiny one. And finally, whatever you want to actually put in your actual comprehension, and that's it.
15:05
Well, in this case, we're not doing anything. That's actually not it, because comprehensions can have filtering using the if syntax. They can also apply a transformation to all the elements, because filtering will, rules them out, so you could do it like so. So now we know which the odd ones are.
15:27
And you're also not just limited to one source irritable, you could use several. There's another example in the PEP that shows just this, right? So it would be like doing a sip, but in a more fun way.
15:41
And finally, there's a younger brother of this that came along after list comprehensions, dictionary comprehensions, and all the same rules apply, right? 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.
16:03
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 irritable.
16:22
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
16:42
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 we 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.
17:03
There's nothing to worry about here, actually, because the iteration interface has already been implemented in all four loops, so four 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 iterable,
17:24
and it also allows you to go over the keys of a dictionary, which is actually the fastest way to go over a dictionary. 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?
17:44
So, for example, if you let iterables.count run long enough, it turns into this. So, next pep, 255, generators. Second to last in our line of fun peps, the best way to explain generators is to say resumable functions,
18:02
which I think is pretty cool. It introduces the yield statement, which would 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
18:20
until it matches a 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. When we call next again, we'll continue right where we
18:44
call 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 p, so whenever we call it, we will get the element of p, and the way we call this is actually
19:00
in a four, right, because of the iterator protocol, and you just go over in a four. 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 Tredinek, who I encourage you to check out.
19:25
PEP 498 describes fstrings, what we have come to know as fstrings. They are the one true god, sorry, way of doing strings in Python 3.6 and onwards. Why do we have them? Because before
19:41
sfstrings, if we wanted to include variables in our strings, we had percentage formatting, which is horrible in itself, and then we also had string.format, which it is an improvement, but still doesn't feel quite right, and if we have a long string with a lot of variables, can turn quite messy. My favorite, most horrible of all, that should never be used,
20:02
and 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, disapproving seal disapproves you. So in order to solve all this, we now got fstrings, and they're as easy as prepending an f to your
20:23
string, that's it. In fstrings, 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.
20:42
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 fstrings. Well, they're great and all. They cannot be used on docstrings, sadly, and they cannot be used with getext. So yeah, sad panda face in this,
21:04
but these are the only two major drawbacks, the rest is just paradise. Finally, our three final peps, more advanced, pep 484, type hints. It is important to note, as stated in the pep, Python will remain a dynamically typed language,
21:20
there is no desire to ever make this mandatory, but right off the bat, this pep enables static code analysis, if you just want to, or someday runtime type checking, of course, optional, not enforced, and it's also useful for documentation purposes. This pep makes use of pep 3107 style annotations, like so, you annotate the
21:43
type of the parameters that your function receives and the type of return value. There are many more things you can do with type hints, the pep is huge, you can create type aliases 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
22:01
years to come and it also provides the building blocks to pep 557 data classes, second to last. The best description for data classes is mutable name tuples with defaults. This pep allows you to define class attributes and types, in return it will generate just for you because data classes are so good, init, wrapper and all the comparison methods.
22:23
So quick example, you just decorate with data class and do it like so, notice that we recent type hints and pretty just forward and in return data classes will create these methods and they will also create these methods and they'll also create these methods, right? So saves a lot of boilerplate code. The main advantage,
22:47
that's the main advantage it has. Another thing that Bert's mentioning here, which if Hineke is in the room I'm sure he's going to start clapping, data classes does not replace adders. Adders provides many more things like validation,
23:03
converters, slotted classes and much more, so it's not a replacement. If you're interested, the following article by Flavio Corella states, when do you use data classes or adders? So final one, controversial, I know,
23:21
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 a 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
23:43
code. And by the way this is the entire point, we have comprehensions, right? Fewer lines, etc. The syntax for assignment expressions look like this. That's called in the middle, that's called the waros operator right there because it looks like a waros actually. Well
24:04
actually a rotated waros. So but what does this look in practice? Consider those if something I just did is not none situations well they now turn into this which is much more readable.
24:21
You can also use assignment expressions with any and all and you can also use them in list comprehensions which is pretty magical like so. 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
24:44
site.py code it turns now into this. I think that's pretty great. Another example would be copy.py which changes each chunk of code and 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,
25:06
we have less indentation, less lines, happy programmer. So we get happy seal. And that's it. That concludes the talk. Thank you. Thank you. We have four minutes for
25:34
questions. Did you consider PEP7 for this talk? No, PEP7 actually wasn't suggested by
25:53
all the people I pinged on twitter. I'm gonna have to look that up.
26:03
Anyone? Okay, thank you Juan. Thank you.