The Changelog: Software Development, Open Source - Python at Microsoft (Interview)
Episode Date: June 13, 2018We talked with Steve Dower and Dan Taylor at Microsoft Build 2018 about the history of Python at Microsoft, the origination of IronPython, Python Tools for Visual Studio, flying under the radar to add... support Python, fighting from within to support open source, and more.
Transcript
Discussion (0)
Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix
things here at Changelog because of Rollbar. Check them out at rollbar.com. And we're hosted
on Linode servers. Head to linode.com slash changelog. This episode is sponsored by our
friends at Rollbar. How important is it for you to catch errors before your users do? What if you
could resolve those errors in minutes and then deploy with confidence?
That's exactly what Rollbar enables for software teams.
One of the most frustrating things
we all deal with is errors.
Most teams either A, rely on their users to report errors
or B, use log files and lists of errors to debug problems.
That's such a waste of time.
Instantly know what's broken and why with Rollbar.
Reduce time wasted debugging and
automatically capture errors alongside rich diagnostic data to help you defeat impactful
errors. You can integrate Rollbar into your existing workflow. It integrates with your
source code repository and deployment system to give you deep insights into exactly what changes
caused each error. Give Rollbar a try today at no cost to you. Welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, leaders, and innovators of open source.
I'm Adam Stachowiak, editor-in-chief of ChangeLog.
On today's show, we're at Microsoft Build once again, talking about Python at Microsoft, the origination of Iron Python, Python tools for Visual Studio,
flying under the radar to add support for Python
throughout Microsoft DevTools,
fighting from within to support open source,
and so much more.
So I'm joined by Dan Taylor and Steve Dower.
These guys are doing Python at Microsoft.
Who knew?
I didn't even know there was Python at Microsoft.
And it sounds like there's not just Python at Microsoft.
There's like a long legacy of this.
Dan, Steve, first of all, welcome to the show.
Thank you.
Thank you for having us.
Yeah, happy to be here.
Let's go back to the beginning a little bit.
You guys have been at Microsoft for a little while.
Tell us about Python and its roots in this company.
Wow. So yeah, Python at Microsoft has such an interesting history. So I've been
there for about six years, coming up on six years now, and it was going before my time.
I don't remember the details. I've heard the stories and the rumors. There was some app
part of Windows Server 2003 or something that shipped and
needed Python. So we briefly shipped Python in Windows for some database app. I don't
even remember what it was now at this point. That went away at some point. Someone upgraded
and went to a different language. We briefly flirted with the idea of, let's implement Python on top of the CLR.
And that became IonPython, along with IonRuby,
which ultimately became the dynamic features of C Sharp
came out of that.
So it wasn't a complete bust of a project.
And I heard some of the features in the debugging area
also came out of that, where you've reused some of the APIs for the PyDev debugger and things like that.
Certainly, yeah.
There's a lot that came out of that project.
After that was kind of wrapped up on the Microsoft side and pushed out and taken over by the
community by the way.
Like there's people still pushing Iron Python along.
Really?
Still making releases.
They're getting their Python 3 support together.
After that was when we kind of turned around and said,
hey, you know, this thing that we do better than anyone else right now
is tooling.
And, like, Visual Studio is far and away
one of the best editors on the planet.
This is, like, 2008, 2009, 2010 kind of era.
Let's invest in Python support there.
And so there was this tiny little team, totally under the radar,
building Python support for Visual Studio and shipping an extension,
which was known as Python Tools for Visual Studio.
And from there, Dan can probably pick up on how we've grown since then.
Yeah, so I've also been at Microsoft for going on seven years now.
And most of the time I've worked on Visual Studio in various areas.
And only in the past year did I join the Python team.
But the reason I came over is because Python is growing so quickly at Microsoft.
And we have, you know, there's a lot of momentum behind it.
And so now we've got these great tools in Visual Studio and Visual Studio Code for Python developers.
We have this very fully featured, rich set of tools.
And we really, as a team, we're all bound together by this mission to make Python developers
more productive, make the Python language itself more successful, and contribute back
to the community.
Going back to this idea of a small team flying under the radar, getting Python into the system,
so to speak, this is something the system, so to speak.
This is something that we hear a lot about and we see with open source tooling or languages
or whatever it is, where rarely is it a top-down decree, we're going to do Python.
It's usually a grassroots effort.
Maybe somebody did something, didn't ask permission, but they were gonna ask forgiveness later.
Is that something that happens frequently at Microsoft?
Is this like a rare occasion?
How does it usually work when new open source comes in?
I know it's different now than it used to be.
Oh yeah, it's a totally different place than it used to be.
I mean, easier to ask forgiveness than permission
is one of the core Python design principles.
So it's no big surprise that we went that way
and started just releasing this product and telling people that, yeah, you can
do Python before your upper management even heard about it. But yeah, it's not really that common.
And even now, I don't think it's that common because the decree has calmed down.
And it took a long time to get there. Certainly in the early days, we had fights with lawyers and many, many discussions
and working lunches with lawyers to try and teach them about this open source thing that
was going on. Encouraging them, hey, go read this Apache license. Go read this MIT license.
See what you think about them. Figure out how Microsoft can release code under these
instead of going off and inventing our own brand new licenses,
which some people may remember we also did for a period.
Oh, really?
Well, I think it's also, as Steve said,
a lot is about education and helping people understand.
I think a lot of people were scared of open source.
A lot of companies, not just Microsoft,
as it started to gain in popularity.
And as Steve says, it's helping people understand
why is this, you know,
why is this a good thing?
Why is this beneficial?
And as they learn more,
you know, they've become more supportive and helpful towards what we've been doing.
And we're at this awesome point now
where we have like automatic systems
for releasing open source projects.
All of the kind of governance
and tracking of licenses and dependencies is all kind of governance and tracking of licensors and dependencies is
all kind of automated throughout the company.
It's easy, like we can self-provision GitHub repositories these days with MIT licensed
code for, you know, provided we're meeting the guidelines that are set around that.
And there's still some restrictions, but employees get to make that decision.
We aren't running everything through some central location that gets to approve or disprove anything it's a totally different
company it feels like in so many ways than it was back when i started and certainly people that
have been around longer have even they're even more impressed at how different it is there's a
lot of systems set up to support and help open source projects flourish at
the company.
There's systems if you want to create a new open source project, how to do that.
They're really there to support all the teams.
Very cool.
Let's talk about Python itself and exactly what Microsoft is doing with Python, for Python,
and who's using Python and what aspects you guys see your customers.
Yep. So let's go ahead and talk about that.
So Python's been growing very rapidly
over the past few years, and if you read
the Stack Overflow blogs and surveys,
it's the fastest growing mainstream language.
So I think as of this year, 38% of respondents
indicated they're using the Python language.
And that's been growing rapidly over the past few years.
So it's got a lot of people.
It's still growing fast.
I like to talk about three different main types of apps or developers that are using Python.
One of them is the data science and machine learning.
That's driven a ton of growth with Python recently.
And the other one is web development.
A lot of large companies, a lot of big websites
are built on top of Python, and that continues
to be a very popular, very productive language, right?
And then the other one is just automation, scripting,
tests, IT operations, system management.
Python's a very productive language to work with,
so a lot of people find when they need to automate
some of their workflow, that Python
is the right tool for them.
I also mentioned that with people learning to program
these days, Python is actually one of the best places
to start if you wanted to learn to program.
And so a lot of people in school, a lot of students
come out of school knowing Python, a lot of people who are in their professional career you wanted to learn to program. And so a lot of people in school, a lot of students come out of school knowing Python.
A lot of people who are in their professional career
and want to learn a new programming language
are coming to Python, right?
So at Microsoft, we really want to enable all of that, right?
So we have our tools in Visual Studio Code
for especially if you're doing some lightweight scripting,
it's a great place to start.
And then we've got tools in Visual Studio,
which for the large, more, say, hardcore uses of Visual Studio, especially if you're already
a Visual Studio developer using C++, for example, or C Sharp, and you want to mix Python in
with that together in the same project, Visual Studio is a great place for that because we
can do cross-language debugging and other features like that.
And then we're also working to enable people in the cloud who are, for example,
doing machine learning projects to be able to run their Python code in the cloud
to do batch training, to be able to do all that stuff.
Yeah. Thinking about education a little bit,
what do you think it is about the language itself that lends itself well to first-timers and even children learning it?
I know a lot of the boot camp schools and a lot of the getting kids into code will be focused on JavaScript because of its ubiquity,
or maybe Ruby because a lot of the syntax melts away and it can look kind of like English.
But Python, like you said,
is very popular for that as well.
What do you think it is about Python
that makes it good at teaching,
good for teaching?
I always like to position Python
as having this very, very shallow learning curve
that then quickly jumps up to a point
where you can do all kinds of magic, amazing stuff.
And I compare it to C++ in that respect as well.
When you get into C++ template metaprogramming and stuff, you can do absolute magic.
And it's amazing and I love it.
But C++ still has that sharp learning curve to be able to use any of that because there's
angle brackets everywhere.
Python doesn't have that.
You can write really simple English-looking code that reads nicely in Python. I've certainly seen papers that have taken Python code and
renamed it pseudocode and not actually changed any of it at all because it reads just like
pseudocode that most people would want to use. But as a library developer or as a framework developer, you can make objects and classes that do really amazing things
but look very natural and read very natural.
And it's not quite the same as Ruby gets used a lot for DSLs,
and it's amazing for that.
You never actually change the semantics of Python.
So you have this consistent language that always behaves the same. It's like equality is equality. Less
than is less than. It's like you, it doesn't do weird things.
Like the operator overriding and stuff.
Yeah, which you can totally do.
It's just not in the, in the community doesn't do it.
Exactly.
So there's a, there's a saying in the community about things being Pythonic, right?
The community always strives for things that look Pythonic.
It's got a very good set of idioms and ways that people use it, and it feels very natural.
There's this joke that Python is pseudocode that runs.
You know what I mean?
And people, I don't, personally myself, I don't know what Pythonic means, but I know it when I see it.
And everyone else seems to have that same impression. Itonic means, but I know it when I see it. And everyone else seems to have that same impression.
It does just mean that you know it when you see it.
Probably shouldn't share this in case people apply for jobs with our team,
but one of the interview questions I like to use
with people who will be Python developers is,
here's a sample of code.
Tell me what's not Pythonic about it.
And it's amazing to see the range of responses.
And some people
who haven't experienced a lot of good Python code look at it and go, it looks mostly fine.
And some people look at it and go, I can't take this away. I'm about to vomit. Because
it's such an artistic thing that when you learn it and you feel it, then the code feels
right and it looks right and it smells right. But you only learn it and you feel it, then the code feels right and it looks right
and it smells right.
But you only learn it through experience
and by seeing good code.
And so, you know, we make a big effort
to make sure that all the code coming out of Microsoft
is Pythonic in a way
because we know that people will see our code
and go, Microsoft did it.
You know, they have good people there.
It must be good code.
And so, you know, we try and make sure that it is actually good code.
Isn't there documentation around, I'm thinking of like, is it Pep8,
or there's like specific documents that say this is the Python way?
Pep8 strictly describes if you're checking in changes to Python itself.
It often gets like picked up and, you know, Python developers say it must be done this way, which
that's true if you're working on Python itself.
Right.
You don't have to use those guidelines to be Pythonic.
And in particular, the 79 character line limit is totally relaxed for everyone else.
But if you're working on Python proper, that's what it applies to.
If you're working on Python proper, then we still... There are people who work on it using 80-character wide screens,
and if you extend too far beyond that,
then they're going to have a harder time reading the code.
So we still have that restriction on the project itself.
But yeah, PEP8 is a generally good set of guidelines
for things that are going to look right,
but it's not like Go has their really strict formatting
that you must get the formatting right.
And other languages have really well-defined defaults
for what looks good.
Pythonic is about so much more than you can describe.
It's not just you put a space before this
and a space after this.
It really is, don't use a class there
when a function will do. And it goes so much deeper. It goes deeper. Well, I was going to ask,
you mentioned Go and they have a tool, like Go FMT or Go Funt. I hate when they say that.
It's like, just call it format or whatever. They will actually reformat your code so you can write
it however you like and then they'll put it in the format. Unfortunately, it uses tabs, so I can't,
the dude cannot abide, but that's just
one man's opinion. Elixir's adopting a similar thing. There's a tool, I think, in Elixir
1.6, which adds a formatter. Is there anything similar in Python? Could you even have that?
Or is that against the grain in the Python community?
You can. And there's actually a tool that's come out recently that's suddenly shot up
in popularity. It's called Black. It's actually written by that's come out recently that's suddenly shot up in popularity.
It's called Black.
It's actually written by one of the core developers who's, I believe, has just written it for himself
and his own team at work.
But that is a very strongly opinionated formatter
that has basically no configuration.
And the idea is that you run it on the code
and it will make your code at least consistent
so that everyone's code looks the same going in.
So it's the same kind of theory as GoFundMe.
Yeah.
We actually have integration with Black coming up
in the upcoming release of the Python extension for VS Code.
Okay.
And the developer of that Black extension
actually contributed a lot of the integration.
Would that be something you guys would consider
adopting internally at Microsoft?
Or does it go against Microsoft culture?
To me, the advantage of a tool like that
is if everybody adopts it, right?
Like the fact that in Go,
pretty much you can expect people to have that format,
that makes it very useful,
even if you don't like the style very much,
because everywhere you go, it's the exact same code style.
And so tools like Black, while interesting in the small,
really their value shines if the entire Python community
realize that's a huge statement.
But maybe the majority would actually get involved
and say, okay, let's use Black style.
Well, certainly it's been, as Steve said,
it's been this huge rise in popularity
for that black tool.
I don't think we prescribe in particular
what developers at Microsoft that use Python use.
I think people, the nice thing about black
is a team is fully empowered to say,
hey, we want all our code to look like this.
We're going to choose black.
And with our tools, we say, go ahead.
You can choose to use that, and we say, go ahead, you can
choose to use that and we'll make it easy for you to integrate that into your coding experience.
Yeah. And the reality is there's so many different, teams are doing so many different things
that it's really hard to enforce any kind of style. Just as like a kind of an extreme example,
we have teams that are building and releasing samples and publishing them on the documentation site.
And we'd really like those to be formatted nicely.
We've also got a huge number of data scientists who are writing Python code that's going to be run once and never seen again.
Yeah, scrap it together.
And if anyone comes out and says, you must always run your code through black, and that becomes like some edict from above, now the data scientists are going, how do we do that?
And it doesn't even really matter.
It doesn't matter.
Yeah, so we have tools like Pylint, for example,
is another popular tool for at least detecting,
there's a lot of style errors and warnings in Pylint.
And so one of the big things that we let you customize
exactly which set of rules your team is gonna use.
And I think if you turn Pylint on,
it strictly follows that PEP8 sort of syntax.
But a lot of people will say,
well, we like this rule, we don't like that rule.
You can figure it, yeah.
Yeah, and so teams will use that.
Well, and we'll say we don't like a lot of the rules too.
And recommend, like we have a file that we suggest
to teams to say, if you follow these,
then it will be acceptably good. There might be more rules that you want to turn on, but these
are the bare minimum. Please stop using CamelCase as a basic example.
So I love CamelCase, but when I joined the team, Brett Cannon, who's our dev lead for
VS Code, he's slowly, and Steve as well, have slowly started to beat the camel case out of me. We're winning him over. Well, so many libraries
use snake case in it. It starts to look weird if you're not, but yeah.
This episode is brought to you by our friends at DigitalOcean.
DigitalOcean is a cloud computing platform built with simplicity at the forefront.
So managing your infrastructure is so easy.
Your business will thank you.
Try it today.
do.co slash changelog.
Effortless administration tools, robust compute, storage, and networking services.
It's an all-in-one cloud.
Flat pricing across all global data center regions.
It's secure.
It's reliable.
24 hours a day, 7 days a week, 365 days a year of world-class technical support and 99.99 uptime SLA for all services.
Once again, head to do co slash changelog and
Also by our friends at OzCon will be there by the way
So if you're going to OzCon make sure you say hi OzCon is where it's at when it comes to open source
2018 features frameworks like tensorflow
MX net blockchain projects like hyper ledger Bitcoin and the Ethereum, as well as infrastructure disruptors like Kubernetes, Prometheus, and Itzio. If you plan to be there, you will get an insider look
at open source and the future of where things are heading. To save 20% on gold, silver, or bronze
passes, use the code CHANGELOG. Head to oscon.com to learn more and register.
It's interesting how our tastes change over time,
where I was very snake- me, I was very snake case for a very long time. And now, and I used to just, I mean, I like despise camel case, you know, I was like that far
on the side. And now I'm like, camel case, not so bad. Like I look at it, I'm like, looks all right.
It's just like, that's why I feel like top down style guides or or forced styles just feel so constraining when I can't even internally
keep my style, my internal Jared Santo style guide over the course of five years because
my taste changes. It's just an interesting phenomenon. Anyway, Steve, you've been a
contributor to Python itself. So you mentioned Pepe. You must be following that at least when
you do your work on Python. Is it Python core or tell us your involvement with the project.
Yeah. So so I, along with four other engineers that we have working at Microsoft,
am one of the volunteers, although I guess I'm partly paid by Microsoft in order to do this,
who work on the CPython project itself.
So that's the core interpreter, all of the core libraries, everything you get in the standard library.
We have a team of, I think on PayPal,
we're like 80 or more people, and at any one time,
there's probably 20 to 30 active developers
who are contributing in some way to Python.
But this is entirely CPython, like outside of Microsoft. It's a volunteer gig.
So it's myself, Brett Cannon, Barry Warsaw, Eric Snow, and Dino Veland are all paid employees at
Microsoft. And we have our jobs to do there, but we also get time to volunteer on this project as
well. And we're supported in doing that for a variety of different things. But overall, it's such an important project
that to leave it in the hands of either volunteer donations,
there's a donation drive going on now for the Python Software Foundation
to keep that running.
I mean, Python is too important to leave in the hands of donations like that.
So having Microsoft say, yes, we'll employ people who are working on this and keep them working on it is a great thing to see.
Well, it's actually exciting because it's also one of the few languages that is kind of purely driven out of community roots.
Most of the other languages were created by a company.
And I think Python grew out of the community more or less
and is very popular these days.
Absolutely.
How is that managed on a practical sense?
We know some companies allow open source Fridays
or there's like 20% time,
or how does the actual, you know,
where do you draw the lines between Steve, the Python,
you know, the do-gooder Python community member working on Python,
and Steve, the Microsoft employee working on Python,
and how does that all play out?
I have strongly considered getting multiple baseball caps,
one with the Microsoft logo on and one with the Python logo on.
Because I have so many conversations with people
where I need to be explicit about which hat am I wearing right now.
Yeah, that's a hard problem, right?
And yeah, and in particular for me,
so my kind of main role with the CPython team
is maintaining a lot of the Windows support.
And so I do a lot of the builds,
I work with a couple of other guys
who are focused on that as well
to keep Python running well on Windows,
which means I will talk to other teams at Microsoft
about, you know, the CPython installer
is doing something weird.
And I mention installer, and they look at me and go,
the Visual Studio installer?
I go, no, no, no, the CPython is a different hat.
Let me change hat for this.
So I don't actually have that harder line
between my contributions.
It really is as needed for me.
Other people do.
Brett, for example, and I think he's talked about this publicly,
so I won't get in trouble, has a very clear,
this is the time that I spend each week on CPython work.
I think it's every Friday.
Is it every Friday?
Yeah, every Friday.
And if you email me about...
Because that's a very clear line, right?
Yeah, and if you email me about Microsoft work on that day,
you're not going to get a response on that day
because I'm not doing that work.
Yeah.
And that's, you know, it's very individually managed.
It comes down to how your manager feels about it
and what value is coming back out of that
for either the community as a whole or Microsoft
and how that's valued.
Yeah, I don't think anyone's really breathing over your shoulder
at Microsoft anyways, you know, and watching what you do every day. But yeah, with Brett, I don't think anyone's really breathing over your shoulder at Microsoft anyways,
you know, and watching what you do every day.
But yeah, with Brett,
I've definitely tried to meet with him on Friday
and he goes, no.
No.
Not talking, yeah.
I'm doing my Python work on Friday.
Yeah, slippery slope.
That's pretty cool.
So we've seen, you know,
we track a lot of the sustainable side of open source.
And, you know, like you said,
like Python's way too important
to be just donations based,
especially when you see the donations coming in,
you're thinking how many corporations are doing very well
because of this completely free-to-them programming language.
We've seen some companies pick up and actually hire
or pay full-time salary people
whose entire purpose is to work on
a specific open source project.
Is there anybody doing that inside of Microsoft?
Is that a conversation that's being had?
Like, wow, I mean, maybe this makes,
in cases where it makes sense.
Hypothetically, Steve, if it made sense for you
to just like pour all your time into CPython,
would that be a conversation that would be
had inside of Microsoft or not? Yeah, that would that be a conversation that would be had inside of Microsoft or not?
Yeah, that would certainly be a conversation to have.
At various points in time, it may be more or less feasible.
So certainly when I started contributing,
that was never going to happen.
At this point, who knows?
The more that Microsoft comes to depend on Python,
the easier it is to say, this is important to us.
We should have someone on it full time
who's not even doing Microsoft work anymore
because indirectly this is.
We don't currently have any of those.
I don't know that that's a policy to do it or not do it.
Right now, as I mentioned, our team is growing quickly.
And so I think we do want to get to that critical mass
where we can have people who are dedicated
to contributing directly as their full-time gig.
Part of that is we need to have a large enough team
that we can sustain that while keeping the team
moving forward.
And we want to make sure that we're able to deliver
the tools to Python developers
and keep those sustainably growing
and then meanwhile giving back to the community.
But absolutely it would be something that we would love to do.
And ultimately when you have
however many hundreds of thousands of users we have for our tools
there's enough feature requests to keep us busy until the end of time.
And so saying we're gonna do less features
for these things that we own,
and work on this thing that a lot of people own is.
That's a non-starter, right?
Yeah.
It's not so much a non-starter, but you just have to.
It's a hard balance, right?
Yeah, it's a tough balance,
and it can be hard to explain to people
why we think this is more important
than the feature that you're asking for
from Visual Studio or Visual Studio Code?
Because the editor is kind of the first,
the thing that people directly interact with
when they're writing Python.
And as I mentioned, it's about being,
helping them be as productive as possible, right?
So the editor is kind of like that top line thing
where if we can help them get their code written,
give them the right IntelliSense,
give them the right warnings,
that has a direct kind of top of the funnel impact to people.
So let's look to the future a little bit.
Dan, maybe you can tell us about the future of Python at Microsoft and with regard to the tooling.
And Steve, maybe the future of the language, where it's headed in the community.
Yeah, so as I mentioned, so we've got kind of two, three main,
well, four main products, right?
We've got...
Two, three, four.
Yeah, there's a lot.
Five?
Well, there's a lot of different teams
that there's probably,
I could dig a fifth one out there.
There probably is.
I'm sure you can throw one out.
Yeah, so we actually do work,
consult with a lot of teams across Microsoft
who are doing stuff in Python.
So there's many more than four or five.
It's really how I choose to bucket them in my head
in terms of products.
But we've got our Python extension for Visual Studio Code.
We've got our Python workload in Visual Studio.
Those are similar.
With those, what we're actually doing right now,
the Visual Studio Code extension originally started
as a community-developed extension.
It was created by developer Don, Don Giamatti,
out in the community. And we actually hired him and brought him on to the team at Microsoft and
republished the extension as Microsoft. So, you know, that came from the community and now we're
giving back to the community, you know, making the team around that bigger. But the big thing
we're doing with Visual Studio and Visual Studio Code is we're actually consolidating a lot of the core IntelliSense
and debugging engines that are powering the two products.
We want to make IntelliSense much richer, much more feature
complete, much faster.
Make sure you get all those warnings and errors as you type.
And so that's been our big priority right now in the sort
of immediate term for those two products.
There's some other things that people want. Once we get sort of through that stuff, a lot of people
have been asking for remote development. Let me target Python in a Docker container, you know,
running in the cloud so I can, you know, access the petabytes of data I have without having to
pull it all down to my laptop. Yeah, exactly. And so that's the sort of very, you know, next on the
horizon for us is to look at stuff like that.
And actually, if you look at our GitHub page for VS Code, our Python extension for VS Code,
that's the top upvoted thing with over 200 sort of upvotes.
And so we have people screaming for that kind of stuff once we get past that.
We also got our Azure Notebooks, hosted Jupyter Notebooks. Right now, that's a free offering where you can go and run your Jupyter Notebooks in the cloud
without having to download and install that stuff.
Where do I go for that, Dan?
That's on notebooks.azure.com.
Thanks, Steve.
I'm supposed to team up for those.
I wasn't doing my job over here.
And so right now, that's a free offering.
But a lot of people, of course,
want to be able to put more powerful machines behind that,
be able to do more powerful things.
So we're looking at how do we enable
to do more workloads in Azure.
And the fourth product was just Azure itself.
So we want to help people get their code running
and Azure functions, Python on Linux,
a lot of the machine learning workloads and stuff like that.
So those are kind of the key areas that, you know, we're really trying to move forward.
Very good.
And if I can bring that up to six products, like you asked for.
I don't know.
Was I asked for them or did I just enumerate them?
Go ahead.
SQL Server embedded Python recently.
So, like, the most, I think, 2016 and 2017 releases of SQL Server
come with an install of Anaconda in them.
You can write stored procedures in Python
and run those queries, and they'll all run on the server.
And you have access to NumPy, Pandas, Scikit-learn
on the same server as where your data actually is.
So if you do want to do a lot of that preprocessing
and it's in a SQL database,
then that option's already there.
And that was really exciting.
Yeah, I forgot to mention that.
The actual really cool thing about that
is that they actually JIT compile the Python code
down to the SQL engine, right?
So you can actually get really good performance
out of that by running it inside of SQL Server.
And you can kind of copy and paste code
from your local Python project
and move it over to the SQL database side.
Interesting.
Yeah, and the other one that I'm really excited about
is Visual Studio Team Services right now,
which is they took a bit of time to convince them,
but they've now gone,
hey, Python is really, really cool, isn't it?
Why aren't people building and testing their Python apps
on our continuous integration stuff?
And we got in touch and basically said, here's why.
And they said, OK, we'll fix it.
And they fixed it.
So now you can spin up, build definitions on Visual Studio Team services, Windows, Mac,
Linux, whatever version of Python you want, be building wheels, running tests with PyTest,
whatever you want to do.
And it integrates with GitHub.
It has its own set of private repositories if you want to use those.
There are more and more exciting things coming for that that I can't talk about yet, but
I am really excited about VSTS.
So I bucketed all those together and one product in my head was Azure.
That's how you go from four to six, is you unpack that bundle.
Yeah, there's a lot of good support for Python and Azure, and as Steve mentions, there's
a lot more coming.
Teams are increasingly coming to us rather than us having to go to them.
So you guys are off to PyCon here.
Actually, you're going to run out of here and pack your bags.
I am going straight home after this and packing and flying out at like, oh God, 30 tomorrow morning. So real quickly,
tell me what's going on in the Python community, Python language. What's fresh there? So Python 3.7
is basically just completely locked down. We've got the fourth beta is out. We're going to have
a release candidate soon. And then the final release of that will be out within two months, I think.
Thereabouts.
I don't have the schedule in front of me.
That has got...
I don't know that it's the most dramatic and exciting release we've ever had.
But it's looking really solid.
There's certainly a lot of improvements in initialization,
which a few people are interested in, but it's really
significant there. Data classes is one of the big ones. So when you're writing, if you just want a
simple class to hold a couple of values, it's just like a few fields, you find yourself writing a
def init and default values and getters, setters, a hash function, comparison functions.
We've now got a type in there, a module in there
that you can basically inherit from and specify
just the names in the class.
And you don't have to write any code.
And you'll end up with a fully defined class
that may have default values for those.
It'll do comparisons. It'll do hashing and just generate all of that have default values for those. It'll do comparisons.
It'll do hashing and just generate all of that boilerplate code for you.
That's cool, for sure.
So that's coming in 3.7 shortly.
We're already discussing stuff for 3.8.
There's been a lot of robust discussion on the mailing list recently.
A lot of exciting potential coming.
I have no idea what's in and what's out at this
point. It's so early in the cycle that people are throwing ideas around and we're discussing them
and some of them have kind of gone to votes and ultimately the Guido van Rossum, our benevolent
dictator for life, BDFL, is going to decide on those and say, I think this is good for Python, or I don't think this is good.
It's just exciting to see what he likes the sound of,
and that'll be what's going towards 3.8 in about 18 months.
Very cool.
Well, Dan, Steve, thanks so much for sitting down with us,
and thanks for coming on the show.
Yeah, thanks for having us.
Thank you.
All right, thank you for tuning in to this episode of The Change Log. If you enjoyed it, do me a favor. Thank you. course thank you to our sponsors rollbar digital ocean and also o'reilly with their oscon conference
we'll be there by the way so if you're going make sure you say hi use our code changelog to save 20
and of course fastly provides our bandwidth we love fastly head to fastly.com and we catch our
errors before our users do because of rollbar check them out at rollbar.com and we're hosted
on leno cloud servers head to leno.com slash changelog check them out at rollbar.com and we're hosted on leno cloud servers head to leno.com
slash changelog check them out support this show this show is hosted by myself adam stachowiak and
jared santo editing is by tim smith music is by break master cylinder and if you want news and
podcasts just like this head to changelog.com. And thanks for tuning in. We'll see you next week. Thank you. Bye.