Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 166, recorded January 22nd, 2020.
I'm Brian Okken.
And I'm Michael Kennedy.
And this episode is brought to you by DigitalOcean.
We'll talk about them more later.
But do you want to get into quantum stuff or what do you got for us first?
Yeah, how about that?
Like, there were many crazy ideas in programming, right?
Like infrastructure as code or, you know, infrastructure as a service and all the cloud computing things.
And, you know, there's this really cool quote from William Gibson, the science fiction writer, is that the future is here.
It's just not evenly distributed, which is pretty cool.
And I think this thing I'm about to talk about is a little bit about making that way more even.
So, Amazon, AWS, you know, the bookstore is announcing a quantum computing as a service.
Okay, we were expecting this to happen.
Yeah, we were.
Well, the thing is the quantum computers are so early stage.
They're so specialized.
They look more like science projects than they do any sort of computer.
They're not in square boxes.
They're usually, like, dangling from the ceiling with, like, all sorts of wires shooting out of them.
Like, you know, you can't go get a quantum computer.
But there are quantum computers that can do limited amounts of computing.
And so, learning to program them is something that might be a good idea, right?
Like, I have no idea what programming a quantum computer is going to feel like because it's just the conceptions.
I just haven't formed it fully in my mind.
Do you have a good sense of what this is going to be like?
No.
Well.
I think we're at the punch card stage still.
Yeah, yeah, exactly.
So, this new service called Amazon Bracket from AWS is a fully managed service that allows scientists, researchers, and developers,
and people just interested in quantum computing to begin experimenting with computers from multiple quantum hardware providers in a single place.
So, there's a handful of people creating these quantum computers, and they have different capabilities and whatnot.
So, you can actually select more than one provider for your quantum computer.
So, we all know about bits, right?
Bits are 0 and 1, on and off, that sort of thing.
That's the conception in my mind that it's pretty easy for things to work.
But quantum computers use a more sophisticated representation known as a qubit or a quantum bit.
And each qubit exists in a state of 1 or 0.
But because of its quantum nature, it also, in superpositions of 1 or 0, which means it can simultaneously occupy both states.
So, it's basically a two-dimensional vector of complex numbers of all these different states, which means it has way more data representation and computing power than just 0 or 1.
You know, it has, like, near infinite.
So, this service is built to give people some, basically, hands-on experience programming.
So, I linked to the Verge article talking about this.
I also linked to the direct announcement.
Now, Brian, do you see that code section down there, that little example?
Yes.
I have no idea what it's going to print.
I have no idea what it's going to print either.
But if not caring what the computational output is, what does that remind you of?
Python.
It definitely looks like Python.
And in the announcement, you can say, in here, you can use a notebook to explore writing in this bracket service, bracket language.
And, yeah, so I don't know if this is literally Python or is just very, very much like Python.
But if you're a Python developer, you know, you can get into this pretty easy, easily, I would suspect.
Yeah, it definitely looks like it's a notebook or something.
Yeah, so if you want to know how quantum computers work, if you want to play with programming them, you know, check this Amazon bracket thing out.
I've not checked the pricing.
It seems like it might not be that cheap.
But, yeah, it still looks pretty interesting.
Well, I think they're really trying to make it available to people that, in a researcher-student situation, so it's probably not terrible.
But I don't know.
Yeah, yeah.
Who knows?
But it's definitely interesting.
And people who are interested can now go and just fire up a quantum computer in the cloud and, through a Jupyter notebook, play with it, which is pretty awesome.
Yeah.
So let's go from quantum to virtual.
Yes, let's do it.
Do it.
Take a step.
Okay.
I couldn't resist.
But, you know, not really that cool.
But anyway, virtual environments.
Right.
With Python.
I know that both of us use virtual environments.
All the time.
I still have coworkers that don't.
And I know that some people still, I don't know.
There's a lot of old guides and tutorials on how to use virtual environments.
And I really didn't know I needed this.
But Brett Cannon wrote a quick and dirty guide on how to install packages for Python.
And it is mostly just basically walking people on how to use virtual environments.
I, of course, already know how to do that.
But I think it's good to have something like this available to throw to people that aren't using them yet because it's pretty short and simple.
One of the things I love about the article is it uses the --prompt flag for creating a virtual environment, which will make it so that your prompt variable or your prompt isn't just V and V.
It's something useful for you to see it.
Yeah, that is super cool.
I love that recommendation about the --prompt.
And in the article, Brett shows you how to have it take the current working directory as a default, right?
So it'll automatically grab that for you, which is cool.
I've got a little bash snippet that I use that essentially does that in my environment.
He hints at that in Python 3.9, there's going to be an improvement that instead of having some code that looks up your current directory name,
that you can just pass in a dot for the prompt and it will just name it that, which I'm looking forward to that.
That's cool.
Yeah, that's really cool.
Maybe I just want to start running 3.9 beta just for that.
Maybe.
Have you started playing with 3.9 yet?
No, I haven't.
Oh, okay.
I'm still actually, I'm still trying to decide what version I want to use because traditionally use Homebrew and something went wrong with Homebrew for Python 3.8.
So if you try to install Python 3.7 from Homebrew, you still get 3.7, which is frustrating, but I haven't decided that I'm wanting to break away from that just yet.
But it's starting to get to the point where maybe I'll just go to 3.9.
I don't know.
I just still use the installers from the Python.org site.
Yeah, I'm going to be back there too.
But yeah, this is cool and it's nice to have this.
This is real clear and concise.
And yeah, thanks, Brett.
So do you know what else is cool?
DigitalOcean is pretty cool.
DigitalOcean is awesome.
Yeah.
So DigitalOcean is sponsoring this episode.
They have awesome infrastructure and an awesome product and we use them for our services.
Do you have a memory intensive workload?
Something like high performance SQL or NoSQL databases?
In-memory caches like Redis or Indexes?
Some kind of large data analysis runtime?
Well, if so, you need DigitalOcean's new memory optimized droplets, or at least you should check
them out.
So check them out by going to pythonbytes.fm/DigitalOcean and get $100 credit.
And that's back.
We used to be lower, but now it's $100.
Yay.
Well done, DigitalOcean.
Thanks for supporting the show.
Sometimes the best thing you can do, Brian, is just say no.
All right?
It's easy to say yes to everything, but when you say yes to something, you're actually saying
no to something else.
Yeah, I've heard that.
That's kind of like the whole pointing a finger and you three point back at you and stuff like
that.
Yeah, exactly.
So this next thing I want to talk about is something that made the rounds the last couple of weeks.
And it's pretty interesting.
It's an article that sort of lays out a case against the no code movement.
And it's entitled, Say No to the No Code Movement by Alex Hudson.
And it's funny.
I don't know.
I might be showing my age, my gray bits in my beard or whatever, my goatee.
But he starts off by talking about 2020 is going to be the year of no code movement where
you can write business logic and entire applications without having to train the training of a software
developer.
I feel like I've heard that before, last century even.
How about you?
Well, yeah.
Are we talking like round trip stuff like UML round trip things?
Yeah, I was thinking of like Vizio and some of these other sort of business intelligence,
draggy droppy things that were going to, you know, quickly replace us as software developers.
And we're just going to be out of a job.
So you probably shouldn't study that because either outsourcing or there's no code stuff
is going to like crush our jobs.
I don't know.
I feel like software has been pretty good over the last 20 years.
Yeah, that's weird.
So yeah.
So the reason I'm bothering to cover this though is I do think it's interesting that this is
something of a trend.
And I think that Alex does a pretty good job of laying out what some of the issues are.
So it's easy to get sucked into wanting this, but it's also good to maybe know where like,
hey, this might make sense to try this, this no code idea.
So examples include like Salesforce, right?
With Salesforce, you can sort of wire stuff together to make things happen.
Other examples were Zapier were doing things.
Yeah.
Maybe if this, then that.
Yeah.
If this, then that.
I feel like Zapier actually, you know, Alex gave it a pretty good vote.
And I agree as well because it's not so much about trying to write software with Zapier.
It's about trying to just do integration.
I feel like no code integration isn't terrible if something awesome like Zapier can do it.
But basically the idea is like, look, there's people want to transform business processes
into the software domain.
And they might want to do that because change control of like, how do you change your business
and understand how it works is now a software problem.
It's easier to innovate on what makes the business distinct because now it's clear.
You're like, these are the things we do.
Everyone does this, but this, this is our special sauce right here.
And there's a cool quote from Satya Nadella that says, every company is a software company
these days.
And so there's a lot of pressure to take maybe traditional companies and organizations that don't have a software team or they have a very small software team that's too busy just keeping the lights on to help everyone else with their little issues.
There's this temptation to say, okay, well, what is our no code story?
Like how do we get some systems that just like let people write code?
You know, Excel sort of played that role to a large degree.
So the article's good for like laying out some of the issues.
Starts out, well, the first assumption is that writing text, like writing business logic in text forms is something that everybody hates, right?
Outside of the software development community, right?
Like if I'm an accountant, I don't want to write text logic because, well, you have to be accurate and things like that, right?
And if you had boxes, you can drag them together.
That might be better.
So it talks about how, you know, there's, it's a simpler abstraction that's really easy to work with.
Or it's simpler syntax.
And in both of those cases, you really run into the problem of, well, you can do the simple little thing first.
Like think of a visual, like a flow chart, right?
Like if you could just run a flow chart.
Well, for a really simple problem, that's fine.
But if you try to solve a real problem, you have a flow chart with like a thousand boxes and lines going everywhere.
That's not going to help you.
Another one, another example of the issues you run into is that many of the no code advocates
are building significant systems by pulling together off the shelf apps and integrating them.
This is kind of like Zapier.
But, you know, Zapier, I think, use right is still good.
But the problem is all the logic becomes implemented as a configuration of all these external systems.
And you're limited by what they can do and what they can accept and so on.
So, yeah.
He said, look, if there was a better way to create software than writing text, most of us would just drop it like a hot rock.
And we'd be like, yeah, okay, what's next?
Let's do that.
All right.
It would be great.
It's not that we love typing so much.
Yeah.
So, I guess, in conclusion, it's like, where does the no code stuff fail in practice?
Well, you get like 80% of the way there.
And then you're like, well, all these edge cases make this so complicated.
Or you end up with all the little edge cases and details that is like this little graphical whatever is so complicated that it's worse than text.
You know, things like that.
But where it might be useful is for a little proof of concept demonstrations and things like that.
Like, hey, here's the happy path of the main thing we want to do.
I threw this together with something like Salesforce or some other BI tool or something.
And look what we got.
Right.
Then you could go rewrite that with Python and Matplotlib or, you know, whatever it is you're trying to solve.
So, I thought this was an interesting take on the whole no code movement.
And I also thought it was interesting that, like, this is going to be the year of no code when I remember hearing that in the 90s.
Yeah.
Actually, my first job at HP was using a visual language for measuring systems.
And it was, I think we should look at some of the failures of the 90s.
Because what happened is what's going to happen again.
Like you said, you have systems that go 80% of the way.
But the corner cases make it so that you still have to be an expert at this tool to do it.
So, you still hire programmers.
But they only are gaining experience with this one tool that they don't even really like.
And they can't transfer to any other job.
And that's terrible.
It's not good.
Plus, visual stuff is sort of really fun when you get started.
But you quickly need a wrist brace.
Working on the mouse all day long is really actually fatiguing to your hands.
That's a good point.
I hadn't even thought about that.
But, oh, yeah.
For sure.
It was a program called VEE.
And I don't think it's even in place anymore.
It was a visual thing.
And we used to joke that if you buy the box set, it comes with a wrist brace.
Yeah, that's not good.
You know, this next item that you got coming up here, I checked this out.
And this is some deep stuff here.
Tell us about it.
So this isn't really a topic that we normally kind of cover.
But it's also something that I was pleased and surprised to see come up with at North Bay Python.
I'm going to highlight Shaw.
And his full name is Shadeed Wallace-Stepter, I think.
But he says he goes by Shaw.
He spoke at North Bay Python.
And we're linking to an article that is his article but also includes a link to the video of the presentation at North Bay Python.
And it's called What I Learned Going from Prison to Python.
And it is Python related.
But the Python take comes in the end, like the last few minutes.
It is a 40-minute video.
But you can even just listen to it because there's no visuals.
I'm not going to really summarize it too much other than this is an amazing story.
And people need to listen to it.
He's talking about how he went from a generational poverty situation to a crime as a teen.
It's interesting that he talks about one of the reasons why he started doing some crimes.
It wasn't because he needed to.
It was because he had zero control over the rest of his life.
And it made him, it was something that he felt had control over.
And then that gets him to the point where his best friend, like, dies on his shoulder by being shot.
And then he ends up in prison and spends 19 years there, 19 years of a 27-year sentence.
But this fight that he had to do to just to fight against the entire system, trying to keep him in poverty or keep him in prison.
It is an incredible story for him.
But I think it also talks about how, regardless of your politics, poverty and the prison system in our country is broken and we need to fix it.
So that's why I wanted to highlight it.
Yeah.
The thing that touched me from this was, I think for the first time, maybe ever, I understood why people would go down some of these paths.
Because, you know, people make some of these decisions and they're just so clearly a bad idea.
You know what I mean?
I'm thinking of, like, drug addicts for hard, hard drugs like heroin or meth.
Or, you know, people who are burglarizing houses and robbing, play armed robbery and stuff.
And just think, man, there's got to be a better way.
But listening to his story, I really understood it.
And, you know, I didn't get all the way to the end.
So it's awesome that Python, it sounds like, helped him move beyond that.
But do you have the last bit of the story?
Or are you going to give away too much?
So, no, I don't think it'll give it away.
I think he ends in a very positive note on talking about the open source community.
He eventually gets into, he goes from studying law to studying entrepreneurship to meeting Jessica.
I'm going to get her last name wrong.
Forgot it.
Jessica McKellar.
Yeah, McKellar.
Yeah.
Sounds right.
Although he said he met her in a journalism setting, but she was, like, not very good at journalism or wasn't a journalist or something like that.
But anyway, she's a great person.
But one of the things that people face when they come out of a prison system, especially if they came in in a poverty situation, is they've got no skills and no job history or things like that.
Or they may have no skills.
And even if they do have skills, who's going to hire them?
But the open source community is just a everybody's welcome.
And coding, there's more situations in coding where I don't know either you can do the job.
And that equality of background of just, it's just about whether you can get stuff done.
It isn't just about that.
We also, you have to be able to communicate and all things like that.
But we don't really care as much about your college pedigree or anything.
It's either you're a great coder or you're not.
And that's a cool story.
And his, even equates the open, he was shocked by the open source community of just working on stuff and giving it away.
Yeah.
But apparently there was a program at San Quentin that O'Reilly gave a bunch of laptops there so that people could watch some of the O'Reilly training videos there.
And that's how he learned Python.
So that's cool.
Man, super cool.
Yeah, I loved his story and it was really different.
So I'm happy he shared it and happy you covered it.
Yeah.
Speaking of covering things, have we covered GUIs?
I don't think so.
We should probably cover GUIs.
We probably should.
But, you know, what I really like about our listeners and our audience is they really help round us out.
You know what I mean, Brian?
Yeah.
Man, like I'll bring up one thing.
I'm like, oh, I heard of this one thing.
Can you guys believe this is a thing?
And they're like, and here, you know, here's the seven others and here are the trade-offs.
Did you know about this?
Yeah, and I can't believe you haven't covered this already.
Yeah, exactly.
So I've already got a bunch of stuff on Q that has that sort of take to it.
But here's one called QUIC, a QT5-based GUI generator for CLIC.
So CLIC is an argpars-based command line interface tool or framework, I guess, where you can put decorators onto different functions and say,
these are some of the arguments, these are required, these are not required, these are the types, and so on.
And it lets you write command line interfaces.
And so QUIC will take those and naturally understand the message given to CLIC or argparse and then create a GUI out of it.
No way!
Yeah, that's pretty cool, right?
So you don't hardly have to do anything other than throw like a QUIC.run and give it a function or something to that effect, and off it goes.
Oh, that is cool.
Yeah, I'm totally going to try this out.
Yeah, it's not super popular.
It's got, you know, like 62 stars and four contributors.
It was changed this month, so that's cool.
But just the example.
So it's a little bit old, but I think it's an interesting take and an interesting idea.
And if it's going to work for people, they can definitely check it out and contribute to it, so on.
So, yeah, I think this is a nice one.
It's based or inspired, not based on, inspired by GUI, G-O-O-E-Y, which is also really, really nice.
But you have to be a little bit more explicit on how it presents the UI for GUI.
You've got to say, here's a, I want a calendar widget for this thing or whatever.
But yeah, anyway, it'll even let you still run your standard click-based CLI app the same.
But then if you throw in a --GUI, it'll turn it into a GUI, even if you just want to change the command line arguments, which is, yeah, it looks pretty nice.
Yeah, a GUI, it's an interesting function call.
Yeah, exactly.
Yeah, so thank you, Ricky Tici, for sending this along and recommending it.
It's a good one.
Yeah, thanks.
Okay, we're not to jokes yet, but I have kind of a funny one coming up.
So it's interesting.
So there's a couple articles, I think it's in a series, falsehoods programmers believe about time.
And wait, what is the title of the blog?
Infinite Undo.
Oh, really?
Yeah, yeah.
It's all like, it all fits together.
I love it.
Sorry, keep going.
Then there's a second follow on one.
Must be a VI person.
More falsehood programmers believe about time.
Wisdom from the crowd edition.
So I'm sorry, I can't find your name on the blog, but wrote this article about falsehoods.
The interesting thing is very few of them have links to tell you why they're false.
But these are all assumptions that are wrong.
I mean, it starts with, there's always 24 hours in a day.
And, you know, there are things that we just sort of know are kind of wrong sometimes.
Like when we change the time, it's different.
Months have either 30 or 31.
A week begins and ends on the same month.
And I think these are, he's coming from the standpoint that he's debugged and tested code
that had these weird assumptions in them that broke.
And then it gets into some stuff that I, I'm going to highlight just a handful, but there's
a whole bunch.
A system clock will always be set to the correct local time.
And if that's not true, well, it'll be set to a time that's not wildly different from the
correct local time.
And if that's not true, well, at least it will be, always have a consistent offset in the number
of seconds.
And yeah, no, that's not true either.
I've been bit by this where we had systems under test be not even on the same day.
It has the following other one.
Let's see.
The day before Saturday is always Friday.
I had to look this one up because I'm like, isn't it?
Isn't Friday always before Saturday?
All right.
What's the deal there?
Samoa decided to change which part of their, the international time zone they were on so
that they were the same day as Australia.
And that gap swapped it like it swapped on Saturday, but it happened in the middle of the week or
something like that?
Yeah.
It happened like Thursday night and then the next second it was Saturday morning.
So they skipped Friday once.
That's some serious daylight savings action going on there.
Okay.
And then the number 81, the last one on the second one is, I think it's just thrown in as a joke.
I hope the software will never run on a spaceship that is orbiting a black hole.
Do we have spaceships that orbit black holes?
Not yet.
Yeah.
Not yet.
But you're going to have legacy code.
You're going to have the black hole bug that you got to go back and fix.
Yeah.
And then one I didn't highlight was that there's not an end to time.
Didn't put a link in for this, but did you know that like the end, if you have a 32-bit
time counter, it's probably going to break in 2038 or something like that?
Oh, wow.
Think of all the consulting opportunities.
I know.
It's like Y2K all over again.
Exactly.
Yeah.
That's interesting.
I mean, real time, obviously, we think doesn't stop and probably won't stop for us.
But yeah, computer time.
Computer time is a whole different deal.
Yeah.
This is really interesting.
And yeah, like you highlighted a few of the 81 and then that doesn't even touch on the
more falsehoods.
Pretty cool.
Yeah.
I get a little nervous every time I get anywhere near a time zone.
So with code.
Yeah.
I always use a time zone package or a time package to deal with that for me because I know I'm
going to get it wrong.
Yeah.
Absolutely.
So I must have forgotten because I feel like last time we, a couple of weeks
ago, we did cover Remy, which is a GUI framework.
Yeah.
Right.
And so Remy.
Yeah.
I remember that.
You brought that up.
Remy's cool.
And it lets you write Python code that then gets turned into something that has an HTML
representation.
But then you can hook events from HTML back into your Python code.
Right.
It's kind of like Electron JS, but swap out the JS for Python.
Right.
Yeah.
Well, we got a message from the creator, David.
And he said, hey, thanks so much for covering that.
You threw out that like, hey, it would be awesome if this wasn't had an editor or something
like that.
So yeah.
If you just look at slash editor in the repo.
Yeah.
There's a drag and drop WYSIWYG editor for this UI.
That's so cool.
I haven't tried it yet, but it's neat.
Yeah.
It looks really cool.
It's like pretty, pretty much like what you would expect.
You've got all the widgets you can drag and drop in there and size them and set their
colors and set all their CSS properties.
And then also wire up button clicks to existing functions or JavaScript events to existing
functions, things like that.
You can totally waste an entire afternoon and look like you're working.
Yeah, exactly.
Yeah.
Here's some of the no code stuff that is good.
So it's got a little, a little walkthrough example of creating, you know, like a hello
world button clicker type of GUI app.
But yeah, it's actually looks pretty killer.
I don't want to diss people that like actually work in the world of creating really good user
interfaces that, you know, and that's needed and I applaud them.
But there's a lot of us nerds that just need some kind of GUI that just sort of works and
that's good enough.
Yeah.
All right, Brian, I've queued up a joke, a visual joke that we'll have to describe through here.
And because this is about testing, I'm going to let you take it.
It's really simple, but it's quite funny.
I actually peeked at this before we're going to link to a Twitter post that somebody did of
this little video says two unit tests, zero integration tests.
And I guess I got to say, I'm a huge fan of these like unit test pass integration test
fail things.
So send them my way if you find them.
This one's hilarious.
Yeah.
So let me describe a little bit.
I'll set the stage.
There's a one of these like super powerful hand dryers and there's a trash can and it's
not like a trash bin that you move around.
It's like a fix to the wall, right?
Yeah.
Okay, go ahead.
And then right next to it's a place where you can grab, you know, napkins or your paper
towels also to dry your hands.
But they put like a one of those, the hand dryers that blows down and it turns on with motion.
And as soon as you throw away a paper towel, the dryer blows all the paper towels out of
the garbage.
It's super strong.
Not just the one you tried to put in the garbage, but every paper towel that was previously in
the garbage is now blasted around.
Yeah.
Two unit tests, zero integration tests.
Yeah.
The creative people that like got the garbage liner to stay in there in the first place.
So anyway, it's hilarious.
Yeah.
I got a little rub, a little syrup or something sticky on there to keep that big in place.
Yeah.
That's pretty funny.
This reminds me of a, I was at a company where we switched from actual plants around the office
to plastic plants, but nobody canceled the watering service.
And so the watering service just kept going around and watering all the plastic plants
once a month or once a week or whenever they did that.
So anyway.
Yeah.
That probably didn't turn out well after they filled up.
I don't know.
That's awesome.
It's just weird.
All right.
Well, thanks.
Thanks, Michael.
You bet.
Thanks for being here.
It's always, it's fun.
Bye everyone.
Bye.
Thank you for listening to Python Bytes.
Follow the show on Twitter 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.
This is Brian Okken.
And on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast
with your friends and colleagues.