Transcript #76: Goodbye zero-versioning

00:00 Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds. This is episode 76 Recorded May 3rd 2018. I'm Michael Kennedy and I'm Brian Okken and this episode is brought to you by Datadog Check them out at pythonbytes.fm/datadog. They're doing awesome stuff. Tell you more about that later, Brian I think you know, we're on the eve of PyCon. We're literally in terms of podcast releasing podcast episodes This is PyCon eve and PyCon is a place where people seem to really care more than most developer communities about sort of welcoming newcomers. And you've got something that kind of ties into that, that angle as well, right? I ran across this article, and it looks like it was a, it's called unlearning toxic behaviors in a code review culture. And this is, apparently, this came from a talk at AlterConf, and then turned into this. So there's the slides are available. But this there's an article with all of the information and this is something that trying to have good manners and be a good human while also helping each other out in code reviews is sort of an interesting balancing act because you've you've got to actually teach people and if you need to teach and everything so anyway I'm going to jump into some of the ideas around this and it's an interesting idea to go off is a discussion of some of the unhelpful behaviors that people have seen and then some of the helpful things you can do.

01:29 So one of the, I'm not going to list all of them, but there's a few of them that jumped out at me, like passing off opinion as fact was the first one and you know as people saying, "Oh this should be implemented this way." But there isn't really a should often with software, those are opinions and so just make sure you state it like that. One of these things overwhelm, next up is overwhelming with an avalanche of comments. So like for example if somebody made the same mistake a whole bunch of times like I don't know there's spaces in the wrong place or some formatting issue or you know not using underscores and doing camel case instead commenting every place. I mean one comment is sufficient to don't put like yeah you did it here too yeah you did it here too yeah you did it here too all over the code review. And there's actually just reading through all of these they're good just reminders of how to be helpful instead of being hurtful during a code review.

02:27 And then popped out some of the helpful things that one of the things that popped out at me is collaborate and don't backseat drive. And this is one actually that I need to work on, because it's hard when I see some code that I think should be another way.

02:41 I don't really want to just tell everybody, tell somebody what's all wrong with it. My instinct is to just do it the right way and show them, say, it should have been done like this.

02:50 But that's not the right way to go.

02:53 But anyway, you have any comments on some of this?

02:56 - So one of the things I think that people need to be really careful about is when, in some of these code reviews, especially for junior developers, this can be like a really sort of sensitive time emotionally, right?

03:07 You put together some work and like, it's one thing to criticize the code, but at the same time, it can come across as feeling like criticizing that person or their skill set.

03:17 And when you're a junior developer, you're feeling is like, you maybe don't feel like you can keep up with your team because they've been doing it for 10 years and you've been doing it for two and you just feel a little bit like you're always trying to catch up, right?

03:28 And so if somebody comes in just matter-of-factly says, we're gonna throw a bunch of comments on this stuff, you should do it the way I've been doing it for 10 years, et cetera, et cetera, like it can, I think it can be perceived as a personal attack or attack on your credibility in your newfound career.

03:45 So I just think being real sensitive of that, especially for junior developers.

03:50 I mean, I'm sure people who've been doing it for a long time feel that way as well.

03:53 But the longer you do it, the thicker your skin gets, and you're just like, you know, the more you're kind of used to having these sort of debates and differences of opinion.

04:03 But yeah, I would sort of second this and say, be cautious of the junior developers and make it more about learning and bringing them along instead of like, hey, I'm gonna show you how to do this 'cause you did it wrong.

04:13 It also depends a lot on personality because when I was a junior developer, I actually was more open for people saying, "Oh, this sucks.

04:21 You should do it this way." And now that I think of myself as an experienced developer, there's still a lot of stuff that I'm learning in new parts.

04:29 And I sometimes will take a comment of like, "Oh, you should do it this way," as like, "What are you talking about?

04:35 I'm a senior developer," you know?

04:37 But I got to check the ego a little bit.

04:40 And one of the things that helped my team a lot, it shows up on this list too, is to automate what you can.

04:47 Like for instance, we use, I mean, whatever your standard is, just define that and codify it with PyCode style or Flake 8 or something.

04:56 Our team uses Flake 8, the Flake 8 defaults.

04:59 We at work, it was helpful for us to increase the line length and a couple other things that we turned off.

05:07 agree on that and just automate that and just so sometimes something will come through a code review and Just a simple comment of hey, can you run this through flake 8 first before we start the review is easier I totally agree with that because people You don't feel personally criticized by a computer. Yeah, right It's just like the algorithm it formats it this way and it Checks that the line length is this and the format is that and if it's wrong, then you fix it But it's not like it has an opinion about that.

05:38 Not really, right?

05:40 Maybe someday computers will have opinions like that, but they don't right now.

05:43 And another thing, sort of adding on what you're saying is, with black, I believe, remember black, the formatter that comes in any color you want, as long as it's black?

05:51 That one, I believe, will modify the code, not just suggest fixes.

05:56 So you can say, black, reformat this the way we like it, and just do that.

06:01 - I still haven't tried to hook that up as a commit hook or something like that.

06:05 - Exactly, it'd be nice.

06:06 I think it's pretty cool.

06:07 Definitely worth thinking about these issues.

06:10 So, Brian, do you remember a few episodes ago that project, that new versioning project that Mahmood Hashemi and a few of his friends put together about zero version?

06:21 Was it zero-ver?

06:22 What was it called?

06:23 - I think it was zero-ver.

06:24 - Yeah, I think it was zero-ver.

06:25 So it was like sort of celebrating in a sarcastic poking fun at maybe you should not be zero version.

06:32 the zero dot whatever version of things like Flask, Pandas, et cetera, right?

06:38 Things that have been around for eight years and are super stable and are still like zero dot one for their version.

06:44 Well, either that article or this episode, or that episode covering it somehow may have had some kind of effect because Flask had been on like zero dot something small for eight years and now Flask 1.0 is released.

07:00 How about that?

07:01 is a great thing. It was interesting that there were some people that like actually commented of like, why bother if it's already stable? I think it's a good, I think it absolutely makes sense. I mean, I know that there are people out there in the world who see it's been around for a long time. It's had many releases that means stable. If it's not stable, you put the little beta, little B on the end of the version or something like that. But there's a large portion of the development world that comes to Python from outside of the core ecosystem of Python and sees 0.1 and goes, can't use it, not ready, what is this, right?

07:34 And so I think it really makes a lot of sense just changing the version because they got some pressure.

07:38 There's actually a lot of stuff here.

07:39 I'm gonna try to go through this quickly 'cause there's actually a lot of stuff here.

07:43 So the CLI is more flexible for creating (audio cuts out)

07:49 and actually you can do things like, say it's in development mode or production mode and that can replace Flask debug settings in the environment, stuff like that.

07:56 >> That's great.

07:57 >> You can get the environment variables from a .flask env file.

08:01 So instead of having to export them in your shell when you launch the shell, like zshrc or bashrc, things like that, you can have it just in these files.

08:13 And it'll actually load them as if they're from the environment, that's cool.

08:17 Development server is multi-threaded, so now you can more properly test concurrent requests during development, which is what you would experience if you were to release it to a proper threaded server like MicroWizKey.

08:29 Flask.ext, which was deprecated, has been removed.

08:33 Some stuff around forms is pretty nice.

08:34 Better error handling, more finer grained stuff there, more logging.

08:38 The stump for you, the test client gained a JSON argument for posting JSON and the response test object.

08:45 A get JSON for decoding JSON, so you can have like test your JSON methods better.

08:50 A test CLI runner for testing your app's command line options.

08:55 Pretty cool, right?

08:55 - Yeah, very cool.

08:56 - So all of this stuff is in Flask 1.0.

08:58 - Nice, actually that very much deserves a bump in the version.

09:01 - Right, and it's time.

09:04 It's definitely time.

09:05 So well done Flask team.

09:06 - Yeah, I'm just getting into some more Flask stuff too, so that's good.

09:10 - Yeah, it's pretty fun.

09:11 So have we gotten used to pip-inf?

09:13 Like I'm not used to it.

09:14 I literally yesterday typed pip install-r requirements.txt a lot because I was rebuilding some servers.

09:20 How about you?

09:21 - I understood it.

09:22 really cool, but I had trouble really grokking what problem it was solving that I didn't have yet.

09:29 So I ran across an article that's called "Pipenv, a guide to the new Python packaging tool." And so since everybody's like, actually not everybody, but it is being more recommended now to use Pipenv where appropriate.

09:46 And so this article actually presented it in a way that I think it made it made me understand it a little bit a lot more.

09:54 For instance, using pip and it's like using pip and virtual environments, but it does a lot of the stuff for you.

10:01 There is some some workflow differences, but other I mean that that I'm not going to cover here, but the video there's a video up on the site that I think the pip and read me or the, I don't know, the documents.

10:15 >> Like the GitHub page, yeah.

10:16 >> Yeah. It has this little video, this is great. It shows you the workflow.

10:20 But what problems does it solve?

10:22 The requirements.txt has an issue, and this article talks about the current without pipenv what the problems are.

10:29 Requirements.txt, you can set it up as just, these are the required packages that my application uses, but it doesn't really have versions.

10:37 You can put versions in there, but your mileage may vary.

10:40 Now, if your dependencies have dependencies themselves, then those versions, how do you keep track of those?

10:48 One of the ways people have done that is use pip freeze, which does both your dependencies and all of the sub-dependencies and freezes all of those, and you can use that as your requirements file.

11:00 But then, you've got to keep track of it.

11:03 So every time one of the sub-dependencies updates, you've got to make sure it works, and that's just a pain.

11:08 >> Yeah. I mean, the requirements is supposed to show you what you depend upon, not the transitive closure of what you depend upon, really.

11:15 Right.

11:16 Oh, math words.

11:17 Not all, not your dependencies, dependencies, dependencies, dependencies.

11:22 How's that?

11:23 Okay.

11:23 The gist of it is in file wise, the pip, there's two files that get generated, pip file and pip file dot lock.

11:30 pip file is the, these are my requirements kind of, but it also does more than that.

11:36 Then pip file lock is like all of the pinned requirements with all the versions.

11:41 It also includes hashes of the downloads so that you don't have to worry about corrupted installs or anything like that.

11:48 Then it does so much more than that, but this discussion really helped me understand why this is useful, especially the sub-dependency thing is something, yeah, nobody wants to deal with that themselves.

11:59 So let PIPM deal with it for you.

12:01 >> Yeah, pretty cool. I got to study that.

12:03 I got to get my workflow zen around this new way.

12:07 >> One of the catches, which is that it's recommended for use for applications and not for packages because your package is used by something else.

12:17 You don't want to pin anything.

12:18 It's the application that should pin things, not packages themselves.

12:22 But you can use it while you're developing packages.

12:26 And if you're really confused on how to set all this up, there's a new cookie cutter for it.

12:30 So we're also going to include a link.

12:32 There's a package somebody did for a generic Python project that uses pipenv, there's cookie cutter for it.

12:41 - Nice, so you basically, if you're gonna start a new project, you can run that cookie cutter to generate it with the proper structure using pipfile and pipfile.lock.

12:49 - And it's kind of a fun way to just get your hand, like, okay, how's this all supposed to work?

12:54 Even if you don't use this for a project, to pull down pipenv and in a project and play with it and say, "Oh yeah, this makes sense." - I think that's a really cool way.

13:03 It kind of gives you the essence of what you need for the structure.

13:06 Which is always something that's fun to debate and we have a few times.

13:09 (laughing)

13:10 So before we get to our next item, which is probably gonna surprise people a little bit if they haven't heard it, I want to tell you about Datadog.

13:17 So Datadog is a monitoring solution that provides deep visibility and tracks issues that you might be running into with distributed applications.

13:25 So if I have an app that has maybe some services, like microservices and it calls into the database and other things and it's slow, like that can be really hard to figure out where.

13:35 But with Datadog, you can just investigate the bottlenecks in your code, explore graphs and dashboards, and really figure out where your app is spending its time across processes, right?

13:45 So you're not just profiling one thing.

13:47 So visualize your Python performance today, get started with a free trial, Datadog, and you'll get a cool shirt, well, a t-shirt with a Datadog mascot is the right word I'm looking for.

13:59 A Datadog mascot on there.

14:01 So check it out for yourself at pythonbytes.fm/datadog.

14:05 So if you're gonna think of a company, Brian, that was going to create like one virtual machine, one runtime, in Python speak, the equivalent of interpreter, to rule them all, how about Oracle?

14:20 - No, I wouldn't have thought Oracle.

14:22 - No, I probably wouldn't either.

14:23 So there's this thing called GraalVM, G-R-A-A-L, V-M, and it says this is built to run Python code and other code that depends on virtual machines and run it faster.

14:37 So they said, look, we see this problem.

14:39 Like current production virtual machines, and you know, threw CPython in there with that, provide high performance of only execution of only certain languages or a small set of languages.

14:51 They all repeat a bunch of stuff.

14:52 I'll do compilation, memory management, tooling, et cetera.

14:56 So it kind of violates the don't repeat yourself, the DRY principle.

15:01 They're heavyweight things usually that take a lot of memory, so they're often difficult to embed, especially like JVM, stuff like that.

15:08 So over at Oracle Labs, they started a new project a while ago to create a single VM that would provide high-performance execution for all of the languages.

15:17 Benefit being, if I have, say, some sort of multilingual environment, like maybe we do Java and Python or something like that.

15:26 If you could put that within the same process and have them directly communicate, they would go dramatically faster than say over JSON-based microservice.

15:35 Like if it was literally in memory.

15:36 That's kind of the idea, right?

15:38 So the goals are basically to create this high performance single VM that can interoperate with zero overhead across these different languages and platforms.

15:49 So you can run all the JVM-based languages, Java, Catlin, and so on, JavaScript, including Node.js, anything that you can do LLVM against, so C++ or Rust, and Python.

16:01 So imagine you're doing some sort of interop type of thing, and you want to write some of your code in Rust and some of it in Python, and you want to try to get the best performance out of it.

16:13 Maybe putting it together in this thing would be pretty cool.

16:17 So it does, I don't know how much it'll help for Python, in its current form, but maybe they'll get something really special, but for some of the JIT compiled languages, it will ahead of time compile them to machine instructions and then run them.

16:30 So things like startup time and initial execution is super fast and predictable.

16:34 So it would be cool if they could do like PiPi pre-compiled or something like that.

16:39 - Just to make sure I get my terminology straight, the Grail VM, the VM is a virtual machine.

16:45 I'm used to virtual machines being like an entire desktop, like on a server or something.

16:52 Is that what this is?

16:53 - No, often VMs are like the Java VM or the .NET CLR or things that are sort of managed memory process.

17:04 - Okay, it's the thing between my code and my computer.

17:07 - Yeah, and it is most commonly used around things that JIT compile.

17:12 Java, JavaScript, .NET, things like that.

17:16 - Okay, so two completely different things.

17:17 - Two different VMs.

17:18 - It's called virtual machines.

17:20 Okay, got it.

17:21 - Right now, the Python support is experimental, but they're working on, one of their main next steps is to make the support for Python better.

17:29 So if this sounds interesting to people, I think, you know, it's early days, it's pretty interesting, and check it out.

17:35 - Actually, I'm like super excited about it, because the combination of Python with C++ and Rust and R and other things, and Kotlin, it's gonna be, I think this is an exciting thing.

17:47 - I think it is too, and there's, And if you can do that with no interop within the same process, without translating between the layers and some kind of like CFFI layer type of thing, I think that would be really cool.

17:58 - Yeah, okay.

18:00 - We'll see.

18:00 It's early days, but it could be a pretty neat step in adding one more way to execute Python code.

18:07 - Yeah, neat.

18:08 - All right, what's your next one, Forrest?

18:09 - I am like totally in getting ready for PyCon mode and didn't have time to do a testing code episode last week or this week.

18:22 So this is a shameless time, I'm gonna take my last slot to do some testing related topics.

18:28 But one of them's Flask, so we covered Flask already.

18:30 There's a--

18:31 - Yes, a brand new version, you can test it.

18:33 - Yeah, there's an article that came out this week called "Testing a Flask Application Using pytest." And those are two of my favorite things, Flask and pytest.

18:43 And one of the third favorite thing is my own book.

18:46 And the book that I wrote was part of the inspiration for this article, so shameless plug.

18:52 But it's a really nicely written article.

18:54 It's basically, if you're working with Flask and you wanna try to work with pytest also, I mean, I've had questions about this, but I didn't feel qualified to answer yet.

19:05 Now I am because of this article.

19:07 But there's talks about both unit testing and functional testing through the test client Flask provides, but the unit tests don't have to be. You can access things directly. But the article goes through both a couple examples, a unit test and then a functional test, like for instance checking the, making sure that the new user works at a unit test level and how to hook that up with pytest and Flask and everything. And it's actually really nicely done. After you read the article, I don't stop there. I go out and look at the project that he's got on. I can't remember if it's on GitHub or GitLab, but it's an open source project that you can take a look and it's got other more testing examples And it's really well done. So good job. I like it. Yeah, it looks really really cool And I see the project structure there again, like here's how you set it up to do testing So that's very nice. And it's cool. Your book was inspiration for it as well. Another thing while we're on the testing topic I wanted to bring up a new pytest plugin that just actually kind of blew me away.

20:11 This is a brilliant idea.

20:12 So, and I also learned the word stochastic.

20:16 I think I knew it at one point, but stochastic is kind of means random and stuff, but it comes up because it's in the, in the readme for this project called pytest-CAPRNG.

20:30 So the, here's the idea is if you've used random, the random module or the NumPy random is being used in your code or in your test.

20:41 Running a test-- if you run a test and it fails, and you try to rerun it and it passes, it might pass because the data is different.

20:48 This new plugin, what it does is before you run each test, it captures the state of the random modules so that the seeds are the same.

20:58 Next time you run it, if you rerun the failure, you'll get the same data again.

21:03 So you'll see the failure again.

21:05 And it's just kind of a small little plugin that is an awesome idea, so I wanted to highlight it.

21:11 It's cool.

21:12 - Yeah, it's cool.

21:13 I mean, coverage might change based on that value.

21:15 Success or failure might change based on that value.

21:17 So being able to lock it down, make it predictable.

21:20 - Yeah.

21:21 - But still have it start from something random, that's pretty cool.

21:23 I like it.

21:24 All right, I did say we were on the eve, on PyCon eve, right?

21:27 So the next time we release an episode is going to be at, well, at least it will have been recorded at PyCon.

21:34 We'll see if it happens there.

21:36 Anyway, there's a really nice article by Trey Hunter.

21:39 He was a guest co-host a while ago on how to have a great first PyCon.

21:45 So PyCon is maybe the big, I think it's the US one is the biggest Python conference there is.

21:52 It's certainly quite large.

21:54 And there's a lot of options.

21:56 It's a little bit of a paradox of choice there, right?

21:58 I mean, did you have that experience when you were there, Brian?

22:00 - Yeah, definitely.

22:01 I'm really having that time, that experience again, looking at the schedule.

22:05 I don't know what to go to.

22:06 - I know, I'm gonna solve that by not going to anything.

22:09 (laughing)

22:11 Which is part of this conversation.

22:12 So, he has a really nice, long, thoughtful write-up about sort of getting the most out of PyCon.

22:19 The first time, maybe if you've gone a few times, you can still read this and get something out of it.

22:24 So, first of all, he mentions that the talks are typically recorded, available on YouTube within, I don't know, 24 hours, something like that, really surprisingly quickly.

22:35 So you don't feel like you have to attend every talk, right?

22:39 If there's something more interesting going on, don't feel like you're missing out, you just watch it later.

22:44 I think one of my number one recommendations, which he touches on, is open spaces.

22:48 - Yeah, that's actually something I didn't know about last year that I missed out on, so that's a good thing to, what are open spaces?

22:55 - There's a big board, and there's a bunch of rooms, and the rooms will hold like 20 to 50 people, And there's probably five to 10 of them.

23:03 I'm not sure exactly how many are available.

23:06 And there's parts of the conference where you can just--

23:10 anybody who wants to have a group conversation about something, they fill out a little three by five inch note, little card, and stick it up on the board and claim an hour in a room.

23:22 And then people just go and attend it like they would any other talk.

23:25 But it's much more high participation, because there's not a proper speaker.

23:29 You just have to basically kick off the conversation and then it's just like a group conversation.

23:34 - I think that's awesome because that's kind of what you go to PyCon for anyway, is to meet with people that have similar interests.

23:41 Not just Python as a whole, but specifically.

23:45 What specific parts of Python that you're interested in?

23:48 - Right, you might have like an IoT open space for people working with MicroPython.

23:54 Who knows, right?

23:55 That would be easily something you could put together.

23:58 The other thing is, all the talks are recorded, almost none of the open spaces are recorded.

24:02 So you can't make those up.

24:04 So that's one thing I really like to do.

24:06 And Trey goes into that a little bit.

24:07 He says they're often more niche and maybe something you're really focused on.

24:12 It's all about interaction and discussion and they're not recorded.

24:16 So he pretty much has the same thoughts I do.

24:18 He has some tips for conversation around breakfast, lunch, dinner.

24:22 Talks about the hallway track.

24:23 I'm a big fan of the hallway track, partly because the sessions are recorded, and partly the reason I go there is to meet people and to make connections and to have these interactions that I don't have outside of that space, right?

24:36 So I find almost always I'm having a great conversation with somebody and then I go, oh, the session's starting.

24:42 And they're like, you know what, forget the session.

24:43 I'll watch it on YouTube.

24:44 Let's keep going on whatever it is we're doing 'cause this is awesome, right?

24:47 And I find I spend the whole conference that way.

24:49 - Yeah, it would be lame if nobody went to the talks, though.

24:52 - No, I know.

24:53 - I'm gonna go to your talk, by the way.

24:55 (laughing)

24:57 - Okay.

24:57 - I guess more I'm saying, you're right, not everybody should just skip them all the time, 'cause then what would it be?

25:03 It wouldn't really be the same.

25:05 - Don't feel bad about it, yeah.

25:06 - Yeah, you don't have to skip every one of them.

25:10 If you will find yourself in a really interesting situation that you're enjoying, just 'cause it's time to go to the talks doesn't mean you have to go to the talks.

25:17 The other thing that I thought was interesting about this was this conversation, this concept of a Pac-Man opening in a group.

25:24 - Yeah, I love that.

25:25 - Yeah, so the idea is like, you know, think of Pac-Man, it's got the little open spot.

25:28 If you're in a group standing around, don't just like create a closed circle 'cause nobody can join or anything.

25:32 So always leave a little gap that says, you know, look for people or look for groups that have Pac-Man openings and make sure that your group always has a Pac-Man opening.

25:41 So that's pretty cool.

25:42 Some advice for interacting online during PyCon, how to make the most out of networking and it's not really a bad thing, things like that.

25:51 And also volunteering, there's lightning talks.

25:53 Have you given a lightning talk, Brian?

25:55 >>Not at PyCon.

25:56 >>Yeah, neither have I.

25:57 Yeah, it's just some general nice things.

25:59 And then finally, one I thought was interesting, there was a person who commented on the post saying, "If you're on Windows, it's helpful to install "a virtual machine image of Linux, "like the current Ubuntu on your laptop, "'cause you might run into a situation, "a talk or a training where something they're talking about "doesn't work on Windows, and you might miss out." That's both an opportunity for us to make the Windows experience better, but also maybe good advice for the first person, you know, coming in with your Surface tablet.

26:27 You might wanna come prepared, I guess.

26:29 Or install Anaconda, something like that.

26:31 - Yeah, so one of the things I wanted to bring up that I didn't know about ahead of time is there's certain sections of the day that is recommended that there isn't, or there aren't any talks scheduled, but what is the other floor called?

26:44 The place where we're at, the conference hall or the--

26:46 - The expo hall. - The expo hall.

26:48 But the expo hall is pretty much open all the time.

26:51 So during a talk, if there's somebody that you wanted to meet up, meet, or a company you wanted to talk to or something, that you can't get to 'em because there's so many people during the normal expo times, skipping one of the talks and going during a talk time, there's way less people in the expo hall and you might be able to catch up with somebody a lot easier.

27:10 - That's great advice, yeah, definitely.

27:12 So I think that leads us really well into our own news.

27:16 What do you think, Brian?

27:17 - Yeah, so you brought up my talk.

27:18 I do have a talk Friday, and I actually forgot the time.

27:22 It's at five something.

27:23 - It's to do with testing, and you're giving that co-presenting with Paul Everett, right?

27:28 - Yeah, Paul Everett and I are going to, so I love pytest, of course, but I also have, in this last year, fallen in love with PyCharm, so we're going to do them together.

27:40 We're gonna show you how to be efficient and effective, and speed up your test and development time with PyCharm and pytest, it'll be fun.

27:47 - Your chocolates and my peanut butter.

27:49 - Yeah. (laughs)

27:51 - That is awesome.

27:52 And we have a booth, you and I and a few others have a booth, I forgot the number, but you'll find us, it's pretty easy, right?

28:00 - Yeah.

28:01 - And we have stickers.

28:02 - Yeah, I just got my stickers this morning, so yeah, I'll be ready.

28:05 - Yeah, it's gonna be a lot of fun.

28:06 I'm really looking forward to meeting people, so I hope everyone comes and says hello.

28:10 - Yeah.

28:11 - That should be awesome.

28:11 And then, another thing, we talked about the open session.

28:15 Are we planning on doing a live Python Bytes recording?

28:18 - Why not try?

28:18 Let's do it, yeah.

28:19 - Let's give it a try.

28:20 So I think we're gonna do an open session, live, the next Python Bytes is coming to you live from PyCon.

28:28 It probably won't be streamed live.

28:29 Maybe we'll stream it live.

28:30 I don't know if we can get the audio to work for that.

28:32 But we'll do what we can to do a live Python Bytes and then make that the show for next week.

28:39 So if people wanna get notified, they wanna make sure they don't miss the time 'cause because it's an open session, We can't pre-schedule it, right?

28:46 We have to go find a slot on that wall there.

28:50 So people just go to Pythonbytes.fm at the top menu bar, click Friends of the Show, and sign up there.

28:54 Then I'll send out an email once we have that time figured out that day.

28:59 I'm thinking Saturday would probably be best.

29:01 - Yeah, I think so.

29:02 - Yeah, okay.

29:03 So sometime on Saturday if we can pull that off.

29:05 So that would be awesome.

29:06 Hopefully as many people can come to that, that'd be fun.

29:09 See how the sausage is made.

29:11 Also, I'm just in a couple days leaving for Seattle.

29:15 I'm gonna be at Microsoft Build.

29:17 - How neat.

29:17 - Yeah, that'll be really interesting.

29:19 Hang out with some of the Python folks there.

29:21 If you're at Microsoft Build and you wanna come say hi, just shoot me a message on Twitter or something and if we're there together, it'd be great.

29:28 PyGotham, the New York City PyCon, effectively, has just opened their call for proposals.

29:34 And PyCon DE, which is held in Karlsruhe, Germany, which is a wonderful part of Germany, very beautiful, is also just opening their call for proposals as well, and that's running 24th to 26th in October in Germany.

29:51 So, a lot of conference stuff.

29:53 It's like conference time.

29:54 - Yeah.

29:55 - Yeah, we have Google I/O, we have Microsoft Build, and we have PyCon all next week.

29:59 It's like they're fighting for attention.

30:02 - Yeah.

30:03 - Awesome, all right, well, anything else, Brian?

30:05 Have we covered it all?

30:06 - Yeah, I think we did.

30:07 - All right, well, wonderful.

30:08 Well I'm looking forward to seeing you at PyCon, that'll be fun.

30:11 Yeah, it'll definitely be fun.

30:12 Thanks.

30:13 Yeah, and all the listeners, yep, talk to you later.

30:15 Thank you for listening to Python Bytes.

30:17 Follow the show on Twitter via @pythonbytes, that's Python Bytes as in B-Y-T-E-S.

30:23 And get the full show notes at pythonbytes.fm.

30:26 If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

30:31 We're always on the lookout for sharing something cool.

30:33 On behalf of myself and Brian Okken, this is Michael Kennedy.

30:37 Thank you for listening and sharing this podcast with your friends and colleagues.