When you think about Microsoft, do you think about Python? Maybe not, but you probably should.
They've been doing an incredible amount of work to improve Python for folks on Windows,
as well as the broader community. You can, of course, look at the wild growth of Visual Studio
Code, but did you know that five of the core developers work there and that the majority of
Python development actually happens on Windows? Join me along with Steve Dower, a core developer
working at Microsoft who published an amazing retrospective on Python at Microsoft entitled
Python at Microsoft, Flying Under the Radar. This is Talk Python to Me, recorded December 6th, 2018.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the library,
the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter,
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python. Steve, welcome back to Talk Python.
Thanks for having me back.
Yeah, it's great to have you back. There's so many interesting things that you're doing,
and you've been really instrumental in pushing Python on its most popular platform, actually,
on Windows. And I think you actually have a few interesting surprises for the listeners. So I'm
really excited about what we're going to talk about. But let's set the stage by just talking about what
you do day to day. You're a Python core developer, and you work at Microsoft. Take it from there.
Yeah, so I really get two hats in most conversations. I'm either wearing my Microsoft hat or my CPython hat.
And I feel like most times when I come and chat with you, I'm normally wearing the Microsoft hat,
which is fun. And that's certainly the one I have on today. So for CPython, I'm one of the Windows
experts, do a lot of the Windows support and builds and everything. At Microsoft, I'm one of the Python
experts. And so I get to kind of roam around the company working with a lot of groups as we really
try and ramp up on Python in a big way, getting to help out various teams, make sure they're doing
a good job. Like, we don't have a huge base of, you know, Python culture, Python experts throughout
the company. So there's a lot of really, really good engineers, like expert engineers in all of
their languages. And bridging that gap between, you know, I'm an expert C# programmer, I'm an expert
C++ programmer. And how do we make you look like an expert Python programmer is a really big part of
what I'm doing right now. But it's a lot of fun. Yeah, I guess two things really strike me there. One is,
you do kind of live in this middle ground where the context matters so much, right? Like when you're
at, say, PyCon, people are like, Oh, my gosh, you're a C core developer, and you work at Microsoft.
What's that like? Right? Whereas when you're at Microsoft, they're like, what do you mean you're
a Python person? Why don't you do C# and C++? What's going on here? Right? So there's like this
really big context switch, I bet. Oh, yeah, I have virtual hats that I will literally mime putting on and
off. And I feel like I just need to get real ones. Yeah, absolutely. So there's a couple of things we're going to
talk about. And the first one really want to dig into is Python's journey at Microsoft, because Microsoft's one of
these companies that started out not super open in terms of its open source contributions, and its
culture around open source, right? Famously, Balmer had not super positive things to say about Linux,
for example. But I feel like Microsoft has really made this transformation. And you've written this
really cool article essay, maybe on your personal journey that sort of charts some of those things
as well. So maybe we'll start there. Yeah, it felt a bit like writing like the start of my memoirs,
which I feel like I'm too young to start doing that. But, but no, I was I was invited. We've got
a series of people's kind of open source journeys, open source stories coming out right now. We've already
had one about C#, and rewriting the compiler for that one about the .NET foundation, if I'm
recalling correctly. And yeah, now one about Python's journey. And it was, I was thrilled to get to write
it, because it has been an exciting time. And it's taken a number of years. But it's one of those things
where I've at least been able to observe it along the way and participate in a few places.
Yeah, so where does this journey start? You know, traditionally, Microsoft's been a kind of,
we're going to build it here, even if it exists, we're going to create our own version of the thing,
right? There's famously Java and C#. In the early days, you know, C# was something or a
reaction to Java, I think that was more of a legal issue on around Sun and Oracle than it was more
the not invented here thing. But there has been that kind of stuff around, say, like source control and
other things that in the early days, I feel like maybe made Python not as welcome as it could have
been. Yeah, yeah, there's, there's certainly when a company gets to a certain size, there's always a
lot of that going on, even within the company, like we still have teams all over the place inventing the
same thing, not realizing that another team at the same company is doing it at the same time,
which is really interesting. And one of the great things that I get to do, because I bounce around
a lot of teams is actually connect some of these up and say, Hey, you know, this other team is doing the
same thing as you. But we have, we're definitely a lot better at looking out than we used to be, because
there was certainly a time that we'd hear about problems, or we'd recognize problems, or we'd have
problems ourselves, and go, Well, the only people who can solve this is us. So let's build a solution. And
that's dramatically changed. Like the first thing now is, let's look out and see how other people have
solved it. And let's help them, you know, let's help our developers use it. Let's help developers
outside the company be able to use it as well. And it's also just hiring. I mean, yes, people change at
the company, people, you know, the older people leave, the younger people join. And they're coming in with a
totally different experience these days. All the open source stuff is everywhere throughout academia,
it's everywhere, obviously, throughout open source. And that's what people are coming into the company
with, right? Even scientists are now, you know, doing pull requests and stuff on GitHub, right? Like,
or writing Python code instead of MATLAB or Mathematica, like it's all aspects of academia seem to be
embracing open source, not just the computer science side.
Yeah, no, absolutely. And I mean, some of the biggest things that we look at and say, oh,
this is a computer science thing were created by scientists in the first place. Like,
Travis Oliphant is quite happy to stand up and say he's not a computer scientist. And yet,
where did NumPy come from? Where did SciPy come from?
Exactly. Exactly. And it's made such a massive, massive difference. Yeah. So I guess some of the
things that I see that sort of highlight some of this contrast, and I only know from the outside,
right? I don't bounce around inside the engineering teams there, are things like Microsoft created
CodePlex as sort of an alternative to places like GitHub. I don't know exactly the timing of when
GitHub came out versus CodePlex, but then eventually I decided, you know what, everybody's at GitHub.
Let's just move things like the .NET open source projects over to GitHub properly, ASP.NET famously,
for example. Then, well, let's just buy GitHub because that's like where the action is,
right. And really embracing this place that is, you know, has plenty of Microsoft stuff there,
but plenty of Python and other others as well. And, you know, there's other examples of those types of
things where it's like, well, it started out maybe this private build your own thing, and now we're
going to go do our, you know, another one is like the source control story, like TFS and all that,
and now Git and GitHub and so on. So I think those are the outside changes I see.
But, you know, on the inside, you've seen maybe, I guess one of the biggest stories is Python is
really starting to gain true traction, right? It's like, it's starting to show up in lots of products
and get some real legitimacy, not just the stepchild thing that we have to care for because some people
demand it.
Yeah, no, it absolutely is. One of the mandates that came down a little while back is that all of,
like, one of the must support languages for APIs and, you know, anything that you might want to
manage from outside the company, anything you might want to manage on Azure. So if you want to create
virtual machines or create new storage accounts, be able to push, pull files from wherever, Python is
one of the required languages. Like, you can't call your service ready until it has Python support for it,
along with a handful of other languages. But that hitting that point was was really exciting. And also a little
bit terrifying, because suddenly there were huge, huge code bases that were suddenly deemed not ready. And of
course, we didn't pull anything, right? Yeah, it was it was an internal. The next thing you need to do is add your
Python support, right? And so then all these teams with this complicated code base come to you and your couple
colleagues and say, we need some help. Yeah. And luckily, a lot of luckily, a lot of them did. There was certainly early on a few that that
would happily just go their own way. And, you know, we'd find out later on, this hasn't happened for a few years now. But we did
occasionally get emails saying, Have you seen this JavaScript code that someone wrote in Python and then published and called it
Microsoft? We're like, Well, we'll go find them. Thank you. That hasn't happened recently. But there's definitely some transition to get there. And it has reached the point, like I mentioned in that story on medium, the Azure CLI team, actually coming to us and saying, We think Python's a good choice for this. Now, for writing a command line tool, that is going to get huge. And we have to be able to manage everything.
Yeah, that's really great. And in your story, you talk a little bit about, you know, they expected this to take a long time. And you're like, No, no, we can knock this out pretty quickly. And they're like, Uh huh, sure. Well, just give it a try. Right? Like, you want to talk about that bit?
Yeah. Well, I mean, any, I feel like most people who've built a command line in Python using argpars, not going to be too surprised at how quickly you can get something working. But I think they were previously doing it in Node.js. And they'd started it much, much earlier on and basically ended up with their entire command line parsing library written by themselves. And so by comparison to that, being able to take something out of the standard library for a language and just use it, and be able to use it so dynamically,
like they have thousands and thousands of commands, which Python can handle because you haven't statically declared everything like you haven't had to write them all out in full, you can loop over a list of files and read stuff out of it and build up your command line that way.
And so it was, I mean, it was, it was an intense few days. Like, don't, don't get me wrong.
Of course.
But, but yeah, it, the first version came out, you can dive back into the Git history and, and see my commits. And I was basically going straight to the repo from the start. So they're all there.
And yeah, it came out with something that had kind of a scattering of features that they said they were interested in.
And then got to stand up and present it and hand it off, which is a really nice feeling to, to be able to give some code to a team and, and walk through it and spend an hour showing off the bits and pieces and have them say, you just saved us months of work.
Thank you so much.
Yeah.
Like that, that's definitely one of the best feelings that I've had in, in what I've gotten to do with Microsoft.
Yeah. That's a crazy, crazy experience. And I, you know, you've heard stories about Python having this effect in different ways, but that's, that's a pretty stark contrast right there. That's great.
Is it still in the Azure CLI? Is that still in Python? Is that shipping now?
Yeah, it's absolutely still in Python. It bears, I think there's maybe two lines of code that are still there from what I wrote because they've
gone and, and rewritten all of it. They've actually eventually migrated off argparsebecause it turns out that when you are getting up to thousands of sub commands that has some performance problems.
Whoever wrote that is like, Oh, what's the upper limit? Like what's the most commands you've ever seen in an app? 24. Okay. Well, this is going to be fine. Right?
I stumbled into a conversation at a conference between two people working on other command line libraries. I forget exactly what the libraries were, but they were
discussing how their performance was kind of falling off around the 50, 60 sub commands level. And, you know, was that okay? That's probably okay. And I'm like, Hey guys, we've, we've got a few more than that.
But the library they, they went and turned it into, as I said, Microsoft is full of amazing software engineers. And a few of them learned Python, didn't necessarily know it to begin with and created what was eventually refactored out into this library called knack.
That is a highly scalable command line parser. The amount of work it takes to get started is higher than argpars. But the result that you get is much, much better.
How interesting. I'd never heard of knack actually. That's cool.
I hadn't actually heard of it either until I was going to the team and saying, Hey, there are people who would love your command line library. Have you thought about refactoring out? And they just sent me a GitHub repo back and said, here it is.
Oh, beautiful.
thousands of sub commands. Wow.
And I don't actually know that he realizes how much of an achievement he's already made to get it down that far with something so big.
That is so cool. I mean, it's projects like that, that kind of push the boundaries and make it better for everyone. If that gets pushed back into CPython.
I, yeah, I hope so.
Yeah. Let's talk about the early days. I guess the, the very first recollection I have of Python and maybe similarly Ruby making its way around Microsoft is first. I heard of iron Ruby and then iron Python. I think that was the order they were created. And then maybe shortly after that was Python tools for visual studio. This is not VS Code that people know today, right? This is like traditional.
So that's the original Windows only visual studio. You had these tools you could plug in for Python, right?
Yeah. So that's basically the timeline there as well. I came in just after Python tools for visual studio was getting started. I think I was there for the 1.0 ship party. I don't remember exactly. I can probably go back and figure that out, but I was definitely there for a party, which was one of the earliest releases. But yeah, before that, there was a project to make the CLR, the common language runtime work well for dynamic languages.
The thing that .NET runs on top of to make it work well for dynamic languages, which have, you know, a whole different style of, you know, when you, you have the code and you compile it into this intermediate language, but you still don't know what your name lookups are going to find, which we're totally used to in Python.
But the common language runtime was not initially designed for that. And so there was this project to make a dynamic dynamic one that could handle all of that.
And IonPython and IonRuby were kind of the test cases for let's show this working on real languages. And both of them got to very good states in terms of supporting the language at that point in time. IonPython is still going in bits and pieces. I do occasionally bump into people at quite large companies with very serious uses of it still. They're actually quite happy with it.
That's cool. There's some interesting integration cases, right? Like you can do things like the UI framework WPF in Python on top of Iron Python, I think. And stuff like that that you just, you're like, wait, you can put these technologies together?
Yeah. And it works fairly nicely provided you're happy to live in that 2.7 world with severely restricted library support at this point. There were a number of projects to try and bridge that gap, which have largely fallen away, unfortunately. So the alternate implementations besides CPython are a little bit weaker in terms of extra library support, which is fairly off-putting. The ecosystem is just so critical to Python.
Yeah, without it, it's just not even hardly the same thing. As a core developer, what are your thoughts on these other runtimes, right? Like PyPy, Jython, Iron Python? Do you look at them and go, ah, the energy would be better placed just like trying to make CPython itself better or they're good experiments? What are your thoughts?
My thoughts are very big and complicated on that. And I think we'll probably go a little bit deeper in the next topic when we get to it. But certainly there's been a huge amount of value come out of the fact that they exist and that people have worked on them and that there's been collaboration between the reference implementation, CPython, and the other implementations. Everyone has gotten better as a result of that.
Now, whether the energy is better redirected, honestly, there's not that much energy in the other projects, which is a real shame. But it also means that redirecting it doesn't necessarily add a lot.
And I'll point out for the dynamic language runtime, Microsoft did two proof of concepts because having Iron Ruby and Iron Python flushed out things that just having one would not. And in the same way, I think having CPython, Jython, PyPy, Iron Python flush out issues in what Python the language is that you would never find out if you only had one implementation.
Oh, that's interesting. So, you know, if they say run the test suite, you're like, actually, this part's really vague, we don't actually know what this means. That could help make CPython better for sure, right?
Yeah, there were a lot of language semantics that were clarified, particularly while Iron Python was growing up. PyPy has been coming up a little bit later. It has a lot more support. There's a lot more people working on it than the other projects, but they're trying a lot harder to be compatible with whatever CPython does. And so there isn't as much kind of push and pull on what does the language actually mean here as when the other languages were really going.
Interesting.
This portion of Talk Python to me is brought to you by Linode. Are you looking for hosting that's fast, simple, and incredibly affordable? Well, look past that bookstore and check out Linode at talkpython.fm/Linode. That's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe, so no matter where you are or where your users are, there's a data center for you. Whether you want to run a Python web app, host a private Git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly support even on holidays, and a seven-day money-back guarantee.
Need a little help with your infrastructure? Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months? Just visit talkpython.fm/Linode.
Let's talk a little bit about your being a core developer and Microsoft employing you, so basically, in some sense, being a sponsor of your open source contributions in that sense.
Maybe I'll kick it off with a joke that Brian Okken over on Python Bytes showed me.
So it was, you know, it's around Christmas time.
So there was this cartoon, and there was like one of these Santas at the mall, right?
And people, kids go and sit on the lap of the Santa, and the Santa asks, what do you want for Christmas?
And the Santa says, now, what do you want for Christmas, girl?
Come on, be realistic.
He says, I want to know if enough donations that I can just work on my open source project.
He goes, okay, what color do you want your dragon to be?
But in a sense, right, like you found this place in the world where, and there's other companies as well, but where Microsoft is basically supporting your work to make CPython better, right?
Yeah.
And the story of that coming about is very different from what everyone gets now.
I feel like now people just, they are going through the interview process to get a job at Microsoft and just kind of tack on, hey, you should give me, you know, one, two days a week to work on this open source project that matters.
And we just go, okay, sure.
Back when I did it, I spent weeks negotiating with lawyers.
I had patent attorneys basically interviewing me to find out what I was going to do.
Yeah.
Would you somehow taint all of Microsoft by like interacting with open source code and you've seen some GPL and then all badness breaks loose, right?
Yep.
A whole lot of advice on, you know, don't have other code up on the screen while you're working on it.
And just the, like the risk management that we were doing at the time makes total sense.
It really does.
And when you understand that the aim of our legal team is not to help us win the eventual court case, it's to avoid it in the first place, you can see why they're so protective.
Because basically once any kind of IP litigation goes to court, everyone's already lost, really.
A couple of lawyers have won, but they're not our lawyers.
So they're not interested in it going to court.
They, this is other people get paid for that time.
So really it's, it's take as much care as possible so that it, whatever comes up just gets thrown out as quickly as possible.
And so there was a lot of caution there.
Yeah.
But again, it's risk management.
So those of us who were doing that kind of work at that time, and we had at like the same time I was doing that, we had MS Open Tech still, which was the totally separate company.
That just happened to work on the same campus and some of the same buildings as Microsoft and beyond the same email network and everything.
Who were legally allowed to do to work on these projects because there, there was some legal boundary where you couldn't sue all of Microsoft if you decided to sue them.
So I was doing it from within the company.
Like people like Dino Veland had already done before me and a handful of others.
Yeah.
I guess it's worth mentioning.
There's more than just you as the core developer at Microsoft, right?
There's Brett Cannon and who else?
Barry Warsaw is at LinkedIn, but we count him because we like LinkedIn now.
Eric Snow and Trent Nelson is starting whenever immigration gets their act together, I believe.
Right on.
The fun of being an Australian working at Microsoft in the US.
Yeah.
A lot of hoops to jump through, right?
But yeah.
Okay.
So it's, it's not just you who have found this place.
There's this group of folks inside the company.
And again, the transition within Microsoft over the last six years has gone to the point where we aren't forcing open source contributors to sit down with lawyers to describe what they're going to do ahead of time.
That's really nice.
It means we have a lot more contributors to projects.
We're able to support and help develop projects in, in ways that benefit.
Obviously they benefit us.
Otherwise, you know, we wouldn't get work time to do it, but they, they benefit the community as well.
So it's, we're trying to find that balance between kind of straight up altruistic development on open source projects and being able to resolve the issues that, that people are having that are kind of specific to us.
Yeah.
Well, like some of this, you know, it's kind of like basic scientific research.
Like some of this comes back to help the world in nice ways.
Like for example, the Git stuff that you all contributed back to Git so that you can move windows to Git because kind of like command line argument thing.
Like the number of files, like the virtual, basically virtualizing the Git file system had to be done for windows to be part of Git, right?
Or to be on Git.
Yeah.
We had a number of repositories internally that were just the working directory was being counted in gigabytes of code.
And we had one.
So one of the repositories I worked on through the transition from TFS to get the, like one checkout.
When I first checked out that repository, it was something like 180 gigabytes, just the, the working directory.
Just the main branch.
And not even the history, like just the latest up to date.
We had a whole lot of stuff checked in that didn't need to be.
Yeah, yeah, sure.
Some massive work went on and I think we got it down to six gig and said, that is the best we can do.
And part of that six gig is a script that downloads the other hundred gig of tools into a different directory.
So.
Wow.
That's incredible.
Yeah.
There's some really, really huge code bases that a lot of the big corporations have inside that simply never get heard of outside.
Like open source community run projects are never going to consider those cases because they sound utterly ridiculous.
And yet all of these really big companies have nothing but utterly ridiculous cases.
Yeah.
And they've been around for so long and so many people have worked on it.
Yeah.
It's, it's pretty insane.
Just the number of developers continuously contributing to that stuff.
So I feel like one of the big turning points in Python's journey probably hinges around Azure.
What do you think?
Certainly Azure has created a place for Microsoft to really care about developers in, in a way that is kind of different from when it was, when Windows was the main thing.
Right.
Because it used to be, well, long as it works well on Windows and we get that app on Windows and then, you know, like that was the key.
But it's hard to say, well, all the Python developers are going to come over and run on Windows potentially because maybe they're hosting on Linux or whatever.
But, but now if they're all going to run on the internet, right?
Exactly.
If they're running in our data centers, then we're happy to have them.
And, you know, we want to do whatever we can to roll out the red carpet for whichever developers want to come in and work with us.
And it's so much less about the end user platform because that's essentially the browser.
Now it's like everyone's hiding behind the browser.
The browsers work everywhere.
The browser and the phone.
Yeah.
So, yeah, it really has created that opportunity to do production apps in Python, which, which I mean, Python was never really designed for rich user facing applications.
That's never been one of its use cases.
It can certainly do it.
There's other languages that have been designed for that kind of thing.
And so Python's place has always really been more developers and command line, happy people and adding the web to that and being able to run your code on Azure enables Python developers in a way that want to encourage.
And I don't want to say it's forced us because most of us are happy about it.
It's broken down the barriers or the walls to pursuing the stuff you'd like to do anyway, maybe.
How's that?
That's basically it.
We have somewhere to put our Python developers that we want to be working with now.
Which is come and run your stuff on Azure or, you know, multi-cloud, hybrid cloud, whatever it is.
But we have somewhere for Python developers to run production code, which Windows never really had a place for before.
Yeah, for sure.
So when I go to Azure these days, I feel like it's like opening up an encyclopedia.
It's just like there's so much stuff in here.
What do I even do?
How many services are there?
This actually came up while I was writing the story because I have a mention in there of Laurent as well, who manages the Azure management SDK in Python, which basically has modules for every single Azure service there is.
And when I drafted it, I'm like, it's probably around 50.
I'll write around 50.
And then at one point I went and checked and it's over 100.
Wow.
And so I checked again.
I'm like, no, it's still over 100.
So I asked him and he's like, yeah, it's definitely over 100.
I don't even know what they all are.
Yeah.
I feel like there needs to be a song about it.
Like there's that song that all the US kids learn in school for all the states.
Yeah.
Like we need that song for all the Azure services just so we can remember what's going on.
So bizarre how music does that.
Yeah.
No, in terms of getting started, what I think was a really good move, and I'm not sure who made it, but I'll go give them a high five at some point.
There's basically a set of free services on Azure.
There's like a free sign up, credit card verification or like .edu email address verification.
And you get like a limited set.
And the thing about it being a limited set is there's one obvious choice for whatever you want to do within that set.
And so it's like, I want to push up a website.
It's like, well, app services here.
That's the obvious choice.
You don't have six things that you could make work that are all subtly different and serve different use cases better, which, you know, you can grow up into.
Once you're at the point where it's like, this is a really serious workload that my company or my users are depending on.
Let me optimize it for certain use cases.
It really just is.
You get one choice.
You know, you want a virtual machine?
Have a virtual machine.
Oh, you want to choose from the 50 different sized virtual machines and different drive options and different GPU options and different memory options.
Step up to the paid thing for that.
But having that kind of filter on this is what you need to just do something.
Taking away that choice is one of those things that I think is actually a really good user experience at time.
Yeah, sometimes less is more in that sense.
That's pretty cool that the free tier starts that way.
So let's spend just a little bit more time on this journey, maybe focus on the areas that you've worked on.
I don't know how many listeners out there know, but you actually, you know, when you interact with Python on Windows, they are interacting with a lot of your work, right?
Yeah, so I actually, the way I got into core development was I was at PyCon.
I think I was at my second PyCon ever, PyCon US, that is, and had some annoyances with the installer for Windows.
And so I basically found some of the core developers and said...
It was cool that it was there, but it definitely was a little bit not...
Tell us some of the challenges that you ran into because of it.
It was a simple installer for a simpler time.
Because there was a time on Windows where you just drop files anywhere and they run, and anyone who has physical access to the machine can do whatever they like.
Then the internet happened, and it turns out that even people who don't have physical access to the machine have access to the machine.
And we really ought to be locking things down a little bit better.
And that sent off the whole security kick that eventually brought us to where we are today, where we get all the way to store packaged apps that are managed in a really, really, really secure and isolated way that didn't exist at the time when the previous Python installer was written.
Which I think came straight out of the DOS days.
So it absolutely served a very important purpose for making Python available on Windows.
But it just hadn't grown up at the same rate as Windows was growing up.
So I basically found some core developers and said, hey, I would like to contribute some work to improve this.
Who do I talk to?
How do I go about suggesting ideas, proposing the work, contributing the work?
And they basically said, you know, give us your contact, we'll chat and we'll get back to you.
And they got back to me the next day because it happened that the person who was currently maintaining Windows, Martin Von Lois, had decided to step away and they were looking for a replacement.
Good timing.
Very good timing.
And so I was basically co-op.
I'm one of the rare people who basically gets dropped into core development without having contributed.
That's not the usual way people become core developers.
But I feel like it turns out when you're very much in a minority like that.
I'm such an affirmative action hire for the CPython core development team.
It's not even funny because there's very few Windows developers there.
And so if someone comes along and says, I would like to do Windows and I'll let you all worry about Linux.
I don't care about it.
I just want to do Windows.
They're like, are you even real?
Yeah.
Who's this person?
They're like, yes, please come and help.
And so I basically just got to rewrite it as I wanted to do things like moving the default install so that it's not writable by anyone on the machine.
Because it was installing and Python 2.7 still installs to this default directory where any user on the machine can add files that the administrator will then automatically run.
And it's something out of place like c colon backslash Python, right?
Yeah.
It's unconventional now.
At the time, it certainly wasn't.
It made a total sense originally.
But these days, yeah, programs go into program files or they go under the user app directory if it's restricted to the user.
And that helps keep things secured.
It sets the access control right so that people aren't modifying files that other people are going to use.
And being able to put it in a per user location means that we don't have to require users to be administrator to install anymore.
And I feel like that's been the most exciting feature about the new installer for people is enabling that don't make me elevate.
For a lot of people, it's don't make me hit yes on that box.
But for others, it's don't make me go get the administrator to type in their password.
Yeah, exactly.
When you're at home and it means the UAC kicks in and you click OK, like that's OK.
That's I mean, it's not super, but it's not the end of the world.
But if you're at a company, like some of the places where it would make a lot of sense at like investment places and whatnot, like they don't even get to ask.
It's just the answer is no.
All right.
No, you don't get to install stuff.
No, you don't get to raise permissions.
No.
Yeah.
And then pip install something becomes challenging as well if it's trying to install into like restricted directories.
And so you basically made it so you can all that stuff potentially happens into your user profile where you can control almost all the time.
Yeah. And at this point with 3.7, I made the final change, which was to do with the C runtime that would still try and install as an admin if you needed it.
We're down to very few people who needed that already.
So 3.7, I just kind of cut that cord completely and said, if you're still running on a Windows 7 machine that isn't receiving updates for whatever reason, then we won't try and install this properly.
We'll just give it to you so it works and assume that you're not ever going to run into the trouble that we were concerned about previously.
But I think my favorite story about people enjoying this feature, I had a teacher who spends a lot of time teaching Python throughout Africa come up to me.
It was actually at Europython this year and absolutely gushing with praise and thanks for making it possible for his students who are coming into like evening classes.
They've borrowed their mom's work laptop.
It's a 10-year-old laptop.
The keyboard's broken.
So they've got a USB keyboard plugged into this laptop because they don't get to buy the latest MacBook Pro every year, right?
Yeah, of course.
And it's running Windows 7 and it's totally locked down and they can still install Python on it.
That's great.
Because of that change.
It's a little mind-blowing that that change, which feels like it's technically a good thing to do, but it also enables kids in Africa to learn to program.
And that's just mind-blowing.
Yeah, that is so awesome.
That's great.
And I think actually that sort of speaks a little bit to the reach of talking about Python on Windows and this journey.
I mean, we talked about, like I talked about, say, oh, Azure is what's like unlocking a lot of the sort of commercial side of the things around Python for you.
But if you look at who is using Python, like what operating system people are using Python on, you go to the conference, maybe it doesn't feel this way.
But general studies and surveys say the majority of them is like massively on Windows, right?
I've actually been going around speaking to this at conferences recently, which I think we'll have a link to at least one of the recordings of the talks in the notes for this.
But my recent presentation I've been giving at conferences is called Python on Windows is OK, actually, which is a bit of a bait and switch title, to be honest, because most of the talk is not actually about Python on Windows because Python on Windows is OK.
And one of the best things when I joined the team was it was already OK.
I think this installer actually makes a big difference.
I think getting it installed properly is a big deal.
It's the first experience, right?
And the first experience matters because if you have a bad first experience, then you may never look twice.
The big kind of controversial thing in that talk and a lot of the reason that I wanted to give it was I started looking at the stats and, you know, I looked around the conferences and was like, yeah, the entire Python world is using Macs mostly.
And occasionally people that have taken a Windows laptop and installed Linux on it instead.
And then I'd get up to give a talk and I've got a Windows machine and I can look out and just see all these glowing fruits staring back at me.
Taunting you.
Yeah. And but then we start looking at actual numbers and it's so skewed in the other direction, looking at things through downloads from PyPI, downloads from Conda, usage in the PSF survey, usage in IDEs like VS Code and PyCharm.
So PyPI accepted.
Windows is a huge, if not the biggest chunk or just a true majority of Python usage.
Yeah. So let me just just to put some numbers behind this.
Let me just read the operating system usage numbers from the JetBrains and PSF survey, the one that you just mentioned, which was not promoted by JetBrains.
They just happened to do some of the analysis.
So promoted by PSF.
We've got other operating systems, whatever that means, at 17 percent.
We have macOS at 15 percent and Linux at 19 percent.
Right.
I feel like everyone has a Mac at the conferences, but 49 percent people said Windows.
Right. That's like not just a little bit more than others.
That's more than Mac and Linux combined.
Yeah. And as you say, it was not promoted by JetBrains so much.
It was like this was promoted in regular Python channels.
And so regular Python users are seeing and responding to this and doing it from a Windows machine, which we just don't have that kind of perception in the community that that's the case.
And so it was really exciting.
Like my favorite part about giving talks in general is looking at the tweets afterwards and the things that people have been most shocked by or most excited by.
And the amount of photos of me standing in front of the slide with the 14 million downloads per month of Python for Windows is one of my favorite photos now.
That's a ridiculous number of downloads.
That's awesome.
It's huge.
And a lot of that is going to be CI systems, to be fair.
But most of the downloads from Python.org are CI systems.
We don't actually think there are 14 million Python developers anywhere in the world right now.
I think the estimates are closer to six to seven million.
So there's automatic downloads.
At the same time, if people are automatically downloading Python for Windows, that means they're running Python code on Windows.
Yeah.
So it doesn't actually spoil the point at all for it to be, you know, oh, it was a script.
It's like, well, every single download of the source for Linux was a script.
Every single download of the Mac installer was also a script.
That's just the reality is no matter how you slice the numbers, I describe it as at least half of the Python community is actually running on Windows.
And we just don't realize that.
And a lot of time we don't act like it.
So the rest of the talk is basically around things that Python projects or Python packages do or have done that make them not work well on Windows.
Likewise.
Things like using string dot split on forward slash to separate paths.
So paths on Windows use backslashes.
And we have a couple of great modules for this.
So I strongly recommend pathlib, which is in the standard library as of 3.4.
But we've had OS dot path module for dealing with paths.
And yet people will still just use the normal string functions to split on a forward slash.
And if you do that to a path on Windows, you get one element with the entire path still in it because there's no forward slashes anywhere.
It's a weird root directory.
And it's things like that.
And my big concern with that is you get, you know, these 50% of Python developers will install your package, try and use it, and it won't work.
And it's just a very unwelcoming experience.
Yeah, it can be.
And, you know, it can be indirect as well.
Like, for example, Sanic is a cool async web framework, right?
Python.
But I believe right now, at least last I heard, it didn't work on Windows because UVlib doesn't work on Windows.
It doesn't install properly on Windows.
And there's just these little glitches just like, ah.
Yeah.
And there's always a very long and reasonable chain of things that would have to work perfectly for the final result to work, which I understand.
Yeah.
Which I understand.
This portion of Talk Python to Me is brought to you by us.
Have you heard that Python is not good for concurrent programming problems?
Whoever told you that is living in the past because it's prime time for Python's asynchronous features.
With the widespread adoption of async methods and the async and await keywords, Python's ecosystem has a ton of new and exciting frameworks based on async and await.
That's why we created a course for anyone who wants to learn all of Python's async capabilities.
Async techniques and examples in Python.
Just visit talkpython.fm/async and watch the intro video to see if this course is for you.
It's only $49 and you own it forever.
No subscriptions.
And there are discounts for teams as well.
Part of the problem is that of those 50% of Python users on Windows, I'm pretty well convinced that 49% of them work at places where they're not actually allowed to release their libraries.
Yeah.
I know for a fact that they have fast networking libraries, that they've re-implemented things for their platforms that make Python run great, that would be amazing to have out there in the community.
That'd be a real enabler for a lot of the rest of us that are not kind of restricted to within these companies, but they just can't do it.
Yeah, it's probably built to drop a half a millisecond on a trading engine for algorithmic trading or something like this where it's like, well, this is our advantage.
We're not putting this out.
Yeah, absolutely.
And that advantage is worth a few millions of dollars per second as well for a lot of these places.
Yeah, it's not unreasonable for them from a self-interested perspective.
But yeah, I hear you.
I would actually say it in reverse, maybe, like how many of the core developers or maybe not even the core developers, let's just say people working on popular packages like UVlib, not calling them out in particular, really, but just those types of things where the developer doesn't even own a Windows machine.
So it just doesn't bother.
And ultimately, I think that's the biggest point is when you don't have the machine to run and test on, then you stop thinking about these things.
And works on my machine is, for volunteers, I think totally reasonable by asking people to invest in new hardware, invest in a new software installation, especially the matrix of things that you have to worry about.
Even for Linux, I would suspect that most Python packages are not tested on more than one variation of Linux.
Yeah, for sure.
For exactly the same reason.
Like no one, very few people are going to be running on FreeBSD and Ubuntu, for example, to make sure that it works on both.
So that is a really valid reason for not doing it.
But at the same time, it doesn't take a lot of work these days to set up a CI system that is going to run on Windows for you.
And it doesn't actually take any money at all.
Azure Pipelines is a fairly recent one that a lot of people are really excited about, myself included, because the open source thing.
So if you mark your project as public so that anyone can see the results, you automatically get unlimited build time, up to 10 concurrent builds, and Windows, Mac, Linux, a choice.
So you can choose, I think there's two Ubuntu images and two Windows images right now.
It has Docker support if you want to be running builds inside containers of whatever container you like.
That's pretty cool.
Can I plug it into like my GitHub repo?
Yeah, absolutely.
You could do that before we bought GitHub.
In fact, that's always been one of the primary uses for it.
Yeah, that's pretty awesome.
We have CPython builds running on that.
Those are not the binding required checks yet.
Pandas has switched over most recently.
NumPy is there.
Condor Forge is investigating moving all of their builds over to it.
Oh, that would be huge.
I mean, I know some people know what Condor Forge is, but maybe not everyone.
And I think they're really interesting in enabling Windows to not have these problems of like building these weird tools because they deliver binaries on the right OS.
Maybe tell people real quick what Condor Forge is so they'll appreciate that if they don't know.
So Anaconda is a distribution and normally how people think about getting to the Condor tool.
So you'll get this big fat installer from Anaconda and install that and get a whole lot of packages.
And you have this Condor tool for creating environments, installing packages.
But Condor is really just a pip equivalent.
And you can, rather than getting the packages from the Anaconda channel, you could get them from other people's channels as well.
Condor Forge is a community organization that basically fills in the gaps.
Like they have something like 5,000 GitHub repositories that are basically the build steps for 5,000 packages.
And they have a set of packages that are built for, I think they're doing five different platforms now.
Just automatically building all of these packages.
So if you've ever run into like trying to pip install something and there's no wheel, Condor Forge has probably done some of the work or someone's contributed the steps to build the pre-built Condor package so that you can Condor install a whole lot of stuff from there that would otherwise not be available.
And they've been doing that through this incredible system of basically abusing as many free CI providers as possible for the various Mac and Windows and Linux builds.
We're doing it for the good of the community.
Yeah.
And I think we timed things right when I mentioned this to one of the Azure Pipelines team members.
And I don't actually know exactly what our financial motivation would be, but I don't really care.
If they're excited to move as many thousands of builds onto one system that does everything that they want and the Condor Forge team is excited to do that and everyone's just excited to do it.
I don't actually know what anyone's getting out of it, but Condor Forge is getting builds, users are getting packages.
And so I'm happy.
It can at least make the story for installing some of these packages on Windows better by ensuring they have a good infrastructure and it's not too much work, right?
So there's maybe something there, yeah?
And it makes installing the packages on Mac and Linux better as well.
Anaconda's popular on Windows, but not like 90% of their usage.
Yeah, yeah, it's true.
They still have really significant use on Linux and Mac because they'll give you far more reproducible installs across various platforms than using Building From Source or even Wheels on pip are going to give you.
Sure, I've used it on my macOS because something wasn't installing right.
I'm just like, I'm just going to get the pre-built version.
Let me ask you a question about something that's bugged me for a while.
And as somebody who creates courses and tutorials, I often have to have like a couple of steps.
Like, okay, here's the command that you type when you register this package so you can develop it in development mode on Mac or Linux.
And, oh, here's the separate command that you run on Windows so that you can do that.
So, like, Python 3 set up PY develop, right, for example.
But, well, Python 3 was not a command on Windows.
And that can be super annoying.
You're like, well, on Windows, what you do is you say Python, but you've got to make sure which Python it is in the right path so that Python 3 comes first.
And you and I, we've had these conversations before, right?
Yeah.
So this, I think, is one of those things.
But you actually have like a super early announcement of something that's amazing around this.
Is that right?
It's not exactly a secret project, but it's, you know, if you're not watching the Python bug tracker, then you won't have noticed.
But hopefully when we start promoting this a little bit more, you'll see it.
With Windows 10, we actually added, so Microsoft added a store, an app store, basically.
Oh, and in fact, it came in Windows 8.
But in Windows 10, some of the recent updates, it's been growing the ability to install regular old apps.
So a lot of people think of app stores like, you know, you get your Apple approved iPhone app that only runs on the phone and can't actually do interesting stuff beyond what the app does.
Like you can't install a full Python interpreter that can access everything on your system through any of the app stores.
What's being added to the Microsoft app store, the Windows app store, is the ability to install those.
So paint.net is actually one of the earlier ones to do this.
You can install paint.net through the store and it installs really quickly.
It's properly isolated between users.
And what we're doing, or at least experimenting with at this point, is adding Python to that store so that when it comes out,
and the aim is to do this with Python 3.7.2 initially and then keep updating it from there,
is be able to, rather than going to python.org and downloading the installer and running through all of those steps,
you'll be able to just go to the Microsoft store and say, get it free.
Obviously, it's going to be a free app and install it.
And that will give you Python on your machine, managed by the store, automatic updates.
It'll do automatic updates.
Beautiful, yeah.
It'll do automatic updates.
I don't know how much trouble that's going to cause yet.
That's why this is still a little bit experimental.
I had to make some significant improvements to VN to make it be able to handle that, but I believe it can handle that now.
Oh, that's great.
But the really cool thing that comes with store apps that isn't available to regular apps is being able to manage path properly.
So one of the problems with the path environment variable on Windows, or just one of the differences from POSIX-like systems,
which I actually talk about in my Python Windows talk, is that on POSIX-like systems, you kind of have,
here's a directory for my user commands, and any commands I put in there are available to the current user.
Here's a directory for my machine commands, and any commands in there are available for the whole machine.
And Windows hasn't had that.
Windows has, let me add a directory to the path, and then go look in that when you're searching for anything.
And so you get apps fighting over who's first on the path.
There's no good way to automatically manage it and say, well, 3.7 should come before 3.6.
But you can't automatically do that.
And so that's always been messy, to the point where that's one of the controversial things I did with the new installer,
was disable setting that up by default, because it just leads to breakage and confusion that we can't manage.
What the store apps let us do is specify aliases for these commands.
And those get managed by the operating system.
There's like a nice GUI for switching which app gets to have that alias.
And they go in a proper directory, that is, here are my user commands that are available to my user,
and it's on path automatically.
That's awesome.
So this store package, when it comes out, is going to have python.exe on path,
managed properly so that you'll get that one, you'll get the right one.
And then when you update the store package, you'll get the latest version because it goes in the same place,
and the newer version wins over the older version.
But because it's so cheap and easy to do this, I thought, hey, why not put python3.exe in there?
Well, since we're here, why not put 3.7.exe in there as well?
So now you have all of those on path with this package.
So that python3 command is going to work.
And then I thought, well, this is still pretty easy.
Why not keep going?
Let's put pip in there.
Let's put pip3 in there.
Let's put pip3.7 in there.
Let's put idle in there.
And so it's very easily got to a point where when you install this package,
you can go to any command prompt and type idle, and it will start running idle in that directory.
You can type, when you end up with multiple ones, idle 3.7 will give you the 3.7,
and eventually idle 3.8 will give you the later version of it.
It's just there.
That is such good news.
Thank you.
Thank you for doing that.
That is really, really cool.
So excited to hear it.
Today, as we're recording, the first preview one is up.
And so there's some more kind of private testing going on.
But my hope is that with the 3.7.2 RC, when that is out, which is probably a week or two ago,
by the time you're listening to this, it'll be up there publicly.
So you can just go to the store and type python,
and we should be showing up somewhere near the top of the list.
And you can use that to install Python on your Windows box.
And the cool thing is that doesn't require admin,
but it installs in a way that only installs it once for the whole machine,
which is really nice.
So if you have 100 users on a machine, it installs it once
and then isolates just the differences per user.
So it doesn't take up 100 times the disk space or anything crazy like that.
That is so cool because you see so many tutorials and stuff
where people just put the POSIX variant up there, right?
The type pip3 here or, you know, you do this and it's like, well, that's not exactly what you need.
So I think this, so you're thinking that this Windows 10 store app of Python 3
is going to be the way to get Python going forward.
I hope so.
There's certainly going to be some cases where it won't be the best option.
And so the old installers aren't going to go away anytime soon.
Sure.
But we'll just have to see how people use it and what people need.
There's already cases where the existing installers aren't ideal.
And this is why we have other distros out there.
This is why WinPython exists, Anaconda exists,
because they offer things that, you know, Python.org can't offer.
So this is another thing to be offered.
And we can track usage.
One of the really nice things is we can get all the crash reports.
So when Python is breaking badly, there's a dashboard for store apps that basically says,
here's how reliable your app is over time.
And so we'll start getting those reports for Python, which will be really interesting.
Yeah, for sure.
And you also were able to recompile Python with the later tools,
like move seven years or five years into the future on the compilers, right?
As you, as part of your project of taking over all this.
Yeah, that was, that was actually one of the first things I did was let's move off Visual Studio 2010
since it's now 2015 or whenever I started doing that.
Exactly.
I've had a number of people thank me profusely for that.
Mostly other people who are trying to build Python itself.
Yeah, because if you're on Windows and you're a developer,
you probably have the latest version of Visual Studio or the Windows Platform SDK or whatever,
but none of those are likely like a seven or eight year old version of the compiler.
It gets harder and harder over time to get the old compilers.
Microsoft supports the latest and try to build in the compatibility that makes it
viable for people to move forward as soon as possible.
Around the Visual Studio 2015 point is where we actually made some big dramatic changes to make that easier.
And so we are at a point now where VS 2015 or 2017 or 2019, which is recently first preview was released,
will all work.
and they can all kind of work across each other so that even Python 3.5, which was compiled with the old one,
can use extensions built with the newest compiler because we've got that.
I think we finally got the compatibility right.
We went through about six or seven different ideas on how to make it right.
And this time I think we've got it in a way that really just helps developers not have to pull all sorts of crazy tricks with their setup to make things work.
That's also really good news.
So I think there's so many positive things around here.
This Python on Windows is okay, actually.
I mean, it did highlight some of the issues, but also some of the great things.
So maybe let's close out this conversation around the journey of Python at Microsoft by talking about this Python Summit at Microsoft.
What's the story on this thing?
I've only just barely heard of it.
There's rumors floating around, and we've put up a blog post with a bit of information.
Being at Microsoft gives me an opportunity to speak to and hear from people at companies that don't normally interact with the community.
And so through that, we get to hear about problems and solutions that various people have tried for fixing things in Python or just in their Python projects.
And we start hearing some commonalities across a lot of different places.
And I'm talking like the Facebooks, Instagrams, through to various big banks who are all heavily invested in Python.
We start hearing so much in common, but also not actually being aware of everyone else.
And we started feeling like, hey, maybe we're in the privileged place where we can see all the overlap, and maybe it's on us to do something about it.
So we basically put out the call to the people that we knew in these places.
And so this wasn't like a public open call for content.
This was specific invites to companies we know heavily invested in Python and say, hey, come, let's get in a room together and basically talk through what our struggles have been, what our efforts look like.
You know, it's like half conference, half counseling session almost.
Yeah.
And, you know, do it in a place where we can have kind of an informal NDA going on about, you know, this is not, we're not broadcasting this on the internet.
So if you want to actually talk about problems that you're having, you don't have to worry that it's going to be a news headline tomorrow.
And people came and we had a room filled with trillions of dollars worth of Python development, which is something that probably makes absolutely no sense to most of the community because we look around and see the same kind of Python developer all around us at most of the conferences.
And then in this room, we had the Dropboxes, the Amazons, Facebook, Google show up along with the big banks that are like actually making huge amounts of money using Python to the point where if Python disappeared or if Python fell away, they would be losing like billions of dollars of income or being able to move money around like and investments and stuff.
So it was just a great opportunity to hear directly from them, hear that and basically find out that, yeah, all of our problems are the same.
And a lot of them are shared with the community.
A lot of packaging concerns affect everyone.
A lot of performance concerns and like the C API for CPython is a hot topic right now, both in the community and in the corporate world.
And everyone kind of has different ideas about what to do and how to fix it.
And so it was a lot of people said it was a great time.
They were very excited that there was a chance to share some of this.
As I said, it's a little bit private kind of thing.
So we're not putting out reports on specific things from specific companies.
But certainly there are those of us like Microsoft who are kind of that channel, right?
So, you know, we're a little bit of gatekeepers, I guess, which is not ideal.
But at the same time, if it's the only way for like if the only way for the community to hear what the corporations are worried about is for us to kind of aggregate it and say, we spoke to corporations that won't publicly talk about this stuff.
And, you know, you'll just have to trust that they said it's a problem to us.
And we're kind of repeating anonymously, which the interactions between the corporate world and the community of open source are actually really, really complicated.
Yeah, I'm sure they are.
Most of what we've talked about today has been how complicated it can be.
It's still so complicated, still so much uncertainty about how to interact.
There's a lot of investment that these corporations want to make into community projects like Python, like Pip, like NumPy.
And really, there's a huge amount of uncertainty about how to actually do it.
And there's a lot of reasons for that.
And probably most of them are solvable.
But the only way to solve them is by having some amount of open dialogue.
And we're trying to open that up and make it possible for companies to say, hey, this is what we're worried about.
This is our concerns.
This is what we can offer.
And try and link up with the community to make some of that actually happen.
Yeah.
So apart from the corporations, we did have some community people in the room as well.
I think we had seven Python core developers in the room, mostly employees of these companies, but they were there.
You know, we were looking around going, did that guy get up and give an entire talk about using Python and not say any dollar amount under a million dollars?
Like it's like every single, not the only number less than a million was the version number of Python he was talking about.
Yeah.
Did that really happen?
Does Python get used for that?
Yeah, it does.
But how do you turn that like millions and billions of dollars into community contributions is a really difficult problem.
Yeah, it sounds like it is.
And I think if you guys could unlock that somewhat, that would be so amazing because there's so many projects that are underfunded or run by one person in their spare time that are probably critical to the work that these other folks are doing.
If you could somehow get that support to flow the other way or get at least their concerns to help make CPython better, that'd be great.
There's been a few attempts to do this.
There's a number of companies out there that are set up for kind of the purpose of redirecting corporate funding into open source projects.
Anaconda, originally Continuum, is one of those.
Travis Elephant's new venture, QuantSight, is trying to do the same thing.
Tidelift is also following a similar thing.
Yeah, Tidelift is really cool.
It largely comes down to corporations will give out money for exactly one reason, and it's to get a return, which means you either have to convince them that altruism is going to get them some good PR or actually sell them a product.
And Tidelift and Anaconda and QuantSight are all selling the corporations a product and turning that into open source funding, which is something that individual projects have really struggled to figure out.
Yeah, absolutely.
Like the Patreon model or the PayPal donate button, you know.
Oh, yeah.
Good luck.
Yes.
You can't convince, you know, a vice president to, like, to give money to Patreon.
It just, it's not how any of these big companies work.
Yeah, they're just like, well, it doesn't make even any sense to us how this works.
Yeah.
And you have a scale problem as well.
We actually face this with trying to sponsor meetups is finding the person that can approve, you know, a $1,000 sponsorship is actually kind of hard.
Like, because no individual engineer can approve that expense because that's too big.
But what if the only people you can find look at that and say, why are you bothering me with something so small?
Yeah.
Come back when it's six figures or more.
And it's actually this really hard spot to get anything done in a large company when it's too big to go unnoticed but too small to be, like, to deserve a decision maker.
Yeah, it's a weird no man's land in the middle there.
Indeed.
Well, it sounds to me like this summit you guys had is a real positive thing.
So, yeah, keep that up.
And thanks for the report.
Yeah.
Yeah, indeed.
All right, well, I think as much as I have a million more questions for you, I think we have to call it an episode on that.
So, let me ask you the two final questions before you go.
And maybe we can touch on something else as well.
So, if you're going to write some Python code, what editor do you use these days?
Probably not Visual Studio Tools for Python these days, right?
That was my project for a long time.
So, I have a lot of sympathy.
I do still use it.
I wouldn't say it's my primary editor.
Like, Visual Studio Code right now is probably my primary editor.
That was going to be my guess, yeah.
Yeah, well, but the main reason for that is I got up on stage at a conference recently to do demos of it and just failed miserably at a number of things because I had not spent enough time using it.
It's a really cool editor, but it's one of those you kind of have to live in because there's a lot of non – there's not lots of buttons and stuff.
You've got to kind of know how to interact with it, right?
Yeah, and I know Visual Studio inside out, so I can use that comfortably, but I don't feel like I'm learning anything.
So, I'm living in Visual Studio Code these days to learn and get a good feel for it because, you know, it's rightly or wrongly, people expect me to know how it works.
And, you know, it would be helpful for that to actually be true when they ask me questions about it.
So, that is where I'm living right now.
But also the extension for that.
So, the Python extension, when we adopted that, oh, gee, a year, two years ago?
Two years ago, yeah.
It was like a one-person part-time thing.
It now has like 100 million people working on it or something.
I can't even keep track of the team.
Yeah.
We have six people based in Vancouver, most of whom I've never actually met in person.
Like, it's moving along so quickly that it's at that really exciting time where every month when the update comes in, there's new and exciting stuff.
And it feels totally fresh.
And it's just exciting to be using right now.
So, that's also fun.
Awesome.
Yeah, it definitely seems like there's a ton of energy around Visual Studio Code.
And I suspect most people know, but obviously, it runs on all the platforms, right?
It's not just on Windows, even though it shares the Visual Studio name.
Yeah, Windows, Mac, Linux.
Having .NET Core support for all of those platforms is, I feel like that's the limiting factor right now.
Obviously, it's electron-based.
So, anywhere that can run, it'll work.
But some big pieces, especially the Python support, are running in .NET Core.
So, that's about the limit.
That's still a really big limit.
Like, you've got some old versions of Linux distros that we support because it works there.
Yeah.
Where really most people would not dream of using them.
But you can run VS Code there.
Like, it's a tool.
It's got to run where people want to use it.
We can't force you to upgrade your operating system just for the editor.
Yeah, that's great.
All right.
I definitely think there's a ton of energy around VS Code.
And I think that whole Python extension editor side of the story deserves.
Like, sort of mention in the Python's journey at Microsoft, even though it, you know, didn't get it to the very end here.
All right.
And then, notable PyPI package?
Yeah.
So, one that I'm really excited about right now.
The Azure Machine Learning team recently came out with their new product.
And the name is very similar to a lot of things we've had before.
So, it can be tricky to track through exactly what it is.
But Azure Machine Learning Service is basically an entire service for being able to do your machine learning tasks.
Everything from data cleaning to model management and deployment.
In a way that works really nicely balanced between your local editor and running stuff and pushing stuff in the cloud.
So, it's got a whole lot of nice functionality for, hey, run this job in a cluster that is this big.
Let me know when you're done.
Nice.
And run that training job and then store the model somewhere.
You get a good history of all the models that have ever been published.
And that's one of the products that has come out with only support for Python.
Like, if you want to use that, you're using Python.
There's actually no other options right now.
So, I'm excited about that.
But one particular part of that package that's really cool is the Azure ML Data Prep package.
So, this is one part of it.
But it's the part for I have a file on disk or I have a set of files on disk that have some raw data in it.
And I need to preprocess.
I need to clean.
I need to extract data from certain columns and split them into more.
I need to add more columns.
I need to remove rows.
I need to replace missing values.
It's a library for doing that.
It does a couple of really cool things.
So, if anyone's used Flash Fill in Excel, which is this cool feature, you can try to put in a list of people's names.
Just first name, last name, however many names in one column.
And then start splitting them out manually.
You put a few examples of type the first name in the next column, then the last name.
And do that for two or three.
And it will suggest splitting up every single row using those examples and figure out how to do it.
So, that's been in Excel for a while.
It's also in this package.
So, you can take a raw data file that has, you know, maybe it has the date and time in those same column.
And you say, okay, here's a couple of examples of how I want it split out.
Put, you know, the date here and the time in a separate column.
And it will figure out how to do that.
And it can, it will use those examples.
And then you can run it, stream it over a huge, huge file that won't fit in memory.
And it will do it to the whole thing and write out a new file that's been pre-processed.
It's changed together.
Yeah, it's cool.
Yeah, it's really, really neat.
I guess there'll be a link in the show notes to the info on that one.
But that, when we look at how far Microsoft has come in terms of Python usage, and it seems, this feels like a great ending to this show, actually.
Yeah.
This is the new point.
We have some amazing technology here that is just Python.
It's just Python.
Like, it's not even .NET first and then Python.
It's not even .NET second right now.
It's Python only.
It's just Python.
It's Python all the way.
That's beautiful.
And that's so exciting.
And, you know, I can't wait to see what comes next.
Yeah, well, it sounds like there's a ton of momentum going there.
And you've done a lot to get it going in the right direction.
So that's wonderful.
All right.
So people are excited.
Maybe they want to learn more about this history.
Some more of the details.
Things like that.
What do they do?
Final call to action.
I'd say go read the Medium post.
And that's got links scattered throughout to interesting things.
And down the end, there's links to all the current things.
So once you've seen where we came from, where we've gotten to, then I'm trying to make it easy to see what we have on offer today.
Yeah.
Well, a lot of cool stuff.
And thanks for doing this historical journey story.
It's great.
Yeah.
Thanks.
You bet.
Talk to you later.
See ya.
This has been another episode of Talk Python to Me.
Our guest on this episode was Steve Dower.
And it's been brought to you by Linode and us at Talk Python Training.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Thank you.