The Python Podcast.__init__

Share on social media:

Summary

Alex Martelli has dedicated a large part of his career to teaching others how to work with software. He has the highest number of Python questions answered on Stack Overflow, he has written and co-written a number of books on Python, and presented innumerable times at conferences in multiple countries. We spoke to him about how he got started in software, his work with Google, and the trends in development and design patterns that are shaping modern software engineering.

Brief Introduction

• Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
• I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
• Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project
• We also have a returning sponsor this week. Rollbar is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your application before your users notice they exist. Use the link rollbar.com/podcastinit to get 90 days and 300,000 errors for free on their bootstrap plan.
• Hired is sponsoring us this week. If you’re looking for a job as a developer or designer then Hired will bring the opportunities to you. Sign up at hired.com/podcastinit to double your signing bonus.
• Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch.
• To help other people find the show you can leave a review on iTunes, or Google Play Music, and tell your friends and co-workers.
• Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
• Your hosts as usual are Tobias Macey and Chris Patti
• Today we’re interviewing Alex Martelli

Interview with Alex Martelli

• Introductions
• How did you get introduced to Python? – Chris
• You have achieved a number of honors and recognitions throughout your career for significant technical achievements. What kind of learning strategies do you use to enable you to achieve mastery of technical topics? – Tobias
• How do you keep the Python In A Nutshell book current as aspects of the core language and its libraries change? – Chris
• You are known for your prolific contributions to Stack Overflow, particularly on topics pertaining to Python. Was that a specific goal that you had set for yourself or did it happen organically? – Tobias
• When answering Stack Overflow questions, do you usually already know the answers or do you treat it as a learning opportunity? – Tobias
• What are some of the most difficult Python questions that you have been faced with? – Tobias
• You have presented quite a number of times at various Python conferences. What are some of your favorite talks? – Tobias
• Design patterns and idiomatic code are common themes in a number of your presentations. Why is it important for developers to understand these concepts and what are some of your favorite resources on the topic? – Tobias
• What do you see as the most influential trends in software development and design, both currently and heading into the future? – Tobias
• As a long-time computer engineer, are there any features or ideas from other languages that you would like to see incorporated into Python?

Picks

• Tobias
  • The Great Gatsby Movie



• Chris
  • Stone Ruination Double IPA
  • Ghost Soldiers



• Alex
  • Alexander Hamilton by Ron Chernow
  • Hamilton Musical

Links

• Permission or Forgiveness
• Good enough is good enough
• Modern Python Patterns and Idioms
• Handling Errors and Exceptions in Modern Python
• Microservices
• Google SRE Book
• Python In A Nutshell use code AUTHD for a discount

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

[00:00:14] Unknown:

Hello, and welcome to podcast.init,   the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.   Linode is sponsoring us this week. Check them out at linode.com/podcastinit   and get a $20 credit to try out their fast and reliable Linux virtual service for your next project.   We also have a returning sponsor this week. Rollbar is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your application before your users notice they exist.   Use the link rollbar.com/podcastinit   to get 90 days and 3 and 300, 000 errors for free on their Bootstrap plan.  

Hired is also sponsoring us this week. If you're looking for a job as a developer or designer, then Hired will bring the opportunities to you. Sign up at hired.com/podcastinit   to double your signing bonus.   You can also visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and sign up for our discourse forum. To help other people find the show, you can leave a review on iTunes or Google Play Music and tell your friends and coworkers.   Your host as usual are Tobias, Macy, and Chris Patti. And today, we're interviewing Alex Martelli. So, Alex, could you please introduce yourself?  

[00:01:21] Unknown:

Welcome, everybody. I'm Alex Martelli,   Italian   by birth   and,   degree.   I   graduated in electronic engineering,   did Harvard for a while, then   inevitably slid into software, entrepreneurship,   management, and things.   And then I met Python, and that changed my life. I   got an offer to transfer from Italy to California to work for this little startup,   which was a Python heavy shop   with a silly name, something like Google.   And   I took a risk.   I've been living in California for 12 years doing   Python at Google.   In the meantime,   I've published a few editions of a few books about Python.  

I've,   been   chosen as a fellow of the Python Software Foundation,   won the Franklin's Memorial   Award   for contributions   to Python,   And,   currently working   leading the 1 to many technical support group for the Google Cloud Platform, which is   among the   many Google teams that use Python heavily.  

[00:02:42] Unknown:

That's great. So, Alex, how did you get introduced to Python?  

[00:02:46] Unknown:

In   the year   1999,   I had   just completed   the, copy of spare time project of which I'm   still proudest.   It was   an analysis   of probabilities in the game of contract bridge.   I   had submitted,   s   the results of this analysis   to the most prestigious   journal in the field called the Bridge World,   where it was published,   in January February,   in issues   in in 2000,   with a forward   saying,   some will say   this makes giant strides towards solving problems that theoreticians   have been   wondering about   ever since before bridge was invented,   and some will say it's not more significant   than that.  

High praise.   And at this point, I started getting   requests   from   mostly famous rich people to   asking if I could adapt to my   simulation and analysis environment for their bridge problems.   And I tried,   but it was such an unholiness.   It contained bits and pieces   in Perl,   but at the time, my favorite language,   e plus plus, assembly code because some parts needed to read   run really fast. Visual basic, because they would need some kind of visual   front end.   Modular 3. Okay. I let's stop listening because it was a mess. Anytime I change the comma somewhere,   something broke elsewhere.  

So I decided I really need to record it from scratch,   a well known   trap which all software developers are prone to. Joel Spolsky   highlighted that pretty well. It's a well known anti pattern. Nevertheless,   given how fragile the whole thing was, I absolutely needed to.   So I looked into   some of the many languages   I'd known and loved, from   to common whisper, from   to,   modular 3,   and couldn't find 1 that would give me   easy access to things. And I I was,   moaning about that to a colleague when said colleague said, oh, you should try this new Python language   that's,   seems to be really great.  

And I was like, oh, come on.   The last thing I need is add yet 1 more language to the mix.   Simplify. Well, you could record everything in Python. Yeah. Right.   Unfortunately   well, fortunately rather, I had a high respect for this guy. So, eventually,   when he got to the first published book in Python and before even opening it,   loaned it to me so I could   get how strong the language was. I gave it a try.   The book was not that good, but the language seemed interesting.   Now having,   accidentally   a long weekend available, I decided,   let me try out the language and see   how well I understand it.  

And   in some of it, let me also write my first ever web application   that was the time of CGI.   I'd never   written 1 before, but, hey,   if learning 1 thing is fun, learning 2 must be better and 3   better still. So I started on Friday night   thinking   by Sunday, my wife and kids will be will be back, and I'll see how far along I've gotten. Of course, I'm not gonna finish   the application,   but, hey,   at least I have an an idea about this new language and this new fangled web, whether   either or both of them are working.   By Saturday night, I   had completed   all the website doing, bridge,   computations   that I wanted in Python in CTI, and   I had to start wondering now what?  

Oh, wait.   This only   this is only an English site, and a lot of my   rec the requests for for   using my stuff come from Italy, where I'm from,   and France.   I've got some roots in France as well.   So I want to do English and Italian and French.   I think   I've read that templating is the right way to go to do a multi language website.   Let's see what's around,   or templating on Python. Looked around a bit. Didn't like   what I saw. There were a few that came. So I decided to write something to be called yet another Python templating utility.   Yep. 2.  

And by about 11 AM on the Sunday, that was done too.   I published it to Usenet. At the time. That's what you did with what we now call open source.   The term hadn't been invented yet. We're talking about the nineties. Remember?   And   that was appreciated. There was a guy   who was busy rewriting,   the   website   for the University of Berkeley computer science department   who had already decided to go with this newfangled Python thing   and was looking for a computing utility,   found mine, decided it was good enough to start,   offered some patches, and   that's how I made friends with Peter Norvig, best known as the   as the owner of the best selling books of artificial intelligence   and   and the director of the search of Google,   also Python and this, Yactu Ping.  

By that time, I was   obviously captured,   but that's not what we were using at work. We're a c plus plus shop with some Fortran   and starting to experiment   with Visual Basic and c sharp.   So   I widely introduced   the Python   among the cracks of those   various languages,   but   I wasn't happy.   I started,   trying to pay   forward   all the wonders that were Python by posting on the Internet   in a few months,   a guy who later go on to found the Python Software Foundation, and   it's now Michael or in the 3rd edition of 5 year in a nutshell,   tagged me in the Bot   into the volume of my   of my contributions   and their,   mostly correct nature.  

On that basis, I contacted O'Reilly   asking if I could   write Python in a nutshell,   and they said I'd have to do the Python cookbook first. But when that was gone, I finally got to write the nutshell, and the rest is history.  

[00:10:16] Unknown:

Well, that is, quite an illustrious history you have there. I those surprise appearance by Peter Norvig. I didn't realize that you had that connection.  

[00:10:24] Unknown:

That's how we made friends. Later, when I interviewed at Google, it was my lunchtime   non interview,   taking me away from the heavy   in technical levels that you're supposed to if you have a   friend there to just make small conversation. It was   even more technical than my interviews in the morning and afternoon, of course.   Peter and I are Carnegie.  

[00:10:54] Unknown:

So 1 of the things that you mentioned early in your story there was that 1 of the ways you got introduced to Python was through your interest in bridge, and I had meant to ask you a bit about that. I know that bridge is well known for being fairly complex   and having a lot of theoretical aspects to it. But having never played it myself, I'm unfamiliar with some of the niceties thereof. So I don't know if you can take a few minutes to briefly explain maybe some of the background of Bridge and what it is that makes it so interesting. At the age of 10, I was a promising junior chess player,  

[00:11:26] Unknown:

and I already had what I still have today, which is, an insane passion for books   about anything, really, but what's interesting me most.   And, my parents, very generously,   had opened a tab at the best local bookstore   so I could buy any book and then periodically go there and close my tab. So, of course, I was gradually   1, 2, or 3 at a time   getting all the chess box   they had. Unfortunately,   they were mixing on the same shelf, chess and bridge. So by mistake,   I once got   an intermediate to advanced bridge box. It didn't explain the rules, just intermediate   to advanced things.  

I, of course, ended up reading it cover to cover and being absolutely fascinating and wanting to learn the rules   of the game that gave,   rise to such fascinating   situations as the book was explaining.   I hadn't   heard   much about game theory at the time. It wasn't,   I mean, it had been invented a long time ago, but it wasn't very much in the news. So I'd only read 2 or 3 books about it. But it did strike me   that this was a case of incomplete information   versus chess, which was a complete information,   game, and the incomplete information aspects   were really fascinating.  

Yeah. I mean, if you played bridge with open cards,   you'd be playing a complete information game, actually, simpler than chess, so it could be solved. It's,   it's also known as double dummy. And, indeed,   by the nineties, we already had   very capable   programs to play double dummy bridge. But since nobody's   showing their cards that the 1 player out of 4 of the dummy, that raises   the interest and difficulty   by orders of magnitude.   So that's how I started. Then my parents, who had absolutely no interest in parts of any kind,   introduced me to family friends who did. So I started playing on the Sunday Sunday afternoons that day,   French sows and,   found it interesting, but,   the guys weren't running to it. It was more of a social occasion.  

So I found out there was a rich club in my hometown, Bologna,   and applied. And, of course, given that I wasn't quite 12 yet, that   at the time, Bridge was not considered a good game, a crooked game for young kids. But, fortunately, thanks to friends of friends, of my family, and so on, I finally got   approved and started spending my afternoons   there.   That didn't interfere with my schooling, which proceeded apace, so that half my brain was into this   fascinating bridge thing. So that's how I started.   And throughout my high school years,   I did I did great, great. I actually   played in the junior championships   of my name in Italy, which was and still is 1 of the great powers of,   international competitive bridge.  

I got 3rd place twice, not   got bronze medals, not exactly   satisfactory.   Then I started university that was engineering, and finally, I   found a professional endeavor that would actually   soak up a 100% of my time and and energy.   So from then on, my bridge has been of the on and off kind.   Also be a good thing because that's left me the time and energy to do other things, but the fascination never stopped. Part of it is that my birthday gift for my, 14th birthday was a lifetime subscription to the BridgeWorld. The BridgeWorld at the time was offering it at a price that would have made a lot of sense if you were 65 or 70.   So I inferred that getting it in my early teens   was sure to be an incredible bargain. And for many decades now, I've been reading it for free every month.  

So that's how I got started with Bridge. And the, actual   problems that I tackled,   actually have to do with the   the simple part beyond the fact that it's not a complete information game.   Even if you saw all the cards,   how would you deal with things? Or suppose you only see your cards, the other that's 13 out of the 52 in the pack. The other 39 could be distributed in only a few tens of 1, 000, 000 ways among the other partners.   What if you did distribute,   deal the other 39 cards in   every possible way solved each situation.   Wouldn't that tell you a lot about the only 13 cards you can see?  

The first person who   hypothesized   that as a concept,   was known was, Eli Culbertson,   in the 19 twenties. He's   was a rather fascinating   guy. Barely got out of jail in the early Russian revolution, the 1905,   thanks to the fact that his father was Scottish American.   But,   he loved Russia and   hang out there until he had to run away to to avoid the XR executing him or something. So, anyway,   if   the the proper way to judge of a bridge hand is to mentally play it in front of every possible combination of the other cards. That's conceptual, of course, because at the table, you can't mentally play tens of millions of hand. But given a computer   was my thinking,   you actually could. I mean, and you don't even need to play, 30, 000, 000. You get a random sample at, I don't know, 30, 000 out of the 30, 000, 000 that essentially   tells you everything you need to know about all the all the 30, 000, 000 possibilities.  

So that's   how I started programming in   my not so copious spare time.   At the time, I was   a cofounder of a start up and a contract professor at a local university   teaching numerical methods.   So my spare time wasn't much, but it was enough as long as there was bridge involved.   So I started hacking on that.  

[00:18:03] Unknown:

It's very interesting. And through your technical career, you've achieved a number of different honors and recognitions for various significant technical achievements. I'm wondering what kind of learning strategies you've used to enable you to achieve mastery of those various technical topics.  

[00:18:19] Unknown:

Interestingly,   I found   over the decades   that work   that what works best to change it with time. In my teens and very early twenties,   I had an incredible memory. Not eidetic. Was never,   I never could remember   where on the page just something was written. I it wasn't images. But for text   and formulas, I essentially   could I I made a nuisance of myself because I didn't realize   not everybody could.   If somebody   we were discussing and somebody said something and later said because I said the x and y, I said, no. You said   x prime   y prime.  

The exact words that said and that made a nuisance of myself thinking they were trying to somehow lie to me, which was silly. So it was so easy to memorize stuff that was 0 effort. What I didn't have   was the way to root whatever I've just memorized of the page in real world experience because I didn't have enough or any actually as a as a younger kid. So that's a you know, despite   the perfection of the memory, it's very shallow learning. I mean, you can memorize a poem, but if the poem talks about emotions,   experiences you've never had, that's pretty meaningless.  

I mean, you have the words, but you don't have anything of what's real in the point. And the same goes for, say, a programming language. Yes. You may know all of the rules of the programming language, but if you've never actually programmed   to solve a real world problem, that knowledge is sterile. Just knowing all the words of a poem without understanding any of the feelings, emotions   that are behind it. As I grow older,   and and by that, I mean, already by my mid twenties, memory became less perfect.   On the other hand,   I did start having real world experiences   to anchor   my learning into.  

So it wasn't about,   memorizing,   2   pages worth of tables of formulas and things. It was getting reasonably familiar with them and then   tying them to something in the real world.   And I found out that,   the more time goes on, the more I get real world   experiential learning,   the more important the strategy is to me.   By now,   I wanna learn something.   Sure.   I still prefer to start with a reference manual.   Now most tutorials   are written assuming you're   a moron, which I'm not yet. I will eventually if I get old enough, I guess, but, not yet.   So I prefer to eschew tutorials,   get all the rules from a reference manual, but then   pick up some problem,   including 1 that I have solved in the past with other technologies,   and try and see how do I solve it with a   new stuff that that's being presented to me. Once I've actually   used   some technology, some approach, some tools   to for some real world application,   my learning is better rooted. So I can't go on that way. I think that's unique to me, but for many people, I believe that will be the case. If you just learn things by memorizing   in the abstract,   Yeah. If you've got a good memory, you'll have   that thing available for recall. But, you know, it's so much easier to check out a page in a book or or a or a web page   for all those formulas and rules.  

What those will never give you is how do you apply them. That starts   telling you why is this feature there,   Because it helps you solve this kind of problem   more easily   by this and that way. And, yes, if, you could get a perfect tutorial that would teach it to you, but I found out that I learn best when I have to find out for myself by applying the technology   question.  

[00:22:39] Unknown:

Yeah. As I've gotten more experience in various technologies, I've definitely found that the way that I approach learning has evolved because, like you said, when you first start off, you need to get a baseline understanding of some of the various   fundamentals. But once you've committed that to your sort of baseline understanding of the topic, then you have a lot more scaffolding to build from. So you don't necessarily need to go to that level and you can start straight with from, you know, the API documentation and have a better understanding of what's actually happening under the covers just intuitively because you've, you know, built it yourself or dug into it for in other libraries or languages.  

[00:23:17] Unknown:

How do you keep the Python, in a nutshell, book current as aspects of the core language and its libraries change?  

[00:23:24] Unknown:

It's essentially,   rewrite every time, which is why   what we're working on now is only the 3rd edition   in over 12 years. It would be great to do a yearly edition, but every edition   is almost a complete rewrite.   So with the other things in place, it doesn't really work. What I did this time is find 2 great co authors,   my wife, Anna Ravenscroft, and the guy I mentioned earlier, the founder of the Python Software Foundation, Steve Holden,   with a very different set of experiences   and knowledge than mine   so that we could work 6 handed   and this way make it more likely that every corner of importance   would be covered.  

I,   of course,   have been with Google almost 12 years now, so my understanding of, modern Python   is focused on how we use it at Google, which is important, but it's only partial. You know, YouTube is Python head to toe,   all of a lot of our infrastructure   and so on and so forth. But my wife and Steve   have used the Python or taught Python   in completely different   surroundings,   so they have different opinions from mine about,   the things that really need to be covered. So   with a 600 work, I think we achieve a better synergy.   It's indeed that we're almost   done with the 3rd editions already available   in early release,   from   as it's all ebooks for now only from O'Reilly. But remember, O'Reilly ebooks are   DRM 3, so no risk. And if you buy the, early release today,   you'll get all upgrades until the final   version.  

So I strongly recommend using a web search for Python naturally release   and see what's on. If at checkout, you apply the,   discount code   a u t h d, that'll be 50% off   Davis price. So I think it's quite a bargain. And you can send me feedback,   and I can act on the feedback even drastically   because   the book will be finalized.   We've actually   just got to the definitive,   deadline. It's 12th day,   January 6th,   of known in my native Italy as.   A day to receive gifts as 12 as is 12th night,   except you don't need to get 12 drummer drumming or whatever it is you're supposed to get on day 12.  

[00:26:14] Unknown:

And 1 of the things that you're well known for is your prolific contributions to Stack Overflow, particularly on topics pertaining to Python. And I'm wondering if that was a specific goal that you had set for yourself or if it's just something that happened organically as you learned things and decided to just try and contribute back? I'd say more of the latter. I had been  

[00:26:35] Unknown:

in early in my Python career. I had been best known as the Marcelli bot being incredibly helpful on the Usenet group in mailing list, Complang Python. Unfortunately,   Usenet   has been essentially   completely taken over by spam, so hanging out there became totally unproductive.   When Joel Spolsky came to visit Google and   explain his new project,   which he was about to launch called Stack Overflow,   I said, oh, assuming there's any interest there   in Python,   I could go back to the kind of fun I was having   helping people   on Complang Python back in the glory days of Usenet. Well, I mean, signed up and started answering questions, and it just grew organically   for from there. At 1 point, my wife, despite being a Python fanatic herself,   commented that we weren't doing anything outside of my workday anymore because every minute of my time was going into posting non stuck Overflow. I said, well, it's kind of fun, but I can   drop it anytime. And she did the typical   wifely things and just challenged me. So okay. So drop it now. And I did. I'll took a year off, and, yes, I survived, and I did other things. So we did,   like, going to theater and and other stuff we enjoy. Then within Google, I got an offer to,   lead a team, which is known as the 1 to many   tech support for the Cloud Google platform. And it so happens that Stack Overflow is 1 of our   main channels.  

So if I can ever get any cycle at work free from the leading and organizing   aspect of the work, I'm actually getting   to use work time to answer   as long as it's relevant to cloud,   answer questions on on Stack Overflow. So that's the happy ending. Well, not an ending, really, but the happy state of things.   Actually, in the last few months, I've been kinda very busy growing the team and and mentoring people and so on. But I do plan to go back to Stack Overflow and do, I don't know, maybe 3 fourth of my time on cloud issues, 1 fourth on Python issues, something like that, and, go back to the sheer joy of helping people,   which is the main reason, the only real reason   I've always been doing this kind of thing.  



[00:29:11] Unknown:

And   when you're answering those Stack Overflow questions, do you usually already know the answer going into it? Or is it something that you typically have to sort of treat it as a learning opportunity and go out and find and figure out the answer before you post back? Both both situations happen. When Python is concerned, I would say I probably think  

[00:29:32] Unknown:

I know the answer 80% of the time. It's still worth checking   often, but,   and then there's that, fraction of the time   where I've never actually asked myself that question, and I need to experiment a bit. For cloud, it's such a broader   issue   that it's more like 5050.   I don't know the answer   anymore, possibly less than 50% of the time. So the other 50% of the time is definitely a learning opportunity.   And being embedded in the tech support teams means that the sheer experimentation   is not the only way I have to learn things.   I often get the opportunity to just ask   a lot of the people I'm sitting close to, which are the support geniuses   of   Google Cloud Platform.  

And then we're back to the 80%   chance that they will know offhand   and be able to give me   a solution in 5 minutes,   without needing to research it. And if they don't know either, that's the most interesting   part of where we wanna find out. Their time is mostly spent supporting   premium customers, customers who pay for support contracts. But, of course, if somebody else out in Stack Overflow land is having the problem, likelihood is that   some premium customer will come up with a same problem sooner or later.   So finding out how things are and how you solve the problem is a good investment of time anyway.  



[00:31:10] Unknown:

And what are some of the most difficult Python questions that you've been faced with on Stack Overflow?  

[00:31:15] Unknown:

Actually, not the important ones. Difficult   t in Python,   more often than not by a big deal,   comes up with when somebody is trying to do things   in complicated   ways that may sound   natural to them   because they come from   other technologies, other languages,   but are really unnatural   and abstruse in Python,   which makes them   really hard. So   more often than not, my natural reaction   to getting 1 of those   most hard question is don't do it. It's like the old joke. You know? Doctor, it hurts when I do it. Well, then don't do it.   That once in a while, even though there's no practical application,   the a question comes up that   resolves   into   me not being completely familiar with a certain internal   deep part.  

Most   of the time,   it's stuff that's explicitly   undefined in the language, so you're not supposed to rely on it. But, of course, any given   release, any given set of binary   running your program,   will have a solution.   You shouldn't rely on that because any upgrade, any any change in your   Python release would break everything, but it's still   interesting   at a curiosity level to know what happens. 1 example,   if I put n items in a set versus I put the same n n items in a dictionary   as keys with whatever values. When I loop over them, will the order be the same or not? That the order in which you get items when you loop on a set or dictionary   is very explicitly undefined in Python. Think of it as random, but it's not actually random. It's whatever   the underlying   implementation   dictates.  

So understanding whether the 2 are the same or not in a given implementation   is really, very hard to do because you need to study in-depth   the inner   functioning of the, data structures in the interpreter.   It's of no practical use because you wouldn't ever   rely on that because it could change in the next minor or or point release,   but that's probably the kind of thing that proves hardest   to respond.   And while the common sense me would say, so therefore, just don't do it and pay no care, I am enough of a geek that if I get curious enough,   I will research the issue and come up with the answer. Whether I post it or not,   sometimes common sense  

[00:34:03] Unknown:

Right.   Yeah. Particularly in that instance, it's probably best to not give an answer because that'll just tempt them to use that knowledge and dig themselves a deeper hole.  

[00:34:13] Unknown:

Working   3 51  

[00:34:15] Unknown:

and then 352 comes out. Whoops. It breaks. So so Right. And particularly with the hashing algorithms concerned, they would even be different from machine to machine because the differences in the memory architecture and the actual memory space available. So Exactly right. So the difficult questions  

[00:34:34] Unknown:

are the ones that really shouldn't be answered.   Even Python.   There are difficult questions in software development,   whether you're using,   Python or Erlang or anything   that have to do with human beings because that's   software development is a task done by a team of human beings.   Human beings are so complicated   differently from the programming languages they use   that   questions can be extremely difficult and extremely important same time. So in a sense,   managing or leading or just working in a team of developers   is much more of a challenge   than looping over a set.  



[00:35:18] Unknown:

In addition to your prolific   posts to Stack Overflow, you've also presented at quite a number of different conferences   and events about Python and various subjects having to do with software development. I'm wondering if you have any favorite talks among the bunch. Well, on the queue offered by the end of my previous answer, I can't fail to point out that the best talks  

[00:35:42] Unknown:

are   only relatively little about Python or any specific technology.   They're mostly about   human beings developing   software. Maybe   my favorite   let's see. There are 2 there are 2   I can't really choose between. 1   has been known as abstraction as leverage   or the tower of abstraction.   If you if you use a   web search for the video, you can find it under either title. Alex Martelli, abstraction   will get you both. And it's about   how do   you properly   design and use   layers of abstraction.   And people who say they don't are wrong and explain why and so on and so forth. And then   there's   another 1 called permission or forgiveness,   which explores   the context and the depth   of the famous talk, It's Better to Get Forgiveness   Than Permission.  

This is true at many levels, I   point out, and it doesn't work in certain situations involving, again, human beings.   That's   what we're all about. Problem with human beings is that we release 1.0   beta, and there's still plenty of bugs. And upgrades   aren't   coming, so we have to work around the bugs.   Oh, and the third 1, always on the same,   meta subject   that developing software is about a human activity.   Is good enough is good enough.   That I don't know what order   I would present these 3. You'll find a little Python in each of them because I often presented them at Python conferences, so I needed an excuse.   But it's really not the point of either   of the 3 talks. If you want to focus   on strictly Python stuff, there's a couple recent ones.  

1 is,   modern   Python   patterns and idioms, which refreshes my   old, still good, but kind of, surpassed talks on design patterns in Python,   about   what's the proper   set of patterns and idioms in Python in 2015, 20 16. And another 1 is   how to,   handle exceptions and error in modern Python,   which is something   we should all know, but there's plan especially if you're moving from Python 2 to Python 3, there's plenty of subtleties   people can easily miss, which are generally improvements in Python 3. But you if you don't know about them, you're not going to be taking full advantage. The last of the 5 talks I've I've mentioned is actually a summary of chapter 5 in the 3rd edition of Python in a nutshell, which, as I mentioned, is available in memory release. But for   40 minutes of your time, you get the gist   of, what you should be doing to properly handle exceptions and errors in Python 3 in particular.  

So the last 2 are   highly technical   and near a 100%   Python.   The first 3 are, I think, of more general interest because   it's not just Python. It's human being involved.  

[00:39:01] Unknown:

Yeah. And 1 of   the themes that seems to be fairly common between them and a number of your other talks is the idea of design patterns and idiomatic code. And I'm curious what your thoughts and opinions are on why those are such important topics for developers to understand.   And I'm also wondering if you can point out some of your favorite resources on the topic.  

[00:39:22] Unknown:

Bokey's partner   in founding Stack Overflow, Atwood, put it best. Don't reinvent   the wheel unless what you're trying to do is understand how wheels work. The only reason   to   do your own   thinking about a certain situation   before researching   what patterns have already been published and vetted is because you need to understand   deeply the reasons under that patterns, which is a perfectly good motivation. But if what you're trying to do is solve a problem,   an application level problem,   whenever you can find an appropriate pattern published and vetted and commented on, you are saving   yourself,   mental   cycles   so that you can apply them to the specific   context of the application or infrastructure   that you are developing. Let me let me just give a simple example. 1 of the modern patterns I I mentioned in the in that talk. Modern patterns, patterns emerge in the last few years   tend to be architectural   ones,   so not   specifically Python, because architecture   is undergoing   a revolution,   which has very few precedents. It may be the 3rd big or 4th big wave of computing. Instead of programming for a single computer or a known set   of computers   in a data center,   today, you should be programming for a cloud   of computer that can come and go, servers that   you can enrich when you need and you can drop when you don't,   and that changes everything.  

And 1 of the architectural   patterns whereby you can best use   this new richness   is known as microservices.   If you are not familiar with microservices,   you haven't studied the vast literature   about them, you start with some   huge monolithic   application, you will eventually   need to reinvent   microservices   for yourself.   That's a huge job.   It will take you a lot of time and energy, and you may get it wrong because it's not trivial to get it right.   Spend a few hours studying what all has been published on the subject, especially a little about how to do living in Python, but it's not really language specific.   How do you divide   the services?  

What can they share as little as possible?   How do you   make them use each other? How do you test? How do you deploy? How do you upgrade? Blah, blah, blah. All those sort of things. Remember, it's not just a development. Development and deployment,   that's another relatively new idea, should go hand in hand. A term often used there is DevOps.   Do you want to reinvent it from scratch? Well, okay. I understand, but it's like reinventing the wheel. It's been invented. It's out there in many   forms,   with advantages,   disadvantages. Why don't you just   reuse the work of your predecessors?  

Remember what   Newton wrote? If I can see a bit further,   it's because I'm standing on the shoulders of giants.   Wouldn't you like to be standing on the shoulders of giants   and thereby being able to see even further than them? That's what understanding   the state of the art in your discipline,   which   in software development and deployment   is in good part   embodied in patterns,   not necessarily design patterns. There's a design, architecture,   deployment.   Each has its own set of patterns,   will let you stand on the shoulders of giant, which is what you should   want to do   and see much further   and push the state of the art forward.  



[00:43:20] Unknown:

Well said. I don't have anything to add to that. That's, definitely,   like you said, by not having to reinvent the wheel and having a good understanding   of   where we've come from and what other people have already established as a recognized   way of performing similar tasks definitely alleviates a lot of the cognitive   load of creating the specific pieces of the application that are necessary for the business. It frees up a lot of critical developer time in the process.   And you've touched on it a little bit, but I'm wondering if you can go a bit more into what you see as the most influential trends in software development and design both currently and heading into the future?  

[00:44:00] Unknown:

It's a dual pronged   push, which   includes   cloud and demo. Those are the 2,   big keywords   you'll find everything under. They work together   because   part of what cloud gives you if you use it right is reduce   the trivial   parts,   trivial but still time consuming, parts of,   deployment   operation work. I mean, maintaining   a data center is a highly technical job,   but it's also   very time consuming and repetitive.   You have to be monitoring   the servers,   being ready with spares if 1 server   goes bad,   installing   the   replacement 1,   sending the the broken 1 to maintenance   so it can be refurbished.  

Keep an eye if it is it time to upgrade the switches   for the local networks in my center? There's a lot of operational work that can be automated only in part,   and it's going to take   superb   technical people   a lot of cycles. Now when you move to cloud,   you're essentially   outsourcing   all that work to teams   at suppliers   such as Google who have   developed   100 of many years' worth   of procedures   and methods to automate everything as much as possible on a scale   of numbers of servers   well beyond what your company orders of magnitude beyond what your company needs.   So, therefore,   your operations   work can move much closer to your development work,   making DevOps not just a slogan, but a reality.  

The putting together   developers and operations,   once the drudge work of operations has been removed by off of sourcing   to, good cloud suppliers like Google is to solve   the inherent tension   between   innovation and stability   to, simplify and caricature a bit.   What the developer wants   is to finish the new feature and launch it, make it available to users. That's core motivation.   I want you make users happy by adding this new feature and then the other new feature and so on. What the operation people want   is   reliability.   They want to avoid customers getting very unhappy by avoiding wreckage, which is quite possibly going to come as a feature   is launched without   all the due proceeding.  

So where dev and ops meet is in   somewhat of   unfairly obscure area. It's been along for   a long time, but it's finally getting to maturity and fruition   called release engineering. Work needs to proceed   so that   releases are precise   and monitored   and launched incrementally.   So for example,   a crucial design pattern there   is an advanced load balancer,   which is able to take in user requests and   send, say,   90%   of them to the   old stable system and a fraction, say 10 10 percent, to the new   should be improved system   and   monitor automatically   that the performance of the new things   is at least as good   as that of the old and proven 1. And so, therefore,   gradually move all traffic to the new and improved stuff   without risking   a crash   that,   I don't know,   strands a 1000000 travelers forever in a 1000 airports all around the world   for days, just to give a very hypothetical example.  

Right. Hypothetical.  

[00:48:17] Unknown:

We all know. I was a release engineer for over 15 years, so I totally agree with you. And it's interesting talking about how   sort of dovetailing your 2 points in that   modern   DevOps culture   is kind of in some ways an outgrowth of of release engineering. Right? Like, in order to  

[00:48:36] Unknown:

It's where the 2 the 2 big things meet. Right. Because it's the only way to keep innovating while maintaining stability   is to do   clean,   organized   releases.  

[00:48:48] Unknown:

Right. But it's it's crucial. I absolutely agree. I think the industry has gone through a bit of a shift though in the sense that for a long time, release engineers,   you know, it it was a very lucrative niche, but I think companies are no longer willing to employ people whose   sole job in life is to do release engineering. I think most companies want people to wear more hats and to be more useful and functional in a broader way.   So it's really interesting.  

[00:49:19] Unknown:

You may be right. Yeah. I've not looked for a job as a release engineer in   in ever, actually. But   what I see from some of my best release engineer friends is that their hats are natural their multiple hats are natural expansion   of what release engineering is all about, which is reliability.   Get   reliable stuff, reliable systems   from unreliable   parts. Incidentally,   there is a book   that I have to recommend. It's amazing even though I didn't   do anything about writing it. It's called software reliability   engineering,   published by O'Reilly,   written by a there's names on it, but it's   dozens of   software reliability   engineers at Google who contributed to it. I think if   you read it, it will show you how   release engineering   is the heart, but a lot of other bits and pieces. Of course, for example, something that's not part of release engineering,   traditional release engineering, let's say, is deliberately   simulating crashes that is cause a   certain data center, certain fraction of the center and so on to crash and make sure the system as a whole degrades gracefully. That's   something   that's, I'm told routinely   done in other areas of engineering such   as aeroplane.  

Airplanes are always tested so that like big jets. I mean, if   1,   engine fails, doesn't mean the airplane has to make it to destination,   but it must not crash to the ground and kill everybody. It must be able   to negotiate an emergency landing. That   cult of reliability,   which is extreme   in aerospace,   is finally at long last, and it was time, invading the field of software. You know, a lot of our software   can actually   be helping that plane fly, for example. So there's no reason to treat it more cavalierly   than you would the wings or the engines.  

[00:51:30] Unknown:

And as a long time computer and software engineer,   sort of jumping topics a little bit, are there any features or ideas from other languages that you would like to see incorporated into Python?  

[00:51:42] Unknown:

Yeah. Sometimes.   However,   1 feature or or language   that I'd like to see more of in Python, it's it's it's unfeasible.   Mostly comes from c, but it was in Python at the beginning, which is to keep it small and simple. And the more stuff you add, the   less small and simple the whole things is because you can hardly ever   remove the old stuff because   when you do, it breaks   existing programs, so you don't wanna do that. And the, move between Python 2 and Python 3 is proving   lengthy and painful enough that it will be quite a long time before we dare do a Python 4 that   removes   excess complications.  

So   while I would love to see certain things, like, for example, I don't think our abstract based classes are quite as powerful and complete as Haskell's   meta,   sorry,   type classes. Haskell's type classes   is   the best feature of Haskell. Well, it's got many great features. But the type classes,   let me give you just 1 example, a trivial example that that I love to give. I want to be I'd love to be able to say, as I can in Haskell, that   some abstract type   has a   write method and a write lines method. Write takes a single string. Write lines take a sequence of strings. And I would be able to say that the implementation of write is, in Python term, that would be self dot write lines open bracket,   the single line, close bracket branch. So a right is equivalent of a right lines on a single item list. Vice versa, the implementation of right lines is   for line   in the list   self write line. This looks like a mutual dependency, but it is not. Given the class is abstract, the type class in Haskell,   you have to implement 1 or the other or both. But if you only implement 1, the other 1   knows how to to be implemented by using   the time class definition. I'm not sure I've, I've gotten the idea across. It could be a bit easier in writing perhaps. But, point is that mathematics is full of situations   where, essentially,   you're saying that   these 2 operations are equivalent, so either could be defined in term of the other. You have to define 1 of them more concretely, of course, because,   otherwise, you've got   a circular recursion with no end, no closure.  



[00:54:19] Unknown:

Yeah. I think you did a good job of explaining that. Essentially, you could kind of define it as being the transitive property of class definition.  

[00:54:27] Unknown:

We don't have that in the abstract based class. I don't   have a clear idea of how to make it work right, but that's 1 thing I'd love to have if it didn't make Python any more complicated or any bigger.  

[00:54:41] Unknown:

So are there any questions or topics that you think we should cover before we close out?  

[00:54:47] Unknown:

Think we've done a reasonable job, except we haven't really dug   much into the human side of software development. I mentioned it a a couple times.   We may tend to think of ourselves   as   specialists   in what we do, which is   deploying and developing   software. This   is a good development,   but it absolutely   must not be the only 1. It's like   let's put it this way. If it was Egypt,   25 100 BC,   we might be scribes,   proud of our skills   in getting the hieroglyphs   just right with our style on papyrus,   A crucial skill. However,   wouldn't it be better if scribes were only called in   for documents which actually   require   the scribe's   exceptional   writing skills. And   most written notes   could be penned   by ordinary people, like a merchant just needing to send his agent over in Memphis   the, request to please send,   50 jars of barley,   shouldn't need to go to a scribe and queue for the scribe's time and and have beautiful hieroglyphs,   pendant, papyrus, and so on. They should just have some way of putting this very simple message   on a piece of presumably papyrus given it's Egypt,   remember, 25 100 BC,   and then put it on a fast camel and have it go to Memphis   and get the the barley back. That is a caricature, but it's kind of the states where we are and are going.  

We have   highly professional specialists   totally focused   on doing,   hopefully, great   software. And a lot of unmet demand for simpler but crucial   bits and pieces of software.   And people who are not programmers, but they may be excellent   accountants,   archivists,   office managers,   who'd really need   something that works, but there's a queue of 3 years to get a request in front of the IT department,   if you're lucky. What we the connection we're missing is that without any   diminution   of the professionality   and the great skills that go into   full time software   development and deployment,   which really should   be doing more   to empower people with different professionalities,   whether they're   medical doctors or,   as I said, office managers or,   store clerks or anything   to do simpler   but effective pieces of software   meeting their own needs.  

That dream   started   at least 50 years ago. It's never   been made reality   in the right way. I I don't have a solution to this, but I think we should never forget the problem.   We can   become   2, developers, deployers, and so on that are twice as good that would not solve the problem because what percentage of the professionally educated population   can be full time developers. I don't know. 5%,   10?   So double that is still a tiny minority.   The remaining 90 plus percent, just like with today's   technology and education,   they can grab pen and paper and write a note   in a hurry without it it will not be grammatically perfect.  

The calligraphy will be inferior, whatever,   but they can get the message across now rather than wait for the scribe. We need to make a similar jump because today,   being able to hack together a small piece of software, a simple piece of software   is the equivalent   of writing a simple note in Egypt   25100   BC.  

[00:58:58] Unknown:

You know, it's really interesting. I've actually thought a fair bit about this because I feel like the the Macintosh   ecosystem   actually made great strides toward this. I I have admittedly only anecdotal evidence, but I have a fair bit of it that says that in the the early days of the Mac, comparatively early days,   with HyperCard,   it achieved something like that. I I've known a number of people who say that their relatives and families were able to build very useful HyperCard card stacks with   no preexisting knowledge.  

[00:59:29] Unknown:

So we just failed to keep   cultivating this. There's been a lot I've heard about HyperCard. So the I'm told the early days of,   VisiCalc,   the very first spreadsheet,   worked   that way, at least for people with, like, accounting skills or the like.  

[00:59:48] Unknown:

So for anybody who wants to follow you and keep up to date with what you're working on, what would be the best way for them to do that?  

[00:59:55] Unknown:

I'm not   very built into the whole social media slash global sphere. So I'll I'll try to do better in the future once the book is out,   like, maintain at least a blog   to discuss, the Python in a nutshell and related   and related,   subjects.   But for now, it not something I'm going to spend cycles for until until the national sum.  

[01:00:23] Unknown:

So with that, we'll take it on into the picks. And my pick this week is gonna be the movie, The Great Gatsby   with,   Leonardo DiCaprio.   And it's a remake of an old movie which is   a retelling of an old book. And the modern version of it, I think, does a really good job of telling the story.   It was very well put together, and the acting was superb. So I definitely recommend anybody who's interested, take a look at it. And with that, I'll pass it to you, Chris.  

[01:00:52] Unknown:

My picks this week, I've only got a couple. My first pick is,   once again, Stone Brewing, and they they can do no wrong as far as I'm concerned.   They make great beer.   This week's is the Stone Ruination Double IPA.   It's just it's a beautiful IPA,   nicely hoppy, really interesting, you know, complex notes,   very well balanced. It's just a great beer. So my second pick and last pick is a book that I've actually had on my shelf for quite a number of years, but I actually finally read,   recently.   I'm about 3 quarters of the way through it, and I really love it. It's called Ghost Soldiers,   and it is about the,   soldiers who survived imprisonment,   in the Philippines during World War 2 by the Japanese,   and the Bataan death march   and their, you know, eventual rescue from prison camp and some of the horrific   conditions that they lived under.  

It's really quite   a reality check   when you're sort of feeling whiny about your day to day life. It's like, no. You really you know, chances are you've got it pretty cushy. These guys can show you how how bad things can get, but it's a really great book, very much worth reading. That's it for me. Alex, what do you have for picks?  

[01:02:08] Unknown:

Can I also, ask a question about your pick? Because I remember   the original well, not the original. 1 of the many remakes of The Great Gatsby, Robert Redford and Maya Farrow and Francis Ford Coppola as the screenwriter   as really hard to surpass. Would you say DiCaprio   and who's playing with him? I don't remember the actress's name. But having not seen the original, I can't give a fair estimation of that. I will have to remedy that soon. Alright. I'll I'll at this point, I'll have to go see it just because anyway, my pick is a book out of which   the most successful   and most   unlikely,   musical comedy of these days has been made. It's,   Alexander Hamilton's biography,   a heavy ponderous tone,   that inspired   Miranda to   put it in music. He just couldn't believe   that this, dusty old   founding father had such an incredible   life. So whether you've already seen the musical, Hamilton   or not, you owe it to yourself   to get Ron Chernow's   biography   titled Alexander Hamilton, and give it a read. It's,   amazingly   well written. My wife and I enjoyed it enormously   before the musical   went out. And   when the musical got out, I said, oh, that wouldn't that it be fun   if this was a popular success and so happens it broke all records of popular success.  

But that's okay. Great music, acting, and so on. But the story itself in Czerna's book comes up so powerfully,   so richly.   This   impoverished   orphan from   the Caribbeans   making it nearly to the top of American politics.  

[01:04:05] Unknown:

Alright. Well, we definitely appreciate you taking the time out of your day to join us and tell us about your history with Python and a lot of the work that you've put into it in the community. So, yeah, just thank you very much, and I hope you enjoy the rest of your evening. Thank you for having me. Bye now. Good night.