Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 82, recorded June 13th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
And we have, I think, quite a big episode.
I'm sure people have heard about this thing with GitHub.
What do you think?
Yeah, I think so, probably.
It's definitely when the news about Microsoft buying GitHub came out, it definitely made some waves.
So we're going to talk about that.
Before we do, though, let's say thanks to DigitalOcean.
DigitalOcean is sponsoring this episode and many of the Python Bytes ones.
So check them out at pythonbytes.fm/DigitalOcean and get $100 credit, which is pretty awesome.
So we'll do the GitHub conversation at the end.
We'll focus on that.
But Brian, you got something about documenting REST APIs first?
Yeah, so there's Doug Farrell.
I think we've highlighted one of someone's writing before.
I'm not sure.
But I definitely remember the name.
But he wrote on the RealPython site an article called Building and Documenting Python REST APIs with Flask and Connection.
So one of the things, as you know, I've been playing with a little command line application on testing code.
But I wanted to add a REST API.
And so this caught my eye.
And I had also heard of Swagger.
So this is one of the things that I like about this article.
It talks about, first of all, it doesn't assume that you already know what you're doing, which is nice.
It does talk about what REST is and what REST isn't.
It has a nice explanation of REST and how that works with web APIs.
And then I know a lot of people are, I think a lot of people use Swagger as a definition.
It's a YAML definition language to define what your API connections are.
And so this article uses that.
And then also it's to implement a little CRUD application.
And then I had never heard of this connection module or package.
And there's a...
Yeah, connection with an X.
Yeah.
So connection that takes a Swagger file and helps you to implement the API with Flask.
And it's just a fairly brief read, but I haven't done the demo yet, but I'd like to.
And one of the things that Swagger gives you, if you're familiar with Swagger, is that if you use it, you automatically get these cool user interfaces for your API that humans can read.
And they can...
So it's kind of a self-documenting API system.
So taking advantage of that is nice.
Yeah, that's really cool.
I definitely have heard of Swagger.
And I think Swagger is pretty cool.
I've checked it out some for some of the APIs I've done.
I've never heard of connection.
It's like...
So basically, you give it your Swagger file and just say, yeah, do that.
And it more or less does, huh?
That's pretty cool.
Yeah.
And then...
And there...
I mean, there's some pieces left over that you have to, like, tie everything together.
So this article goes through that.
And one of the nice things also that I...
I've seen a lot of REST API tutorials that kind of leave the ending.
Then you just have, like, a REST API with nothing using it.
This article finishes it up with a web application that uses the API to...
With some JavaScript plugging into it.
So it talks about that.
Which is good.
Because I wanted to play with this.
But I'm really not a...
I'm not a JavaScript person.
So having somebody write that for me so I can play with it.
That's cool.
Yeah.
Thanks, Doug, for saving Brian all the work.
Yeah.
And it turns out that a connection comes from Zalando, which is the largest online fashion platform in Europe.
I actually had them on Talk Python a while back, which is interesting.
I didn't put those two together.
Although I'm pretty sure we talked about that, like, two years ago and I just forgot.
Zalando.
I like that name.
Cool.
Yeah.
It's pretty cool.
I'm probably mispronouncing it, actually.
But that's all right.
That's pretty standard fare for our podcast, right?
Yeah.
Nice.
Yeah, that's a good pick.
I really like it.
I think Doug's article is well done.
And it's super thorough.
So, yeah, if you're looking to get into writing APIs with Flask, then this is worth checking out.
And certainly the swagger connection aspect is kind of unique, I think.
Yeah.
So mypy, that's Guido Von Rossum's main project, as far as I can tell right now.
Him and some folks from Dropbox are working on mypy, which is a static type checker for Python, right?
Yeah.
That's pretty cool.
Yeah.
They haven't heard much about it yet or recently.
Yeah.
They're still doing stuff on it, as far as I can tell.
And it's coming along.
The big news that I got for this next item is there's now a plugin for PyCharm for mypy, which is pretty cool.
So you're like in your PyCharm project, you hit a hotkey, and then you just get full mypy type checking.
Okay.
That's cool.
Yeah.
I like that.
Yeah.
That's pretty awesome.
So, yeah, this is by Ivan Levkinvitsky.
See?
What did I say about this?
So, yeah.
Thanks, Ivan.
This is really awesome, and it's great.
So, Ricky Tici asked, you know, what on Twitter, I linked to the conversation, says, you know,
like, PyCharm already has type checking, right?
So if you pull it up, it'll say, hey, you're calling this function, and it's using it wrong,
or you're trying to pass an int, and it takes a string, or vice versa.
It says, well, why would I care about this plugin into PyCharm, which already does that kind of stuff?
So, Ivan had a few bits of feedback.
He said, well, mypy is a little bit more strict and precise than PyCharm.
It's a lot more configurable with rules, and it type checks the entire program, like, all at once, not just, you know, what's loaded in your project.
So that's pretty cool.
And then sometimes people use mypy as part of a continuous integration path, and you might want to run mypy quickly before you do a push, just to know what the outcome will actually be.
So, you know, hotkey, and then you commit.
Pretty sweet.
Yeah, I'll have to check that out.
It's nice.
Yeah, I've been pretty much just leaning on the PyCharm type validation whenever I use it.
But I can certainly see projects where mypy has lots of value, and it's still my working theory that the reason they're so heavily working on it at Dropbox is they're trying to use mypy to convert to Python 3 safely, maybe even automatically.
Okay.
Well, speaking of automatic.
That's my working theory based on no data other than outside observation.
Was that, like, a really cool segue that I just missed?
Yeah.
Okay.
So I've got, like, what if you had, like, a tool that could just automatically upgrade for you?
That would be fantastic.
I know that there's, so there's a 2 to 3 already, but it's fairly non-invasive, the 2 to 3.
I think Python still ships with that, doesn't it?
I think so.
Yeah, I think so.
And I've used it a couple times, but it's pretty conservative.
It's basically to get you over the hump from 2 to 3.
But what if you want to go, like, farther?
And you want to, like, one of the things that I want to do is I want to take some of the code I was using prior to Python 3.6
and be able to convert some of the strings to f-strings because they're nicer to read.
And this will do it for me.
I found a tool called PyUpgrade.
And it's a tool, and it also can be a pre-commit hook that automatically upgrades your syntax to new versions of the language.
And it does all sorts of stuff, not just f-strings.
And the f-strings also is optional, so it doesn't do it by default.
Like, if you're converting to Python 3.5, don't do that.
Yeah, it'll crash.
But, for instance, the set literals have changed.
You can have an easier-to-read set literal syntax.
Also, dictionary comprehensions and some things like that.
The Unicode's changed a little bit.
And, yeah, anyway, being able to automatically do that is pretty fun.
Yeah, that's pretty awesome.
And 2 to 3 is make it run on Python 3, whereas this looks like make it embrace Python 3.
Yeah, definitely.
And, yeah, dictionary comprehensions are just awesome, so you may as well use the better syntax.
Yeah, that's pretty awesome.
And then you have another one for documentation, right?
Yeah, since this was a pretty short little thing, I thought I'd go along with this.
And we've all heard of black, and we've talked about it a few times on the show.
But an extension to this is blacken docs.
So it runs black on your REST and RST and Markdown files.
For any of the code examples inside of there, it makes sure that those are blackened also.
So that's fun.
That's pretty awesome.
You've got maybe like a little bit of demo code for your project that shows how to use it,
and that's in your documentation.
You could blacken it, and boom, it's formatted like the rest of your code, right?
I think blackened docs also, I was thinking it runs as a pre-commit hook,
but I'm not sure if it does or not.
And that's, actually, I don't think we've talked about pre-commit,
so maybe that's for another time.
Yeah, yeah, let's talk about that.
But definitely, so, you know, sort of as part of your GitHub check-in, just magic happens.
Yeah.
Or your git check-in.
Yeah, awesome.
All right, speaking of awesome, DigitalOcean, they're pretty awesome,
both as an infrastructure provider and for supporting the show.
So you can go from zero to a running server in about 60 seconds.
They have a bunch of cool different types of servers.
They even have one-click apps.
You want a ghost blog server on Linux, press a button, you know, 30, 40 seconds later,
you have it all set up and running.
Super nice.
So we've talked about Python.
So we've talked about legacy Python.
And I believe that that original terminology of legacy Python was from a digital platform.
And then check them out.
All of our stuff is running on it.
At least all the Python bytes and my things are running on it, which has been super flawless,
like super happy customer and going to continue to be.
And if you want to be as well and get a credit, check them out, pythonbytes.fm/digitalocean.
So we've talked about Python and we've talked about legacy Python.
And I believe that that original terminology of legacy Python was from Matthias Poussigny,
who is from the Jupyter Project.
Actually, I had him back on episode 44 of Talk Python.
And he's part of this project called python3statement.org.
So this was sent over by Bruno Alla.
Thank you for that, Bruno.
And the idea is to have these projects make a public statement of dropping support for legacy Python sooner.
Yeah.
And we've seen that for some projects already, right?
Yeah, that's right.
And you'll see, you can go there and you can see the ones that are listed.
So they say they now have 44 projects that are pledged to drop legacy Python in less than 30 months.
And some already have, which is awesome, like Django, for example.
I don't know if Django is even listed there, but they should be.
Maybe they didn't make a pledge, but they did it.
Anyway, it basically shows you various projects that are committing to it.
And the main motivation is like we have tools and we have techniques to support legacy Python.
But at the same time, it's like a small but constant friction
on newcomers, on adding new features.
And you just have to keep making sure your code works, right?
Like when, I think it was Django, when they switched to Python 3 only,
they were able to drop a bunch of code and actually get smaller and have less to maintain.
So that's pretty awesome.
They say over there on their site, they say they're keen to see Python 3 reach its full potential.
And they think that they don't want to, you know, they're happy to have these projects support Python 2 to help smooth that transition, but not forever.
Right?
And actually, one of the things I like about the site is they have a really nice why switch to Python 3 with like articles from say Brett Cannon and other folks.
It's pretty cool.
It also has a timeline, a visual timeline that you can see the different projects that are signed up for this.
Oh, that's nice.
And when they're...
So this seems pretty heavily dominated by the data science crowd.
And I think that's because the folks that put the Python 3 statement.org together are data science people.
And they just have, you know, greater interactions and leverage on those projects.
So I'd like to see other projects like, you know, Django could come and be part of this and it would take them zero effort.
Right?
Because they're already doing that in Django 2 and things like this.
So, yeah, I just want to encourage people if they have a project to go over there and make a statement.
I'd like to see more projects do that, too, because there's a lot that I utilize that aren't on here.
But there's...
And they make it real easy.
You can either...
They said that they've got a GitHub issue tracker.
You can just submit an issue with your project information and have somebody else do it.
Or you can submit a pull request on this tool to pull in the information.
So both those are cool ideas.
So no reason to not do it.
That's right.
I definitely love it.
Soon we will speak of Legacy Python in the past.
Well, there's an elephant in the room.
It is.
Don't you mean a really giant octopus cat thing?
Octopus cat thing?
Yeah, the Octocat.
That's the logo of GitHub.
Okay.
Got it.
Forgot about the cat part of it.
So...
Yeah.
The head is a cat and the bottom is an octopus.
I don't know.
You know, it's a pretty non-standard sort of creature.
But it's like a platypus, but it's the cat octopus version.
Okay.
It is definitely big news.
And I think the Twitter was blowing up with people both somewhat cautiously optimistic,
I'd say, and two totally freaked out.
And that is that Microsoft has paid or agreed to pay $7.5 billion for GitHub.
Yeah, that's a lot of money.
It is a lot of money.
When I first heard about that, I was a little bit on the slightly negative side of things.
Like, oh man, really?
The more I've looked into it, the more I feel like this is probably a positive thing.
So you and I haven't really had a chance to talk about this.
You've been like hanging out of the Eiffel Tower and stuff like that.
Yeah.
So this is our first chance we get to chat.
Yeah.
So tell me, what's your thought on this?
Well, like you, I was a little bit on the negative side at first.
And then actually you shared with me an article called
Everyone Complaining About Microsoft Buying GitHub Needs to Offer a Better Solution.
And it's not just a glib article.
It's actually a nice article that talks about some of the history.
One of the reasons why I like it, it talks about it from the GitHub side
of saying really GitHub needed to go somewhere.
So it was still, I didn't know that GitHub was taking VC funding
and didn't have a good roadmap ahead of it to,
or at least there's a speculation is there wasn't a sound model to continue.
Because the way GitHub makes, I mean, GitHub spends money in it clearly,
but it makes money on the enterprise side.
And it kind of makes sense to have, so this article talks about the three potential,
it makes sense to have it be bought or to, and to be bought by somebody that already has
ties into enterprise, have an enterprise sales staff and stuff like that.
So the, it said potentials were really Microsoft, Amazon, or Google.
I think that's what it listed.
Yeah, pretty much.
Yeah.
And that makes sense.
And I, from that standpoint, so on the, on the side of like being able to sell enterprise,
GitHub enterprise, those three totally would make sense.
And so I actually, after reading that, I'm like, actually, I would have been okay with
like any of those people buying it.
But Microsoft is not, is not the evil empire that it used to be.
So I guess, I guess I'm kind of okay with it.
So how about you?
That's sort of where I came around to as well.
I did a lot of looking into this, a lot of research when the first few days when this
was out to sort of figure out, okay, I have a gut reaction, but how should I feel about
it?
Like, I didn't realize how much trouble GitHub was actually in.
Like they have been, like they went like six months or something without a CEO at all.
Cause they just couldn't find one, which is not super encouraging.
They took tons of VC money.
There's a really interesting retweet, a self retweet.
It's not like a, a selfie tweet.
I don't know.
Whatever.
David Hanna-Meyer Hansen retweeted himself when this news came out and he tweeted something
that he wrote when GitHub first took VC money back in 2012, said, I love the GitHub product
to bits.
We're proud paying customers.
And I hope they figure out how to disarm this VC time bomb before it blows up.
That's what he said in 2012.
So of course, 2018, GitHub's time bomb has exploded right on time with the sale of the
Microsoft, the sales of Microsoft.
And I think, you know, when you take VC money, it's not okay to just be doing all right, right?
You got a 10 exit.
And if you're not 10 X in it, something's going to happen like a sale or, you know, if
it's going really great, it's an IPO.
If it's not going super great, it's some kind of sale and acquisition.
And, you know, they sort of went down that path.
You know, maybe GitHub wouldn't be what it is today if it weren't for that VC money.
But it does sound like something had to happen.
They had, so they had this sort of VC pressure.
They had, you know, financial pressure.
They had the sort of organizational stuff with like not be able to find a CEO.
There's a guy who was a CEO, Chris, I forgot his last name.
Sorry.
Who was the CEO in turn.
Then he stepped down and they became the CEO again.
And they stepped back down.
And so now Nate Friedman is going to be the CEO.
He's the co-founder of Xamarin, which is pretty awesome.
Yeah.
And I think if you look at Microsoft's history of acquiring companies and either making them
awesome or making them not awesome, it's a mixed bag a little bit.
All right.
So for example, under the not awesome category, people have put Skype.
I think, I don't know, Skype was actually having some issues as well, but it's Skype seems to
always be changing and never amazing.
Like it doesn't ever stabilize on a UI.
It's just always like, why is this hard?
Wait, it's differently hard now.
Now it's hard in a different way, but anyway, so like that's one example of not so great.
But I think an example of really them shepherding something pretty well is Xamarin, right?
Xamarin was a big open source way to build mobile apps on C#.
And Xamarin did a lot with bringing .NET to Linux.
So they bought them and I think they're still doing pretty well as independent organizations.
So it's a bit of a mixed bag.
I feel like taking care of a developer space is better than other tools.
And like regarding the Skype thing, although the interface might be all weird and occasionally
I still rely on it and it's still there.
I would rather have it be there than disappear without an owner if that was the other option.
Yeah, absolutely.
I know one of the fears is what's going to change with GitHub.
And I think it's big enough and in everybody's face enough that I don't think they're going to make major changes right away because they're under a microscope.
And they always will be.
I think the other thing is you got to look at where Microsoft is the last three or four years in terms of what their priorities are, right?
We got Sachin Nadella who's doing pretty good stuff.
But mostly what I mean is it used to be how can we make this jammed into some sort of lock in for Windows?
How can we make it like some kind of thing for Office you have to do?
You know, things like that.
Whereas lately it's always it's all about Azure, Azure, Azure.
How can we get people to use Azure?
And Azure is their cloud stuff, right?
It doesn't matter if you use Python or .NET or Linux or Node.js or whatever, right?
So I feel like there's not going to be pressure to, say, push people to one of their languages or something like that.
But there probably will be like up sales to Azure.
And, hey, if you get GitHub Enterprise, you get a certain amount of Azure credits.
So you get like brought into that world.
I think that that's the angle.
And I don't think there's going to be a lot of negative pressure because of it, right?
Like I can resist an Azure ad just as much.
I can resist all the other ones.
I don't really care.
But if they, you know, said, well, it only really like GitHub really only works well if you use Visual Studio.
Like that would be super bad.
I don't think that that is even in their interest as they see it these days.
So I feel like it's probably going to be okay unless they screw something up on accident.
I don't see that they'll screw it up on purpose.
As the community noted, you can always switch to GitLab if you want.
You can.
Yeah.
I was amused by that and also pleased.
I didn't, I don't.
At first there were people going, there's like a mass, mass exodus out of GitHub into GitLab.
And although the imports from GitHub to GitLab are going up dramatically, it's really kind of a drop in the bucket for how many projects are on GitHub.
Yeah, exactly.
But I do like that there's some discussion to say, hey, everybody, GitLab is not that bad.
I've used GitLab and I actually kind of like that this has highlighted the fact that it's not bad for something to be in GitLab, even if you're trying to get people to contribute.
It's pretty much the same process.
So it doesn't really matter too much.
Yeah, that's cool.
So in summary, you're sort of like summarizing my feelings.
Like I'm kind of like genuinely cautiously optimistic.
I think Microsoft brings tons of resources to GitHub and maybe GitHub will be more awesome.
They're going to keep running as an independent organization.
They've got somebody who's pretty awesome leading it.
So these are all good things.
Yeah.
We've got the Linux Foundation actually said something pretty surprising.
So they wrote up an official thing on it after a few days and said, Microsoft's GitHub buy is a win for open source.
And one of the guys there who's been, I forgot his name, has been super anti-Microsoft sort of said, look, these are all the reasons why this is good and I'm happy for it, which is surprising, I suppose.
That's cool.
And then also Nat Friedman did an Ask Me Anything session on Reddit where there was quite a few questions and answers on like what's going to happen and things like that.
Yeah, that's cool.
There's Atom also.
Like how does Atom and code, they're kind of overlapping.
So they'll keep both of those, things like that.
Yeah, that's encouraging.
And it's also interesting that VS Code is based on Electron.js, which was extracted out of Atom, right?
So Electron.js used to be called Atom Shell.
Okay, interesting.
Yeah, in its early days.
Yeah.
So one thing I do want to throw out there for people who want to dig into this a little bit more is this podcast called Exponent.
It's one of my absolute favorite podcasts actually.
And the guys there, they basically do tech business analysis and they did a really nice job of looking at the sort of motivation and the pluses and negatives of Microsoft buying GitHub.
So I would link to that in the show notes, episode 154.
Yeah, I listened to that.
It was good.
The one thing I thought was interesting is nobody's really mentioned the, to me, the obvious truth that Microsoft would just rather be the owner of GitHub than have any of its competitors be the owner of GitHub.
I think that's real and legitimate.
I agree.
And one other, like I had said my positive, the negative that I somehow forgot to tie together there was the thing that made me just go, I'd rather not see this.
Even at the beginning was this is such a consolidation of a really major tech player, right?
We already have so many things being sucked into Google, Facebook, Amazon, Microsoft.
And there was like this nice independent place that wasn't any particular technology stack at all.
It was just GitHub.
You could go there and you could build your software and they didn't try to encourage you to use Ruby or whatever it was, right?
There's just like that was a place where the code goes.
And now there's a less of that in the world.
And I think that's a negative.
Yeah.
There's still GitLab.
That's true.
Yeah.
There's definitely, I mean, there's also Atlassian Bitbucket, right?
So that's another possibility as well.
But I think GitHub still is a special place for social coding and open source collaboration.
And I don't think it's going to change.
It'll change if they muck it up.
And yeah, so we're a pretty fickle group.
But I think they know that.
But we've seen, yeah, like we've already hashed.
Microsoft is a different company towards open source than it used to be.
All right.
Well, that's our thoughts.
If you have your own thoughts, feel free to put them in the show notes at pythonbytes.fm
slash 82.
And just go to the discuss section down at the bottom.
All right.
That's it for our news.
Brian, you got any extra stuff you want to chat about?
No, not really.
Other than I did figure out how to bring home a over 100-year-old Venetian glass chandelier
on an airplane.
That was fun.
That's insane.
Can I get a bulkhead seat?
My chandelier needs to have a little room to breathe.
Yeah, I had to take the thing apart and put it in bubble wrap and put it in two suitcases.
Oh, how interesting.
That's awesome.
We made it.
How about you?
Anything going on?
Nothing too major.
I'm working on a couple of projects like always and have news on them eventually.
But I do want to give a shout out to Pi Ladies.
So we were just in Cleveland, Ohio, right?
Had a nice time at Pi Con there not long ago.
Yeah.
So Cleveland now has an official Pi Ladies meetup or group.
So they just launched and they're going to have their first meeting on June 22nd.
And I linked to their meetup and their Twitter and everything in the show notes.
So if you're interested in Pi Ladies and you're somewhat near Cleveland or you can even stream
it live.
I think they're streaming their stuff live on YouTube.
So you could check that all out just in the links to the show notes.
Awesome.
That's great.
Cool.
Yeah.
One more good step down that path.
That's awesome.
All right.
So thanks.
And it was great to share the GitHub conversation with you.
Yeah, it was.
I thought we'd be more argumentative, but we're pretty much in agreement.
Yeah.
That's too bad.
Would have been fun, but we don't argue too much, I don't think.
All right.
We'll talk to you next week.
Yeah.
Catch you next week.
Bye.
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.