The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers,   40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show. Your host as usual is Tobias Macy. And today, I'm interviewing Luciano Hamalio about the recent and upcoming changes in the Python language. So Luciano, can you start by introducing yourself?  

[00:01:07] Unknown:

Thank you, Tobias, for having me. I'm a self taught software developer who later in life got a degree in library   and information sciences.   I've been using Python since 1998.   Version 1.5   was the version then.   I'm now a principal consultant at Thoughtworks,   a software   consultancy   with offices in 14 countries and I work in their Sao Paulo, Brazil office.   And of course, I need to mention, I am the author of Rent Python.  

[00:01:42] Unknown:

Yeah. It's definitely how I first came to know you, but I've definitely seen you around a lot of other places as well. And the fact that you went from being a self taught developer to somebody who's so well known with having written such an iconic book for the Python community is a testament to your drive and your energy.   Oh, thank you. And do you remember how you first got introduced to Python?  

[00:02:04] Unknown:

Yes.   Totally. It was   98,   and at the time, I had left 1 of the first major   web portals in Brazil,   which was called Brazil online,   and then we did   a lot of things with Perl at the time there. Perl was the language   of dynamic web pages   back then.   PHP had just appeared. We started using PHP in in some new projects.   That was actually around 96.   In 97, I was working as a freelancer   doing web consultancy.   And then in 98   I tried Java for a while,   but I really didn't feel comfortable with it. So I decided to go back to Perl because Perl at the time had become object oriented   in Pro 5.  

And so I thought, okay. So now there's a solid, you know, stable release of Pro that's object oriented, and I was   a big fan of object oriented programming.   So let's try that again.   And then as I was reading lots of messages   in the   Perl mailing lists about how to do stuff,   often people commented, oh, this is how they do it in Python.   So the word Python in the sense as a reference to our programming language   appeared to me in messages in a Perl, maybe this where people were discussing   how to do object oriented programming in a dynamic language   that has many similarities with Python.  

Python started object oriented. Right? It was object oriented   programming or classes and so on. It was not something that was bolted on to Python. It was there since 1.0.   So after the about the 3rd or 4th   mention of Python in the mailing list, I decided to go check it out.   And I   read the tutorial, and I was in love with it immediately because for me,   it was the combination of the best features that I thought   Pearl and Java had,   but without   the worst features that, in my opinion, those languages had. So it had   you could write quick programs. It was very expressive and dynamic like Perl,   but it was also very readable like Java,   and it was really object oriented.  

It felt natural to program   to write object oriented programs in Python as it did in Java. And so   for me, it was like the combination of the best features of the 2 languages that I was   using at the time. So it was like immediately, I said, okay. This is my language.   And the next opportunity I had as a freelancer to present   a project to a client, I told him   I told her, it was a a woman   journalist,   that I was going to do it in Python. She didn't care. She let me do it, and now I had a case   suddenly. In the the end of 98, I had a case of a news website in Brazil running on Python,   And that helped me then start this   whole journey with Python.  



[00:05:13] Unknown:

And can you give a bit more of an overview about the role that the Python language and community has played in your career since that time?  

[00:05:20] Unknown:

It's super important.   I am now 57 years old, and I've started programming   as a kid with 16 years, I think, about 16, 15.   So I learned several programming languages before I learned Python, and I always enjoy I still do enjoy learning new programming languages. But I've never been   with 1 favorite programming language for so long,   and I think because I think Python has some   there was an old slogan about Python that said it fits my brain. Now that's what I think   Python does. It really fits my brain. It's natural to express   solutions   to problems   to many problems in Python. Of course, not all problems. Some problems   are hard to express in Python.  

So the impact on my career was at in in 99, I created a company that was   the first company in Brazil as far as I know that was doing   all work in Python,   and we did   server side web programming   in Python.   Well, we did client side too, but it was much simpler at the time. And then afterwards,   I started speaking about it at conferences. I helped organize   the Brazilian Python Association,   which we created to support   the local teams who were doing Python events   but needed a way to collect   sponsorships   and sign contracts.   So   I and a group of Brazilian Pythonistas decided that we needed an association   to help with that. And then   yeah, and then I started   when I could, I started going to conferences   in the US.  

And in at 1 of those conferences, I presented the idea of my book to O'Reilly in   2013. Took them about 2 months to   respond.   When they did, they said, okay. We like your your book idea. Let's go with it.   And then after my book was published, I was hired by Thoughtworks, which was a company that's always admired.   But to be completely honest, I did not have the courage to apply   for a senior position at Thoughtworks,   but they came after me. Then I went through their regular interview process after 6 interviews and programming exercises and so on. I was accepted.   I believe the fact that I had written the book was important for them to come after me.  

So, yeah, it's   it's been great. And now with the success of the first edition, which was released in 2015,   it has been translated   I wrote it in English, but it has been translated to 8 additional languages,   and it has been published in 10 different countries.   It's a big success   for a book that's not an introductory book.   It's a more of an intermediate and advanced book,   and it's opened a lot of doors for me. For in last year, I was really happy to go to China. I spoke,   Picon China in Shanghai.   Was an amazing experience to be there.   I also spoke at PIKON Germany in Berlin,   which was also great.  

And I've   been well, before the pandemic, I was traveling a lot speaking at Python conferences. But this year, I spoke at a few online Python conference as well.  

[00:08:38] Unknown:

Taking a bit more into Fluent Python, it's quite a substantial book, and I'm curious what your   inspiration and motivation was   for writing it and the actual process of going so deep into all the different aspects of language and helping so many other people level up their use of the language?  

[00:08:57] Unknown:

The idea of the book   I love to teach, and so   besides   I'm now working at Thoughtworks, but I also offer   workshops   in the on in the evenings. And also when   there are events, I often submit,   tutorials as well. I've presented tutorials at PyCon and other conferences.   Over the 20 some years that I've been using Python, I've developed a lot of materials to teach different aspects of the language,   and then I realized that   there's 2 things. First of all, a lot of people   this happens with any language. Right? When you learn a new language, you sometimes try to apply patterns that you learned in in a previous language to the new language, and that may or may not work.   Sometimes it does work, and sometimes it doesn't make sense to bring the that pattern from the other language to Python.  

So I gave a lot of emphasis on these aspects in my talks and my tutorials.   I also knew that there were some interesting aspects of the language that were considered intermediate to advanced,   which I thought was interesting to give more visibility to these ideas   because they actually   help people understand the language better as a whole.   So for instance, the special methods, right, also known as the dander methods, that's   it doesn't appear in the Python tutorial, for example. You can do the whole Python tutorial. They talk about dander in it,   and that's it in the Python tutorial, and they don't even I don't remember if they certainly, when I read, there was no mention of the idea of special methods. There was just this convention that the so called constructor was supposed to be called under init.  

But anyway,   I realized, for instance, that once you understand a little bit of the special methods and you you don't even need to learn them all, but few examples of what the special methods   do   and how they work and the purpose that they serve in the language, suddenly a lot of things   make sense in the language in ways that are amazing.   So I think 1 of the   more original aspects of Python   fluent Python, certainly by the time I wrote it, I don't know   this change, but at the time, I think it was the only book in the market   that talked about special methods in the first chapter.  

The first chapter is really an introduction   to what special methods are all about.   So   and all of that, both the thing about understanding   patterns that make or may not make sense in Python and also understanding   a little bit of the inner workings of the language with special methods and so on. Like I said, I've spoke a lot about those things   in talks and tutorials,   and I actually created a course   about 7 or 8 years ago that was called   Python for people who know Python.   And, basically, the book is   an outgrowth of that. It's a book intended for people who already know the language and are   probably using it in their professional lives, but want to understand more. That was my motivation.  

Writing a book is super hard, but 1 advice   that I followed   from,   another book called what's his name now? He wrote a book called Graphic Java.   David Geary. Yeah. His name is David Geary. He specializes   in writing books about graphics.   And 1 of his books in the preface, he says that his approach to writing a book is to   think about the   in in the start of the chapter,   think about the topics you want to cover in the chapter,   just an outline, and then you develop the examples.   The examples you are going to use to   explain that. And then the text   flows around the example.  

Right? The text is to explain the examples.   So I think this is a very useful approach,   and I recommend anybody who's gonna write a book about programming to follow it. Just, you know,   outline,   then the examples,   and then the text.   I call it example driven writing.   Right? Having the examples first   and then having to explain them   kind of focuses   your writing in the essentials.   You know? This is what I need to explain.   And things that maybe you find interesting but   are just   curiosities   don't need to appear in the in the main body of the text. In my book, I put those things   either in footnotes or in   sections at the end of the chapters called   soapboxes   where I am more opinionated.  



[00:13:38] Unknown:

Yeah. It's definitely   an interesting approach to   constructing it because, as you said, it gives you something to focus on as you're going through the chapter so that if you are just going pros first, it's easy to accidentally veer off into   side channels that aren't necessarily relevant to the topic that you're trying to cover. Whereas if you have something to focus your attention that you're   driving toward and you're structuring the pros as a means to get to the example and explain the example,   value   to increase their facility with it. It's definitely a valuable addition to the overall canon of resources that exist for the language because   it's generally very easy to find a lot of resources for newcomers to a particular language or newcomers to programming.  

And then you might also find resources that are very advanced, but it's often difficult to find that intermediate range of content. And the fact that you have such a substantial   amount of information in fluent Python to help those people go from beginner or intermediate through to advanced and expert level is definitely a valuable   addition to the ecosystem.  

[00:14:53] Unknown:

Totally. I think that's the reason why it sold so well because I was lucky at the time   when I wrote it. The 2 books that had more advanced   Python content, which was David Beasley's   Python essential reference   and Alex Martelli's   Python in a nutshell.   Those are books that go into details like descriptors and metaclasses and things like that. They were very outdated at the time. They were, like, you know, the latest releases of them were, like, 7 years old at the time.   So there was a need   for some more updated content in that area.   And it's interesting as I'm working now in the second edition,   the focus on the examples   means   that a lot of changes in the second edition. We can talk about that soon, but what I want to mention now is that in in several cases, I actually   simplified examples   from the first edition.  

Because then, you know, having a critical look at it a few years later, I realized, oh, you know what? This feature that I added in this example is a distraction.   Some easier way, they just hard code something.   Just yesterday, I was dealing with an example that had to do with dynamic attributes and exploring   JSON content   by implementing a class that dynamically creates objects with the attributes   of the JSON objects.   And I realized that there was a part of the original code that had to do with downloading this data source.   And I said, well, this is totally there was, like, a 1 and a half page in the book with the listing of that part and explanation of it. I said, you know, I don't need that. Just put the data   in the I can do that because it's an O'Reilly data source. So I just put the data in the   example code and just load it with   the file reads.  

That's just 1 example.   I continuously   updated the chap the the examples   and in some cases, simplified them.  

[00:16:56] Unknown:

Another interesting aspect of being an author of a technical book, particularly about a programming language, is that the subject matter doesn't stand still. There are continually   updates to the language and updates to the uses of it and updates to the   particular use cases and topics that developers are interested in. And that's definitely 1 of the more challenging aspects. And I think that because you do also cover a lot of the foundational aspects of Python, it's something that has aged very well because   dunder methods are still as valid today as they always were.  

But sometimes there might be new dunder methods added, or sometimes they might be deprecated. And that brings us to the   topic of what has changed in Python,   particularly since you wrote fluent Python, but also just in terms of your overall career and perspective with the language. And I'm wondering if you can just give a bit of an overview about what you see as being the   biggest changes that have occurred in the Python language and community in recent years, and I'll let you determine what that range actually is.  

[00:18:00] Unknown:

Yeah. So my book came out in 2, 015.   Right?   Python 3.5   had not been released   by the time I wrote finished the book.   It was, like, in alpha at some stage,   And the biggest change that happened was actually in Python 3.5, which is was the addition of   the typing module   and support for   static typing in the language. Right?   Of course, that was something that was kind of slow to catch on   because it was a major change and because the tooling around it, because it requires   external tooling,   was not, I don't know, was kind   of evolving, let's say, at the time.  

So, anyway, but certainly   over the years, this has become the major new thing in Python that   professional development teams have adopted   as something that you have to have in your code base.   And it was a change   that was sponsored mostly by companies   that do have huge code bases. Right?   So   Guido at the time   was working at Dropbox.   They apparently have millions of lines of Python codes.   And, also, there were type checkers developed by Google and Facebook.   So these 3 companies are companies that have   huge code bases in Python.   They hired   Guido was already working at at Dropbox, but, like, invited Le Hostel. I don't know how to pronounce his name. But, anyway, there was the guy who created Mypy.  

Mypy was his PhD dissertation,   and so we invited him to work for Dropbox.   And, of course, what they were working on was the typing   system. Right?   So that was the major thing that appeared. And the other thing that was an important change   was asynchronous   programming with the async await. I wrote about asynchronous programming in the first edition.   It was something brand new at the time,   but it was done with   the viewed from keyword.   And the API   also changed a lot because although   the asyncio module was part of the standard library   in Python 3.4,   it was provisional.  

And in fact, the only pieces of code in the book that broke over the years   were the examples using asyncio   because async   was the name of a function, for example,   in asyncio, and then it became a reserved   keyword.   And the API changed regardless of that in other aspects as well. The API improved a lot, actually.   I haven't written the that chapter yet   or updated it, but it's going to be a major rewrite and it's going to be simplified.   I mean, the explanations are going to be simpler, I think, because the API   is easier to use.  

I also created more examples during those years as I talked about   asynchronous programming in different events   that I'm going to use in the book. So I think those are the 2   major   changes.   Now I have to say, because if people follow me on Twitter,   they may know that sometimes I get involved in some   discussions about   new features of Python.   I now can say that I enjoy   the static typing system of Python.   Okay? I think with Python 3.9,   it got to a place where I really like it because we have the built ins   like list, dict, and so on,   supporting the square brackets for generics so you don't need to import so much stuff from the typing module.  

And another major improvement was the addition of protocols   in Python 3.8   typing dot protocol.   Without that feature, it was just not possible to annotate Pythonic code completely   before.   You either had   to dumb down your code to become more Java like   or   you didn't annotate it. That was the situation because Python is a language that supports dynamic typing,   and duck typing is is part of the essence of how you program in Python.   And if the static type system has no support for duck typing, then it's   very limiting.   And so now I'm happy with the type system,   but I'm still not happy with the fact that some people who are type system or static type evangelists   keep pushing the idea   that everybody should use it and that it's almost like a blasphemy not to   annotate your all your code with types.  

And I think that's not good because   for different use cases and different context of use of the language,   the type system introduces a complexity.   It always introduce a complexity, but the benefit you get from it varies a lot depending on your context. Right? So for people learning to program for the first time,   especially if they are not computer science majors. Right? Because people are learning to program in all areas. Now there's digital humanities, for instance, right, and data science   and scientific computing.   So there are many other areas where Python are used and there are actually   key to the recent growth of the language. It's the growth of the language in those other areas   apart from regular   server side   or infrastructure   programming.  

In those areas,   you know, it's debatable,   the benefit of you of annotating everything with types. There's a certain cost   that is higher to people that don't have a computer science background   to learning about, you know, concepts like generics   and covariance and countervaryance and so on. That's what I wish we had, you   know, more balanced.   It's clear this says the main types of typing that it's always going to be optional, but there are certainly areas or places   where treating it as completely mandatory.   I actually think that even in situations where you have professional developers, you know, with a lot of programming experience and computer science backgrounds and so on, choosing to annotate a 100% of the code base a mistake   because I actually found a paper that I quote in my book.  

So the paper is called Static Typing Where Possible, Dynamic Typing When Needed,   The End of the Cold War Between Programming Languages.   And it was written by Eric Meijer and Peter Drayton of Microsoft   in 94.   The abstract of this paper is really short, it says. This paper argues that we should seek the golden middle way   between dynamically and statically typed languages.   And let me just give you an example.   So this is actually happening. What we see is   there's   a kind of a limited but real conversions.   We have languages like Python   and Ruby that have always been dynamically   typed,   suddenly   adopting   static typing mechanism   that it hasn't appeared yet in pipe in Ruby, but in in Ruby 3. And then we have TypeScript,   which is basically   a superset of JavaScript with static typing.  

And also, on the other hand, we have languages such as c Sharp   and Go   and Kotlin,   not all Kotlin, but I will explain that in a minute, 1 variant of Kotlin.   These 3 languages   have a way of declaring a variable   of a type that is dynamic.   You're saying it basically have a way in Kotlin and and c sharp, the type is called dynamic,   and in Go, it's called the empty interface. So so it's the interface keyword with an empty brackets   besides   So, basically, when you declare an argument or a variable of those types, you're saying anything goes. Okay? And then to make that work, those languages have runtime mechanisms to actually   inspect what is there and then handle   whatever is there. And why   does that exist?  

In Go, the reason is to make it easier to talk or to write Go code that handles   data source that may be   unstructured or semi structured like JSON.   Right?   In Kotlin,   the variant of Kotlin that has the dynamic type   is called Kotlin JS. It's the 1 that targets   JavaScript.   So the compiler tar generates JavaScript code.   And the reason why they added dynamic to that variant of Kotlin   is to make it easier for Kotlin JS code to interface with the whole ecosystem   of JavaScript languages,   right,   that sometimes have APIs that are difficult to annotate   just like we have in Python. Some APIs that are traditional,   that are extremely popular like requests   that are super hard to annotate because of the way it handled all kinds of different parameters and so on. I totally believe in this. This the paper goes on to say that it's a fact that static typing   brings lots of benefits,   but it also   reduces   the expressiveness   of the language. There are some things   that I can there is Python code that you can write that you cannot annotate.  

For instance,   the type system in Python doesn't support   recursive types   So that's why, actually, there's no way to annotate   there's no good way to annotate   dynamic   JSON   in Python.   If if you're trying to annotate something that may return a JSON structure   that has nested   dictionaries   and lists,   If you don't have, recursive types, you just can't express that in the type system.   If you go to the   radical approach of saying, now in this team, a 100% of the Python code must be annotated,   that's going to generate unnecessary suffering   for the developers.  

Actually, that's the same thing with automated testing. Right?   It's great if you can have a 100% coverage, but it's not a very good idea to aim for it because sometimes there are some tests that are super difficult to write,   and they're   so expensive that they are not justified, you know, just the expense   of writing those tests. So it's the same, I think, with with typing. It's good to be   aware   that it's not a cure all. It's not a it's not something that is good for all teams. And even for teams   of professional developers, there are situations where it's better   to okay. You know what? I'm not gonna annotate this function because I really like the way it works.  

It's very expressive   and but it's not worthwhile to   to annotate it.  

[00:29:13] Unknown:

Yeah. I I definitely   appreciate   the typing capabilities like you, and I can agree with the the sentiment that it doesn't make sense   to have a sort of draconian mandate that everything has to be annotated because there are, like you said, a number of cases where it's not really possible to have full type coverage. And that's why you have some cases where the annotation of a parameter or an attribute is, you know, square bracket text comma any because, you know, when you have those nested structures, it's, you know, anything goes. So I mean, you at least know that it's a dictionary, but it still doesn't provide a huge amount of value. So in some cases, what's the point of even having there in the first place? Annotating anything with any type is, you know, essentially useless.   So, you know, typing and asynchronous programming are definitely the biggest headline changes   in Python in recent years, but there have also been a number   of more nuanced or smaller additions to the language or changes to the language. I'm thinking of things like the new parser that was just released in Python 3.9   or the matrix multiplication operator   and the Walrus operator and things like that. And I'm wondering if you can just give you a perspective   on the smaller changes that have been included in the language and some of the ways that it influences   the   way that the community develops around it, and also   from the other side, the reason   the the growth of the community has   brought on some of these additions or changes to the language?  



[00:30:44] Unknown:

So, yeah, thank you for this question. I want to address all 3 of the of these things that you mentioned. So the   warus   let's start with the   matrix multiplication   operator,   the new parser, and the wireless operator. So the matrix multiplication operator, I think, is a great addition because it's something that is   completely harmless   to people who don't need it, and it's super useful   for people who need it. Right?   I think it's an example of the core   developers being responsive   to a community that is   1 of the most important   communities of users   in the Python world   who are the, you know, the scientific computing community   and then the data science community   also.  

And it's very interesting that it's an operator that has it that has been implemented in Python 3.5,   but there is no, at least as far as I know,   no use of it in the standard library.   Nowhere in the standard library,   there's codes that uses   that operator.   It was designed really for external libraries that needed it,   and I cover it in the book and he give an example of it. I already did in the first edition as well because I thought it was interesting.   That's when I used the alpha version of Python to test that. But okay. So this is, I think, a very   minor   but good new feature.  

Of all the topics in in   computer science,   programming languages   are my favorite topic. So I like to learn about how they are designed, how they are implemented,   how interpreters and compilers work, and so on. And I think the PEG style of parser,   which is the new parser is a PEG parser,   is a great new development   in computer science as a whole as a recent thing.   I think 21st century,   the PEG parser.   It's a welcome development. What worries me about that development is that   I recommend to everybody who wants to understand the philosophy of Python   beyond, of course,   the the zen of Python   is PEP 3099,   but things that will not change in Python   3, 000.  

It was created in 2, 006.   So Python 3, 000 was the nickname at the time of the version of Python that was going to to be backwards incompatible   with Python 2,   and that eventually became Python 3. But they didn't want to commit to a time frame, so they called it Python 3000, like Python in the year 3000.   And 1 of the things that this PEP says,   it says no braces.   Okay? We are not going to introduce braces ever in the language for the purpose of delimiting blocks   and so   on. But 1 of the things that it says there is the parser won't be more complex than l l 1.   Right?  

So l l 1 is a category of parses that are the simplest parses,   and that was how the part Python parser has always been   before they adopt adopted the PEG parser.   So the PEG parser is more expressive.   What they say in this entry here, the parser would be more complex than l l 1 is,   simple is better than complex. This idea extends to the parser.   Restricting Python's grammar to an l l 1 parser is a blessing, not a curse.   It puts us in cuffs that prevent us from going overboard and ending up with funky grammar rules.   Right?  

So this was considered a feature, the fact that Python had a limited parser. And   I used to say that my second program favorite programming language was Ruby, now it's Elixir.   But Ruby has a very complicated parser. It's famous for its complexity.   And also so the syntax is extremely flexible that's why it's easy to do DSLs,   internal DSLs in Ruby,   but I always thought it was a misfeature of the language because it allowed you to write code that was super hard to read.   And I like the fact that the Python syntax was very simple. Now   with the adoption of the peg parser,   this limitation doesn't doesn't exist anymore   and it's amazing that immediately   after this new parser was accepted,   now they are talking about pattern matching   which is a feature   that would be very hard to implement with the old parser.  

Okay?   So it's like   opening the floodgates   of   evolving the languages in ways   that are not so simple.   So like I said, my second favorite language now is Elixir, and and Elixir is   heavily inspired   by Erlang,   which in turn is heavily inspired by Prolog.   And these are languages that are pretty much based on pattern matching. Pattern matching is part of the essence of those languages,   and I love it.   Okay?   I love pattern matching,   and I would   like to see it in Python,   maybe.   Why do I say maybe? It's because   it's   maybe   a very difficult feature to add to a language   that already exists   instead   of designing the language around the feature.  

You know?   And   and I think what we are seeing with this feature   is is kind of I don't know what's the rush, you know.   Now it's slated for Python 3.10   that's already   in alpha.   You know?   So people serious that they want to have such a major change in the language in the next year.   You don't need to use pattern matching if you don't want it. But that's kind   of not true because   if the feature is adopted, then it's going to be   popping up in the source code that people need to read. Right?   Just the fact that we already have 1, 2, 3, 4, 5   peps   about pattern matching.  

1 was superseded and replaced by 3 others, and then there's a 5th 1 that is already an evolution on top of the basic ideas.   You know, it's complicated. There are lots of corner cases,   and I wish people were more careful with this. 1 thing that somebody wrote in the Python dev mailing list that I think makes perfect sense to me is   1 of the things that pattern matching needs to have   is a way to express   parts of the batch   expression   that are constants.   Right?   So for instance, in Elixir, there's a a sigil. It's the caret character that you put in front of the variable to pin it, to say, okay. I want to match against the value that's already   in this position,   and I don't want to update this with whatever values in this corresponding position on the other side of the match. Right?  

So it's a big part of the arguments around pattern matching is how to do that, you know, if it's seduce or   some, like, a prefix symbol like that, or   if it's keywords or convey or rules that are super complicated   about where the symbol came from. Is it that global or I don't know.   And somebody said, you know what? Here's a thing that Python maybe could have, which is the concept of a constant,   a real constant.   You know? In the static type system, there is the final declaration.   But in Python outside of the static type system, there is no way to declare and enforce   at runtime   that a symbol refers to a constant. Right?  

Perfect sense to me. Maybe we should fix that first.   You know?   This is a simple change.   This is much simpler than pattern matching. Just let's introduce   a way to have constants in the language,   and then then we can rethink the whole pattern matching idea after that is incorporated and used.   You know?   Like I said, I'm totally for having a modern   parser,   and I like the feature of pattern matching in other languages. I'm not sure if I like it in Python,   and I am   afraid that   the commitment to a simple syntax   is going out of the window   because now we have a more powerful   parser.  

You know?   And the third thing that you mentioned, the virus operator   is something that,   of course, is not as complicated as pattern matching,   but it is something that has the potential   of popping up   across code bases.   And as somebody who teaches,   often I teach people who are learning to program for the first time,   that's not an easy feature to explain, you   know. This other way   of doing assignments,   but this way also works as an expression. So you have to explain this idea   of an expression.   It's   versus a statement.   You know, what's the game? I think it's so small.  

In my opinion, it's not a feature that is worth its cost in terms of   complicating the language, but it's not something that is   as serious as pattern matching. Pattern matching, like I said, I'm not against it in principle.   I do think people are rushing it. You know, just the fact that we've had   probably   more than a1000   messages already about it.   And 5 peps   to me is a serious indication that this stuff is complicated and that we should take it slow.  

[00:40:48] Unknown:

Yeah. I really appreciate that you went on to discuss the pattern matching PEF because that's another thing that I've been tracking as well and wanted to ask you about, so you saved me the trouble.   And to your point too about   the complexity   that that introduces   and the complexity of things like assignment expression to the Walrus operator.   1 of the key benefits of Python   over the course of its history has been that it's a very approachable language. It's very easy to   learn the syntax and be able to explore it. And then there are multiple layers where you can dig deeper   using things like the Dunder expressions or metaprogramming   and abstract based classes.  

And I'm wondering what your thoughts are on how the current evolution of the language   affects   that selling point and   the challenges that you see people come up against who might be familiar with Python   and have been using it since maybe the 2.x days or started with 2.7 or earlier versions of Python 3.   What you see as being the cognitive cost of   learning and trying to incorporate some of the new capabilities of the language and   some of the attrition that that might lead to?  

[00:42:05] Unknown:

So 1 thing that I think the community   needs to recognize   is the ease of learning Python   is   its strongest points. Right? And the fact   that it was adopted   so how is it that Python is so successful today? You know? If you look at Ruby   and Python, do a Google Trends search over the last 15   years   with Ruby language and Python language.   You're gonna see those languages having   a kind of a parallel growth   for a while,   and then Ruby went into decline.   And at the same time, Python started to take off faster.   Right? To become, like,   now   certainly 1 1 of the top 3 languages   in the world. It's super hard to evaluate that, but different   statistics   and   publications   put it in the 1st, 2nd, or 3rd slot.  

Right?   So what happened? Data science happened. But how did data science happen?   Data science happened because   scientists   who are not   mostly,   you know, computer scientists, but, you know, physicists,   chemists,   biologists,   engineers of other areas, you know, materials engineering,   other areas of engineering,   and   people in the humanities.   Anyway, users that are not the typical users of what   Ruby uses   are even today or Python users were at the time, like 15 years ago.   Basically, physicists at first recognized the value of having a glue language   that was simpler   to use, to learn,   to   to glue   functionality implemented in Fortran or c plus plus. Right? And Dave Beasley made a   huge historical contribution   to that because he was the author of SWIG   and was the library to do that bridge to bridge   c plus plus code bases with Python.  

And so then the scientists started   building these bridges and using Python as this glue language.   And then when data science   or machine learning emerged, I'm old enough to remember the old AI   trends in the seventies   where it was all about symbolic computation,   and then there was a lots of promises that were unfulfilled.   And then there was a time that was called the AI winter   in the eighties,   early nineties because all the funding   went away   from AI because too many unfulfilled promises.   And then this other area of research appeared that was called machine learning, and I remember my first reaction when I said machine learning and I read what it was. So, okay. So these 2 things to say about that. First, they were smart enough to not use the AI term, which was   kind of   had a bad reputation at the time.  

So machine learning is a good alternative name. And the second thing is they are using a completely different approach, which is not symbolic computation at all, but numerical computation.   So that was the gist of what machine learning was about as a major trend in computing.   And it turned out that there was this language that was very high level   and that had already a huge ecosystem of libraries to do, for instance,   linear   algebra   that are the foundations of machine learning and that those libraries already existed in Fortran and c plus plus and they were bindings for Python that had lots of users that worked well.   So that's how Python took off.  

But at the origin of this story is the fact that the language is approachable. Right?   The physicists picked it because it was approachable,   and then everybody else started using it because using Python because it was approachable and because   it had the backing of the scientific computing community   developing all the libraries   that turned out   became   the core of what machine learning is,   but they were not designed for machine learning. They were just, you know, general scientific   computation   libraries.   And and, of course, our whole ecosystem   designed for us, but machine learning specifically   was built on top of that.  

So this is really the crown jewel. You know? The reason why Python is successful   is because it is approachable to a wide   variety   of users.   And that's why too much emphasis on typing for me is bad   because it may scare away   new users of the language.   You know? It worries me that   some changes are I must say that there   were changes made in the language that are super sophisticated   things that were added to the language in a way that didn't affect   negatively   the life of users.   And that was important since Python 2.2   when the new style classes were introduced   that had the cons the concept of descriptors   which is underlying technology of   properties,   but also the underlying of technology of ORMs like the Django ORM where you declare   fields   in a database in database table.  

So   descriptors   were an addition to the language   that   made it super powerful   and also metaclasses   also at the same time with the Python 2.2.   But there were things that you didn't have to learn to use the language. At the time, when Python 2.2 was released,   actually, for me, it took   several years   to actually   go and study   metaclasses   and descriptors   because I was an occasional user of properties,   and I was   a regular user of   Django   and its model classes.   But I never stopped to think about what that meant really, and I didn't need to. You know, I was happy coding   my jungle classes without knowing what a descriptor is.  

And so I think this is a characteristic of a good language feature. It's something that enhances the language for the more advanced users,   allows the more advanced users to provide facilities   for the   other users,   but doesn't   intrude,   you know?   That's what I think we need to go after.   It's a problem of open source in general. Right? I am a big defender of of open source, free software, whatever you call it. I'm a big defender of that, but it's a known issue   that when you have volunteer developers,   sometimes there's a lack of alignment between the needs of these core developers   who often work at big corporations and have, you know,   deep technical backgrounds   with the needs of other users of the tool. Right,   who are less sophisticated programmers and who would have a very hard time contributing to the core of the language baiting or even participating   in discussions like the ones that we are having about, pattern matching.  

So   there's this skew   towards the needs of the more sophisticated   users of the language, and I don't know how to counterbalance   that.   I think Guido did that for a while,   but   I also know that he was behind. He was a supporter of the wireless operator and also a supporter of the pattern matching now.   So   I think the steering committee that replaced Python as sort of the providing   more of a vision   to the language needs to   be aware of these things.   You know, because at the same time, it's obvious that features like typing and pattern matching   occupy a lot of the bandwidth   of the   core developers. Right? Just the sheer amount of   PEPs. There's more than 17 PEPs about typing   and all the discussion that goes   around each PEP and implement the and the changes in the language and so on.  

This takes a lot of oxygen out of the room, and if you did some   research, the wider community,   you would probably find people   would prioritize other things like for instance, better   performance with multi core machines,   you know,   better support for   programming mobile applications.   Yeah. Actually, that's the number 1 thing. You know, if I had 1, 000, 000 of dollars,   I would provide grants   for   the people in the Bware project and, you know, other projects that are aiming to do make Python a viable language for mobile development.   I think this is the biggest weakness today.  



[00:51:01] Unknown:

Yeah. And as   a somewhat tangential aspect to   mobile development and multiplatform   usage is also the question of packaging and distribution, which has been solved for some cases, but is still a glaring absence for others, particularly in terms of distributing applications to end users, which is something that there is ongoing work for. But as you said, it doesn't seem to be taking the kind of center stage for the people who are driving the direction of the language.  

[00:51:30] Unknown:

Oh, yeah. Totally.   It's interesting because that aspect that you mentioned,   the packaging and ease of distribution   of applications to end users,   and the other 1 that I mentioned   about better multicore   performance   are probably 2 of the key reasons why a lot of people who like Python are now using Go   because it's just such a pleasure to write something and compile it into a static binary,   you know,   and give it away,   deploy it, whatever is a static binary.   Awesome. You know?   Yeah. The story of packaging in Python has always been   problematic.  

So Dropbox obviously solved that problem. Right? Because I think Dropbox still uses Python in its client codes   everywhere in all platforms. In or at least in all desktop platforms,   there's a Python   interpreter hidden inside the Dropbox app that you install on Windows,   Mac, and Linux.   But I wish they contribute to that   technology or some of the technology they developed over the years to do that.   But,   maybe they do. I'm I'm not aware. But,   yeah, you're right.   Like I said, I learned to program when I was 16 years old.   Recently, between   writing the first and the second edition of fluent Python,   I thought about writing   a book for introducing programming. Right?  

And then I was thinking of doing it maybe in Python, but then I discarded Python   because   of   the   lack of   easy   support for packaging   applications for   mobile   platforms.   I think because I was thinking, you know, if I was today   15 or 16 years old   and I was interested in learning to program, I would want to learn to program   for the smartphone. Right?   For me, this would be appealing. But writing programs that basically   print stuff on the terminal,   You know, first several weeks of learning to program is not so great. And then doing web development,   which is something that, you know, when I was learning to program, I wanted to be able to show the things that I was doing to   my family and my friends and have them find it interesting   at some level. And it's hard to show something that's printing out stuff in the terminal   to somebody else who is not in IT and they find it interesting.  

Well, anyway, now I'm writing with Python again,   but I do plan to   maybe I'm not saying when I start a new book immediately. This is such a marathon. I need to have   many months away from the commitment of writing every day.   But I do have plans for content for   teaching people to program from scratch.   And I hope that when I do come back to this project,   Python is better suited for that.   And I think a way that it would be better suited for that would be to have better support for mobile   applications.  

[00:54:41] Unknown:

So there are a number of other topics that I'd love to dig into with you. It's definitely been fun exploring this subject matter. But just wanted to see if there's anything else in terms of some of the recent changes to Python or   features or changes to the language that you're particularly keeping an eye on or invested in or worried about that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:55:05] Unknown:

Yes. Like I said, when I talked about concurrent   programming with multiple cores,   there's been some discussion and even a PEP written   about subinterpreters,   which is apparently kind of a dormant feature of the Python interpreter that's been around for many years,   but the idea is not to expose it to end users.   There's been a lot of discussions about it that people were saying that it was difficult to implement it in a way that didn't break   external libraries,   and that's where   our really   the strength,   right, when when we talked about data sciences in the external libraries,   we can't afford to break them at all. That's probably the main reason why PyPI   is not more popular today is because of incompatibility   with third party libraries   and c and Fortran and so on.  

But, anyway, so   I wish there was a solution to this problem of multicore programming,   but I do want it to be well considered and something that will not   break. We don't need any more breakages. I think 1 of the things that I like to say to people that are newer than I in the Python world is that everybody has been   through the trauma   of the Python 3 migration.   Right?   Python 2 port 2, Python 3. And I want to say to everyone that this is not typical,   what happened because I was around when Python   1.5   became   2.0.   There was also, like, a transitional version 1.6,   which was sort of like 2.62.7   that backported some features of Python 2   to Python 1 at the time,   but   the transition was super smooth.  

Most programs just simply continued working   with the transition from 1.51.6   to 2.0.   And, really, some very advanced things broke, but most user code just worked.   And then when the new style classes were added in Python 2.2, that was also done in such a wonderful way that basically   nothing broke.   And so that's I think this commitment to backward compatibility was always very   much part of the core developers,   and I think they still have that. They   decided to do Python 3, basically, to fix the Unicode issues.   I was   totally supportive of that change.  

I do think it was obvious that the cost was huge,   but I don't think we're gonna see that in the future.   And I think we're gonna have a a smooth evolution of Python.   And so with that in mind, I hope the language continues to evolve, but I think we should be careful about things that break   existing code and also things that make it harder to   teach the language.  

[00:58:05] Unknown:

Well, for anybody who wants to follow along with you and get in touch, I'll definitely have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks.   And this week, I'm going to choose   the Magic the Gathering Arena platform for being able to do online play. I think they did a really good job of making a pretty polished product with that. So for anybody who's interested in trying out something to play a game and, you know, maybe interact with some other people, it's definitely worth taking a look. And so with that, I'll pass it to you, Luciano. Do you have any picks this week?  

[00:58:38] Unknown:

Well, I really enjoyed very much watching The Queen's Gambit.   I think it was wonderful in many aspects.   I was really thrilled to read that the sale of chessboards and chessbooks   increased because of the miniseries.   I recommend everybody to see it. Yeah.  

[00:58:59] Unknown:

Well, thank you very much for taking the time today to join me and share your experience working with Python and your perspective on the ways that the language has changed and evolved over the past few years. It's definitely been a lot of fun, and I definitely would like to have you back anytime you're interested.   So thank you for all the time and effort you've put into helping to educate the Python community, and I hope you have a good rest of your day. Thank you so much, Tobias. This was a pleasure for me too, and I look forward to talking to you again. Bye bye.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast.com   for the latest on modern data management.  

And visit the site of python podcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastthenit.com   with your story.   To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.