How Python's Evolution Impacts Your Fluency With Luciano Ramalho

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Unknown (00:13):
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,

(00:35):
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?

(01:06):
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,

(01:27):
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.
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.

(01:59):
Oh, thank you. And do you remember how you first got introduced to Python?
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

(02:23):
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,

(02:45):
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.

(03:06):
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

(03:29):
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

(03:51):
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

(04:13):
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

(04:38):
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

(04:59):
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.
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?

(05:20):
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

(05:41):
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

(06:02):
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,

(06:26):
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

(06:49):
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.

(07:13):
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.

(07:39):
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,

(08:00):
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.

(08:22):
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.
Taking a bit more into Fluent Python, it's quite a substantial book, and I'm curious what your

(08:43):
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?
The idea of the book
I love to teach, and so
besides
I'm now working at Thoughtworks, but I also offer

(09:06):
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,

(09:27):
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.

(09:50):
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

(10:10):
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.

(10:41):
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.

(11:03):
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

(11:24):
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,

(11:45):
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.

(12:08):
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

(12:29):
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.

(12:51):
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

(13:12):
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

(13:32):
sections at the end of the chapters called
soapboxes
where I am more opinionated.
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

(13:59):
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

(14:26):
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

(14:51):
addition to the ecosystem.
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.

(15:11):
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,

(15:34):
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.

(15:59):
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.

(16:24):
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

(16:47):
the file reads.
That's just 1 example.
I continuously
updated the chap the the examples
and in some cases, simplified them.
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

(17:10):
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

(17:34):
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.

(17:59):
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

(18:20):
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.

(18:42):
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?

(19:05):
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.

(19:25):
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

(19:46):
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.

(20:07):
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

(20:29):
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.

(20:52):
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.

(21:12):
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,

(21:33):
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

(21:55):
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,

(22:16):
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

(22:36):
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.

(22:57):
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

(23:19):
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

(23:44):
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

(24:08):
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.

(24:31):
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

(24:56):
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

(25:18):
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

(25:39):
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

(26:05):
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?

(26:25):
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

(26:47):
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

(27:08):
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,

(27:29):
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

(27:51):
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

(28:13):
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,

(28:38):
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

(29:00):
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.
Yeah. I I definitely
appreciate
the typing capabilities like you, and I can agree with the the sentiment that it doesn't make sense

(29:21):
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.

(29:56):
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

(30:17):
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

(30:37):
the the growth of the community has
brought on some of these additions or changes to the language?
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

(31:03):
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

(31:24):
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.

(31:46):
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

(32:11):
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,

(32:33):
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

(32:54):
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,

(33:16):
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

(33:38):
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.

(34:00):
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.

(34:25):
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,

(34:48):
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

(35:09):
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

(35:31):
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,

(35:57):
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.

(36:19):
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.

(36:44):
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

(37:04):
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

(37:29):
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

(37:51):
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

(38:12):
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.

(38:32):
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.

(38:53):
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,

(39:18):
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,

(39:41):
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

(40:06):
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.

(40:28):
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.
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.

(40:57):
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

(41:22):
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

(41:43):
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?

(42:04):
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

(42:24):
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.

(42:46):
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?

(43:08):
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.

(43:29):
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

(43:50):
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

(44:12):
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.

(44:33):
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

(45:02):
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

(45:27):
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.

(45:50):
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

(46:10):
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

(46:31):
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

(46:52):
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

(47:14):
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

(47:34):
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

(47:55):
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

(48:18):
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,

(48:39):
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

(49:03):
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.

(49:26):
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.

(49:48):
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

(50:11):
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

(50:33):
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.

(50:58):
I think this is the biggest weakness today.
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.

(51:30):
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

(51:53):
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

(52:19):
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.

(52:40):
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

(53:06):
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

(53:28):
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

(53:50):
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

(54:11):
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.

(54:33):
And I think a way that it would be better suited for that would be to have better support for mobile
applications.
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

(54:55):
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?
Yes. Like I said, when I talked about concurrent
programming with multiple cores,
there's been some discussion and even a PEP written

(55:15):
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

(55:37):
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.

(55:59):
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

(56:19):
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,

(56:41):
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.

(57:02):
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

(57:25):
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.

(57:47):
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.
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.

(58:15):
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?

(58:37):
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.

(58:58):
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.

(59:31):
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

(59:52):
with your story.
To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.

All Episodes

Summary

Announcements

Interview

Keep In Touch

Picks

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

Las Culturistas with Matt Rogers and Bowen Yang

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}How Python's Evolution Impacts Your Fluency With Luciano Ramalho