Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is one of your hosts, Michael Kennedy.
And this is Brian Okken.
And we're here with our first post-PyCon episode.
So, Brian, let's just jump straight into it.
How was PyCon for you?
Yeah, I wanted to bring up that right away because it was incredible.
It's the first one I've been to.
And I got to say, it was even more than I expected.
Hard to put in word.
We hung out.
We had a booth there.
Thanks to everybody that showed up to say hi.
Apologies to anybody that stopped by and we weren't around at the time.
But, Michael, you were pretty good about hanging out and talking with everybody.
Yeah, I went deep into the hallway track.
Yeah.
Which meant I mostly ended up spending time at the booth having conversation with people or at other people's booth talking to them or something to that effect.
That's the real value of PyCon to me.
Like, I think the talks are amazing.
And I really enjoy the keynotes and things like that.
But the open spaces and these, like, impromptu meetings, that's where it's at for me with PyCon.
Yeah, actually, the open spaces, that's something I didn't really do much.
And I think that I'll have to make sure to do that more next time.
They put up those.
For anybody that hasn't gone, they put up these boards with just, like, a whole bunch of empty rooms.
And you can just sign up for a time slot.
And if you get it, you have it.
They start out fresh each morning.
So, people just hang out and do things.
And it's not just all testing related.
Or not testing related.
Python related.
Sometimes they do things like tie knots and stuff like that.
Yeah, one thing that I went to was how to start a business.
One that I went to was how to market yourself as a developer.
And then I actually ran two.
One was, like, a Python podcaster meetup.
That was really cool.
A bunch of people came.
Thanks to everyone who came.
And then one on out-of-the-box ideas for improving the diversity of funding for PyPI.
So, that's something that will be coming out later.
That requires some write-up.
Oh, that's cool.
Yeah.
For my benefit, as well as the people listening, I'm going to put a link to the YouTube channel with all of the talks.
Unfortunately, all these, like, open spaces and stuff aren't recorded.
But one of the things that also I wanted to bring up was that I was surprised how much I enjoyed the lightning talks.
I think it's neat to have a full range of people that are really great at speaking and people that they're new to it as well.
Yeah, it's pretty.
If you want to try your hand at public speaking and you're new, like, five minutes is not too tough.
Although it's a big audience, it's only five minutes.
Yeah.
Okay.
And, yeah, lastly, I wanted to say it's amazing.
How many people know Michael?
Man.
I also find this amazing.
It's, like, entirely humbling and, you know, it was amazing.
Yeah.
Okay.
Well, let's move on.
Awesome.
Okay.
So, keeping in the current latest state-of-the-art, like we talked about with many, many things at PyCon, we recently heard that AWS Lambda, which has nothing to do with Python Lambdas, it's just the serverless computing offering from AWS, has started supporting Python 3.6.
And so, someone else who was there at the conference was Matt McKay from Fullstack Python.
And he put together this little quick tutorial on just how can you quickly set up a AWS Lambda Python 3.6 function and do some interesting things like read from the environment variables and things like that to create this little app.
Nice.
Yeah.
So, basically, if you can write a function, like a single function, then you can pretty much write and deploy these AWS Lambda functions, which, if you have something kind of like a micro service, micro architecture type thing, then, you know, maybe it makes a lot of sense to do it as these little AWS Lambdas.
I'm actually going to have a guy tomorrow, a guy named Ryan, come and talk about serverless computing in general on Talk Python.
But here's a little precursor if people want to check this out.
Oh, that's cool.
I'll be looking forward to listening to that.
I was just curious on the Lambdas.
Do you know if the functions you put in there have to have names?
They have names, but you basically map them to endpoints that you can set up.
And there's all sorts of events.
Like, they maybe are not even public in terms of HTTP.
Like, they might not be web service endpoints.
They could be.
It's basically event-driven.
So, for example, you can say, I would like this function here, whatever you name it.
It's kind of irrelevant, but you have to pick the name, right?
I would like this function here to execute when somebody uploads a file to this subfolder, this bucket in S3.
Okay.
Right?
So, maybe you're going to do, like, let's say we have a video delivery service for, like, training or something.
Well, if you upload a new video, you might want to create an adaptive stream, like a low bandwidth, a high bandwidth version, different formats, like MP4 versus WebM or something like that.
Like, you could detect when a file is dropped there and automatically, by virtue of effectively just uploading to S3, have this code manage and juggle all that in the background, and you don't ever have to do anything.
So, you can set up these cool event-triggered things, but it could just be as simple as, like, here's an HTTP endpoint.
Okay.
I'm going to try that out.
Yeah, it's pretty cool.
Definitely.
One of the things I talked about at the conference was PyPI and the Python Packaging Authority and so on.
And that was around funding.
But, you know, one of the reasons they have such a challenge with their infrastructure is because they have so many packages, right?
Yeah.
Yes.
And so, you should put some more out there, everybody.
Yes.
Everybody, let's make more.
Let's do more of that.
There's a pretty good JetBrains article called How to Publish Your Package on PyPI.
I think it does a really good job on talking about what all you have to put into your package.
The structuring is pretty good, although I'd like to see them include the source directory in their article.
But one of the things I liked was just a discussion of all the contents of the setup.py file, all the stuff that you've got to put in there, your license, your email.
And I guess it's all pretty obvious.
But when you just see it all in an example setup, it can be a little overwhelming.
But it's really, there's the minimal amount of stuff you put in there.
It's just not that complicated to put in there.
I also liked that they, I hadn't seen a decent example recently of what you ought to put in your PYPIRC file.
So, I guess it's like a, yeah, config file for, so that you can talk to PyPI easily.
Right.
Like, I think you could put like your account information so you don't have to like log in every time and stuff like that, right?
Yeah.
And then they talked about using Twine to push both to the test, the test repository, I guess, and then the actual one.
That's something that people ought to do also.
If you just want to try this out, but you don't have a package that you're ready to actually put out there to the world yet,
you can use their test server and push things up and try it out.
Yeah, definitely make use of the test server.
And what surprised me is actually how easy it is to put something on PyPI.
I found most of the difficulties that I ran into when I did this were actually around packaging itself, just purely packaging.
And once you kind of had that solved, it was like, it wasn't too bad.
Yeah, and I actually encourage people to just, yeah, come up with something and try it out.
I have to drink my own Kool-Aid with this one.
I still haven't put anything out there, so I got to put a couple of things up there.
Yeah, maybe after you're done writing your book, huh?
Yeah, actually, there's a lot of, quite a few pytest plugins that I'd like to write and put up there.
Oh yeah, that'd be a good set.
That'd be good.
Yeah, that'd be awesome.
Speaking of Pythons, Pythons live the same place where there are coconuts, right?
No, that's...
So, the next thing that we're going to talk about is called coconut.
And there is a tie-in to Python.
But you've got to go back to the origins.
Back to Monty Python.
Oh, right.
Yeah, okay.
Right, you know those knights that run around and they've got like those coconuts, they click together.
Yeah.
Because they don't actually have horses, but it sounds like the galloping, basically.
We should have had some for the show.
We should have brought some to PyCon and just run around with them.
Next year, we know what to bring to Ohio.
Okay, so the next thing I want to talk about is a Pythonic functional programming language.
Now, functional programming, you know, some people are really into it.
Some people are, I don't know, kind of stay away from it.
To me, it's one of those languages where it's kind of like a good puzzle more than, I don't know, like building blocks.
But it's more like this thing you have to sort of, you write a little bit of code and then you think about it for a long time, deeply.
And then you write two more, you know, characters and you're done or something like this, right?
So it's very concise and it's very interesting to write, you know, basically functional programming.
And there's many options that have been for a long time.
Scheme, Haskell, whatever, right?
F-sharp, Erlang, you name it.
But as Python programmers, we have all of our awesome PyPI packages, just as we talked about.
And we may have some more after the session, right?
So we have all of those and then we may be of existing Python code.
So Coconut is a functional programming language that is deeply functional and unique, but is a superset of Python, Python 3 specifically.
So what that means is you can take a given existing Python 3 code and go and rewrite one function or one algorithm functionally rather than imperatively.
And you can use all the PyPI packages because it's just Python.
Okay.
So you can gradually add functional programming to an existing application or something.
Right.
And you don't have to start over.
Like you have to learn the functional programming concepts where they apply, but you don't have to use them all the time.
You can just use them where they make sense.
So there's all kinds of unique things for Coconut.
There's pattern matching, which I'll tell you what that is in a minute because that's wild.
There's basically algebraic data types, which are immutable data types.
Think anytime you see a class, replace the word class with data and that becomes immutable.
But there's some other cool stuff that happens.
Really interesting parallelization operations.
Because once you have immutable data types, many of the problems that you solve by paralyzing them, these algorithms become what's called embarrassingly parallel.
Right.
Embarrassingly parallelizable.
Right.
Like if there's no real interaction because everything's read only, well, just let it roll.
Right.
Just fork it out and just give the pieces to little sub processes or something.
So there's a lot of cool stuff.
But just to give you a sense, I'll tell you about the pattern matching.
Suppose I want to write a recursive function or let's just say a function that implements, like say factorial.
That's their example they have.
You would have a function.
It would take a number.
It would have a test.
It would say if this number is zero, then return one.
Otherwise, do some multiplication stuff with the current number plus times the factorial of n minus one.
Something like that.
Right.
And you would do this kind of recursion thing.
So you have these if statements for different situations in your function.
In coconut, you can define one function for the degenerative case and another function for different situations.
So, for example, like your parameters can say, I would like to take an n, but only if the n is an integer and it's greater than zero.
Oh, wacky.
It's kind of like a method overloading in, say, C++, C#, Java, where it might match by type or type plus number of parameters.
It does that, but by if statement.
It's crazy.
Okay.
It's pretty mind-bending.
Anyway, people, check it out.
There's a cool tutorial.
It's just pip install coconut, so easy to get started with.
It's definitely worth looking at because, you know, it'll make you think a little differently, which is always good.
Well, thanks.
I guess I'm just going to go back to packaging again.
But one of the things that I have had trouble with is understanding all the open source licenses.
And I guess I got into open source a little bit when everybody was afraid of the GPL, especially in the corporate circles.
And now, you know, I just knew that MIT was, like, not as freaky, I guess.
MIT is, like, super simple and permissive if you want to use it, but it's hard to decide.
For these more permissive licenses, for me, it's hard to decide, like, well, what if I want some restrictions?
Right.
Right?
It's like, what can I offer this useful to people, but it has, like, the kind of protections I would like to have in this code, right?
Plus, if you start reading it into it, there's a bunch of legalese that, like, I just glaze over.
My eyes glaze over.
So I ran across a site called choosealicense.com, and it's pretty darn cool.
It talks about the MIT and Apache and GPL, but it also has, like, a cool list of all of the whole bunch of different licenses
and has some color-coded bullets for what you're getting with those and what you're giving up and what rights you keep and all that.
And I like it.
It's good.
Yeah, very nice.
Very nice.
We even have the unlicensed covered there.
Which is pretty cool.
And then also a comment about you don't have to, you don't actually have to pick a license if you don't want to.
There's nobody forcing you to.
Yeah, yeah, in which case you pretty much just retain the copyright.
There's somewhat of a problem with that on GitHub, I believe, in that there's a number of what are meant to be open source projects on GitHub
that just whoever created the repo didn't do the little dropdown and say, yes, pick a license and choose one.
And so there's the stuff that looks like public open source because it's publicly accessible and it's on GitHub and you can clone it and do stuff.
But there's technically no license, so it's not really open source, which is kind of interesting.
Yeah, and I guess one of the reasons why I picked up on this is because I'm trying to teach people to use simple setup files so that you can make a package pip installable even locally.
And one of the requirements is you have to fill something in for license.
So you may as well just kind of think about it a little bit ahead of time so that you can throw it in there.
Anyway.
Yep, absolutely.
It's a good idea.
All right.
Let's round it out with something free for people.
A free book.
So there's a book called Python for Scientists and Engineers.
And I think this was not free before, but now just became free.
So this is a book if you're getting into basically using Python for science or machine learning or natural language processing, all these different things.
There's a bunch of examples of using it there.
All right.
So just to give you a sense, there's like some introductory stuff.
And then they've got image and video processing in Python, data analysis with pandas, audio and digital signal processing.
Of course, you've got to control your Raspberry Pi with Python because who wouldn't want that?
A couple of things on machine learning like building an Amazon-like recommendation engine.
And then a bunch of stuff on natural language processing and sentiment analysis and looking for spam and, you know, basically text processing type things.
So if learning about those things and dabbling in those things sounds interesting, here's a book with a bunch of applied chapters.
Nice.
Lots of cool stuff in there.
There's all these cool things that I would love to know and would love to learn and have no applicable use for in my world.
You know what I mean?
Like I would love to build like a machine learning sort of something, but I have nothing to turn machine learning loose on right now.
Yeah.
And one of the things that I noticed in here is the audio and digital signal processing section.
I think that's pretty cool because it's been on pretty hard to get into DSP stuff before Python and some of the engineering tools that came about with Python made it a lot easier.
So that's pretty neat.
Yeah, absolutely.
Yeah.
Very cool.
So that's our news for this week.
I don't know about your podcast, but mine is definitely going to be a buzz with lots of stuff that we learned at PyCon.
So I want to loop it back to the very first thing that you covered.
Be sure to go check out those videos.
I don't know how many there are, but it's like a hundred presentations.
It's crazy.
And there's so many good ones.
Actually, I'm not watching them while driving, but I'm listening to them while driving and then just knowing to get back to the slides later if I want to see that.
Yeah.
And a lot of those talks, I think you can get like the 80% just in audio and it's probably good enough because you might not watch it all, but you're stuck in traffic.
So why not?
Right?
Yeah, definitely.
Right on.
So how's the book?
I saw a great giant like floor to head height banner of the book, but what's that mean for the rest of us?
It was a nice timing.
It was hard to get it out, but we got the beta out available.
So it's not available in hardback yet, but Python testing with pytest is available within a beta.
So the first five chapters are ready and the first five chapters cover like just about everything you need to know.
The only thing that's left to wrap up in the last couple of chapters is the configuration files, like the any file and stuff like that.
And then the last chapter is going to be using pytest with other tools like with Selenium and with continuous integration.
These are definitely meaty, nice things, but they are not things that are necessary to get learning.
And I've already had one of the comments from Twitter is somebody bought it and said, wow, this is like the best thing to learn pytest.
So that was a good.
That's got to make you feel good after like months and months of months of working in isolation.
Yeah, yeah, definitely.
And also just like it's been an incredible experience working with an editor too.
It's been good.
Yeah, yeah, I'm sure it has.
That's awesome.
All right.
Well, we have a link at the bottom of the show notes.
And so people want to check it out, they can totally do that, right?
Yeah.
All right.
Well, that's it for this week.
Brian, as always, thank you.
It was great to hang out with you at PyCon.
And once again, thanks to everyone who stopped by.
We met so many people.
It was really amazing.
Right.
Incredible.
Thanks.
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.