Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 62, recorded on January 25th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
And we have a bit of a surprise and some pretty excellent news to share with you all this week.
So before we get to that, let's say thank you to Datadog, Pythonbytes.fm.
Check them out. They're doing really cool stuff. We'll tell you more about it later.
Hey, Brian, what's the surprise?
Actually, this is funny because you told me that Dan was going to be on the show with us.
We've got Dan Bader here.
Hey, guys. How's it going?
Hey, Dan.
Hey, Dan. Welcome to the show.
I also wanted to bring up some news with him because Dan is taking over RealPython.
That's awesome. Let's jump right into that.
So Dan is just coincidentally going to be on the show.
I was supposed to meet with him. I'm like, Dan, just, you know, we're doing the recording now.
We got to move it or you can just stick around and be part of it.
So Dan nicely agreed to be here.
Yeah, I literally picked up the Skype call and it was Brian and Michael on the call.
No, no. We had some pre-planning.
That's what it feels like.
A little warning.
Yeah. But coincidentally, the very first thing that you chose, Brian, also has to do with Dan
Bader. Has nothing to do with why he's here, though.
Doesn't make sense for me to tell anything about it.
So Dan, what's going on with you taking over RealPython?
Yeah, well, that's pretty much what's going on.
Moving forward, I'll run RealPython.com and, you know, all the social media stuff, the newsletter.
And it's just been a pretty crazy couple of weeks for me to, you know, get like work myself
into the site and like understand what all the content is there.
And actually also rewrote the whole thing and put it on Django.
So that was a lot of fun and a lot of work, too.
And yeah, so basically, you know, at some point a couple of months ago, I reached out to Michael
Fletcher and Jeremy and just asked them if they were interested in potentially selling the
site. And we worked out some deal over the last couple of weeks.
And yeah, so moving forward, I'll be running RealPython.com.
And I think, you know, it can grow into a really, really fantastic resource for Python developers
on the Internet.
There's a ton of really, really good guides and, you know, solid tutorials.
And it's just a treasure trove of content.
Yeah, I think it's a great thing because I'm going to link the announcement email that the
previous Michael and I think Michael sent out.
But the reason why they're letting this go is not because of anything bad.
They're being successful in their own careers and need to move on and do other things.
So I'm glad somebody's going to take it over.
And I'm excited that it's you.
Yeah, same here, right?
Yeah, that's really awesome.
Dan, what's the plans?
Where are you going with this?
With that sort of transition, it's always I think it's always really easy to break something
that fundamentally worked well.
And I don't want to do that.
Right.
So I'm working really closely with everyone on the team.
like actually, Michael, just published a fantastic Docker and Python wheels tutorial on realpython.com.
And so I'm sort of more like the managing director.
And I'm working with a bunch of authors to put really, really awesome content on the site.
And I think that's also where the biggest value is on the site, right?
Just a lot of free, really, really good content.
I mean, it's getting more.
It's getting close to a half a million page views a month.
So it's a really, really popular resource for Python.
And I think I want to grow on top of that, you know, and just have it grow even further
and have like really, really awesome tutorials and guides that people can go to and learn about
Python, learn how to program Python, learn about web development with Python, and just
turn it into a really, really awesome and nice community that people love going to and
like a really good resource that they enjoy learning from.
That's cool.
I know you've done it before.
And I think you can do it.
Does this mean that any of your other stuff is going to slow down?
Are you going to slow down activities on any of your other projects that you're working
on?
Or do you just sleep less?
Probably means I need to grow a couple more arms so I can, you know, write more, more content,
record more videos.
I don't plan to.
Like I haven't, I haven't really fully made up my mind yet.
I mean, to be honest, like one of the challenges with, with my stuff was that it was all under
a personal brand of sorts.
And I think that's really, really great.
But the challenge is that it's very hard to kind of bring in some other people and say
like, Hey, you know, this person is an expert at web scraping.
Like, I don't know a whole lot about web scraping, for example, but it always felt like a little
bit.
I didn't really feel supernatural, you know, to put that on my own, like private blog.
You know, that's, that's how I started out.
Like just started blogging on my own, like private portfolio site.
And now it's turned into, into something bigger and I'm offering courses and stuff.
But the challenge was always like, you're getting, I don't know, you're buying a ticket for some,
to see some, some show, like some band play.
And it's like some, someone completely different there.
And a lot of cases, like these tutorials were actually better than my own stuff, but it just
didn't really feel natural.
And I think with real Python, the expectation is much more that, Hey, this is everything about
Python and not necessarily from any one single person that's kind of driving all of that content.
And I think, you know, it could go either way.
Like maybe in the longterm, I'll actually merge my own stuff with like merge it a hundred percent
together with real Python.
And I'm just another author on real Python, or I'll actually keep it separate.
I think in the beginning, I don't want to, you know, move too quickly because it's, again,
it's very easy to break something that works, but it could happen.
I don't know yet.
Okay.
Well, moving on.
Yeah.
Congrats, Dan.
That's cool.
I'm looking forward to more nice stuff coming from there.
So Brian, you know, that I've kind of somehow put us out there as like carrying the torch for
Python GUIs with my, this is a weakness we need to work on.
And then we got a lot of feedback and both, you know, a lot of people agreed with that.
We had a lot of feedback and a lot of people agreeing, but also a lot of people saying,
Hey, it's working great for me and this is what I use.
So that's wonderful.
I really appreciated that because there were some things that I didn't know about and some
of them are really interesting and simple.
Some of them are more full featured.
I still stand behind that.
I think this is actually a place where there needs to be a lot of reinforcement to make it
more solid in the world.
But I want to introduce you to two things I'd never heard of and they're surprisingly similar
in their name.
One is called WUI and one is called GUI.
Have you, either of you heard of WUI or GUI?
No, but both seem like horrible names to find on Google, although the projects themselves are
awesome.
Brian?
Yeah.
Well, I get, I mean, I wonder if they're related because I get GUI that it's like G-O-I, but
it's spelled G-O-O-E-Y, but maybe WUI is just a, I don't know.
It's who knows.
So here, yeah, I think there's maybe a relationship between these.
So let me tell you what WUI is.
And while I'm at it, why don't you guys click through the link and go to the demo server,
which is at the bottom of that page and just like run one of those.
So what WUI is, is it's a Django app that creates an automatic web UI for Python scripts.
So if you have some sort of command line script, then, but you somehow want to expose this to
people who maybe don't want to run it on their own computer, but you don't want to write a
full web application.
What you can do is you can basically give it the command line arguments that it needs and
say like one of the examples of solving like a chess problem or something like that.
And one of the command line arguments is a number.
And so there's just a numerical dropdown for that.
And you press go and it runs on the web server instead.
And so there's a cool app on Heroku that you can go check out and play with.
And that's pretty cool.
What do you guys think of it?
I think it's a fantastic idea.
Like the last job I had, we were working with a data science team and they were producing
all of these scripts that were in some case like running,
like really important like processes for that business.
And it was always a challenge to get that stuff to run, like just as a one-off job.
And I feel like this WUI thing, I mean, it would be amazing, you know, if you could just host
that in the cloud somewhere and you have this interface to kick off these jobs.
And then, I mean, I like what it's doing with the outputs as well.
Like this cat picture example, like it actually gives you these downloadable images.
So it's not just throwing a bunch of text back at you.
And I think that's pretty cool.
Yeah, yeah, yeah.
It's pretty cool.
Brian, do you see you use for this?
Yeah, like a lot of times we'll, for things like this, we've been actually doing small
Jenkins jobs that you just push to start.
But this seems pretty much a lot easier.
It's pretty neat.
Yeah, it's pretty cool.
Okay.
So WUI, I think the WUI part must be for web GUI.
And then GUI is just a GUI.
So this one is similar.
It'll turn almost any Python command line program into a full GUI application with one line.
So if you check out the screenshots here.
So if you check out the screenshots here, this one is really cool.
So it'll create these sort of, you know, full desktop applications.
Like the example that they have in the screenshot is really a, like a Windows application.
And it has a, like a nice little header with a description.
It's got the, you know, the arguments that you can, they're either like options, selects, or places you type.
But it's really, really similar in the same idea.
But this is actually, you could package this up with, say, was it briefcase from Toga or from Bewareguides?
Or you could package it up with CX Freeze or something like that and just say, here, we built an application.
The word Python doesn't have to appear in that statement, right?
What do you think, Brian?
Of course, I'm often building tools for development teams.
And for something like that, I think that's a great idea.
So instead of having somebody that's not used to working on the command line so much, be able to give them a command line tool where it, like, describes all the input.
Yeah.
Yeah, it's cool.
Again, these aren't, like, generic.
You can build any application with this.
These are still sort of shims that bridge command line programs to user interfaces.
But it's not, this isn't the final solution.
No, this certainly doesn't cover everything.
But this covers, like, a really quick, hey, I want to take some arguments from a user and I want to be able to click a button.
But I don't want the, you know, you're not going to go to, like, the secretary at a dental office and say, okay, you're going to need to pip install the requirements and then run the CLI command.
And then the thing is going to work, right?
But you could give them this and, like, the same effect would basically happen, right?
You know what it reminds me of?
Yeah.
There's this GUI version of curl, like, the C URL, the download command.
And that's something that somebody had to build around CURL or, like, you know, recompile it and add all of that GUI stuff.
And with this GUI framework or tool here, it looks like you could just take any Python script and basically have something really similar, like some kind of Windows front end or I feel like this is cross-platform.
I think so, yeah.
And just have that within a couple of minutes, potentially.
So this is really cool.
It's really tricky.
It really is a sweet trick for a nice, small CLI.
What would be the GUI equivalent of a CLI app?
Yeah, for sure.
And one more shout out I want to give to you.
I can't remember if I already did this because this is, like, week three or four that we've been on this journey.
But Toga as well from the Beware guys.
So they're doing pretty good stuff.
This is, like, a framework that lets you build truly native apps, which is really cool.
But I feel like it's not quite polished enough for people to be building full-on things with.
And mostly what I mean around that is there's the two things you're like, oh, these are really awesome.
Let me check the, you know, like the two we had the conversation around where you were able to run the demo server and get the cat pictures.
Or you were able to see these awesome screenshots of, like, all these examples.
And I feel like the Toga project could totally use some, like, showcase of what people have built.
Because right now there's, like, really none.
And so if anyone's built anything cool, like, try to work with the guys over there to showcase what you've already built.
Because I think that would make a big difference in the adoption of that.
Yeah.
And I think they're super receptive to that.
They have a really good first-time contributors guide and, you know, how to get your pull request reviewed and stuff like that.
So I think it's a really welcoming project, too.
Yeah.
Absolutely.
Brian, you think that Python's readability might be a little misleading.
It lulls people into believing this is just a simple little thing.
Great.
Like, a lot of times we've said that the way to convert a pseudocode to working Python is to change the extension from text.
TXT to PY.
Exactly.
I wish.
Yeah, I fixed it.
Here's an article from Ned Batchelder, who I hold in the highest regard.
But he's got an article called Python's Misleading Readability.
And I wanted to point it out because it's something that I didn't even really think about.
Is that often we're sharing script, you know, bringing new people up on a team and teaching Python or at least enough to run some code that you've got or some test code.
And some of the pieces of it are so readable that they are misleadingly wrong.
So one of the couple of the examples are is and or.
We use those and they almost read like English.
Like if if name is Ned, well, that's not going to work because, you know, it's it's we really need equality there, not is.
And then a similar thing with or.
It's something interesting that I wanted to point out because, yeah, a lot of people get this messed up.
I think that's a really interesting angle.
And I feel like it also means that people don't fully commit to learning Python when they come from another language.
So I know Java.
I got dropped into a Python project.
I did some tutorials over the weekend.
I now know Python in my mind.
Right.
But it's actually, you know, the whole Pythonic code, the proper idioms, the hundred and twenty five thousand PY package libraries that you don't know to use.
There's so much to learn, but it doesn't feel like it at first glance.
You can read somebody else's code and understand it easily, but you may not be able to reproduce it.
Right.
So anyway, I think that's a good.
So go out if you if you're learning Python, make sure you learn.
Don't get afraid of it, but make sure you learn the what the all the operators do and what the core data structures are like.
And one of the things that I've seen.
So I see I have a lot of coworkers that switched our learning Python from coming from C.
So one of the things that we don't do in C is if you're like in a Ned puts an example at the end of his article of if you have got a possibility like you should.
If a variable could be many different values and a common thing in C would be, well, if X is three or if X is seven or if X is eight.
And the Pythonic way is to just say if X in and then a list of the possible options.
And that's a that's a mind shift that freaks people out when they first see it, if they're coming from C or something else.
A lot of this stuff could be caught by a linter.
Good job, Ned.
Yeah, really, really enjoying the article that Ned put together because it's yeah, I definitely agree.
Like it's it's a double edged sword, right?
If you have a language that's relatively easy to get into or just learn enough to be dangerous with it.
But it kind of creates this false impression that you already know everything, right?
If you if you can write a bit of Python.
And yeah, it's definitely not like that.
Yeah, I totally agree.
There was a great talk at PyCascades, which I'll talk about later.
That was just this week, actually.
Like I literally got back last night by a guy named Thomas Bollinger called Python is not Java or C++.
And it was really, really interesting.
He's Python developer, I think, at Google.
I can't remember, but somewhere like that.
And basically, he said, look, a bunch of people are coming into this company and then getting into these projects that are Python projects.
But they have maybe Java or C++ experience.
And so these are the common pitfalls Java developers have when coming to Python.
These are the common pitfalls that C++ developers have.
If you're aware of them, you can help shepherd them along and make the transition easier.
So that's also worth checking out.
I'll link to that in the show notes.
All right.
Before we move on, let's talk about Datadog really quick because they are making this show possible.
So thanks for supporting the show, Datadog.
They if you don't know about them, they are a monitoring solution that provides deep visibility and lets you track down issues for distributed Python applications.
So not just your Python code, but deep down into the systems like inside MongoDB or inside Linux and things like that.
So you can quickly investigate bottlenecks in your code and actually explore them in like rich dashboards, which is really cool.
You can visualize your Python performance today and get sort of the free trial.
And if you go through their little tutorial, you can even get a free T-shirt.
So it's got a cute little dog on it.
So at pythonbytes.fm/Datadog, check that out.
Help support the show.
And, you know, check out a cool product.
So I mentioned that we I was at this conference, PyCascades, which was the first time it was ever run.
It was a big success.
It was very fun.
Like I said, I'll talk more about that later.
But one of the big messages really was around Python 3.
And I think this whole legacy Python versus Python thing is starting to have an effect, right?
Yeah, I think it definitely.
Yeah, we've heard from a number of people that said, hey, you know, you guys, I've heard it enough.
I've switched.
And like, here's my commit that makes my project actually Python 3.
I've seen that more than once for us.
Yeah, it's kind of a need to, we didn't really ask people to, but I've been enjoying having people contact us and say, I've switched.
I love Python 3 now.
That's right.
It's awesome.
So one of the ways that I think, you know, people get stuck is there's some particular package they depend on.
This is less and less and less, but it still is the case.
Or there's some part of code.
They're like, they really just don't want to touch that.
The person who wrote it left.
Nobody knows how it works.
I don't want to break it because that makes it mine.
So we're just going to leave that alone.
So one of those interesting projects that I ran across is this thing called a warp 2.
Have you guys heard about this?
No.
Nope.
I hadn't either.
So it says you can use this project called warp 2 to access Python 2 code from Python 3.
Brilliant.
Yeah.
So you've got a subset of your app that's running in Python 2.
That can stay in Python 2.
And the modern part of your app can be upgraded to Python 3.
That's really nice.
I mean, that must be great for if you have a lot of legacy code and you don't want to tackle everything at once.
You can sort of use this divide and conquer strategy and just like fork out some work to Python 2 and then ferry data back and forth.
That's really cool.
It's really interesting.
And I think it might be a solution for certain situations.
At PyCascades, the keynote was given by Guido Van Rossum, which is really great.
It was awesome to have him there.
And basically, the keynote subject was Python 3, a retrospective.
What went right?
What went wrong?
One of the things that he talked about that he wished they would have done would have been enabled Python 2 and 3 code to execute in the same runtime somehow.
Right?
And so this kind of makes that possible.
And the way it works is it communicates.
It basically creates a Python 2 subprocess.
And the main Python 3 app runs.
And then anything that needs to run in Python 2 runs in the subprocess.
And then they're communicated with using Pickle.
So it kind of serializes the objects in a binary form back and forth, which is not totally amazing.
Right?
But, you know, for people who are out there looking to migrate maybe new features in Python 3 or they need to keep some small section of their app in Python 2, check out Warp 2.
This is pretty interesting.
It's just a very tiny example of it does show that there's you can have this like create a Python 2 object that the Python 3 world can like reference object.
Yeah.
And then you can have this like methods and stuff.
Yeah.
Interesting.
Yeah.
It's a really cool idea.
And so I had never heard of it.
And I think it could be we've got a couple of pillars making this Python migration really like even better.
Right?
So one of them is mypy and PyAnnotate and all the stuff around there, which is also a huge subject at the conference.
And then this Warp 2 is just another tool to make this smoother.
Yeah.
Cool.
All right.
So you're having a problem with your tests and they can't see your code, Brian?
Is that what's up?
Well, I wanted to bring this up because, okay, so I wrote that pytest book.
And probably the number one question I get from people is, okay, I love this stuff, but my test code can't see my code under test with pytest.
It could with unit test and now I'm running pytest and I can't see it.
And so I wanted to highlight it here, talk about it a little bit.
I really probably should cover this on testing code also, but I'll try to make this quick.
But the gist is that pytest, on purpose, this isn't a bug.
It doesn't add the current directory to the Python path.
But Python does.
And when you're running unit test, you run unit test with Python-m unit test.
And so you're getting the current directory added to your Python path.
So as long as you can see your code under test from your Python path, and let's say you have all your test code in a test directory,
you'll be able to import stuff in your test code because your current directory is in the Python path.
Now pytest takes that away from you.
And how do you get back at it?
Well, the real answer is you write a setup file and use pip install-e for your project,
which makes it so you can keep writing your code, but your test code can see it also.
That's sometimes a hurdle that people aren't willing to do.
So there's two quick answers.
That's run pytest just like you would unit test do it as Python-m pytest.
That adds your current directory.
That's interesting.
So you still run Python as the main thing, but then you just tell it to run pytest.
And it does the path alteration.
And if that is a cringeworthy for you, there's a little package called pytest.
It's a plugin for pytest that's called pytest-PythonPath that does it for you.
So it just modifies.
It's a very small plugin that modifies the search path to add your current directory.
It also adds a couple extra hooks so you can include your test code in your code under test or completely in different way different directories.
You can specify where that stuff is with that.
So I just wanted to highlight those here.
So if people are having trouble with that, go check that out.
Yeah, those look really cool.
Brian, are you using pytest?
Yeah, every day.
Sorry.
I mean, Dan, are you using pytest?
Yeah, I am using.
I'm looking at your picture, Brian, and talking to Dan.
It's hard.
I'm using it.
I think it's a really great, yeah, just testing framework, test runner.
And I mean, Nose, I also like Nose.
And I think there's a benefit to using what's built into the standard library as well.
But usually for my projects, all of them are in pytest.
And I know it's just so frustrating when you run into an issue like that.
When you just want to try out a new tool or even get started adding tests to your app in the first place.
And then you run into a roadblock like that.
I mean, Brian, would you just describe?
That could take someone almost like a day to figure out, right?
Like if they had to dig through the depths of the internet to find that.
And so, yeah, I feel like resources, you know, like your book and what you just said.
I think that can be a real lifesaver if you're just getting started with pytest, for sure.
Right.
And if it's the first roadblock you hit, a lot of people are going to go, oh, this just sucks.
I hate pytest.
Why is it hard?
I'm out of here.
Yeah.
Yeah, for sure.
All right.
Last official thing, at least.
I want to talk about cement.
But not, you know, like buildings.
But the framework for building CLIs.
So it's a yet another CLI application framework for Python, which is pretty cool.
So others are like argparse and click and these types of things.
And it tries to provide like a full featured platform, but also, you know, allow you to just have like a nice, simple way to work on it.
And it has this idea of like extensions and handlers.
So you can like sort of build these plugins that you hook into your CLI application, which is pretty cool.
So people can check it out.
It even has things like built-in logging, caching for improved performance.
Lots of cool stuff.
Yeah.
Wow.
This seems, I'm looking at the examples right now.
This seems really, really intense.
I wanted to say, but this seems really powerful.
This is more like the, I don't know, like the Django framework of Python CLI frameworks.
It's pretty in-depth.
Yeah, it did feel a lot like that.
So just one more thing to put on people's radar for building CLIs.
If Wooee and Gooee weren't enough.
Yeah.
So I usually use Clix.
So I'll be interested to try this and see how it compares.
Yeah.
Clix got its very own special way of working, doesn't it?
Yeah.
I mean, what I like about this cement thing is that it seems to have a really nicely designed
object-oriented interface.
So it looks like it's maybe a little bit more boilerplate to get set up, but then it's probably
more maintainable in the long run.
Like if you can really, you know, factor things out nicely and split up your app.
Right.
Like I like the idea of these extensions and handlers you can plug in and stuff.
They're probably pretty testable too, if pytest can see them.
All right.
Well, I think that's it for our items.
Dan, we already heard your news.
Very, very big news with RealPython.
Congratulations.
Thanks.
Yeah.
Brian, how about you?
Any personal news to share?
A couple of test and code interviews coming up, the recording.
And so I'll be excited to get those out.
Awesome.
What are the topics?
Actually, one of the topics is whether or not you should consider continuing education
through a university versus learning online and other things.
Oh, very nice.
Yeah, cool.
All right.
Well, I mostly want to talk about conferences today because I feel like conference season
is either here or nearly upon us.
So like I said, I was just in PyCascades and that conference was really fun.
It was, I don't know, maybe 250 people, something like that.
But really nice conference, a lot of luminaries there.
Get to spend some time talking with them.
The talks were really well done.
I think they're going to be online, but I'm not sure if they are yet.
So the next one they're going to have in Seattle in about the same time next year, which is going
to be cool.
And I think even after that, it comes to Portland.
Woohoo.
Yay.
And we're trying to plan some sort of outdoor adventure around it, like a skiing or like
a snowshoe adventure, like before or after the conference is like a part of the conference.
It'll be fun.
So anyway, check that out next year.
It's in the past.
So you missed it this year, but you probably see the videos online.
It was really good.
I want to give a shout out to PyColumbia.
That's coming in February 9th, 10th and 11th in Medellin, Colombia.
I'm not going to be able to make it, but if you're in South America, that would be awesome.
There's PyCon.
Before we move on, I just need to shout out to PyColumbia that you guys need to send me
a t-shirt because your logo is really cool.
Yes, it is definitely cool.
PyCon Slovakia, March 9th to 11th in Bratislava.
And I'm actually going to be speaking there.
I'm going to be doing a workshop and that's going to be super fun.
And then there's the big one.
PyCon US, Cleveland, Ohio, May 10th.
Tickets sell out.
I don't think they're sold out yet, but do not wait if you're going to go to this.
Right, guys?
Definitely.
I missed out on one PyCon and I'm not going to do it again.
Yeah, I already got my ticket.
Are you both going to be there?
You got your ticket?
Yeah.
Awesome.
And finally, this just in this morning, PyCaribbean, Santo Domingo, Dominican Republic, 17th and 18th
of February.
So a lot of cool stuff coming up in February and then a little bit later as well.
Also, there is a new Python podcast that gave a shout out to both you and me, Brian, our
various podcasts and the intersection here as well called Python Out Loud.
So that's pythonoutloud.com.
Check that out.
And yeah, that's about it for the news this week.
A lot of good stuff going on.
And so, Dan, thank you for making our meeting a podcast episode.
Yeah, thanks for inviting me on the show.
Yeah, yeah.
Thanks for joining us.
Nice surprise.
And Brian, as always, thanks for sharing the news with everyone.
It's great.
Yeah, thank you.
Yep.
You bet.
Talk to you next week.
Yep.
Bye, everyone.
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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.