This is Python Bytes. Python headlines and news delivered directly to your earbuds. Episode 4 recorded November 28th, 2016. This episode is brought to you by Rollbar. They help you take the pain out of errors. Hey, Brian, how's it going? It's going really good. Yeah, we had a Thanksgiving break, which meant kind of a shakeup in a lot of the news and the topics and whatnot. But that does not mean it was not interesting or controversial. It was a very controversial week last week.
In fact, it might be one of the most Pythonically controversial Thanksgivings ever. If I had to guess, I don't know. Trying to intersect those two things. Yeah, so let's jump right into that as the first item that we're going to cover. And we'll sort of lay this out for you. So you may have heard that a guy named Zed Shah has written a very famous book teaching people to write programming, basically teaching people to become Python developers.
He wrote this article called The Case Against Python 3 or something to this effect. And it turned out this article, which is a huge, long, in-depth, highly charged criticism of Python 3. It's like 15 pages long. And it basically, let me just read you a short excerpt straight from the article. And remember, this is coming from the person who is the author of the primary book for learning Python. It's referring to Python 3. It's as simple as that.
If you learn Python 2, you can still work with a legacy Python 2 code in existence until Python dies, or hopefully you move on. But if you learn Python 3, your future is very uncertain. You could really be learning a dead language and end up having to learn Python 2 anyway. Quote Zed Shah. Now, if this was just some guy on the internet, like who cares, right?
But the fact that this guy is our greeting person, this guy greets the new developers and welcomes them to Python and says, gee, Python is great. And you can even use it until it dies or hopefully you move on. Like this is actually a really big problem. How did this whole experience strike you? It was hard to have coherent words come out when I was trying to express how angry I was about this article. I'm just shocked by it, actually.
Yeah, I think shock and awe is really quite an appropriate summation of a lot of people's feelings. I got people writing me on Twitter going, what is this? Oh my God, this doesn't even like, like they couldn't even like cognitively put it together with Zed Shah being the author of that book. So let me like, like I said, it's a 15 page article. Let me give you a few of the key points. In fact, I was able to condense it down pretty tightly, I believe.
And everyone out there listening can decide sort of what this means to them. So there's a couple of key points. First of all, Zed says it's learning Python 3 or Python 3's existence is not in your best interest. And so this is a quote. The Python project's effort to convince you to start with Python 3 are not in your interest, but rather are in the best interest of the Python project. That's a case or point one against Python 3.
Number two is you should be able to run Python 2 in the same process as Python 3. Like, so they should be able to coexist in the same process as an execution engine. And the fact that no one has written a Python 3 interpreter that does this shows that Python 3 is not Turing complete.
It's one of the reasons that newcomers to the language can't use Python 3. I don't really understand that, but that was one of the major arguments that Turing completeness, because Python 3 has not been made to host Python 2, which I think is actually not even correct, but also not making a lot of sense to me. It also doesn't make sense that a newcomer would want to try to write a Python 2 interpreter in Python 3. It doesn't seem like a beginner task to me. Yeah, absolutely.
And so I actually had an exchange with Zed on Twitter. He was busy. He was talking to many people, because a lot of people had the feeling that you and I did, like, well, we'll get to that in the end. But we had this feeling that made us want to reach out. And so it really comes down, actually, to his, even though it took 15 pages in Turing completeness and computer science and all sorts of stuff, the actual complaint is the way the strings changed in Python 3 are hard.
And so here's a quote, again, from the article. The strings in Python 3 are very difficult to use for beginners. And in an attempt to make strings more, quote, international, unquote, they turn themselves into difficult to use types with poor error messages. And so that was straight from the article as well. So in my final analysis, I would say this. There's a huge uproar on Twitter and various other things like on Reddit.
I think you got like 500 upvotes across a couple of people who reposted this saying, basically, look, I'm going to absolutely scare newcomers to Python away from Python 3. And here's why. You can't add the byte string hello to the Unicode string hello in Python 3. That will crash. There's too many string formatting choices. And bytes aren't decoded to strings automatically. You have to pick the encoding and explicitly do that. Therefore, all newbies should avoid Python 3 like the plague.
It'll curse your career and cloud your judgment. So that was Thanksgiving in the Python world, basically. Yeah, that's just weird. I really have a hard time imagining that a newcomer to Python would need byte strings or byte arrays right away. Just not sure about that. Yeah, I mean, surely after a while, like if you were the person writing a network layer, like if you're writing requests, you're writing flask, you're writing pyramid, you got to deal with this stuff.
But beginners don't like do that the first day. They just work with strings and they might get something from a framework that's already done that decoding for you. It's crazy. Yeah, and I mean, I learned in Python 2 and the conversion to Python 3 was very painless. I mean, the only thing, I mean, I remember, gosh, the only thing I was waiting for was one of the libraries that I depended on. The interactions with DLLs was a little different.
So some of the, because of the string things, but let's face it, Python 2 used basically C strings and they aren't normal, just arrays of characters. And that's not good enough. It's not real. And it's actually, the argument's a lot contradictory to itself because the many formatting choices for strings are because we've came up with lots of better ways to format strings and kept the old ones for backwards compatibility, which is exactly what Zed wants us to do to keep backwards compatibility.
And yet there was this, one of the things that caused the break between two and three and make them not backward compatible is this decision about strings. And I just, at first I disagreed with it, but I'm after working for with it for a while, I totally understand the choice and it makes sense. Yeah. I think, I don't know what the alternative is. Sporadic runtime errors. Great. You know, I mean, come on. So, and it's one thing to say strings in Python 3 suck.
Like that's a reasonable contention. I don't make that myself, but you could. But to then make that immediately to be the case that you should absolutely stay away from Python 3 and even Python 2 is kind of a bad choice for you, but you can kind of stick with it for a while. Like that is, one does not follow from the other.
So, I got worked up and I was going to write up something about this, but this guy, girl, I don't even know the gender, Eve, E-E-V-E-E, wrote a fabulous point by point logical rebuttal of this and then sort of a personal comment as well. And so, we're going to link to that, which has the original article's quotes as well as comments about it in our show notes. Yeah. And I'd like to just say for anybody that's actually freaked out about this at all, don't be freaked out. It isn't a big deal.
And for history reasons or just a little background, Zed does like to jump up and down and make a lot of noise every once in a while. Yeah. Yeah. He even said on Twitter that he was looking to move on from Python. So, that's fine. I mean, I totally respect that. I've moved on from other technologies to Python, actually. But don't, you know, poison the well on your way out the door as your last act, right? Like that's...
Yeah. So, personally, I'm not going to recommend Zed's book anymore just as a point of... I just don't think this is the person that should be representing the first touch with people coming into Python. So, everyone else can do whatever they like. All right. I agree. Right on. So, let's talk about something newer, something in Python 3, actually. Okay. Well, one of the things that has come up in Python 3 as our second article is the asyncio has changed quite a bit.
And in Python 3, it's sort of gone through several iterations. And I'm not really an expert on it. But there was a Reddit discussion talking about an article. The article is actually from February. But the Reddit discussion is about the asyncio for the working Python developer. And actually, the article that we'll link to is, I think, a pretty okay tutorial on understanding some of the different terms. Like, now I'm even going to blank on them. But, like, futures and threads and tasks.
And I think it does a pretty good job. There's a couple downsides. It does use Python 3.4 syntax. And the syntax has changed. It still works in 3.5. But there is a newer async await syntax in 3.5. And... Yeah. And that makes it much more approachable, I think. It makes the code change significantly less coming from a synchronous model to an asynchronous model. Let the implementation and runtime deal with that for you. Yeah. But in that regard, I'd actually like this sort of...
So, this is one of the reasons why I included it. I'd like somebody to take this type of an article and write it with the new async await keywords. And it would also be great if they could come up with an example that didn't include just, like, sleep statements. Yeah. A real-world example would be great. Yeah. So, anyway. That's my second article. Yeah. And if you're looking to get into async stuff in Python, check this one out. It's cool.
We'll have another thing later in the show as well about async. All right. So, my second choice here was Piston, P-Y-S-T-O-N, which is an alternate implementation of Python as opposed to, say, CPython. And this actually is maybe most notable because it's coming from Dropbox, where Guido Van Ralsam and crew work. And Dropbox is one of the biggest sort of users of Python in the commercial space. And so, it's really a center of the Python universe.
So, they're working on a JIT version, a just-in-time compiled version of Python that is different than CPython. So, that's pretty cool. This release is the .6 release. The main goal was to reduce the overall memory footprint. So, they actually – there's a couple of interesting comparisons. It's 50% better than it was before. And let me look at the graph. Yes, in every single case, the memory usage is actually better in Piston now. It wasn't before.
Now, it is compared to PyPy, P-Y-P-Y, which is the other major active JIT implementation for Python. So, they also picked up some of the Python 3.6 features like order dict and so on. Okay. I guess I'm misunderstanding the graph. It is – it's still larger memory footprint than CPython. It is still more memory than CPython because I believe it's a reference counting garbage collector. I don't know that for sure. But it's – I think it's a GC-based language.
Okay. Possibly, which generally means more memory usage. Oh, okay. Certainly, PyPy is GC, which means more memory usage. So, it's interesting. It's – I don't think it's really there yet. I'm not totally sure. They focused a lot on NumPy implementation and some of the scientific stuff. But it's nice to know there are many implementations of Python. And here's yet another. Yeah, it would be cool.
And I think it'd be kind of neat if we could get somebody from the Piston project to maybe go on your show. Yeah. I would love to have them on Talk Python. I actually talked to them a little bit when the project was announced like a year ago. And they were like, maybe. I don't believe anybody ever agreed to come on the show. So, I might have to follow up with that. You're right. That would be cool.
I've had the Pidgin guys on, which is the Microsoft's version of that, which is actually really cool. Some of the Python core developers are working on it, Brett Cannon and groups. I had them on my show. And that was a super interesting topic. Yeah, it is interesting. I'd be interested to hear some of the motivation because, I mean, Dropbox has thrown money at it. There must be a reason around there. It's not just they're curious. No, there's something.
They actually are not using it in production yet, but maybe they're looking to. We'll see. Yeah. Okay. Before we get to the next one, I'd kind of like to tell you about our sponsor. How cool is it that we have a sponsor already? That's great, right? Yeah. I'm very grateful to these guys. Yeah. Rollbar is awesome. So, I actually use Rollbar. I use Rollbar before they sponsored the show. So, let me just tell you about them.
So, on the Talk Python websites, those across three sites there, they handle almost 2 million dynamic ACP requests a month and transfer upwards of 5 terabytes of data. But I deploy to them several times a week. I'm not even worried about pushing them out. Because in addition to continuous integration, if something goes wrong, my Slack, my email, my phone, everything will be blowing up with notifications from Rollbar saying, something broke, click, quick, quick, check the server.
And you'll get detailed error reports whenever something's wrong. If there is an error, you usually don't even have to debug it because all the info is right there. So, you Python Bytes listeners, you can have the same peace of mind. Just visit rollbar.com slash pythonbytes, which is also in the show notes, and sign up for the free tier. So, thanks, Rollbar. Thank you, Rollbar. And also, while you're there, there's a really fun demo you can play with. All right. Let's talk about docs.
Okay. I just heard about this last week. I'm not sure when they announced it. But there's a website called pydoc.io. And we're actually going to link to the announcement. It's on the Read the Docs site. I forgot who's behind this, but the idea is similar to a lot of API documentation generators. But it looks like they're going to try to automatically generate documentation about the APIs for at least a whole bunch of PyPI repositories.
Yeah. They said they're starting with the popular ones, but they said eventually their plan is to auto-generate API references for every package on PyPI. So, that's over 90,000 packages. That's pretty awesome. That's kind of incredible. Yeah. It may surpass all of the rest of the stuff on the Read the Docs right now, but I'm not sure. Yeah. So, it's really interesting. And, you know, I'm not really sure quite how it works.
Maybe it looks at the actual documentation in your Python code or whatever. But, yeah, have a look. If you have a package out there and you want to make sure it shows up well here, you know, be sure to check that out. Yeah. What they, a few of the packages they've got so far, I looked around and it looks pretty neat. Yeah, absolutely. I was cruising through requests. It's up there, of course.
So, we talked about things that maybe advanced people care about, you know, like converting bytes to byte strings and whatnot to regular strings or whatever. But I found an interesting article, really a conversation that I wanted to highlight. And the question was, what's the one thing or the primary thing that took your Python experience to the next level? And this is asked by a guy who's had like three months of Python and trying to get into it.
And so, I picked out five that I thought were pretty cool. So, the first one out there said that sort of changed their relationship with Python and how they wrote code was mastering generators. Another person said, how iteration really works. Understanding how iteration really works opens up so many possibilities, like learning how to do tuple unpacking, playing with zip, enumerate all, any, looking at iter tools. I find it's interesting in Python.
You know, another person said, list comprehensions, how important iteration and sort of processing streams of data is, right? Yeah. These are good. Yeah, these are good. One of them, I think, is going to be near and dear to your heart is unit testing and pytest in particular. Yeah. I would probably say do system level tests first. But yeah, I agree. Well, it changed this guy's life.
So, another person said, for me, all of David Beasley's work, in particular, his work on coroutines, which was sort of hinting at the AsyncIO stuff as well. Maybe I should check that out. Yeah, we should. Yeah, we could check that out for sure. One of the things I'd like to add to this is the, I see a lot of people that already know several languages. And then when they come to Python, there's a desire to just jump in the deep end and skip over some of the basics.
And I think anybody that's in that boat should go back and make sure they understand all of the basic data structures in Python because misusing data structures and things like for loops and if else and all those things and some of the comparison operators that are different than other languages can make your code a lot better right off the bat. Yeah, absolutely. I think it's one of the curses of Python's ability to be quickly and easily learned. You don't have to trudge through all the details.
You can almost just jump in like right away. But you do actually overlook some of its really beautiful nuanced aspects of it if you just have the same mindset as they come in from like C or whatever. Yeah, like I still find people that are surprised that have actually written Python for a long time that don't know that you can do two comparisons in an if statement. You can say like if one is less than X is less than 12 or something like that. Yeah, I tried pipe pipe and it didn't work.
So it must not be in there. So when you write code like that, you probably want to debug it easily, right? And the best place to learn how to quickly and easily debug your code is from my dinosaur. What? The guy who gave the talk was wearing a dinosaur suit. Oh, yeah, yeah. So I'm talking about Q. Our friend Luciano Romano gave us. Oh, yeah, totally. You like set it up for me and laid it up and I just dropped the ball. I was playing baseball over in the corner.
Dinosaurs. So Luciano Romano tweeted out something really cool and we both picked up on it. Yeah, Luciano Romano, by the way, way cool name. There's a product, a project on PyPI called Q and it's a quick and dirty debugging output for tired programmers. And there's a link to a five minute lightning talk by now I'm going to forget this guy's name. It was something cool. I think. Yeah. And the gist of it is just a way to add logging that saves to a file and in very little code.
And this is something you can add even to a running like a web service or something that you have no idea where standard out and standard error going. And you could still add some logging to find out what's going on. Yeah, it's really cool. What I really like about it is you basically say the guy hates typing. So everything's like one letter, which we could debate the merits of that. But you go instead of log something or print something, you say Q dot Q and you give it an expression.
It can be as complicated as you want. And it will actually figure out the expression, the method it's in, as well as the value and like give you a little summary. It's really cool. There's also a tracing thing. So if one function is being called with the wrong parameters and you're like, why is this happening? You can put like a decorator Q dot T on that function and it will trace the entire call stack with the name of the function, all the local parameters that are passed and so on.
Yeah. And just watching him in this talk to add like fairly complete logging onto a module in like, I don't know, 20 characters, the added to the file. It's pretty cool. So definitely check it out. And a bonus because he's in a dinosaur suit. Yeah, he's also in a dinosaur suit. One of the things I liked about it is because I'm one of those quick and dirty debuggers that I will not reach for the debugger first. I will reach for logging. And so this is good. Yeah, it was really cool.
And it's a five minute lightning talk at a PyCon, but it's like 25 minutes in. And so the link I put in there actually has the timestamp in it. So it should jump right to his talk. One of the things I liked is just it's a decent example for giving a good lightning talk as well. Oh, yeah. It was really compelling. People loved it. Yeah. All right. That's it for the news. You might have thought Thanksgiving was going to be dull, but no, it was not. Brian, what else is up with you?
Thanksgiving has put me behind schedule on my book. And so I'm going to have to take a little bit of a pause from some of the podcasts. Other than this, I'm going to keep up with this, of course, and catch up on my book. I do have some interesting interviews coming up, and I'll definitely keep those flowing as soon as whenever they come in. But that's up for me. What do you got going, Michael? Excellent. You know, not too much. I tried to catch up on a bunch of things over the downtime on break.
But also, I just have a quick follow-up from last week. We talked about how cool Python 3.6 is and that the release is coming that was in beta. I think I forgot to mention the expected release date of Python 3.6, according to the official page there, is December 16th, 2016. So that's actually coming up, you know, in a couple weeks, right? We're going to be having a shiny new Python 3.6. It's going to be great. Yeah, we'll definitely have to include that in that week's Python Bytes.
There's no way to avoid that. That's going to be awesome. Looking forward to it. It was great to chat with you, and thanks for sharing all the news you found with everyone. Thanks for talking with me, Michael. You bet.