Python Bytes - #76 Goodbye zero-versioning

Episode Date: May 4, 2018

Topics covered in this episode: Unlearning toxic behaviors in a code review culture Flask 1.0 Released How to have a great first PyCon Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/76

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 76, recorded May 3rd, 2018. I'm Michael Kennedy. And I'm Brian Ocken. And this episode is brought to you by Datadog. Check them out at pythonbytes.fm slash datadog. They're doing awesome stuff. Tell you more about that later. Brian, I think, you know, we're on the eve of PyCon. We're literally, in terms of podcast episodes, this is PyCon Eve. And PyCon is a place where people seem to really care more than most developer communities about

sort of welcoming newcomers. And you've got something that kind of ties into that angle as well, right? I ran across this article, and it looks like it's called Unlearning Toxic Behaviors in a Code Review Culture. And apparently this came from a talk at AlterConf and then turned into this. So the slides are available, but there's an article with all of the information. And this is something that trying to have good manners and be a good human while also helping each other out in code reviews is sort of an interesting balancing act. Because you've got to actually teach people if you need to teach and everything. So anyway, I'm going to jump into some of the ideas around this. And it's an interesting idea to go off as a discussion of some of the unhelpful behaviors that people have seen,

and then some of the helpful things that you can do. So one of the, I'm not going to list all of them, but there's a few of them that jumped out at me, like passing off opinion as fact was the first one. And, you know, it's people saying, oh, this should be implemented this way. But there isn't really a should often with software. Those are opinions. And so just make sure you state it like that. One of these things, next up is overwhelming with an avalanche of comments. So like, for example, if somebody made the same mistake a whole bunch of times, like, I don't know, there's spaces in the wrong place or some formatting issue, or, you know, not using underscores and doing camel case instead. Commenting every place.

I mean, one comment is sufficient. Don't put like, yeah, you did it here too. Yeah, you did it here too. Yeah, you did it here too. All over the code review. And there's actually just reading through all of these. They're good just reminders of how to be helpful instead of being hurtful during a code review. And then popped out some of the helpful things that one of the things that

popped out at me is collaborate and don't backseat drive. And this is one actually that I need to work on because it's hard when I see some code that I think should be another way. I don't really want to just tell everybody, tell somebody what's all wrong with it. My instinct is to just do it the right way and show them, say, it should have been done like this. But that's, you know, that's not the right way to go. But anyway, do you have any comments on some of this? So one of the things I think that people need to be really careful about is when, in some of these code reviews, especially for junior developers, this can be like a really sort of sensitive time emotionally, right? You put together some work and it's one thing to criticize the code, but at the same time, it can come across as feeling like criticizing that person or their skill set. And when you're a junior developer, your feeling is like you maybe don't feel like you can keep up with your team because they've been doing it for 10 years and you've been doing it for two and you just feel a little bit like you're always

trying to catch up right and so if somebody comes in just matter of fact only says we're going to throw a bunch of uh comments on this stuff you should do it the way i've been doing it for 10 years etc etc like it can i think it can be perceived as a personal attack or attack on your credibility in your newfound career so i just think you know being real real sensitive of that especially for junior developers right i mean i'm sure people who've been doing it for a long time feel that way as well but the longer you do it the thicker your skin gets and you're just like you know the more you're kind of used to having these sort of debates and and differences of opinion but, I would sort of second this and say,

you know, be cautious of the junior developers and make it more about learning and bringing them along instead of like, hey, I'm going to show you how to do this because you did it wrong. Also depends a lot on personality, because when I was a junior developer, I actually was more open for people saying, oh, this sucks, you should do it this way. And now that I think of myself as an experienced developer, there's still a lot of stuff that I'm learning in new parts. And I sometimes will take a comment of like, oh, you should do it this way. As like, what are you talking about? I'm a senior developer, you know, but I got to check the ego a little bit. And one of the things that helped my team a lot, it shows up on this list too, is to automate what you can.

Like, for instance, we use, I mean, whatever your standard is, just define that and codify it with PyCode style or Flake 8 or something. Our team uses Flake 8. The Flake 8 defaults, at work, it was helpful for us to increase the line length and a couple other things that we turned off. But agree on that and just automate that. So sometimes something will come through a code review and just a simple comment of, hey, can you run this through Flake 8 first before we start the review is easier. I totally agree with that because people – you don't feel personally criticized by a computer. Yeah. Right?

It's just like the algorithm, it formats it this way and it checks that the line length is this and the format is that. And if it's wrong, then you fix it. But it's not like it's – you know, it has an opinion about that. Not really, right? Maybe someday computers will have opinions like that, but they don't right now. Yeah. And another thing, sort of adding on what you're saying, is with Black, I believe, remember Black, the formatter that comes in any color you want, as long as it's black? Yeah. That one, I believe, will modify the code, not just suggest fixes.

So you can say, Black, reformat this the way we like it, and just do that. I still haven't tried to hook that up as a commit hook or something like that. Exactly. That'd be nice. I think it's tried to hook that up as a commit hook or something like that. Exactly. That'd be nice. I think it's pretty cool. Definitely worth thinking about these issues. So Brian, do you remember a few episodes ago that project, that new versioning project

that Mahmoud Hashemi and a few of his friends put together about zero version? Was it zero-ver? What was it called? I think it was zero-ver. Yeah, I think it was zero-ver. Yeah, I think it was zero-ver. So it was like sort of celebrating in a sarcastic poking fun that maybe you should not be zero version.

The zero dot whatever version of things like flask, pandas, et cetera, right? Things that have been around for eight years and are super stable and are still like zero.1 for their version well either that article or this episode or that episode covering it somehow may have had some kind of effect because flask had been on like 0. something small for eight years and now flask 1.0 is released how about that i think it's a great thing it was interesting that there were some people that actually commented of like, why bother if it's already stable? I think it's a good thing. I think it absolutely makes sense. I mean, I know that there are people out there in the world who see it's been around for a long time. It's had many releases. That means stable. If it's

not stable, you put the little beta, the little B on the end of the version or something like that. But there's a large portion of the development world that comes to Python from outside of the core ecosystem of Python and sees 0.1 and goes, can't use it, not ready. What is this, right? And so I think it really makes a lot of sense just changing the version because they got some pressure. There's actually a lot of stuff here. I'm going to try to go through this quickly because there's actually a lot of stuff here. So the CLI is more flexible for creating a Flask app. And actually you can do things like say it's in development mode or production mode and that can replace like Flask to bug settings and the environment, stuff like that. That's great. You can get the environment variables from a.flask env file. So instead of having to export them in your shell when you like launch the shell, like ZSHRC or BashRC, things like that, you can have it just in these files and it'll actually load them as if they're from the environment. That's cool.

Development server is multi-threaded. So now you can more properly test concurrent requests during development, which is what you would experience if you were released it to a proper threaded server like MicroWhiskey. Flask ext, which was deprecated, has been removed. Some stuff around forms is pretty nice. Better error handling, more finer grain stuff there, more logging. The, something for you,

the test client gained a JSON argument for posting JSON and the response test object, a get JSON for decoding JSON. So you can have like test your JSON methods better. A test CLI runner for testing your app's command line options. Pretty cool, right? Yeah, very cool. So all of this stuff is in Flask 1.0.

Nice. Actually, that very much deserves a bump in the version. Right. And it's time. It's definitely time. So well done, Flask team. Yeah. I'm just getting into some more Flask. Right. And it's time. It's definitely time. So well done, Flask team. Yeah. I'm just getting into some more Flask stuff too, so that's good.

Yeah, it's pretty fun. So have we gotten used to PIP? Like, I'm not used to it. I literally yesterday typed pip install-r requirements.txt a lot because I was rebuilding some servers. How about you? I understood it. I think it's really cool, but I had trouble really grokking what problem it was solving that I didn't have yet. So I ran across an article that's called Pipenv, a guide to the new Python packaging tool.

And so since everybody's like, actually not everybody, but it is being more recommended now to use PIPenv where appropriate. And so this article actually presented it in a way that I think it made me understand it a lot more. For instance, using PIPenv, it's like using PIPenv virtual environments, but it does a lot of the stuff for you. There is some workflow differences that I other, I mean, that I'm not going to cover here, but the video, there's a video up on the site that I think the PIP and read me or the, I don't know, the documents. Like the GitHub page. Yeah. Yeah. It has this little video where this is great and it shows you the workflow,

but what problems does it solve? So the requirements.txt has an issue. And this article talks about the current without pipenv, what the problems are. So requirements.txt, you can set it up as just these are the required packages that my application uses. But it doesn't really have versions. You can put versions in there, but your mileage may vary. Now, if your dependencies have dependencies themselves, then those versions, you know, how do you keep track of those? So that one of the ways people have done that is use pip freeze, which does both your dependencies and all of the sub dependencies and freezes all of

those. And you can use that as your requirements file. But then you've got to keep track of it. So every time one of the sub dependencies updates, you've got to make sure it works. And that's just sort of a pain. Yeah. I mean, the requirements are supposed to show you what you depend upon, not the transitive closure of what you depend upon, really. Right? Oh, math words. Not all.

Not your dependencies, dependencies. Not the dependencies of your dependencies of your dependencies. How's that? Okay. The gist of it is in file-wise, there's two files that get generated, pipfile and pipfile.lock. Pipfile is the, these are my requirements, kind of, but it also does more than that. And then pipfile.lock is like all of the pinned requirements with all the versions. And it also includes hashes of the downloads so that you don't

have to worry about corrupted installs or anything like that. And then it does so much more than that. But this discussion really helped me understand why this is useful, especially the sub-dependency thing is something, yeah, nobody wants to deal with that themselves. So let PipInv deal with it for you. Man, pretty cool. I got to study that. I got to get my workflow zen around this new way. One of the catches, which is that it's recommended for use for applications and not for packages because your package is used by something else. You don't want to pin anything. It's the application that should pin things, not packages themselves.

But you can use it while you're developing packages. And if you're really confused on how to set all this up, there's a new cookie cutter for it. So we're also going to include a link. There's a package somebody did for a generic Python project that uses pipenv. There's a cookie cutter for it. Nice. So you basically, if you're going to start a new project, you can run that cookie cutter to generate it with the proper structure using pipfile and pipfile.lock. And it's kind of a fun way to just get your hand like, okay, how's this all supposed to work? Even if you don't use this for a project to pull down pipenv and in a project and play with it and say, oh, yeah, this makes sense. I think that's a really cool way.

It kind of gives you the essence of what you need for the structure, which is always something that's fun to debate, and we have a few times. So before we get to our next item, which is probably going to surprise people a little bit if they haven't heard of it, I want to tell you about Datadog. So Datadog is a monitoring solution that provides deep visibility and tracks issues that you might be running into with distributed applications. So if I have an app that has maybe some services like microservices and it calls into the database and other things and it's slow, like that can be really hard to figure out where.

But with Datadog, you can just investigate the bottlenecks in your code, explore graphs and dashboards, and really figure out where your app is spending its time across processes, right? So we're not just profiling one thing. So visualize your Python performance today. Get started with a free trial at Datadog, and you'll get a cool shirt, a little t-shirt with a Datadog mascot is the right word I'm looking for. A Datadog mascot on there. So check it out for yourself at pythonbytes.fm slash Datadog. So if you're going to think of a company, Brian, that was going to create like one virtual machine, one runtime in Python speak, the equivalent of interpreter to rule them all. How about Oracle? No, I wouldn't have thought Oracle.

No, I probably wouldn't either. So there's this thing called Graalm g-r-a-a-l vm and it says this is built to run python code and other code that depends on virtual machines and run it faster so they said look we see this problem like current production virtual machines and you know through the c python in there with that provide high performance of only this execution of only certain languages or a small set of languages they all repeat a bunch of stuff they all do compilation memory management tooling etc so it kind of violates the don't repeat yourself the dry principle they're heavyweight things usually that take a lot of memory so they're often difficult to embed especially like jvm stuff like that so over at oracle labs they started a new project a while

ago to create a single vm that would provide high performance execution for all of the languages benefit being if i have say some sort of multilingual environment like maybe we do java and python or something like that, if you could put that within the same process and have them directly communicate, they would go dramatically faster than, say, over JSON-based microservice. Like if it was literally in memory. Yeah. That's kind of the idea, right?

So the goals are basically to create this high-performance single VM that can interoperate with zero overhead across these different languages and platforms. So you can run all the JVM-based languages, Java, Kotlin, and so on, JavaScript, including Node.js, anything that you can do LLVM against, so C++ or Rust, and Python. So imagine you're doing some sort of interop type of thing and you want to write some of your code in rust and some of it in python and you want to try to get the best performance out of it maybe putting it together in this thing uh would be pretty cool so it does i don't know how much it'll help for python uh in its current form but maybe they'll

get something really special but for some some of the JIT compiled languages, it will ahead of time compile them to machine instructions and then run them. So things like startup time and initial execution is super fast and predictable. So it would be cool if they could do like PyPy pre-compiled or something like that. Just to make sure I get my terminology straight,

the Grail VM, the VM is a virtual machine. I'm used to virtual machines being like uh an entire desktop like in a on a server or something is that what this is no often vms are like the java vm or the dot net clr or things that that are sort of managed memory process. Okay, it's the thing between my code and my computer. Yeah, and it is most commonly used around things that JIT compile. Java, JavaScript,.NET, things like that. Okay, so two completely different things, both called virtual machines. Okay, got it. Right now, the Python support is experimental,

but one of their main next steps is to make the support for Python better. So if this sounds interesting to people, I think, you know, it's early days. It's pretty interesting, and check it out. Actually, I'm, like, super excited about it because the combination of Python with C++ and Rust and R and other things and Kotlin, it's going to be, I think this is an exciting thing. I think it is too. And if you can do that with no interop within the same process, without translating between the layers

and some kind of like CFFI layer type of thing, I think that would be really cool. Yeah. Okay. We'll see. It's early days, but it could be a pretty neat step in adding one more way to execute python code yeah all right what's your next one for us i am like totally in getting ready for pycon mode

and don't have uh didn't have time to do a testing code episode last week or this week so this is a shameless time i'm going to take my last slot to do some testing-related topics. But one of them is Flask. So we covered Flask already. Yes, a brand-new version. You can test it. Yeah. There's an article that came out this week called

Testing a Flask Application Using PyTest. And those are two of my favorite things, Flask and PyTest. And one of the third favorite thing is my own book. And the book that I wrote was part of the inspiration for this article. So shameless plug. But it's a really nicely written article. It's basically, if you're working with Flask and you want to try to work with PyTest also. I mean, I've had questions about this, but I didn't feel qualified to answer yet. Now I am because of this article. But there's talks about both unit testing and functional

testing through the test client that Flask provides. But the unit tests don't have to be, you can access things directly. But the article goes through both a couple examples, a unit test and then a functional test, like for instance, checking the, making sure that the new user works at a unit test level, and how to hook that up with PyTest and Flask and everything. And it's actually really nicely done. After you read the article, I don't stop there, I go out and look at the project that he's got on. I can't remember if it's on GitHub or GitLab, but it's an open source project that you can take a look and it's got on I can't remember if it's on github or or get lab but it's an open source project that you can take a look and it's got other more testing

examples and it's really well done and so good job I like it yeah it looks really really cool and I see the project structure there again like here's how you set it up to do testing so that's very nice and it's cool your book was inspiration for it as well another thing while we're on the testing topic, I wanted to bring up a new PyTest plugin that just actually kind of blew me away. This is a brilliant idea. And I also learned the word stochastic. I think I knew it at one point, but stochastic kind of means random and stuff. But it comes up because it's in the in the readme for this project called pytest-caprng so the here's the idea is if you've used random the random module or the

numpy random is being used in your in your code or in your test running a test if you run a test it fails and you try to rerun it and it passes, it might pass because the data is different. This new plugin, what it does is before you run each test, it captures the state of the random modules so that the seeds are the same next time you run it. If you rerun the failure, you'll get the same data again. So you'll see the failure again. And it's just kind of a small little plugin that is an awesome idea. So I wanted to highlight it. It's cool.

Yeah, it's cool. I mean, coverage might change based on that value. Success or failure might change based on that value. So being able to lock it down, make it predictable. Yeah. But still have it start from something random. That's pretty cool. I like it. All right.

I did say we were on the Eve on pycon eve right so the next time we release an episode is going to be at uh well at least it will have been recorded at pycon we'll see if it happens there anyway there's a really nice article by trey hunter he was a guest co-host a while ago on how to have a great first pycon so So PyCon is maybe the big, I think it's the US one is the biggest Python conference there is. It's certainly quite large. And there's a lot of options. It's a little bit of a paradox of choice there, right? I mean, did you have that experience when you were there, Brian? Yeah, definitely. And I'm really having that time, that experience again, looking at the schedule. I don't know what to go to.

I know. I'm going to solve that by not going to anything, which is part of this conversation. So he has a really nice, long, thoughtful write up about sort of getting the most out of PyCon the first time. If, you know, maybe if you've gone a few times, can still read this and get something out of it. So first of all, he mentions that the talks are typically recorded, available on YouTube within, I don't know, 24 hours? Something like that. Really surprisingly quickly. So you don't feel like you have to attend every talk, right? If there's something more interesting going on, don't feel like you're missing out. You just watch it later.

I think one of my number one recommendations, which he touches on, is open spaces. Yeah, that's actually something I didn't know about last year that I missed out on. So that's a good thing to... What are open spaces? There's a big board and there's a bunch of rooms. And the rooms will hold like 20 to 50 people. And there's probably five to 10 of them. I'm not sure exactly how many are available and

there's parts of the conference where you can just anybody who wants to have a group conversation about something they fill out a little uh three by five inch new little card and stick it up on the the board and claim an hour in a room and then people just go and attend it like they would any other talk but it's much more high participation because there's not a proper speaker you just have to basically kick off the conversation and then it's just like a group conversation i think that's awesome because that that's kind of what you go to pycon for anyway is to meet with people that have similar interests not just python as a whole but specifically what specific parts of Python that you're interested in.

Right. You might have like an IoT open space for people working with MicroPython or something. Who knows, right? That would be easily something you could put together. The other thing is all the talks are recorded. Almost none of the open spaces are recorded. Yeah. So you can't make those up. So that's one thing I really like to do. And Trey goes into that a little bit. He says they're often more niche and maybe something you're really focused on.

It's all about interaction and discussion, and they're not recorded. So he pretty much has the same thoughts I do. He has some tips for conversation around breakfast, lunch, dinner. He talks about the hallway track. I'm a big fan of the hallway track, partly because the sessions are recorded. And partly the reason I go there is to meet people and to make connections and to have these interactions that I don't have

outside of that space. Right. So I find almost always I'm having a great conversation with somebody and then like, oh, the session starting. Like, you know what? Forget the session. I'll watch it on YouTube. Let's keep going on whatever it is we're doing because this is awesome, right? And I find like I spend the whole conference that way. Yeah, it would be lame if nobody went to the talks though. No, I know. I'm going to go to your talk, by the way. Okay.

I guess I think – I guess more I'm saying you're right. People – not everybody should just skip them all the time because then what would it be? It wouldn't really be the same. Don't feel bad about it. Yeah. Don't feel bad about every one of them. If you will find yourself in a really interesting situation that you're enjoying, just because it's time to go to the talks doesn't mean you have to go to the talks. Right?

Yeah. The other thing that I thought was interesting about this was this conversation, this concept of a Pac-Man opening in a group. Yeah, I love that. Yeah. So the idea is like, you know, think of Pac-Man. It's got the little open spot. If you're in a group standing around, don't just like create a closed circle because nobody can join or anything. So always leave a little gap that says, you know,

look for people or look for groups that have Pac-Man openings and make sure that your group always has a Pac-Man opening. So that's pretty cool. Some advice for interacting online during PyCon, how to make the most out of networking, and it's not really a bad thing, things like that. And also volunteering. There's lightning talks.

Have you given a lightning talk, Brian? Not at PyCon. Yeah, neither have I. Yeah, it's just some general nice things. And then finally, one I thought was interesting, there was a person who commented on the post saying, if you're on Windows, it's helpful to install a virtual machine image of Linux like the current Ubuntu on your laptop because you might run into a situation,

a talk or a training where something they're talking about doesn't work on Windows and you might miss out. That's both an opportunity for us to make the Windows experience better, but also maybe good advice for the first person coming with your Surface tablet. You might want to come prepared, I guess, or install Anaconda, something like that. Yeah. So one of the things I wanted to bring up that I didn't know about ahead of time is there's certain sections of the day that is recommended that there aren't any talks scheduled, but what is the other floor called? The place where we're at?

The conference hall or the? The expo hall. The expo hall. But the expo hall is pretty much open all the time. So during a talk, if there's somebody that you wanted to meet up, meet, or a company you wanted to talk to or something that you can't get to them because there's so many people during the normal expo times, skipping one of the talks and going during a talk time, there's way less people in the expo hall and you might be able to catch up with somebody a lot easier. That's great advice. Yeah, definitely. So I think that leads us really well into our own news. What do you think, Brian? Yeah. So you brought up my talk. I do have a talk Friday

and I actually forgot the time. It's at five something. It's to do with testing, and you're giving that co-presenting with Paul Everett, right? Yeah, Paul Everett and I are going to, so I love PyTest, of course, but I also have, in this last year, fallen in love with PyCharm, so we're going to do them together. We're going to show you how to be efficient and effective

and speed up your test and development time with PyCharm and PyTest. It'll be fun. Your chocolates in my peanut butter. Yeah. That's awesome. And we have a booth. You and I and a few others have a booth.

I forgot the number, but you'll find us. It's pretty easy. All right? Yeah. And we have stickers. Yeah. I just got my stickers this morning. So yeah, I'll be ready.

Yeah, it's going to be a lot of fun. I'm really looking forward to meeting people. So I hope everyone comes to say hello. That should be awesome. And then another thing, we talked about the open session. Are we planning on doing a live Python Bytes recording? Why not try? Let's do it.

Yeah. Let's give it a try. So I think we're going to do an open session live. The next Python By bytes is coming to you live from pycon it probably won't be streamed live maybe we'll stream it live i don't know if we can get the audio to work for that but we'll do what we can to do a live python bytes and then make that the show for for next week so if people want to get notified they want to make sure they don't miss the time because because it's an open session, we can't pre-schedule it, right? We have to go find a slot on that wall there. So people just

go to pythonbytes.fm at the top menu bar, click friends of the show and sign up there. Then I'll send out an email like once we have that time figured out that day. I'm thinking Saturday would probably be best. Yeah, I think so. Yeah. Okay. So sometime on Saturday, if we can pull that off. So that would be awesome. Hopefully as many people can come to that, that'd be best. Yeah, I think so. Yeah, okay. So sometime on Saturday, if we can pull that off. So that would be awesome. Hopefully as many people can come to that. That'd be fun. See how the sausage is made.

Also, I'm just in a couple days leaving for Seattle. I'm going to be at Microsoft Build. Oh, neat. Yeah, that'll be really interesting. Hang out with some of the Python folks there. If you're at Microsoft Build and you want to come say hi, just shoot me a message on Twitter or something and we're there together.

It'd be great. PyGotham, the New York City PyCon, effectively, has just opened their call for proposals. And PyCon DE, which is held in Karlsruhe, Germany, which is a wonderful part of Germany, very beautiful,

is also just opening their call for proposals as well. And that's running 24th to 26th in October in Germany. So a lot of conference stuff. It's like conference time. Yeah. Yeah, we have Google I.O., we have Microsoft Build, and we have PyCon all next week. It's like they're fighting for attention.

Yeah. Awesome. All right, well, anything else, Brian? Have we covered it all? Yeah, I think we did. All right. Well, anything else, Brian? Have we covered it all? Yeah, I think we did. All right. Well, wonderful. Well, I'm looking forward to seeing you at PyCon.

That'll be fun. Yeah, it'll definitely be fun. Thanks. Yeah, and all the listeners. Yep, talk to you later. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S.

And get the full show notes at PythonBytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.