Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 69, recorded March 15th, 2018. I'm Michael Kennedy. And I'm Brian Okken. And Brian, probably nothing to cover with notebooks or anything. Like last time we had kind of an over-the-top notebook thing, didn't we? Yeah, we did. We covered a few topics on notebooks. Good thing. We probably won't do that again this week. I just want to say a quick thanks to DigitalOcean.
They're sponsoring this episode and many of the episodes of Python Bytes. So they really are helping make the show happen. Check them out at do.co slash Python. We'll talk more about that later. Maybe we'll talk about notebooks, Brian. Yeah, let's talk about them just for a little bit. So because we talked about notebooks last time, one of our listeners contacted us and said, we should take a look at a project called PYNB.
It says, Jupyter Notebooks in plain Python code with embedded markdown text. So the comment from our listener was, loves Jupyter Notebooks, but he also loves using his own editor. I think he uses PyCharm. I like doing that too, but you can't, it's like not trivial to edit. I haven't even tried to try to edit a notebook in PyCharm. You probably can, but I haven't tried.
But anyway, but I, I like this idea of there's, it's basically a converter that you can convert back and forth between a plain text with, or a Python code with embedded markdown back and forth to a notebook. So it looks pretty cool. Yeah, it's pretty wild. So you define like a cells function, and then you can put like docstring type equivalent of markdown, and that becomes a cell. And then you put a little bit of Python, that becomes a Python cell.
the more markdown within docstrings, and that becomes like another cell. And yeah, it's super cool. So a really nice, simple example. It's quite cool. Yeah. And one of the things that it points out, which is nifty, is it allows you to, to use diffs better with, with your version control tools or things like that. So that's, yeah, it's worth checking out if you, if you want to do more with notebooks, but want to be able to store them in plain text better.
It's really just right down to the essence of it, isn't it? Because the notebooks, they're pretty verbose. If you crack open the text file and look at them, you know, you look at, you look at this, and it's like, literally what you would see in the notebook is like, all you type. It's pretty cool. was one of my to-do lists was to play with some notebooks a little bit. So I'll play with this also. Yeah. So PiNB, Pi Notebook, check that out. Very, very cool.
So you know how there's this really cool William Gibson quote, the future is already here. It's just not evenly distributed. Yeah. I love that. That's a cool quote. Yeah, I do too. And I often, when I think of like, oh, where's that future we were hoping for? Well, it's not, well here. Well, maybe it is. It's just not evenly distributed. So this next thing feels like it kind of falls into that realm. And it's, it's definitely, like from the futuristic world.
I don't know how far futuristic is this two years in the future, 10 years or a hundred years or, or something like that. Or is it just live in science fiction? But I promise this has something to do with Python. It just takes a moment to get to it. So the announcement is that Microsoft has created a quantum computing language called Q sharp. Yeah. Okay. This just sounds neat. This is awesome. Right. Yeah. And it's been out for a little while. And we were talking before the show.
It's like, it was almost worth covering before just because, wow, there's a program programming language specifically designed for quantum computers. That's a pretty nice language actually. But the news is now it's available for macOS and Linux and you can try it. Right. So there's this new language called Q sharp. And if you look at it, it's a little bit like C#. It's also a little bit like either typescript in some ways, but also like Python.
And I was really pleased to see like the if statements don't have parentheses around the condition and stuff like that, because we don't need them. Why are we forced to write all those parentheses? Like they're unnecessary. We all know that from Python and Q sharp is sort of borrowing some of these cool ideas. The type annotations are very much similar to Python's type annotations as well. So quite cool. There's this new language.
One of the first questions you might ask is like, great, there's this quantum computer programming language, but there's no quantum computers. So what's the point? Like, why are we going to run this? I mean, I know there's like a couple of bits, but not, you can't go and get like a quantum computer to test your program on. So how do you test it? Good question.
Yeah. So they've got like this emulator type thing that emulates the behavior of a quantum computer, although I suspect it's slower than a real one. Well, are there, maybe I'm just not up to date. Are there quantum computers now? There are like, I can't remember who was, it feels like IBM, but there's like a couple of bits, like a two bit quantum computer and like, like it's super, super cold environment that can do like very simple things.
So, but it's not like a general purpose, you know, unless you've got like a hydrogen bath, like liquid hydrogen bath to put it in and things like that. So it's, it's based on topological qubits and quantum computers. So hence Q sharp, and it's out from macOS and Linux. It's awesome. On windows, you can play with it in visual studio standard, but on Mac and Linux, you can use Visual Studio Code. And there's like a quantum, programming code extension for Visual Studio Codes. That's pretty cool.
Yeah. And so you're saying that this ties into Python somehow. Somehow. In fact, so they said, all right, we created this new language and we created this way to emulate it. And there's actually some stuff in their cloud computing platform, Azure, where like you can plug in these things. So like they all tie together in interesting ways, but they said, look, we know other languages exist. And they're really important. The one language we think is so important.
It should be involved in this as well as Python. So you can now, you can now call, use Python to program quantum computers. Oh, that is awesome. Yeah. That's awesome. Right. You know, emulated quantum computers, but still super awesome. And they said, Oh, and a lot of this analysis has to do with like data science type stuff. So we'll also support Jupyter. Yeah. I predict a whole bunch of like people in college doing their thesis on this stuff like this. Yeah. That's a really good point.
Put the, the, the, the sciencey aspect back in computer science, right? Yeah, definitely. That'd be neat. So do you speak Spanish, Brian? I, you know, this is embarrassing. I took two years of it in high school, but I barely can order a burrito. Yeah. My Spanish is not very good, but one of, there is, there is a fellow, um, a Valbana, I think is his name. Um, that does speak Spanish.
And he gave a talk at PyCon ES in 2017 about pytest and let me know about it and, uh, showed me the slides and, and this was kind of cool. He sent it to me on Twitter and said, Hey, um, I forgot to tell you, I gave this talk last year and I think it was in September. And, uh, and I said, that looks really cool. There's a lot of neat stuff in it. Unfortunately, I don't speak Spanish. Um, but neat anyway. And he said, Oh, let me translate it for you.
So he translated the slide deck for me and the slide deck. We have a link to the English slides. Um, and there's also, if you speak Spanish or want to watch anyway, um, there's a video on YouTube that we'll link to. but one of the things I, one of the reasons I wanted to bring it up is because there's some neat things in there that I'd never heard of before. There's some that I have and some that I haven't. Like for instance, he does talk about, uh, using pytest Django.
So how to, how to hook up pytest with, how to, uh, Django models and stuff. And then a thing called model mommy, which is a way to mock out, uh, Django models. Uh, haven't heard of that. One of the things that doesn't get that I need to talk about in full length on my podcast is, uh, I test lazy fixture, which is, um, it's probably soon to be one of the recommended ways to, to have fixtures be able to go into a test function parameterized input.
Anyway, it's a, it takes a bit of explaining, but then there's some fun, also some fun things. Uh, freeze gun is a way to freeze time for your testing into a specific spot. And the interface, it looks really cool on freeze gun. That's cool. That, I love the names here, the model mommy and the freeze gun. These are great.
Yeah. And then a package called eradicate, which, um, like removes all the comments out of some code because, you know, sometimes code is easier to read if you remove the comments. So that's fun. Code comments are deodorant for code spells, right? They're there to explain why your code is fully written. Right. So a lot of the times if they're not full on documentation meant for like a help statement. Yeah, I totally agree. That's awesome. Anyway, those are, those are some fun things.
So I wanted to bring it up and then a bonus topic, uh, just today was announced that, um, by test.org added a reference page, which has a one page reference, full reference to the by test API. Oh, that's cool. All, all in one place. Yeah. Super nice. All right. Speaking about stuff in one place, let me tell you about digital ocean and a cool feature they have. So, you know, that you can go to digital ocean and create virtual machines, right? Like Linux servers and stuff.
Yeah. Yeah. So, you know, that's just the start a lot of time. What if you want to run get lab or you want to like set up MongoDB, or you're going to run like a discourse server, you got to install Ruby, you got to install the whole discourse stuff, the database, et cetera. So one of the things you can do at digital ocean, and when you go to create a new machine, they call them droplets, as you can create these one clip apps, one click apps.
So I can click over here and say, I would like to click and say, boom, new discourse server, all set up, configure it and save, go. I want a new ghost server, go. I want a new WordPress instance, go. And just click it and it's up and running. It's pretty awesome. Really? Okay. That's neat. Yeah. You can even do Docker. Like you want a Docker server, boom, hit that button and you've got Docker 17, 12 running. Yeah. On Ubuntu 1604. Perfect.
Neat. I'll have to check out all the one click things they've got. Sounds cool. Yeah. So they got a bunch of stuff that helps you get going in a, a nice way. So check that out. D O C O slash D O dot C O slash Python. And let them know that they are doing the right thing, supporting our show. Great. It is once again, that season in which the stack of workflow developer survey results come back, come out. So the 2018 developer survey results are out.
They said they had a hundred thousand, over a hundred thousand developers this time. I think last year they had 64,000. So this is cool. It's growing. And I thought it'd be fun to just cover some of the, um, high points. They spent a lot of time actually talking about like history of education. You know, like how much education level did your parents have a lot of that kind of social stuff. Interesting. That, that sounds neat. Yeah. Yeah. It's pretty interesting.
Like, um, yeah, things like that. There's a bunch of that, but I'm going to focus mostly on like the tech tech bits. So first, one of the first questions they asked was about open source. And they said, how many of you contribute to open source and 55% of professional developers contribute to open source. That's higher than I would have expected. That's awesome. Yeah. Yeah. It's really awesome. I think for, uh, all respondents, there were some students and stuff and people who retired.
So it was slightly higher. It's not surprising, but I thought the professional 55% was like the most interesting there. And then people often feel like if they didn't get a computer science degree in school, like they don't necessarily belong in programming or it's hard for them to get into programming, but it turns out that only 64% of the people have CS degrees. That's actually, um, yeah, I think that that's actually seems high to me.
Um, there's only about a third or less of the people I work with have CS degrees. Yeah, I agree. I think that seems even high for my experience as well. Maybe CS degree people spend a lot of time on stack overflow. I don't know. Maybe, but why are they spending so much time? Because supposedly they have a degree. Exactly. Come on. Uh, so one of the, um, one of the social things they talked about was sort of the sense of, belonging. Oh, nice. People's perspective as developers among their peers.
So they taught, they put that under the manner of experience and belonging. And they said, they had a graph and they said, okay, how much do you feel this is, is true or false over time? Like how much does this apply to you over time? Well, not over time, but if you've had one year experience versus a people with five year experience, versus people with 10 years, there's like a graph over years of experience and, and this metric.
So they said, uh, your connection and sense of community with other developers. And apparently the more time you spend in the programming world, the more that, you know, matches, which makes sense. Right. But they, they also said, uh, how much do you feel like you're competing with your peers instead of actually working together? Right. How much do you see it as a zero sum game? I guess. And at, in the beginning, it's people feel quite high that it's like direct competition.
That person gets more recognition. I get less, they get a raise. I don't, I don't know something like that, but over time that diminishes quite significantly. That's good. Same thing for, yeah, for sure. And then also the feeling of I'm not as good of a programmer as my peers pretty high at the beginning. Over time, people feel less and less and less like that's a true statement, which I thought it was good as well.
I mean, it seems to me like all of these are going in the right direction, the longer you're in programming, which is a positive statement for the whole ecosystem. Yeah. So, but it also shows that we need to try to teach students, try to get that connectedness and the less, less competitiveness. Teach that earlier. Yeah. Right away. Right away. You want a kind of a bleak statement that totally applies to me. How much time do you spend on computers?
The most popular answer, nine to 12 hours a day. Does that include your phone? I think it might even be behind a screen. I'm not entirely sure, but if like you kick back and play games or watch Netflix or whatever, it was also notable that the usage of Python has exceeded C# for the first time. They called that out specifically, I think. Yeah. Cool. Then the couple more things like there's languages and databases. They talk about the most loved, the most dreaded and the most wanted.
So most love is you're using it and you love it. Dreaded is like you've had to use it or you've never, ever want to use it. It gives you fear. And then wanted is I'm not yet using it, but I want to use it. So these are all interesting ways to measure things. So languages most love. Number one is rust, even though not that many people use it among the people who use it. They love it so much. Apparently, Kotlin is number two and Python is number three. Pretty nice.
Okay. Yeah. Dreaded VB six and coffee script. Keep away. Wanted. Python is number one, the most wanted language by 25%. Number two is JavaScript at 19, which is quite a drop. And then go is at 16%. So it drops off really quick. And Python is sort of ruling that. Yeah. That's great. Yeah. Databases. Yeah. Databases. Most love Postgres. Most dreaded is IBM DB2. Memcached in Oracle. And Memcached was responsible for the largest distributed denial of service attack ever.
And that was put onto GitHub recently. So, and then most wanted is MongoDB. A most popular editor, Visual Studio Code. Pretty interesting. Yeah. And for developers, what OS do they use? Last thing. Windows, 49%. macOS, 27%. Linux, 23%. Not where they deploy to, but what do they write their code on? That, and this is one that we need to pay attention to more, I think.
Because, um, of all the, a lot of the, the podcasters and bloggers and all of that within the Python community, I think, uh, either Linux or macOS might be, uh, higher. Much higher. but you're teaching to a group of people that half of them are running Windows. So you just can't ignore Windows.
Yeah. It's, it's a really good point that like, even though it's sort of the thought leaders and the people who see at conferences and, and speakers and whatnot are probably either Linux or Mac, the actual people doing the work and using the stuff is, is very much Windows still. So definitely not to be forgotten. Speaking of presenting. Speaking of presenting, um, Doug Hellman, um, he came up with, and there's got a new project, um, called Demo Shell.
And the idea is, um, it came out like somebody named Gene Hack on Twitter said, um, Hey speakers, if you're going to do live demos in a shell, clear the screen after every command and get the prompt back to the top. So folks in the back can see what you're doing. And that's, uh, completely reasonable. Yeah, it's a great idea. But instead of fiddling with it, um, so this, uh, demo shell is this site.
The idea is basically just to do that, to capture, um, a Python project, to capture your input and emulate a shell. But it really just pushes all the work off to a shell to do the work. But, um, but between commands, uh, puts your prompt back at the top and it's, um, it's in its very early stages. So, um, I actually reached out to Doug and said, Hey, do you want me to announce this yet? Are you, you ready for it? And he said, yeah, I put it up there to start the discussion.
Be happy if a bunch of people showed up and, uh, started, uh, participating and adding things. But, uh, he added a warning also that, um, too much interest is going to be met with commit privileges on the repo. Essentially, if you want stuff done, he might say, Hey, just go ahead and do it. Um, but actually that's a good thing. He's up, he's up for people to help him out. So, yeah, I think it's really neat. It's a cool idea. It definitely makes a lot of sense.
I've done so many training classes where it's not like stadium seating. It's like flat, right? And it's usually in some room with a crappy projector screen. That's like too small, like a third of it's off, you know, people in the back can't see it at all. And this is perfect, right? You just, everything stays at the top. It's really great. And people out there looking to find an open source project to work on, right? Go and express some interest.
You might be met with commit privileges on the repo, but it's, it's still in its really small stages. There's not a lot of code there, so it's pretty easy to read. So yeah, that's awesome. It's cool. Nice. All right. So let's wrap this up with a really nice definitive statement. The last thing I want to talk to talk about is Python two's end of life. So we've spoken before how there's the Python death clock and it's, we know that in 2020, Python two will go unsupported.
What exactly does that mean? How strict are they going to be about that? Is it going to be at PyCon 2020? Is it going to be the end of the year, beginning of the year? Well, my friend, Nicola Aroshi, he, who I have more news about in just a little bit, he's put this out on Twitter and got my attention. Basically there was this discussion on the Python mailing list saying, will there be a period where Python two seven is in security only status before hitting end of life.
So like say 2020, will it go into like, well, we'll do security fixes for a while, but no new features and we're not changing anything. Or like, what is that going to happen earlier? Guido actually came out and said, let's not play games with semantics. The way I see it, the situation for two seven is the end of life is January 1st, 2020 beginning of 2020.
And there will be no updates, not even source only security patches after that date, period support from the core devs, the PSF, Python.org completely stops on that date. Yeah. There's, there's your answer. That's a pretty abundantly clear, isn't it? Yeah, but that's way out. That's like, that's like, like way in the future. That has to be at least, a year and a half away.
So for those people with like millions of lines of code on Python too, they probably should start checking out things like my pie and some of the other tooling on pushing that along. Right. Yeah. Or, I mean, if you're planning on leaving your job and going to another company within the next couple of years, don't worry about it. Yeah, exactly. Or I, I know I've got a better one for you, Brian. I got a better one.
Or you want to get a really sweet consulting job, migrating Python two to Python three, you know, learn all the nuances and go and, you know, when people are freaking out in November of 2019, you're going to be in sweet demand. Actually, that's not a bad idea. Right. My rate's $250 an hour to start. So let's go with that. Yeah. I can help you with this problem. It's going to take a while though. Hmm. I got, I got about a year to beef up on my conversion, do some conversion study on this. Right.
All right. Yeah. Awesome. Do you, you got any, uh, news or extra things you want to throw out there? You did some recent testing code episodes, right? Yeah. So I, I guess I just wanted to shout out that I'm back into recording more often. Yeah. Yeah. Um, and I thought I'd, uh, um, I start with a little test project.
So I've got a project called cards that, um, it's kind of a to do app, but I want to, I'm focusing around using it as an, just as an example bed to talk about things that I get questions about all the time. So, okay, your book is great for how to write the, the tests actually, but what tests do I write? How do I pick which tests to write? How do I, how do I pick test cases? Basically this, this, um, intro to quality assurance, uh, but for busy people that don't have a QA team, how do I do that?
So that's where, where we're exploring. I'm, I'm two episodes into it and I'm just going to run with it until it runs out of steam. So check those out. Those are really awesome. I think that's great, uh, advice. And when people get that wrong, testing seems super horrible, right? You're like, what do you mean I got to test every single thing? Like, like if you're focused on testing the wrong thing, you can just feel super, like it's just super busy work.
Yeah. But it's, testing should be something to help you, uh, develop faster, not slow you down. And that's where I'm focusing my energy. How about you? Anything else? Well, I just got back from PyCon Slovakia. That was pretty awesome. So I wanted to send a shout out to everyone there who I met. And that was, that was fun. So if you're in central Europe ish, uh, next year, be sure to check that out. That was a good event. And also I have a new course. You do. And I'm excited about it.
Yeah. it's on the most, uh, most wanted database technology. So this is our, the first course based on Flask that I have. So this is, uh, on a thing called Eve, Eve, E, the E framework, which is a way to take Flask and a MongoDB database and turn it into a really awesome, restful API with validation and business logic and all that kind of stuff. So it's, it's a super cool way. And it's like really declarative. So you say, here's my models. Here's my end points. Here's the validation for them.
Make that a rest service. Go. And it's nice. So that's out now. That's actually written by Nicola Aroshi, the guy who talked about the Python two seven statement. He, he wrote that. And we just shipped it. He's also the creator and maintainer of Eve. So, uh, he's pretty qualified to talk about it. That's great. And I'm, I've already started listening to it because I'm very interested in this topic. So, yeah. Awesome. Cool. Well, links in the show notes, check that out.
And I think that might be it. Um, I'm really excited that we have a concrete statement on Python two seven and it's not like, it's just vague, right? Yeah. That's good to have it. I wonder if they updated the clock. Exactly. I was just thinking that we've got to recalibrate all the clocks. Cause they were all guessing. They probably got shorter. Awesome. All right. Well, thanks again, Brian. And thanks everyone for listening. 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 Python bytes. Dot. F M. If you have a news item, you want featured, just visit Python bytes. Dot. F M and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Okken. This is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.