Welcome to the first episode of a new podcast focused on bringing you the stories of the people who make the Python language and ecosystem great.
Outline
The intro and outro music is from
Requiem for a Fish (The Freak Fandango Orchestra) / CC BY-SA 3.0
Outline
- Introduction
- Brief Host Biographies
- Why We’re Doing This
- Why We Love Python & Favorite Tools
- Thank You
- Picks!
The intro and outro music is from
Requiem for a Fish (The Freak Fandango Orchestra) / CC BY-SA 3.0
[00:00:14]
Unknown:
Greetings, and welcome to podcast.init. News, views, and reviews on Python and the people who use it. I'm Tobias Macy.
[00:00:22] Unknown:
And I'm Chris Patti. In this first episode, episode, we'd like to briefly introduce the show, who we are, where we're coming from, and what we hope to bring to the table in the coming episodes. Tobias, why don't you start us off with a bit about you?
[00:00:34] Unknown:
Thank you, Chris. I'm a software and systems engineer currently living and working in Northern New Hampshire for a startup based in Boston. I also do freelance work on the side, and when I'm not working or hacking on side projects, I like to go on adventures with my family. You can find me on Twitter at at tobiasmacy, or you can read my blog at renaissancedev.com.
[00:00:55] Unknown:
Wow. You got a lot going on. I'm a senior software engineer for a Boston based online backup company, and I live in Somerville. I'm a process automation junkie and had been for 25 years. Lately, I've been loving my work in infrastructure as code space using tools like Chef, Ruby, and most recently Python. You can find me on Twitter as at Theo, that's f e o h, or read my blog at Theo dot org.
[00:01:21] Unknown:
We realize that while there are innumerable podcasts available that address a wide swath of the software engineering landscape, there was a glaring absence of any that covered Python. The few that we did find are no longer producing any new content, so we decided that it was our duty to the community to remedy the situation. Starting now, at least once a month, we will be bringing you news and opinions on the Python ecosystem and interviews with the people who are working on the front lines, building the tools and toys that we use every day. Chris, why don't you tell us a bit about what you like so much about Python and maybe some of the, tools that you particularly like to take advantage of?
[00:01:57] Unknown:
Yeah. Sure. So, I mean, I've been a a Rubyist. I mean, I a scripter in general for for many years. I I started out writing shell scripts back in the dark ages with, you know, dinosaurs roaming the earth, and moved on to Pearl. And so a real, you know, modern dynamic object oriented language like Ruby was like a was like a breath of fresh air. And fast forward quite a number of years working for my current gig in the interest of the Python. And, you know, it it's it's really I kind of feel like the the sort of partisanship involved in the 2 camps is unfortunate because both languages are awesome and have a tremendous amount to bring to the table. There's a lot going on in each each ecosystem that that, really is to be, you know, played with and recommended.
I think a couple of things that that I'm really impressed with in the in the Python space are are IPython notebook. There's nothing like it that I've seen, you you know, in the rest of community, computing really, in the sense that, you know, you you can create all these amazing interactive presentations or classes or whatever and share them around, and it's, you know, they're so accessible. It's a it's a web browser, so virtually anybody can can get to it. It's just an amazing tool, And I really like, the the various Python modes that go with, with Vim, the the Vim rope pardon me, I believe it's rope Vim mode and things like that. It really makes for you know, it's just an editor. It's not an IDE, but it makes for an incredibly rich programming environment.
[00:03:38] Unknown:
Great. Yeah. Totally in agreement with you about the, sort of zealousness that goes along with a lot of programming communities and particularly the, some of the shots that are fired across the bow between Python and Ruby. Although I have noticed a lot of times too where both communities like to borrow ideas from each other. For instance, there's the the whole idea of the Gherkin format and cucumber behavior driven development that seems to have started mainly in the Ruby camp has definitely come over to the Python side. I've seen it in a few places, and they're I actually recently came across a tool called I believe it was called Bundler that is a Python version of Bundler, essentially, that Oh, that's really cool. Yeah. It gives you a really sort of a different, different approach to managing your dependencies than our typical virtual ends that takes a lot of ideas from bundler and seems to do a pretty good job of executing on that.
I will say 1 of the things that I do love the most about Python is the really strong focus on being explicit in what you're doing, particularly in terms of name spacing. That's 1 thing that I found somewhat lacking in the Ruby communities or the Ruby programming language is the namespacing capabilities leave a bit to be desired. So sometimes it can be somewhat easy to pollute your namespace, whereas in Python, there's a very strong focus on making sure that every time you are dealing with some something that is brought into your namespace, you can fairly easily go back and see where it came from and see what things might possibly be overriding it as well.
[00:05:12] Unknown:
Absolutely. I mean, the name spacing thing is a definite issue. It's, you know, it's interesting that you point out the, explicitness of Python. As a long time, Ruby is coming to Python. That's 1 of the things that actually kinda threw me initially was, like, even something as simple as lack of implicit returns. You know, some of the people that we worked with at, at our last well, I guess not our last, but at the previous gig that we worked together on, really had sort of inculcated me into this idea, this almost school of thought that code should read, you know, almost like English and be very, very terse and, you know, functions should be as small as they possibly can. And Python really kind of rejects that wholesale, you know, coming to Python and trying to write little functions is something as simple as can you find this substring in another string. And if you don't put the return in, it's the function's not gonna do what you want, and you're gonna get none back. And as as a Rubyist, that really took me by surprise, but I can totally see the advantages to being explicit. It's just it's really 1 of the things I think people should really consider, you know, there's been a lot of talk lately about, oh, if you're gonna learn another language in your in your Rubyist, you should go learn closure or or Haskell or something. And and those are awesome languages and you definitely should, but I think sometimes even just sort of going, you know, going for a dive into a completely different idiom can be really, mind expanding and instructive as well.
[00:06:40] Unknown:
Yeah. Definitely in agreement there. There's definitely a lot to be learned by learning a language that has a totally different take on how to go about doing things. Another thing I'll say I do love a lot about Python is some of the conventions in terms of managing your code layout itself, particularly PEP 8 really makes it easier to get into you know, to to just jump into a new code base without having to try and figure out, okay, what is the
[00:07:05] Unknown:
particular style guide that this person decided to adhere to? Yeah. I totally agree. PEP 8 is great. I really I really do love it. I I mean, 1 the 1 kind of beef I have with PEP 8 is I think an 80 character line limit just makes it really tough. If you're using, you know, nice descriptive variable names and, you know, at all complex literal data structures, it can get to the point where it's like I'm doing yoga with my source code to get it to make fit into the 80 character line limit. So at my shop, we've decided that a 120 characters is is a more reasonable stance to take.
[00:07:40] Unknown:
Yeah. So that's what we've settled on where I'm working right now as well. We're focusing on trying to maintain a 120 character limit. Although, I will say that having the 80 character line lengths, while it can sometimes become a little bit difficult to try and manage keeping it within that limit, A lot of times, it can actually be a good guide as well to letting you know when you should sort of refactor a function. Because if you're starting to nest things so deeply that you can't stay within 80 characters, then it suggests maybe you should break some of that out into separate functions so that it's more easily so it's easier to reason about.
[00:08:14] Unknown:
That's very true. It's it's kinda funny. It's something that I've learned being in the business for as many years as I have is, you know, what's old is new. I I can't help but think back to, who's the guy who invented 4th? I can't remember his name at the moment. It might be Charles Moore, actually, talking about how, you know, all your your 4th, words should be no more than a screen in in length. It's kinda like, you know, keep things short, keep things concise, keep keep things very sort of minimalistic. That idea really seems to to carry a lot of weight and be applicable as we move forward into, you know, newer and higher level languages.
[00:08:51] Unknown:
Yep. Yeah. And 1 thing too that PEP 8 seems to foster is is, shorter names for things, whereas in Ruby and particularly in Java, a lot of the names can become very verbose. Whereas in Python, I generally have noticed that the names are a bit shorter. And I think part of that is to adhere to PEP 8 so that you're not taking up a huge portion of your line just in the, you know, name of a variable or a or a method call.
[00:09:17] Unknown:
You know what, Dwight? I have to say I don't I mean, and maybe this is just a matter of I'm I'm still relatively new to Python. I've only been using it for about 6 months, but I think descriptive variable names are a good thing. Like I mean I cannot tell you how many times I've been staring at source code and I'd see this thing that says like PTR and it's like well what the heck is a PTR and especially in a dynamic language like Python I feel like and or Ruby for that matter, I feel like really descriptive variable names are an asset. But again, maybe that's because I I I haven't fully, you know, fully partaking of the Kool Aid and and and maybe I'll come around. I don't know.
[00:09:54] Unknown:
I'm I'm totally in agreement with you about the utility of descriptive So, yes So, yes, it can occasionally become confusing as to what people are intending to refer to, but it's just 1 of the 1 of those dangers of working in the world that we work in. Another thing that I really like about Python is the strong focus on documentation, particularly the fact that the language itself has has capabilities built in to very easily document what methods, you know, to add documentation to methods. And there's a very strong convention around the syntax that you should use for stating, in particular, what the inputs of a function are and what the expected return values.
And then also another really great add on to that is the whole doc test module where you can actually write some simplistic tests in line in your documentation. So it serves dual duty as both an example of how to use a particular method, but then it also lets you go back and use that same documentation to validate that the method is doing what it's supposed to do without necessarily having to pull that out into a separate unit test. Although you should certainly do that as well. No. I I definitely totally agree. I think that's 1 of the big problems with the Ruby community
[00:11:14] Unknown:
is this whole sort of mantra of use the source, Luke. You know, it's like it's it's fine, but when you find yourself hip deep in a really mature Ruby module or gem, it can be really, really hard figure out what's going on. Like, I remember in particular, the job we both worked at, I was trying to use a particular feature of fog, which is an awesome, Ruby gem for working with cloud, functionality. And I just I couldn't understand how it was trying to work. And and, you know, the people that we worked with at time were just like, well, just, you know, go read the source. And I'm sitting there staring at this source and and I totally agree with you. The fact that not only not only does Python provide really strong documentation support, but all the tool all the tooling around it really sort of, like, basically will even tell you, you know, hey, you don't you didn't have a doc string there in that method. So it really makes it easy and and you're goaded into making your workflow include that, and I think that's such a huge help to provide that kind of crumb trail for programmers who might want to use your work going forward. I I totally agree that is that's definitely a feature. No question. Yep. Yeah. And having it in line with the code as well makes it a lot easier to prevent it from drifting
[00:12:32] Unknown:
away from what the actual code is doing. Because if you're working in the method, it becomes almost trivial to just scroll up a little ways and edit the docstring as well since you're already in the source. So rather than having it as a you know, in in a separate file or even just having it above the method definition sometimes can just make it seem a little bit more separate. Whereas if because the documentation starts at the line just below the def of what the function or class name is, it just really encourages you to think of it as 1 unit, both the documentation and the code.
[00:13:07] Unknown:
Exactly. Totally
[00:13:10] Unknown:
agree. Shall we move on to PIX? Sure. Yeah. So I'd like to thank everyone for staying with us through our introductory episode. And as Chris mentioned, now we're gonna go to some pics. So Chris, why don't you start us off?
[00:13:21] Unknown:
Okay. I'm gonna borrow the convention from, Avdi Grimm, 1 of the Ruby rogues. I totally have to give them a shout out because as far as I'm concerned, you know, they are watching them evolve from the beginning to where they are today. I've kinda learned a lot about how to, you know, what I like in building a technical podcast. And so I'll have 1 tech pick and 1 non tech pick. My tech pick is a tool that was released without much fanfare, but that when I saw it, I was kinda blown away and I thought this is something I really wanna explore. It's called PT Python and we will, have the links for these tools up in the on the episode, page when we get that up.
What's kind of amazing about it is it's kind of like a better IPython. It has all the interactive capabilities of IPython and in fact even has an IPython compatibility mode so you can use all your tooling and such with it. But what's amazing about it is that it provides almost IDE like curses based object method and etcetera. You know all the good completion goodies. So that as you're typing, you know, you don't have to get the exact name of something right. You can just hit tab or whatever and and boom, you have a nice cursors completion list up there to to to help you get get to the right place.
And that's just scratching the surface. It has a tremendous number of of really great innovative interactive features and it's just a great interactive tool. And I and I really think that having a rich REPL to play around in is 1 of the really awesome things about dynamic languages. You know, I cannot tell you how amazing it is after working in languages like Java, where until very recently you could not just pop into a prompt and try out some expressions like that is my workflow. When I'm trying to understand how to build something or even trying to understand how to use other people's code, I need to be able to just like pull it in and pop it up and sort of try and, you know, a few invocations to see like what parameters does it want to take, what does it do, how does it behave.
That kind of Play Doh phase as I like to call it is is is a really, it's something I'm I'm I find very hard to live without and PT Python just makes it a joy. So my non technical pick, I'm gonna pick a beer because I like good beer. And so I'm going to pick, Duchess de Bourgogne. I don't know if I'm pronouncing that quite right. It's spelled b o u r g o g n e. It's the Burgundy region. And it's just it's a it's considered to be a Flemish sour. I I like sour beers because for a long time I sort of like most people tried the the traditional sort of like what we'd seen porters, stouts, IPAs and the like and and, lager's and eels obviously.
And the sour is just a completely different animal. You know, it it is what it says. It is it is a sour flavor. But to say that it's not like sucking on a lemon, there's a tremendous amount of complexity there. It's like a little bit sweet, a little bit fruity. It just has a tremendous amount of depth. And I really recommend that if you're an open minded person and you like good beer and you're looking to try something new, it's definitely worth hunting down. It's even good. It's it's even full bodied and strong enough that they can take being bottled. So if you don't have a not aren't lucky enough to live in a city and have a a beer establishment near you that will serve it on tap, The bottle is certainly a fine way to give it a try.
And I really like it. It's my favorite sour beer that I've ever tried. There's been a couple of others that I also enjoyed, but the majority of them that I encounter are kind of 1 note. They are sour, which is nice, but they lack that sort of depth and complexity, complexity that the Duchess provides. I think that's it for me. Great.
[00:17:14] Unknown:
I'm gonna second your pick on PT Python. I came across that recently, and I've been using it a bit. And it definitely is a superb REPL. I've been a long time user of IPython as my standard REPL when I'm doing development, and pt Python really just takes that up a notch and just adds some extra utility to what IPython already offered. So thank you for bringing that 1 up. So my picks this time are going to be to start with, there's a database management tool called DBeaver that I've start that I started using. I use Linux on my machine at home and for work. And for a long time, I've been hunting for a really good cross database, just GUI tool to work in so that I could not necessarily have to tie myself to using pgAdmin when I'm using Postgres or the MySQL admin when I'm using MySQL. Just having 1 tool that'll let me connect to a number of different databases without, you know, 1 that's free and open source and 1 that isn't hamstrung by an open core kind of model, and DBeaver just really has everything that I could ever want.
So I'll have the link to that in the show notes. Another tool
[00:18:22] Unknown:
Oh, I'm I'm really sorry. I didn't mean to interrupt, but but Dbeaver, that's really funny that you had mentioned that tool because I, you know, I'm mostly a Mac guy, but lately at work, I I just sort of the the company that I'm working for now is largely a Linux and Windows shop. And so my desktop at work is a Linux box. And so I've been sort of, like, moving in there, adjusting the drapes, and figuring out where all the furniture is and how I like things. And 1 of the things that I had been struggling with is, you know, the shot we were a Windows shop before my group came in and started transitioning things to Linux. And, so they have a tremendous number of Microsoft SQL Server databases. And d beaver is 1 of the only cross platform clients that let me work with that as well as the, you know, my SQL databases that we use. So that's very cool. I like it as well. I think it's a really good tool. And and, now that I really used to like Aqua's Data Studio, Aqua Data Studio, but now that's gone commercial and and a pretty hefty price tag, like $500 a license or something. So Yep. DBeaver is great. Definitely second that. Yeah. I I used to use Aqua Data Studio as well at a previous job where they paid for the license. But,
[00:19:32] Unknown:
yeah, have having an open source offering that really has a lot of really good functionality and the capability to attach to a large number of databases, including even, MongoDB and, I believe, Cassandra as well. Oh, cool. Just yeah. Real really really great tool. Another thing that I've been using recently is a tool called KDE Connect. So it's both a desktop application for the KDE desktop environment and an Android application. And what it does is it lets you link up your desktop and your Android device whenever they're on the same wireless network so that you can actually get notifications from your device that show up in your desktop notification panel.
It lets you have 2 way copy paste between devices. So I can copy something on my desktop and then paste it into something on my tablet. It also lets you use your tablet as a, essentially, as a trackpad, so you can use your tablet to move your mouse around and click on things. You can also use your tablet to type on your computer. So So it's just a really great, really interesting tool from the folks who build kde who if you're not using kde and have never tried definitely recommend that you at least take a look, particularly in its latest incarnation with the, with the new Plasma 5 desktop,
[00:20:52] Unknown:
really slick. Oh, I totally agree. As a matter of fact, when you may have seen me sort of ranting and whining and and piteously flailing on on, Twitter. When I first tried to set my desktop up with, with Linux again, it's been a long time since I've worked on the Linux desktop. Like, just to give you a sense, I think the last Linux desktop I ran had, f b w m, I think, as it's it was back when they weren't desktops, pardon me, Ubuntu on my box, and they have their own, pardon me, Ubuntu on my box, and they have their own desktop manager. I think it's Unity, actually. Yep. And it's I really applaud the way that the direction they're trying to go in with it. I think it's a really great tool, but it just lacks so much of the polish of the KDE folks have really put into play with with their desktop.
Particularly I'm partially blind. So excuse me, the handicap accessibility features are absolutely critical for me. And I was finding myself really struggling with things like I can't adjust the system fonts for the icons or the menu items or or anything for that matter of the desktop. So I'm sitting here dealing with massive eye strain issues by the end of the day because I can't see the tools that I'm trying to work with. And KDE is just man, their stuff is is slicker than snot to use a perhaps, somewhat launchy phrase, like everything is configurable right down to the nines.
It's very clear and straightforward most of the time how to get everything to work within the desktop itself. And I've been loving it. The only thing that I will say and this this is less to do about Katie and more to do about Linux is I still feel like the Linux community needs to figure out needs to agree upon a standard for like app and desktop interoperability, something as silly as, okay, you know, I listen to Spotify all day most of the time, and I would love to be able to find a way to, from wherever I am, control the volume of my Spotify, clients and and be able to, like, fast forward and rewind songs and the like. Doing that on the Mac is super trivial because of AppleScript.
You know, as as much of an ugly duckling as it is, it it really is like duct tape. It binds the entire Apple environment together and you can control virtually anything with, you know, with anything with it. And so you get these awesome tools like Quicksilver and Alfred and I can make my entire environment to the tune that I want it to and it's really trivial. But I'm in the Linux world. It was kind of it was kind of a, you know, spelunking expedition to figure out if it was even possible. And when I got it to work, it was a great deal of effort. So I feel like, you know, they've come a long way. KBE especially is just amazing. And I wish that they would go that extra 15 yards to cross the finish line. They could make the Linux desktop into a really amazing environment that I could recommend without without any caveats at all.
[00:24:00] Unknown:
Sure. And, that sort of leads me to a bonus pick. There's a library called player control, playerctl, that lets you really easily bind media keys to play, pause, stop, next track, and backtrack actions that will actually execute on Spotify. So that's what I use on my desktop for controlling the playback of Spotify when I'm listening to it.
[00:24:26] Unknown:
Nice. That's I will I will definitely check that out because I I gotta admit, like, it's so hard. I'm sitting there at work and I'm working away and I'm in my editor and someone walks over and it's like, well, hold on. I have to pause my music and I have to, like, flail flail flail for the, you know, for the app and the and the and the write everything when really I just wanna be able to get a key. So I will check that out. Thank you. Yep. And, so for my last pick today,
[00:24:48] Unknown:
I'm going to go with a nontechnical pick. There's a board game I picked up a little while ago and I've had a chance to play a few times called summoner wars. And for anyone who hasn't heard of it, my best way to describe it is somewhat of a cross between Magic the Gathering and chess.
[00:25:05] Unknown:
Oh, wow.
[00:25:06] Unknown:
So the way that it works is you have different decks that correspond to different factions, and you play it on a physical board. So you play you know, you you place the cards on the board. Each deck has a certain setup that it begins with. And then there's a summoner for each faction, which is essentially the king in the chess analogy. So the object of the game is to destroy the opponent's summoner. And in order to do so, you have units that you can move around the board that have the ability to attack. Some of them are ranged units, some of them require to be adjacent to the unit they're attacking. And there are also effect cards, which add effects.
For instance, 1 effect might limit the movement capability that your opponent has on their next turn. So rather than being able to move 2 spaces with a unit card, they can only move 1. So it's just a really interesting combination of game styles, and, it's really well executed. They've also done a good job of adding some expandability to it with additional factions that you can purchase to add some add some variety to the gameplay. So definitely worth checking out and again we'll put the links to that show notes. That sounds awesome. So that is all I have for picks for today. So, Chris, I would like to thank you very much for joining me. And everyone who's listening, I'd like to thank you very much for taking the time out of your day to listen to us ramble on for a bit. And we will be back as soon as possible with our next episode. So thank you very much.
[00:26:40] Unknown:
Absolutely. We've got some we've got some great ideas in the incubator, and hopefully we'll we'll be back soon with, some interviews and and a a more fully fully stocked episode the way we hope to run them. Thanks a bunch, folks.
Greetings, and welcome to podcast.init. News, views, and reviews on Python and the people who use it. I'm Tobias Macy.
[00:00:22] Unknown:
And I'm Chris Patti. In this first episode, episode, we'd like to briefly introduce the show, who we are, where we're coming from, and what we hope to bring to the table in the coming episodes. Tobias, why don't you start us off with a bit about you?
[00:00:34] Unknown:
Thank you, Chris. I'm a software and systems engineer currently living and working in Northern New Hampshire for a startup based in Boston. I also do freelance work on the side, and when I'm not working or hacking on side projects, I like to go on adventures with my family. You can find me on Twitter at at tobiasmacy, or you can read my blog at renaissancedev.com.
[00:00:55] Unknown:
Wow. You got a lot going on. I'm a senior software engineer for a Boston based online backup company, and I live in Somerville. I'm a process automation junkie and had been for 25 years. Lately, I've been loving my work in infrastructure as code space using tools like Chef, Ruby, and most recently Python. You can find me on Twitter as at Theo, that's f e o h, or read my blog at Theo dot org.
[00:01:21] Unknown:
We realize that while there are innumerable podcasts available that address a wide swath of the software engineering landscape, there was a glaring absence of any that covered Python. The few that we did find are no longer producing any new content, so we decided that it was our duty to the community to remedy the situation. Starting now, at least once a month, we will be bringing you news and opinions on the Python ecosystem and interviews with the people who are working on the front lines, building the tools and toys that we use every day. Chris, why don't you tell us a bit about what you like so much about Python and maybe some of the, tools that you particularly like to take advantage of?
[00:01:57] Unknown:
Yeah. Sure. So, I mean, I've been a a Rubyist. I mean, I a scripter in general for for many years. I I started out writing shell scripts back in the dark ages with, you know, dinosaurs roaming the earth, and moved on to Pearl. And so a real, you know, modern dynamic object oriented language like Ruby was like a was like a breath of fresh air. And fast forward quite a number of years working for my current gig in the interest of the Python. And, you know, it it's it's really I kind of feel like the the sort of partisanship involved in the 2 camps is unfortunate because both languages are awesome and have a tremendous amount to bring to the table. There's a lot going on in each each ecosystem that that, really is to be, you know, played with and recommended.
I think a couple of things that that I'm really impressed with in the in the Python space are are IPython notebook. There's nothing like it that I've seen, you you know, in the rest of community, computing really, in the sense that, you know, you you can create all these amazing interactive presentations or classes or whatever and share them around, and it's, you know, they're so accessible. It's a it's a web browser, so virtually anybody can can get to it. It's just an amazing tool, And I really like, the the various Python modes that go with, with Vim, the the Vim rope pardon me, I believe it's rope Vim mode and things like that. It really makes for you know, it's just an editor. It's not an IDE, but it makes for an incredibly rich programming environment.
[00:03:38] Unknown:
Great. Yeah. Totally in agreement with you about the, sort of zealousness that goes along with a lot of programming communities and particularly the, some of the shots that are fired across the bow between Python and Ruby. Although I have noticed a lot of times too where both communities like to borrow ideas from each other. For instance, there's the the whole idea of the Gherkin format and cucumber behavior driven development that seems to have started mainly in the Ruby camp has definitely come over to the Python side. I've seen it in a few places, and they're I actually recently came across a tool called I believe it was called Bundler that is a Python version of Bundler, essentially, that Oh, that's really cool. Yeah. It gives you a really sort of a different, different approach to managing your dependencies than our typical virtual ends that takes a lot of ideas from bundler and seems to do a pretty good job of executing on that.
I will say 1 of the things that I do love the most about Python is the really strong focus on being explicit in what you're doing, particularly in terms of name spacing. That's 1 thing that I found somewhat lacking in the Ruby communities or the Ruby programming language is the namespacing capabilities leave a bit to be desired. So sometimes it can be somewhat easy to pollute your namespace, whereas in Python, there's a very strong focus on making sure that every time you are dealing with some something that is brought into your namespace, you can fairly easily go back and see where it came from and see what things might possibly be overriding it as well.
[00:05:12] Unknown:
Absolutely. I mean, the name spacing thing is a definite issue. It's, you know, it's interesting that you point out the, explicitness of Python. As a long time, Ruby is coming to Python. That's 1 of the things that actually kinda threw me initially was, like, even something as simple as lack of implicit returns. You know, some of the people that we worked with at, at our last well, I guess not our last, but at the previous gig that we worked together on, really had sort of inculcated me into this idea, this almost school of thought that code should read, you know, almost like English and be very, very terse and, you know, functions should be as small as they possibly can. And Python really kind of rejects that wholesale, you know, coming to Python and trying to write little functions is something as simple as can you find this substring in another string. And if you don't put the return in, it's the function's not gonna do what you want, and you're gonna get none back. And as as a Rubyist, that really took me by surprise, but I can totally see the advantages to being explicit. It's just it's really 1 of the things I think people should really consider, you know, there's been a lot of talk lately about, oh, if you're gonna learn another language in your in your Rubyist, you should go learn closure or or Haskell or something. And and those are awesome languages and you definitely should, but I think sometimes even just sort of going, you know, going for a dive into a completely different idiom can be really, mind expanding and instructive as well.
[00:06:40] Unknown:
Yeah. Definitely in agreement there. There's definitely a lot to be learned by learning a language that has a totally different take on how to go about doing things. Another thing I'll say I do love a lot about Python is some of the conventions in terms of managing your code layout itself, particularly PEP 8 really makes it easier to get into you know, to to just jump into a new code base without having to try and figure out, okay, what is the
[00:07:05] Unknown:
particular style guide that this person decided to adhere to? Yeah. I totally agree. PEP 8 is great. I really I really do love it. I I mean, 1 the 1 kind of beef I have with PEP 8 is I think an 80 character line limit just makes it really tough. If you're using, you know, nice descriptive variable names and, you know, at all complex literal data structures, it can get to the point where it's like I'm doing yoga with my source code to get it to make fit into the 80 character line limit. So at my shop, we've decided that a 120 characters is is a more reasonable stance to take.
[00:07:40] Unknown:
Yeah. So that's what we've settled on where I'm working right now as well. We're focusing on trying to maintain a 120 character limit. Although, I will say that having the 80 character line lengths, while it can sometimes become a little bit difficult to try and manage keeping it within that limit, A lot of times, it can actually be a good guide as well to letting you know when you should sort of refactor a function. Because if you're starting to nest things so deeply that you can't stay within 80 characters, then it suggests maybe you should break some of that out into separate functions so that it's more easily so it's easier to reason about.
[00:08:14] Unknown:
That's very true. It's it's kinda funny. It's something that I've learned being in the business for as many years as I have is, you know, what's old is new. I I can't help but think back to, who's the guy who invented 4th? I can't remember his name at the moment. It might be Charles Moore, actually, talking about how, you know, all your your 4th, words should be no more than a screen in in length. It's kinda like, you know, keep things short, keep things concise, keep keep things very sort of minimalistic. That idea really seems to to carry a lot of weight and be applicable as we move forward into, you know, newer and higher level languages.
[00:08:51] Unknown:
Yep. Yeah. And 1 thing too that PEP 8 seems to foster is is, shorter names for things, whereas in Ruby and particularly in Java, a lot of the names can become very verbose. Whereas in Python, I generally have noticed that the names are a bit shorter. And I think part of that is to adhere to PEP 8 so that you're not taking up a huge portion of your line just in the, you know, name of a variable or a or a method call.
[00:09:17] Unknown:
You know what, Dwight? I have to say I don't I mean, and maybe this is just a matter of I'm I'm still relatively new to Python. I've only been using it for about 6 months, but I think descriptive variable names are a good thing. Like I mean I cannot tell you how many times I've been staring at source code and I'd see this thing that says like PTR and it's like well what the heck is a PTR and especially in a dynamic language like Python I feel like and or Ruby for that matter, I feel like really descriptive variable names are an asset. But again, maybe that's because I I I haven't fully, you know, fully partaking of the Kool Aid and and and maybe I'll come around. I don't know.
[00:09:54] Unknown:
I'm I'm totally in agreement with you about the utility of descriptive So, yes So, yes, it can occasionally become confusing as to what people are intending to refer to, but it's just 1 of the 1 of those dangers of working in the world that we work in. Another thing that I really like about Python is the strong focus on documentation, particularly the fact that the language itself has has capabilities built in to very easily document what methods, you know, to add documentation to methods. And there's a very strong convention around the syntax that you should use for stating, in particular, what the inputs of a function are and what the expected return values.
And then also another really great add on to that is the whole doc test module where you can actually write some simplistic tests in line in your documentation. So it serves dual duty as both an example of how to use a particular method, but then it also lets you go back and use that same documentation to validate that the method is doing what it's supposed to do without necessarily having to pull that out into a separate unit test. Although you should certainly do that as well. No. I I definitely totally agree. I think that's 1 of the big problems with the Ruby community
[00:11:14] Unknown:
is this whole sort of mantra of use the source, Luke. You know, it's like it's it's fine, but when you find yourself hip deep in a really mature Ruby module or gem, it can be really, really hard figure out what's going on. Like, I remember in particular, the job we both worked at, I was trying to use a particular feature of fog, which is an awesome, Ruby gem for working with cloud, functionality. And I just I couldn't understand how it was trying to work. And and, you know, the people that we worked with at time were just like, well, just, you know, go read the source. And I'm sitting there staring at this source and and I totally agree with you. The fact that not only not only does Python provide really strong documentation support, but all the tool all the tooling around it really sort of, like, basically will even tell you, you know, hey, you don't you didn't have a doc string there in that method. So it really makes it easy and and you're goaded into making your workflow include that, and I think that's such a huge help to provide that kind of crumb trail for programmers who might want to use your work going forward. I I totally agree that is that's definitely a feature. No question. Yep. Yeah. And having it in line with the code as well makes it a lot easier to prevent it from drifting
[00:12:32] Unknown:
away from what the actual code is doing. Because if you're working in the method, it becomes almost trivial to just scroll up a little ways and edit the docstring as well since you're already in the source. So rather than having it as a you know, in in a separate file or even just having it above the method definition sometimes can just make it seem a little bit more separate. Whereas if because the documentation starts at the line just below the def of what the function or class name is, it just really encourages you to think of it as 1 unit, both the documentation and the code.
[00:13:07] Unknown:
Exactly. Totally
[00:13:10] Unknown:
agree. Shall we move on to PIX? Sure. Yeah. So I'd like to thank everyone for staying with us through our introductory episode. And as Chris mentioned, now we're gonna go to some pics. So Chris, why don't you start us off?
[00:13:21] Unknown:
Okay. I'm gonna borrow the convention from, Avdi Grimm, 1 of the Ruby rogues. I totally have to give them a shout out because as far as I'm concerned, you know, they are watching them evolve from the beginning to where they are today. I've kinda learned a lot about how to, you know, what I like in building a technical podcast. And so I'll have 1 tech pick and 1 non tech pick. My tech pick is a tool that was released without much fanfare, but that when I saw it, I was kinda blown away and I thought this is something I really wanna explore. It's called PT Python and we will, have the links for these tools up in the on the episode, page when we get that up.
What's kind of amazing about it is it's kind of like a better IPython. It has all the interactive capabilities of IPython and in fact even has an IPython compatibility mode so you can use all your tooling and such with it. But what's amazing about it is that it provides almost IDE like curses based object method and etcetera. You know all the good completion goodies. So that as you're typing, you know, you don't have to get the exact name of something right. You can just hit tab or whatever and and boom, you have a nice cursors completion list up there to to to help you get get to the right place.
And that's just scratching the surface. It has a tremendous number of of really great innovative interactive features and it's just a great interactive tool. And I and I really think that having a rich REPL to play around in is 1 of the really awesome things about dynamic languages. You know, I cannot tell you how amazing it is after working in languages like Java, where until very recently you could not just pop into a prompt and try out some expressions like that is my workflow. When I'm trying to understand how to build something or even trying to understand how to use other people's code, I need to be able to just like pull it in and pop it up and sort of try and, you know, a few invocations to see like what parameters does it want to take, what does it do, how does it behave.
That kind of Play Doh phase as I like to call it is is is a really, it's something I'm I'm I find very hard to live without and PT Python just makes it a joy. So my non technical pick, I'm gonna pick a beer because I like good beer. And so I'm going to pick, Duchess de Bourgogne. I don't know if I'm pronouncing that quite right. It's spelled b o u r g o g n e. It's the Burgundy region. And it's just it's a it's considered to be a Flemish sour. I I like sour beers because for a long time I sort of like most people tried the the traditional sort of like what we'd seen porters, stouts, IPAs and the like and and, lager's and eels obviously.
And the sour is just a completely different animal. You know, it it is what it says. It is it is a sour flavor. But to say that it's not like sucking on a lemon, there's a tremendous amount of complexity there. It's like a little bit sweet, a little bit fruity. It just has a tremendous amount of depth. And I really recommend that if you're an open minded person and you like good beer and you're looking to try something new, it's definitely worth hunting down. It's even good. It's it's even full bodied and strong enough that they can take being bottled. So if you don't have a not aren't lucky enough to live in a city and have a a beer establishment near you that will serve it on tap, The bottle is certainly a fine way to give it a try.
And I really like it. It's my favorite sour beer that I've ever tried. There's been a couple of others that I also enjoyed, but the majority of them that I encounter are kind of 1 note. They are sour, which is nice, but they lack that sort of depth and complexity, complexity that the Duchess provides. I think that's it for me. Great.
[00:17:14] Unknown:
I'm gonna second your pick on PT Python. I came across that recently, and I've been using it a bit. And it definitely is a superb REPL. I've been a long time user of IPython as my standard REPL when I'm doing development, and pt Python really just takes that up a notch and just adds some extra utility to what IPython already offered. So thank you for bringing that 1 up. So my picks this time are going to be to start with, there's a database management tool called DBeaver that I've start that I started using. I use Linux on my machine at home and for work. And for a long time, I've been hunting for a really good cross database, just GUI tool to work in so that I could not necessarily have to tie myself to using pgAdmin when I'm using Postgres or the MySQL admin when I'm using MySQL. Just having 1 tool that'll let me connect to a number of different databases without, you know, 1 that's free and open source and 1 that isn't hamstrung by an open core kind of model, and DBeaver just really has everything that I could ever want.
So I'll have the link to that in the show notes. Another tool
[00:18:22] Unknown:
Oh, I'm I'm really sorry. I didn't mean to interrupt, but but Dbeaver, that's really funny that you had mentioned that tool because I, you know, I'm mostly a Mac guy, but lately at work, I I just sort of the the company that I'm working for now is largely a Linux and Windows shop. And so my desktop at work is a Linux box. And so I've been sort of, like, moving in there, adjusting the drapes, and figuring out where all the furniture is and how I like things. And 1 of the things that I had been struggling with is, you know, the shot we were a Windows shop before my group came in and started transitioning things to Linux. And, so they have a tremendous number of Microsoft SQL Server databases. And d beaver is 1 of the only cross platform clients that let me work with that as well as the, you know, my SQL databases that we use. So that's very cool. I like it as well. I think it's a really good tool. And and, now that I really used to like Aqua's Data Studio, Aqua Data Studio, but now that's gone commercial and and a pretty hefty price tag, like $500 a license or something. So Yep. DBeaver is great. Definitely second that. Yeah. I I used to use Aqua Data Studio as well at a previous job where they paid for the license. But,
[00:19:32] Unknown:
yeah, have having an open source offering that really has a lot of really good functionality and the capability to attach to a large number of databases, including even, MongoDB and, I believe, Cassandra as well. Oh, cool. Just yeah. Real really really great tool. Another thing that I've been using recently is a tool called KDE Connect. So it's both a desktop application for the KDE desktop environment and an Android application. And what it does is it lets you link up your desktop and your Android device whenever they're on the same wireless network so that you can actually get notifications from your device that show up in your desktop notification panel.
It lets you have 2 way copy paste between devices. So I can copy something on my desktop and then paste it into something on my tablet. It also lets you use your tablet as a, essentially, as a trackpad, so you can use your tablet to move your mouse around and click on things. You can also use your tablet to type on your computer. So So it's just a really great, really interesting tool from the folks who build kde who if you're not using kde and have never tried definitely recommend that you at least take a look, particularly in its latest incarnation with the, with the new Plasma 5 desktop,
[00:20:52] Unknown:
really slick. Oh, I totally agree. As a matter of fact, when you may have seen me sort of ranting and whining and and piteously flailing on on, Twitter. When I first tried to set my desktop up with, with Linux again, it's been a long time since I've worked on the Linux desktop. Like, just to give you a sense, I think the last Linux desktop I ran had, f b w m, I think, as it's it was back when they weren't desktops, pardon me, Ubuntu on my box, and they have their own, pardon me, Ubuntu on my box, and they have their own desktop manager. I think it's Unity, actually. Yep. And it's I really applaud the way that the direction they're trying to go in with it. I think it's a really great tool, but it just lacks so much of the polish of the KDE folks have really put into play with with their desktop.
Particularly I'm partially blind. So excuse me, the handicap accessibility features are absolutely critical for me. And I was finding myself really struggling with things like I can't adjust the system fonts for the icons or the menu items or or anything for that matter of the desktop. So I'm sitting here dealing with massive eye strain issues by the end of the day because I can't see the tools that I'm trying to work with. And KDE is just man, their stuff is is slicker than snot to use a perhaps, somewhat launchy phrase, like everything is configurable right down to the nines.
It's very clear and straightforward most of the time how to get everything to work within the desktop itself. And I've been loving it. The only thing that I will say and this this is less to do about Katie and more to do about Linux is I still feel like the Linux community needs to figure out needs to agree upon a standard for like app and desktop interoperability, something as silly as, okay, you know, I listen to Spotify all day most of the time, and I would love to be able to find a way to, from wherever I am, control the volume of my Spotify, clients and and be able to, like, fast forward and rewind songs and the like. Doing that on the Mac is super trivial because of AppleScript.
You know, as as much of an ugly duckling as it is, it it really is like duct tape. It binds the entire Apple environment together and you can control virtually anything with, you know, with anything with it. And so you get these awesome tools like Quicksilver and Alfred and I can make my entire environment to the tune that I want it to and it's really trivial. But I'm in the Linux world. It was kind of it was kind of a, you know, spelunking expedition to figure out if it was even possible. And when I got it to work, it was a great deal of effort. So I feel like, you know, they've come a long way. KBE especially is just amazing. And I wish that they would go that extra 15 yards to cross the finish line. They could make the Linux desktop into a really amazing environment that I could recommend without without any caveats at all.
[00:24:00] Unknown:
Sure. And, that sort of leads me to a bonus pick. There's a library called player control, playerctl, that lets you really easily bind media keys to play, pause, stop, next track, and backtrack actions that will actually execute on Spotify. So that's what I use on my desktop for controlling the playback of Spotify when I'm listening to it.
[00:24:26] Unknown:
Nice. That's I will I will definitely check that out because I I gotta admit, like, it's so hard. I'm sitting there at work and I'm working away and I'm in my editor and someone walks over and it's like, well, hold on. I have to pause my music and I have to, like, flail flail flail for the, you know, for the app and the and the and the write everything when really I just wanna be able to get a key. So I will check that out. Thank you. Yep. And, so for my last pick today,
[00:24:48] Unknown:
I'm going to go with a nontechnical pick. There's a board game I picked up a little while ago and I've had a chance to play a few times called summoner wars. And for anyone who hasn't heard of it, my best way to describe it is somewhat of a cross between Magic the Gathering and chess.
[00:25:05] Unknown:
Oh, wow.
[00:25:06] Unknown:
So the way that it works is you have different decks that correspond to different factions, and you play it on a physical board. So you play you know, you you place the cards on the board. Each deck has a certain setup that it begins with. And then there's a summoner for each faction, which is essentially the king in the chess analogy. So the object of the game is to destroy the opponent's summoner. And in order to do so, you have units that you can move around the board that have the ability to attack. Some of them are ranged units, some of them require to be adjacent to the unit they're attacking. And there are also effect cards, which add effects.
For instance, 1 effect might limit the movement capability that your opponent has on their next turn. So rather than being able to move 2 spaces with a unit card, they can only move 1. So it's just a really interesting combination of game styles, and, it's really well executed. They've also done a good job of adding some expandability to it with additional factions that you can purchase to add some add some variety to the gameplay. So definitely worth checking out and again we'll put the links to that show notes. That sounds awesome. So that is all I have for picks for today. So, Chris, I would like to thank you very much for joining me. And everyone who's listening, I'd like to thank you very much for taking the time out of your day to listen to us ramble on for a bit. And we will be back as soon as possible with our next episode. So thank you very much.
[00:26:40] Unknown:
Absolutely. We've got some we've got some great ideas in the incubator, and hopefully we'll we'll be back soon with, some interviews and and a a more fully fully stocked episode the way we hope to run them. Thanks a bunch, folks.
Introduction to Podcast.init
Meet the Hosts: Tobias and Chris
The Need for a Python Podcast
Chris's Journey with Python
Python vs Ruby: Borrowing Ideas
The Importance of Explicitness in Python
PEP 8 and Code Layout in Python
Python's Focus on Documentation
Picks of the Week
