Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
It's episode 85, recorded on July 3rd, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian. How are you doing?
I am doing great today.
I know. It's another day in paradise here in the Pacific Northwest, isn't it?
Yeah, as long as you're not driving, because it's the 3rd of July.
That can be problematic. We do have our traffic issues, don't we?
Yeah.
Yeah. Well, yeah, before we get to items, I want to say thank you to DigitalOcean.
They've been supporting the show in a major way.
And so, you know, like I've said, our stuff runs on DigitalOcean, which is really great.
If you want yours to run on it, you go to pythonbytes.fm/DigitalOcean, get $100 free credit for new users.
I find myself, Brian, more and more loving the concept of limited use of type hints in just the right places.
I was just typing that 15 minutes ago.
Were you?
Yeah.
Yeah. Yeah. That's nice.
The more I use them, the more I'm warming to them.
And there's a couple of resources that came by just recently that I really enjoyed.
So there's an article called The State of Type Hints in Python.
And this is a fairly thorough article, but it pretty much like, okay, now it's 2018.
What is it like to use type hints now?
And especially, and I, okay, I'm, the article talks about if you want to use type hints in 2.7 and prior to 3.6 sort of stuff.
And that's doable.
Python 3.6.
Because you can use commented type annotations in 2.7, I believe, because they're just comments.
But adding the little arrows for the types and the colons and everything, it's more concise and it looks better.
And I, my personal feeling is, unless you really are trying to convert a large code base, which I know some people are, I would switch to 3.1 first and then add type hints.
If it was me, if you have that option.
Yeah.
And 3.6 is even better than 3.5 because you can put types on variables.
You can, although I find my, I'm not really doing that.
When I'm using type hints, I'm just mostly doing it for interface, to document interfaces.
You know where I end up doing that is where there are core functions that I can't control.
So I need to call a function and I know it returns something rich that I know what the type is and I would like to be able to get better editor experiences, better autocomplete.
But it's a package function, not something I've created.
Okay.
So then you can say this variable is a, you know, SQLAlchemy session, for example.
And then it's like, oh, I see.
Now you've got add and delete and all this stuff and it's amazing, right?
Yeah.
And, you know, one of the things I like about the article and I agree with is the main point of a good reason to use type hints isn't, I mean, it is good to be able to catch all the, catch more bugs and incompatibilities.
But it does, there's a lot of reasons why it makes your, makes your code more maintainable and more readable because there's, you just have that option to be able to document it right there to say, hey, this, this is the type that this function needs.
So that there's so many things and the article walks through a few of them, like refactoring is easier, helping when you come back and read it later, it makes it more obvious.
I mean, when you're writing, yes, there are some great polymorphic functions that can take multiple types of type, multiple types.
But, you know, most of the code I write really does expect one type.
It expects a list or maybe the most generic thing is it expects an iterable.
And I'm actually still not sure how to write that in the type shed stuff.
I'm sure there's a way.
But yeah, this article does talk about things like unions.
I ran my pie on my, on some of my code and I realized that I had some uninitial, some default values set to none, which I wanted to be okay.
But if they're not none, they're strings or they're integers or something.
And the type system allows you to add a union type.
So you can say, well, it's, it's either none or it's a string.
And it's pretty interesting.
But this article talks about a lot of stuff that I really had forgotten about actually is like interface stub files.
And I haven't worked with those at all yet.
And I know that the type shed is around that allows these, that has these interface stub files for the standard library and a bunch of other popular libraries.
But I haven't really used it yet.
So, or maybe I have, but I just don't know about it.
But I don't know.
This is good.
Yeah.
You have an interesting quote in here that type hints should be used whenever unit tests are worth writing.
What's the backstory on that?
It's just one of the, in the conclusion of the article, it talked about that.
It said, okay, all of this information, but when should you use it?
I mean, if you're going to just write a little utility function for, I don't know, for your own use or something, do you need type hints then?
And, and they just came up with this rule of thumb is if you're going to, I quoted it just as is.
It says unit test.
I personally would just say automated tests.
If the code you're writing is worth having automated tests, it's worth putting, trying to think about where you're going to put type.
The other thing I wanted to add was I, I was listening to, I got about halfway through it so far, but there's a recent seminar that Guido presented at Stanford called optional static typing for Python.
And in part of that, it talks about mypy, but it talks about some of the beginnings of this, of like where this came from and how it came to be,
what it is now.
And so for, and what, how are we doing with it now?
So it's a, it's about an hour and a half though.
So it's, it's a chunk of time to watch, but.
It's a commitment.
Yeah.
But it sounds interesting.
Yeah.
But I think I recommend even like the first 20 minutes for some of the backstory is, is interesting.
Okay.
Yeah.
That's, that's really cool.
I'm definitely a fan of it and I'm glad you're bringing it up.
There's some nice stuff in there.
So I have no idea how to transition from a type hints to MongoDB.
So I guess that's a reasonable transition.
That's it.
So I've actually found a pretty interesting thing on MongoDB.
People know that I'm a fan of course.
And one of the big decision points, I think, when you're trying to decide, do I go with Django
or do I go with one of these smaller web frameworks like Pyramid Flask?
You know, many of the micro frameworks is the micro frameworks.
You can pick the little pieces.
I want SQL Alchemist here.
And maybe this part's going to be Mongo.
And this part's going to be this other aspect that I would like to bring into this framework
for authentication or something.
Whereas Django is more like, here are your big building blocks.
Click them together.
Right.
And a big challenge there can be like the Django ORM and the admin stuff.
It's all tied into that.
And well, if you don't want to use that, then you're kind of out of luck, right?
There's a lot of challenges of sort of bringing your own thing.
You lose some of the value, at least, out of Django traditionally.
So the Django ORM, it depends on a, not a particular SQL database, but it does assume a SQL database.
Is that correct?
Yeah, I believe so.
I believe that's right.
And things like the Django admin section, which is really valuable to some people, depends upon
the Django ORM, right?
So like there's these layers of stuff.
And so if you pull out the bottom brick, there's problems.
But I actually, this guy named Robin sent me a heads up about this thing on Twitter that
I had never heard of, but it's pretty awesome, called Django MongoDB Connector.
Cool.
Yeah.
So the idea is you continue to use the Django ORM just like you normally would, except it's
now had its backend swapped out to be MongoDB.
And that's pretty awesome.
And at first you're like, okay, well, how much value am I going to get in that, right?
Like if I give up, if I continue to use what is effectively a relational ORM, like you can't
use the hierarchical documents, right?
But what they've done, a little bit like MongoEngine, is the parameters that go into your query can
be more interesting, right?
So you would say, like imagine if you had a blog, you say blog.objects.filter, and you
would pass like name equals something in traditional relational stuff.
But in Mongo, you might want to traverse like into a blog object and then go find the name
and then find that the name is contained in a set.
And so you just pass different arguments to the filter parameter and boom, it becomes Mongo
hierarchical enabled.
It's beautiful.
Wow.
That's actually pretty cool.
Isn't that cool?
It's so simple.
Yeah.
And it says you can also use it to connect third party apps like Django REST framework
and Vueflow and other stuff, which heavily depend upon these Django models.
They can now super easily be integrated with MongoDB as well.
And it has a hilarious name.
Yeah.
What is his name?
Django.
Yeah.
Or something like Django.
The app, the official Django app you put in the settings file is Django.
That's great.
Yeah.
Because for Django, I get it.
Django, Mongo.
Smushed together.
Yeah, exactly.
Another thing that's interesting is this is a Python 3.6 or higher only and Mongo 3.4 or
higher, which is like, I don't know, a year, year and a half old, something like that.
So it's not quite so new, but Python 3.6 is really quite new for the store.
Yeah.
But I mean, it just also seems like something you would start a project with.
You probably wouldn't like rip apart an old project.
Probably not.
I mean, you may have an app you're trying to make better and migrate, but yeah, I would
think you probably wouldn't really.
Yeah.
I'd throw that more in there.
Just like it even has like a pretty high requirement for MongoDB.
Just so if somebody's got like an older or something or another, you can't just jam it in there.
You got to make sure you got the new goodness.
Okay.
So I was actually, so this is a not sort of related.
I was talking to somebody about Mongo before and they asked me about migrations from if you're
going to change the databases.
Does Mongo have that sort of concept?
It does have that concept.
You do it a lot less often.
Much of the time at what your migration is, is something like I'm adding an additional
column here.
I'm adding another table there, right?
Like it's not that common that you're say deleting a column or you're renaming a column.
It happens, but it's way less often than new column, new table.
And in MongoDB, new column or new table is automatic.
You don't do anything.
It just, it just adapts, right?
As you use it.
So you don't actually run any scripts or migrations to do the common transformations.
But if you're going to say like delete a column or reorganize your data, you would do the same
thing and you would run a script against it.
I don't think there's something like a limbic where there's like a framework for migrations,
but the concept of like a migration with a script definitely exists, but it's not very
common.
All right.
And I brought this up hopefully because if we're wrong about this, somebody can get ahold of
us and tell us.
So yeah, if there's some cool framework for doing that, let us know.
Awesome.
So what's this deal with Python idioms you got going on here?
This was a tiny little article, which, you know, sometimes I like that.
Just a small article of like, hey, I learned this thing and it's helpful.
And here's a small blog post about it.
And this was Amir Ratchnam.
Why do I try to pronounce people's names?
Anyway, multi-line strings.
So the idiom he's talking about is multi-line strings.
So if I've got, and we know this is like a triple quote.
You can have strings.
Strings can be multiple lines if you use triple quote.
And we usually see these with doc strings, but it can be really anywhere.
You're going to use a string.
But if you're using it like in the middle of a function, it's awkward because it either,
you have to, everything but the first line has to be, is like over on the left side of your page.
And it's not indented the right place.
And if you do indent it over, it's including all of those spaces in your string.
But the way to get around it is to use a standard library function.
The module or the package is textwrap and the function is ddent.
So it's textwrap.ddent.
And that will strip out.
What it does is it takes, looks at all of the lines of the multi-line string and takes the common spacing at the beginning of it and just rips that off.
So it's just automatic.
And I was actually, I use this enough with, actually I use it, you know, generating tools and generating other things.
And I can't think of a good example right now where I've used it, but I have used it enough times and I've looked this up that I want people to know about it.
It's an easy trick.
So it's good.
Oh, I love it.
I didn't know about it.
Thank you.
This is cool.
So I've definitely had multi-line text strings because I've got some big formatted piece of text.
And I'm like, all right, I, instead of trying to break this apart and turn it into something I can store in code, if I just, you know, triple quote it and put it in here, it's going to be golden.
But you do get that weird, you've got to like indent it to the left outside of your function and it's all bizarro.
So this lets you can keep your code looking really nice and it obviously puts the string to like visually into the block that it belongs in.
It's really nice.
I love it.
Yeah.
And I've also like tried to punt and like put, define a global variable or at least a file global variable so that I can get around it.
But this is cleaner and it's good.
It's a good thing.
Yeah.
I love it.
That's awesome.
Other good things include DigitalOcean.
I definitely want to tell people about DigitalOcean because they're sponsoring the show in addition to just us being happy customers there.
So you can go from zero to a customized server in 60 seconds.
I've talked about how we've done cool stuff with virtual machines, how they've got spaces, how they've got other various things that are pretty awesome.
Like the one click containers for like machine learning.
One thing I haven't talked about yet is container distributions.
So if you want to set up your own like Docker container, you can go click over there and create a core OS or Fedora atomic server, even a rancher OS, which I've never used, but it's got a cool icon.
And you can just fire one of those up and it's like all ready to go to be your container host for all sorts of cool Docker stuff and Kubernetes.
So definitely check them out over at pythonbytes.fm/DigitalOcean.
Get a $300 credit to play around with those kinds of things.
That's actually pretty cool.
I like it.
Yeah, I like it too.
And I had a DigitalOcean accident the other day.
Oh no, what happened?
Well, I wore my favorite DigitalOcean t-shirt to work and I spilled coffee on it.
But luckily it was a gray shirt and it didn't show up as a stain.
So it's all good.
It's pretty fail safe.
Yeah.
Unless you're painting.
So how do you feel about your design skills, Brian?
Are you a fan of shuffling around CSS and HTML and that kind of stuff?
No, CSS is definitely one of those things where I either rely on a framework or I try to hire somebody.
Nice.
So something that you might be able to use if you're using Flask, and I know you've played around Flask recently, is this thing called Flaskerizer.
Flaskerizer.
Okay, I don't know what the name stands for.
I guess to make Flask-ish or something.
But the idea is you can go to one of these places that has Bootstrap themes.
So Bootstrap is nice.
Obviously it's a CSS front-end design framework.
It's pretty well known.
But what's really awesome about it are the themes.
Like people make these pre-made themes, and for like $10 or even free a lot of times, you can get incredible web designs, and you just drop them in, right?
You just put in your logic into the bits where it goes.
So this Flaskerizer thing is what you can do is you can download the themes from certain locations that have a known format, and it will convert the static Bootstrap theme into a Flask app.
Oh, that's cool.
Yes.
Isn't that sweet?
So instead of worrying about how it all goes together, you just go, you know, command line, boom.
Now I've got like a dynamic running Bootstrap theme in Flask.
I like it.
Yeah.
So there's a couple of sites that they work with.
I don't know how general this is because I don't know how common Bootstrap themes are, but I think it's pretty cool.
And, of course, if you open up the website and you look around, you can tell that it's a proper design.
This is the GitHub repo because they go from just plain white, like no design, no logo, to clearly a designer with a black turtleneck.
Yeah, he's definitely a designer.
Yeah, definitely.
Dark black glasses, too.
And a beard.
Yeah, exactly.
Oh, he's all good.
He's got all the boxes checked.
Very nice.
So if you want to do a Flask site and you want a design to, you know, go pick a theme and just start working with that design, check out FlaskRiser.
It could get you up and running really quick.
Wow, interesting.
I was reading down this.
This is one of the few applications I've ever seen or the frameworks that uses Nose 2 as its testing.
Oh, nice.
What's the story with Nose 2?
I only know about Nose.
Well, so Nose was sort of kind of abandoned, but Nose 2 was a, well, I'll offend anybody that's still working on Nose.
But Nose 2 was kind of trying to reboot it and redo a lot of the, make a backward compatibility break.
So it doesn't do some of the things, but it does other neat things and clean up the code base.
But still, it started kind of running, getting some steam at the same time pytest was sort of getting a lot of steam.
So I think that there's not a lot of projects that use it, but I mean, it's still reasonable.
It's just since there's not that many people working on it, getting fixes and stuff is sometimes an issue.
Yeah, nice.
Okay, well, very interesting.
Very interesting.
So are you learning Python now?
Is this your next project?
No, but I thought this was fun because I encourage every youth I meet and actually everybody I meet to learn Python.
And I always tell them.
Good advice.
Yeah.
The reason I tell them the reason isn't so that you can become a programmer.
It's so that you can, like, it's a power boost to what are the other skills you have.
So if you're a biology student, also learn Python because now you're a biology student that knows Python.
You're now the favorite person in the lab that can actually solve the problem with the data that they got in Excel or something, right?
Yeah, and it doesn't matter.
It's science or non-science.
If you're an artist that also knows how to code, it's just going to help.
There's no downside.
And so a lot of times with code, people kind of have – they start writing code and it's precious to them and they don't want to throw it away because they worked really hard on it.
And so I wanted to highlight this article because of its advice.
This is – I think it's a real Python.
Yeah, it's a real Python article.
And it's called Learn Python the Methodical Way.
And I'm just going to read the steps.
The steps are make your way through a tutorial or a chapter from what you're learning, a book or something, that teaches you some discrete four to six-step skill.
You're going to work through it while you're reading it.
Now write down the steps as distinctly and generically as possible.
Put the tutorial and chapter and its solutions away and build your project from scratch and peek at the solution and the steps only when you get stuck.
Now erase the whole thing and do it again.
And then go back, completely put it away, and then erase everything and do it again like a day or two later.
And this sort of erasing and redoing it, I think at least a couple times is good for people because it gets rid of that preciousness.
Because the second time you do something, it's always faster.
Anyway, I just thought this was neat advice.
So I thought I'd share it.
I like it.
It's pretty interesting.
I definitely feel like when you're new, you feel like I put a lot of effort into that.
And so there's no way I'm throwing that away.
But the really valuable lesson is actually the second time, it's probably better.
And the third time, you're like, whoa, this is really a much improved version of what I did.
And it takes less and less time, of course, right?
Yeah.
And also, it's easier to throw away the cruft.
And if it's just something you spend an hour working on, even if you had to redo the entire thing, it's only a wasted hour.
And you realize that you can really do it again pretty fast.
And so the one part I kind of disagree about is I never code without resources anymore.
But I wouldn't say try to do it just for memory, but try to use the normal resources that you would otherwise, like Google or Stack Overflow or whatever.
Right.
Exactly.
To look up things.
You don't have...
I think it's silly to try to memorize the order of parameters to a function.
That's what code completion is for and stuff like that.
Exactly.
That's probably a type-ins, isn't it?
Yeah.
So I totally agree.
I don't think these completely abstract, in isolation sorts of things make sense.
But maybe the idea is don't just keep following these steps three times, but try to recreate it from your mind.
And to me, recreating it is totally fine to go, but how do I actually insert that thing?
What is the function I call it?
That is a totally reasonable Google search.
Yeah, definitely.
Awesome.
So we've talked about debuggers before.
We talked about the breakpoint thing last time.
One of the areas where doing proper debugging, and by proper I mean visual debugging, not command line debugging, but like visual debugging where you see all the state of the system and everything, that can be really tricky in Jupyter Notebooks, right?
Because, you know, like attach to them.
They're running in the notebook, in your web browser, right?
Yeah, I've never tried.
Yeah.
So you can use PDB, but that's like a command line thing.
It just happens to be the command line is a Jupyter cell.
That's not the same, I don't think.
However, there's this thing called Pixie Debugger.
So the idea is you include this Pixie Debugger into your Jupyter Notebook, and then it becomes a visual debugger for each cell that you're working in.
Oh, wow.
It's pretty cool.
And they have a really nice video, and they've got some nice screenshots of the thing I linked to.
And so it has one of those, I don't know what the right word is, like a magic command for Jupyter that escapes out of Python and speaks to Jupyter, like the percent, percent.
And you can just say percent, percent, debug this function or debug this cell.
And then, boom, it just drops into a thing where you can, like, step over, step into, view all the states of all the variables.
You can set little breakpoints.
There's like a little command prompt REPL underneath when it's paused.
And you can just ask it questions, like type in a variable, and it'll show you the value or even change the value of the variable, things like that.
Oh, nice.
Yeah, this is neat.
Yeah, so if you're working in Jupyter, this is really cool.
And it's interesting because it comes from the video that the guy did, David Tayeb.
It was at the Watson data platform.
So a Jupyter Notebook hosted on IBM Watson, which was pretty interesting.
Oh, yeah.
So I didn't even know that was a thing, but apparently the IBM Watson data platform is another one of these hosted notebooks.
And the reason I bring that up is he's like, well, we needed a really good way to debug these things called, what do they call them, Pixie Apps, I believe.
And a Pixie app is like a GUI interactive thing that you can put in a notebook that's kind of like a web app, but kind of like a desktop app, but in a notebook.
It's kind of funky.
So I don't know.
Maybe I'll cover the Pixie apps as well.
But that's also kind of an interesting thing.
It's kind of like Flask running inside of a notebook.
It's bizarre, but cool.
Yeah, neat.
Yeah.
So anyway, anyone out there doing notebooks and wishing for a visual debugger, check out the video that I linked to at the end.
It's only in like two or three minutes, and you'll know whether or not this is for you.
It looks cool to me, though.
Yeah.
And having debugger tools available in any, wherever you're working is good.
Yeah, I know.
I always feel like I don't need a debugger until I'm like, geez, I really want a debugger for this.
This is just not.
Until you really need a debugger.
Yeah.
Exactly.
It's not that often, but when I do need it, I'm like, oh, my gosh, I'm so happy this is here.
Awesome.
All right.
Well, Brian, thank you for sharing everything.
Anything else you want to give a shout out to while we're talking?
No, not today.
Yeah.
Not me either.
So, well, have a happy 4th of July.
It is probably exactly that day when this comes out.
Oh, you too.
Thanks.
Yeah, thanks.
Yeah.
Bye, everyone.
Bye.
Thank you for listening to Python Bytes.
Follow the show on Twitter via at Python Bytes.
That's Python Bytes as in B-Y-T-E-S.
And get the full show notes at Pythonbytes.fm.
If you have a news item you want featured, just visit Pythonbytes.fm and send it our way.
We're always on the lookout for sharing something cool.
On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.