Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 299, recorded August 31st, and I'm Brian Okken.
Hey, I'm Michael Kennedy.
And I'm Wilma Guggen.
Will's also known as usually the topic of Python Bytes.
Time to time you mention me.
So, it's awesome to have you here.
But you're part of Texturalize, right? Or you are Texturalize.
That's right. I guess I'm part of Texturalize.
We are a company, a very small company, but we're a tech startup.
We have three employees, and we'll have five in a few months.
Nice.
Yeah, tell us a bit about it.
You know, people know, that's amazing.
Tell people about it.
They know about Rich and Textural, perhaps, because we talk about all the things that are adopting Rich.
But you actually have a company around that, which is super fantastic, right?
So, the model is we're building Textural, which is going to be like a free and open source project distributed through PyPy.
And then, somewhere down the line, we're going to make this web service, which takes those applications and then serves them on the web.
And it'll be like a nice free tier, but we'll be able to add services on top of that, which we can, you know, charge a subscription for.
That's fantastic.
Like, like 2Es as a service.
2Es as a service, yes.
There you go.
A TAS.
A TAS platform.
All right.
Cool.
Well, it's great to see all the progress there.
It is.
Brian, am I up on the first one?
You are.
So, this one comes to us from John Hagen.
Thank you, John, for sending this in.
IPI, as the warning is gone, but they were under a pretty heavy phishing attack.
And they wanted everyone to know they had this big banner that was letting anyone who maintains a package is really where the problem lies.
If you maintained a package, like, say, rich, the goal of this phishing attempt was to get your credentials so that you could then, so that they could sign in and put malware into that package.
The more popular, the better, I presume.
So, this was a couple days ago, August 24th, so like a week or so.
So, today we received reports of, this is from PyPI, the Python Package Index.
Today, we received reports of a phishing campaign targeting PyPI users.
This is the first known phishing attack against PyPI.
We're publishing the details here to raise awareness of what is likely going to be an ongoing threat.
There was many comments and quote tweets and so on.
It said, "The background of the phishing message claims to be there's a mandatory validation process being implemented, and they invite users to follow a link to validate their package, like a so.
Otherwise, their package will be removed."
So, importantly, they say, "Note, we will never remove a valid project from the index.
PyPI only removes projects which violate their terms of service or in some way determined to be harmful, for example, malware."
This takes you over to this site, if you were to click the link, to, if you look carefully here,
sites.google.com/view/ipivalidate/validate-by-pi-package, or some kind of redirect.
And it does bad things when you fill this out.
It just posts the form to somewhere else.
So I guess they were hosting it on google.com, sites.google.com, in an attempt to avoid the domain getting blocked, something like that, right?
But it posts over to linkedopports.com or something.
I don't even know how you pronounce that domain, but don't go there.
It's not good.
And it says, "The malicious releases follow a pattern, exotel."
And I kind of laughed, even though it's not really funny.
One of the packages that got phished through this email is called spam.
I don't know what spam does.
But if you were like phished because your package, if you were phished by spam and your package is called spam, there's just, it's just too much meta for me.
Will, did you hear about this?
Did you get any notifications for your packages?
I didn't, but I could see how, if I got that early in the morning, I could fall for it.
Yeah, exactly.
You're just waking up.
Before my coffee.
Not another thing I got to do.
I feel like they're taking a little bit of advantage of the notifications coming from the Python Packaging Authority, where they've been sending out messages about security and about packages.
And there's the critical packages.
Will, I saw you tweet and Brian was like, "Wait, what is this?" about what is a critical package the day that stuff came out.
And so, you know, it kind of, I think is trying to hide under that, that noise and slip through the cracks there a bit.
I think I don't get very many notifications from PyPy.
I think the fact that I don't get very many, I might just take them at their word.
If you get a lot of notifications, you might learn to recognize what is a legit notification and what is some kind of phishing attempt.
So you're asking PyPI to send us more email?
No, not really.
Funny.
So you can actually look at what the code does that is the malicious versions.
They said they've taken down and they've taken down several hundred typosquatting ones that also do a pattern.
So you can just set up the code.
So you can just set up, you can just set up, you can just set up, you know, it's just hijacking the most used function or feature.
So you can just set up, you can just set up, you can just set up, you know, it's just a good thing.
So you can just set up off of this malicious place.
So you can just set up the code.
Download it with requests and then write it to a file and then just execute some executable.
And that's pretty much what it was doing to all or attempting to do all these packages.
It's kind of lazy this malware is not cross-platform when he works on Windows.
I agree.
Come on.
Well, I mean, also, they're looking for investors so that they can, like, expand to other platforms.
Maybe they'll get a macOS and a Linux one coming at some point.
Just hope our VZ is listening.
Yeah, exactly.
Like, here's an opportunity to, I don't know what it does when it runs, but it can't be good.
Whatever it does.
Can't be good.
Now, I remember I got an email from someone and I'm sorry I didn't pull the details together as part of the write-up here saying, I think it was on Twitter, a DM that said, you're probably going to talk about this.
The 2FA wouldn't necessarily help you because if they asked for the 2FA, you're going to enter it in maybe there and it might, you know, pass it through as part of the process as well, right?
It could maybe get a software-based 2FA and use it.
But you know what does help with this really, really well?
Password managers.
One password, LastPass, and so on.
If you go there and it says enter your password and you hit the hotkey to like fill out the site or you click in there like with one password, if you just access it with the latest version, it'll automatically drop down or suggest the dropdown for the site.
If you do that, it will not come up with anything because you don't have an account at sites.google.com, presumably for this login, right?
Yeah.
And so some combination thereof, I think, you know, at least I always, if I go to a site, the less sure I am, I like double check.
Does the password manager think it should fill this account into this website?
If it says no, then I triple check it.
It's not just like, oh, the password manager is not working.
Let me just copy it over, you know?
Anyway, there's some more details in here.
You can read about what they're doing and what you should do.
Some ideas on how to verify the signed certificate.
I would prefer to just use a one, just a password manager right away instead of trying to follow the chain of the cert, but you can do that as well.
Anyway, it says it's got a lot more details there if you want to check that out.
What do you all think?
Yeah, it's interesting.
And it's an ongoing threat.
I think if you're an internet user, you're getting bombarded with this.
With PyPy, if they get a hold of your, it seemed like it was more like attacking individuals.
Were they trying to get your credentials to like install malware in your Python packages?
I'm pretty sure what they were doing is they were publishing a new version of your package.
Ah, okay.
And the new version had malware in it.
Yeah.
So, yeah.
That would be a huge concern.
Yeah, yeah.
It says, yeah, we've additionally determined that some maintainers of legitimate projects have been compromised and malware published as their latest release for those projects.
Their accounts have temporarily been frozen and the bad versions removed.
But that's what they were trying to do.
Okay.
Well, good on them for catching it.
Yeah, for sure.
I love how Seth out the audience says, another win, W-I-N for Linux on the desktop.
Yeah.
How about that?
Yeah.
Or Mac.
I'm like, well, that wouldn't hit me at all.
Yeah.
However, anybody, any package that you publish, it would affect your Windows users if you were the maintainer.
Which is half the users, as we know, about, you know, half, at least half the operating systems are Windows.
Yeah.
Yeah, yeah.
Not so good.
So Seth also points out that the timing of this phishing combined with Dustin mentioned there hadn't been any phishing attacks or something like that.
It's in Dustin Ingram.
Don't give people ideas.
If, by the way, you want to hear more about this, I did interview Dustin with us like three weeks ago or so on Talk Python, talking about Python packaging and security and supply chain stuff.
But all that predated the phishing side, but not the malware side.
So people can check that out if they want.
Okay.
All right.
Anyway, make sure that you don't put your password for PyPI in the wrong place.
Yeah.
All right.
How about we talk about something nice?
Yes.
Friendly.
We can have nice things.
Like Python being on top of the IEEE spectrum languages.
So it has been for a while.
So we're just reviewing this to say, yay us, partly.
But there's some interesting information here.
So if we go through the review stuff, there's a cool chart.
So the top programming languages of 2022.
Python's at the top.
It's both the spectrum survey.
Actually, I don't know where the spectrum number comes from.
I assume it's a survey thing.
And then trending.
It's on top also.
A little different.
And cool animation graphics on there.
But one of the interesting bits is in jobs.
If you look at job listings.
I think they were looking at job listings and requirements.
SQL is at the top.
And this is a comment because it's not just SQL.
They're not going to just say, we need somebody that knows SQL.
But it's like Python and SQL.
Or Java and SQL.
Or JavaScript and SQL.
The end SQL part is coming in a lot now.
And actually more than it used to.
Which is interesting.
There's also a related article on the same on IEEE as well called The Rise of SQL.
And it's really talking about that.
It's not just because.
I mean, I do remember SQL has always been a part of programming.
Or it has been for my career.
But it's often been a larger thing.
It's not something you do in a small application.
It's something in the server or large applications.
But it's growing in using it for even little small things.
And a lot of applications, you don't have a specialist doing the database stuff.
You've got the developers doing the database everything.
So anyway, I thought that was interesting.
That just the highlighting that SQL is and always will be important.
And it's even growing in popularity.
It's interesting that ORMS haven't made a dent in that.
You know, I used to use Django ORMS back in the day.
I didn't have to touch SQL.
But clearly, people are not using ORMS that much.
If SQL is like top of the charts there.
My first thought when I looked at this was there's probably a lot of data warehouse, data lake, semi-structured data that people are exploring with SQLs and queries before they lock it down and productionize it with an ORM or something along those lines.
Right.
Like the data science side.
If a lot of that data is dropped into a database by an API or some web scraping or something, and then you have to ask it questions.
And like knowing the SQL is the asking arbitrary questions of the data before you really know what questions ask is my first thought.
But yeah, ORM is all the way for the win.
For me, I don't want to do straight SQL.
There's also a growing thing of just doing a small, like a SQLite.
Just the knowledge that SQLite is everywhere.
And I don't know if SQLite has any effect on this or if Simon Willison does.
Because he's with data set taking like CSVs and stuff and turning them into little SQLite websites.
But things like that have just even services and smaller applications collecting data.
Isn't there a JavaScript API to SQLite?
I think there's all languages have, I think, APIs into SQLite.
I think something built into the browser is local storage.
Does that not use SQLite or am I mistaken?
Don't think that that does.
But it's very similar if it's not the same.
It's like, yeah, what do they call it?
Local SQL or local DB, something like that.
I wonder if that's contributing to.
Yeah.
Dave out in the audience says, I wonder how the jobs one was measured though.
SQL can be one of those not really considered must have items that often goes into the list of requirements.
You really could just use an ORM.
Yeah.
And that might be the case.
But even with ORMs, sometimes you got to get in there and find out what's wrong.
Like do optimizations and things.
Yeah.
Kim out in the audience says, is it becoming less common for developers to know at least enough SQL to be dangerous?
I think that that's the minimum bar for what you should know to use an ORM.
You should know kind of what's happening.
You should know what a join is and that you might want to do it so it doesn't do 50 queries.
You do only one and things like that.
Yeah.
But yeah, very, very cool, Brian.
Well, where are we at next?
Well, I think Will is up.
What have you got for our first one, Will?
Oh, I'm on the wrong page.
So I came across this article.
It's by Charlie Marsh about using my pie in production at Spring.
And I looked at Spring and it's some kind of interface for researching medicine.
But he was saying that they have a big project, 300,000 lines of Python.
And they started typing it.
And that was a few years ago.
And they've since typed the entire code base.
And they were very impressed.
It's reduced bugs and made things more maintainable.
And even have all the strictness settings on to Max.
I'm a big fan of typing, but I don't have everything on Max.
I relax it just a tiny bit.
But they've got all the settings on there.
So he covers the basics of typing.
There's some interesting stuff about the history of typing.
Right.
It's interesting how typing started.
It didn't spring out of nowhere with the same goals.
It did actually evolve through various other projects.
Originally, when mypy started, I think they were building something that was
essentially more like mypyC.
It was to run Python with typing.
To use the typing to actually sort of transpile to another language almost, right?
Yeah.
And then it turned into a type checker, which didn't actually run your code.
It just analyzed your code.
So it's quite an interesting article.
They covered how it started and go through a bunch of their experiences.
With typing, in mypy in general, they cover improved readability.
That's a big one for me.
I love typing.
I find it makes code more readable.
Some people would disagree because you add lots of these annotations.
And some people find that clutters your code.
I find it super helpful to understand other people's code and to understand my code.
Because I don't have to remember the types of everything when I can just see them written
down.
Yeah.
I'm totally with you on that.
I think there's a fear that, oh, look, Python is becoming like C++ or something.
But it's nice and clean and it's simple until you're focused on some area, some function
or a class or something.
You're like, well, what happens here?
You can either go read the documentation, try to put it together, or you can go find all
the places it's used and try to put it together.
Or if it has types, you don't have to go do that exploration, right?
You're just like, okay, this is an integer and this is a list of users.
I know what's happening now.
I don't need to hold more information in my brain.
And I think that makes it great.
The shape of data is what really helps me.
Like you mentioned, like a number or a list or something.
But sometimes things can either conceptually, an argument to a function could be one thing
or it could be a set of things.
Is it expecting if it's just one thing, can I do that?
Or is it expect?
And types can give you that.
And one of the things you mentioned, which perfectly sums up my philosophy for typing is
I don't want to do it, but I want everybody else to put types in there.
Because it's readability counts.
Also, Mr. Wilson in the audience points out typing greatly assists with co-completion
for the editors.
Yeah, it's got a bunch of tangential benefits.
It's not just the one benefit.
I mean, it catches bugs.
But even if it didn't, even if it didn't, I think typing would be an excellent addition
to Python.
I agree.
If I can hit dot and it gives me more help, I'm already happy.
Yeah, bingo.
Yeah, I love typing.
This is a very nice article.
I'll let people read it.
Yeah.
They also talk about the pain points of how that was painful for them.
I think trying to get mypy to completely analyze everything is a different level of, I want my
public interface to say what it returns.
You know, there's like, you got to decide where do you live on this spectrum?
And what are some of the goals?
Like catching bugs, it's more important to have everything covered.
There's documentation, you know, a little bit less, I think.
Yeah.
I found it's changed my programming style.
The code I write is less dynamic.
I'm more likely to fix types quite early on.
And I don't do any, well, I don't do too much get atter and set atter.
Yeah.
And I don't use all the dynamic capabilities of Python.
I prefer to write static code that looks a bit more like C.
So I can understand why people have that.
They feel like it's taken away a bit of freedom from them.
But I do think it's given you the freedom to write solid code that doesn't have, you know,
no attributes on none type errors.
Yeah, I agree.
I think you compare it to things like TypeScript.
TypeScript has a similar idea, but TypeScript is very particular.
And if you don't get it just right, it'll give you compiler errors and it won't do the
steps it needs to do to make the JavaScript.
Whereas Python, maybe your editor will give you a warning or some tool like mypy will give
you a warning.
But it doesn't really get in the way of it still functioning, you know, which unless
you're doing something where it depends upon it, like Pydantic or FastAPI where it's actually
using that.
But most of the time it's there when you want it and you can kind of ignore it if you don't.
Yeah.
So Rich has a lot of typing.
Yeah, Rich is fully typed.
Yeah.
So it's textual.
It's not passing mypy currently.
There are some like little dynamic corners and little typing errors which we're gradually
improving.
But all new code is typed and changes are typed.
So yeah, we're really big on typing at textualize.
Right.
And how about with your pytest extensions, plugins?
You know, it doesn't really come up much, but I don't really think about it a lot, actually.
So I would like, but I have other applications that I'm working on that I definitely involve
typing.
And I started out with just the, like you were saying, trying to help with documentation.
So making sure the API is typed.
I think that's essential.
I don't think I think it's just a good idea.
Especially now with the improvements of some of the typing.
So you can do, you don't have to say union anymore.
I like the bar for or.
Yeah.
Like it's a, it's a non, you know, it's this, it's an int or a none or something like that.
That's way cleaner than it used to be.
And you don't have to import typing as much as you used to.
I don't want to import typing just so that I can type some type in something.
It seems wrong.
But, and I'm on the phase of trying to integrate it more into the rest of my code, just because
I'm, you know, even in a solo project, sometimes you're also a user because you come back to
something six months from now and try to figure out what you're doing.
And it's nice to be able to not have to look at the code.
So I like it.
Yeah, absolutely.
Absolutely.
Well, we could find Will.
Yeah.
So I want to say something nice about AI in real life and actually the podcast IRL from Mozilla.
So this episode of Python Bytes is brought to you by the IRL podcast, an original podcast
from Mozilla.
And I'm really enjoying it.
I'm listening to a whole bunch of it.
If you care about ideas behind technology, not just the tech itself, you'll enjoy IRL.
Tech has an enormous influence on our society.
Many effects are beneficial.
The influences, like for instance, the information and assistance we get through cell phones is
amazing.
I love being able to look up the closest coffee shop wherever I'm dropped on the earth or knowing
where my kids are.
But some are not so great because like, I don't want somebody else to know how often I hit the
coffee shop.
And I definitely don't want somebody else tracking my kids.
So Mozilla has always been on the lookout for possible downsides to technology and works to
mitigate negative influences of tech on the negative influences on all of us.
If ideas like that and concerns about technology resonate with you, you should definitely check out the IRL
podcast.
This season is hosted by Bridget Todd and is looking at AI in real life.
Who can AI help?
And also who can it harm?
The show features fascinating conversations with people who are working to build a more trustworthy
AI and also using AI to help us.
So I really enjoyed a few episodes so far.
There's an episode on how our world is mapped with AI.
So data and maps is being used to make decisions that affect real people, even like by districts and by
governments.
But how can people reclaim the power over their own maps and stories using AI?
This is fascinating episode.
Another episode is about gig workers who depend on apps for their livelihood.
It looks at how they're pushing back against algorithms to control how much they get paid and seeking new ways to
gain power over the data to create better working conditions.
And how about elections?
So episode four of this season addresses the role of that AI plays when it comes to both
spreading dense information around elections, but also how to combat disinformation.
This is a huge concern for democracies around the world.
And for me, especially in the US, but I know it's affects everybody.
If this sounds interesting to you, you should try it because it is interesting.
Try an episode for yourself.
Just search for IRL in your podcast player or visit pythonbytes.fm/IRL.
I think the best way is to select I go to pythonbytes.fm/IRL.
So they know you came from us.
And the link is in your show notes.
Thank you, IRL and Mozilla for supporting our show.
Yeah.
Cool podcast.
Thank you.
Thank you, Mozilla.
All right.
On to the next one.
Well, we already touched a little bit on the whole ORM thing.
And I hear some people use Django.
It's a web framework.
Yeah.
A few people use it.
I'm proud of it.
Yeah.
So really popular.
And they're picking up the speed, of course, for their releases, right?
For a long time, it was a one.
Then we had two, three, four.
Going really quickly over a couple of years there.
Well, one of the big moves with many of the web frameworks ever since Python 3.6 or so has
been how are you going to participate and facilitate using async and await, right?
If you're doing a long database query and you block with an ORM request, for example,
how do you parallelize that or scale that without much effort?
Well, the asyncio is perfect for it.
But if your APIs don't support it, you can't use it.
And Django has been making its way towards having async capabilities.
But what is the one thing that websites wait on the most?
Databases.
What is the one thing Django did not have async support for?
Databases.
So it's a little bit late here on the announcement.
So in the beginning of August, Django 4.1 came out.
And this means three, eight and above.
But the big deal is the second one actually is an asynchronous ORM interface for doing queries.
So you can do anything that's a query set.
So you can say, like if you have a class, a model class called authors, you would say author.objects.filter.
And then you do a thing and so on.
So now you can say async for and do your query.
And now it's all happening async.
And if you want to do like a join author.books, you can await getting access to that thing.
Books normally has a dot first in this example.
But they've now added also an A first.
So if you want the async version, you put the A as a prefix.
Not sure how I feel about that.
Not sure I would have gone this path.
But, you know, it doesn't really matter.
It's awesome that there's some kind of async support in the Django ORM.
So that's really, really cool.
So I think I just wanted to highlight that this has been a major blocker to like real async programming in Django.
It's like, well, you can make the web view method async, but then you can't do async stuff that you really want to do.
So, you know, where are you, right?
This is like this unlocks the final keys, right?
You could call APIs previously with, say, HTTPX asynchronously, but then block on the database.
Now just use the A version and off you go.
I guess they couldn't make the one without A.
They couldn't make first awaitable because that would break old code, I imagine.
Yes, but here's my thought, right?
So what I'm getting back.
So when I say async for author in query, you are now switching into an async mode.
So I think the thing that returns would be really great if it like now everything must be async on it.
If you just said for author in query, now it returns a synchron and everything on it must be synchronous.
This is how I would have maybe done it instead of trying to like prefix everything with A and double down on it.
But maybe it was just a bridge too far.
I don't know.
But this is what I had in mind when I said, I'm not sure what it is.
Like you can go in async mode or synchronous mode and then you're kind of there is what I had in mind.
Yeah, that makes sense.
Async for would return a special version of the object which had different first methods, the same API, but awaitable.
Right, but awaitable.
Exactly.
You know, that doesn't mean they can't do that in the future potentially, but yeah.
Yeah.
Okay, a few other updates just for while I'm already here.
The thing I really wanted to call it is async ORM in Django.
Good to go.
Also, you can have class-based views where you have a class and then methods like get, post, put, and so on.
Or you can have just method-based ones.
I prefer the method-based stuff with a decorator, but if you have the class-based ones, they now can also be async.
Right, so that's cool.
And there's also some validation of constraints is one of the other big changes.
So check unique and exclusion constraints defined in meta constraints.
Our options are now checked during model validation.
Apparently they weren't before.
So that seems pretty valuable too, but the ORM is the big news, I think.
Yeah.
Yep.
That must have been a big project.
All right, so yeah, it's great to see Django coming along.
It's been around for so long as a stalwart of the Python web world, and now it's much closer to the most modern features, which is great.
Yeah, very cool.
Yep.
All right, Brian, what you got next for us?
I have walrus operators.
Walruses on the brain?
I do.
I like walrus operators, the walrus operator.
But I don't think I've been using it enough.
And especially because this article is telling me all sorts of places that I should use it more.
So I've got an article from Martin Hines titled, you should be using Python's walrus operator operator.
And here's why.
And there's just some stuff that I never even really thought about before.
Like, it just starts right off the bat.
I'm talking about the basics.
In the basics section, I never would have thought about this.
So there's a list that happens to call a function to create the data in a list.
And it calls it three times.
Now, really, I probably wouldn't have done this in code.
I probably would have called the function once and then named the variable and stuck it in there.
But you can do that.
It's still easier.
You can do the call the function in the first element and save the value and then use the value in future operations just to create a list.
So right off the bat, that's pretty cool.
I wouldn't have thought to do that.
It's nice.
I didn't actually quite follow this.
Oh, we get to save.
Here's a comprehension where a function is called twice.
So you put in the value of a function if something around the function, like if it's true or if it evaluates Boolean true.
You can do that with the walrus operator and only call it once.
So that's kind of cool.
One of the things I really liked around was I didn't think about before, but I'm definitely going to use it now, is the regular expression match function.
You often had to call match.
And then if something was found, then you do something with the match object.
You get the groups or some other thing on the match object.
It is cleaner to just go ahead and do the call.
Like, go ahead and do that query of whether or not the match returns something right with a walrus operator.
Way cleaner code.
So I like this.
And actually, it's just a fairly big article talking about a whole bunch of places.
Now, here's the place where I like wild true loops.
That always drives me nuts or having to flag something.
This is definitely a place where I started using walrus operator right away.
Instead of saying like wild true or wild flag or something, do something and then break out if necessary or set the stop bit or something.
You can do that right within the wild loop.
Actually, I don't know if it's cleaner.
It's less code.
I don't know if this is easier to read, though.
Any thoughts from you guys?
Yeah.
I think once you know it, it's not too bad.
It is quite different from Python prior to the walrus operator.
Even for me, I barely use the walrus operator because I'm working on libraries and the minimum version is 3.7.
So I haven't trained myself to read the walrus operator.
But to me, that doesn't look too bad.
That looks really clear.
Okay.
Yeah, this is nice.
Especially if you do one of those things where like the example here is getting input from the user where you might get input from the user and then say, wow, it's not exit or whatever.
Then in your loop, you get the same input with the same basic question again.
But you've got to ask it before to see if they ever enter.
You know, there's like this weird sort of do it two times and you could skip that with the walrus operator, which is very cool.
Oh, yeah.
Yeah.
I used to do that.
Like on the top example of just putting the command equals input and doing that above the loop.
Yeah.
And then do the same test.
Exactly.
Because I really don't like while true loops.
Only if you mean really do it forever, right?
Yeah.
Or like until.
Yeah.
Yeah, exactly.
Until it really is some case where you need to break out of it.
Yeah.
Anyway, so the rest of the article is great too.
Accumulating in place.
There's a whole bunch of cool places.
Oh, this is one I really liked.
I wanted to highlight.
Naming values inside of an F string.
So there's an example of an F string where you like take the date time and you're using, for instance, you might say use the date time value in two different formats.
It formatted in two different ways.
Once with what year, month, day and once with A, which I don't know what A is, but oh, which is the day spelled out for like Friday.
Now, it's assigning the date time today value to a today variable and then using it, using the value in a format string and then using the today variable later in the same format string.
This is a pretty cool trick.
And there's, I mean, there's multiple times where I'm using the same value in a couple places because I'm formatting a different with an F string.
So this is pretty cool.
Yeah, that is pretty cool.
The one that I really like is the list comprehension because that always drives me crazy.
If you're going to do an if section, right?
You know, if you're going to say X for X in collection, if something.
Yeah.
And that the thing you want in the list is some kind of like a database call or some other thing that has to be computed, then you need to test that computer value.
Before the walrus operator, you had to call that function twice, no matter what.
Like if that was a go get me the user from the data.
Like I want to go through all the emails and then get a list of users that correspond to them.
But maybe some of the emails don't actually exist in the database.
Every if statement has to be get me the user if it exists.
And then the list result, the value select out is also get me the user, right?
And this way, when it's really expensive like that, it's super nice.
It also is really useful in this situation when you're doing data science stuff that expects one line of a thing.
You know, you're like, I want to do, I want to pass this expression to like a pandas data frame or some other thing.
And you can kind of get a little bit more done this way.
It's really nice.
Yeah.
This is pretty cool.
Actually, I hadn't thought about doing it within the if clause within a comprehension or something.
Yeah.
This is the one where there was no other way.
Like there is no way in 3.7 to do this without calling the function twice in a comprehension.
You could do a totally different structure like a loop or something, right?
But in a comprehension where you have to have one line like a data science scenario, you had to call it twice until the walrus.
So I think that's fantastic.
Yeah.
I suppose you could create a list of expression of the return value of bunk and then use a zip or something.
But it's super awkward.
Right.
Exactly.
Yeah.
All right.
So very cool.
It's nice to see a bunch of different use cases because then you can see, oh, I will never do that.
That's horrible.
But this is really great.
And I didn't do that.
Right.
Like you could even see in the audience, people are reacting like this is amazing.
But this one is, I don't know about this one.
This is.
Yeah.
So cool.
Well, what do we got next from you, Will?
Yeah.
Oh, we're writing the right page.
So I'm sure we all love regular expressions.
We have a love-hate relationship with them.
Yeah.
Those, I'm not, I don't like regular expressions, but I use them a lot because they're powerful.
And there is no really, there is no alternative a lot of the time.
But they are very difficult to read.
You tend to get long strings of gibberish, which even if you're very well versed in regular expressions,
you might find it quite hard to parse and figure out what's actually doing.
You know, when you've come back to your code, you know, like in the afternoon.
But this is a library written by Al Swigert.
And I think that's how you pronounce his name.
Rhymes with Wider.
Al Swigert is an author and he's written this Python library, which gives you kind of like a nicer way of expressing regular expressions.
It compiles regular expressions from a bunch of function calls.
And these function calls are much more descriptive and they read quite well.
So you can essentially read a regular expression in the future and find it quite legible.
I like the either option.
It's either this or it's that, for example.
It's very readable.
Like here we've got one.
Exactly five digits plus optional white space plus one or more non-white space.
That's very readable.
If you read that a second time, you'd know exactly what that did.
But if you saw this, this is a very short regular expression.
Yeah, exactly.
Even if you're good at regular expressions, I've been using them for 15 years.
I'd have to like analyze that.
And it might take me several minutes to figure out what that does.
So, you know, if it's quite powerful just for such a short regular expression, but you can make much larger ones.
You know, here's something that's more complicated, but it's still quite readable.
Either non-captioning group, non-captioning group, either this or that, one or more of this plus non-captioning group.
It's readable and you can, you know, come back to it and other developers see it.
They can understand what's going on.
And in the end, it compiles it to a regular expression.
So it's just as fast and powerful.
But now it's just easier to work with.
So, yeah, it's really nice because the output of this little library is just the text pattern of the regular expression, which then you can do.
It's not like you've got to adopt this entire library for everything.
Yeah, you can, you know, just anywhere that you need to write a complex regular expression, you could use this.
I guess if you wanted to develop the regex, you could use this.
And then once you've done, you could compile it and then put the actual regex back in your code.
Or you could just leave it like that.
It's probably not, it's not slow.
You know, it just does sound strange.
I would probably leave it like this.
But I'm thinking if you're using another library where it expects a regular expression string, right, it's still totally compatible with that because you just say, give me the string and off it goes.
Yeah.
So it's not going to break anything.
It's not like you're switching or you don't have to port anything per se.
It's a nice drop in thing when you need it.
So, yeah, it's pretty cool.
Yeah.
Very cool.
Excellent find.
So that thing's called H-U-M-R-E.
Is that human readable regular expressions, I think?
I just like, I'm going to call it humor because then the regular expressions are humorous.
Yeah.
Very nice.
Okay.
I love it.
All right.
Brian, is that all of our things?
All of our main topics?
I think that is.
Do we have any extras?
I didn't, but now I do.
Okay.
Let's have it.
Out in the audience, Dean pointed out that the very first PyData Tel Aviv is happening in December, December 13th, 2022.
So if you're in Tel Aviv and you care about Python data stuff, you know, check that out.
The call for proposals, I think it's open for two weeks or something like that.
So, yeah, if you want to submit a talk or attend, then there you go.
Nice.
Cool.
Yeah.
Cool.
All right.
But that's my only extra.
Okay.
Well, you know what?
I'm not going to let Will off the hook because the reason why I wanted you on here is so that you could promote Rich CLI.
Okay.
Yeah.
So why do you want more people to use Rich CLI?
Or why do you think more people should use it?
I just think it's a cool project.
I use it.
You've got all the power of Rich, but it's on the command prompt.
So you can syntax highlight files.
You can also just generate colorful, Rich style content.
You can put those in your Bash scripts.
It's just a very useful thing.
Yeah.
You can get it from Homebrew.
If you do Homebrew install Rich, then you'll have Rich at the command prompt.
And you can use PipX.
And yeah, it's got a lot of cool stuff.
So do you have some workflow that you're using it for on a regular basis?
Or do you use all of these workflows?
It's more just a general tool.
Okay.
You know, when I'm navigating the command prompts, I want to look at a file.
If it's a large file, I can use Pager.
I can page it up and down.
Yeah.
It's just people check it out.
It can display nice tables.
You can take a CSV and turn it into a nicely formatted Rich table.
And you can generate simple things like rules.
And oh, it can display markdown as well.
So it's kind of like a general toolbox of like Rich related stuff in the command prompt.
I think I'm going to use it for...
I didn't know it did CSV so easily.
So I think I'll use it for that.
So maybe anytime you might type more or cat or something like that to see the contents of a file,
you're proposing now I could type Rich and get, you know, syntax highlighting and better.
Yeah.
So you do Rich, then name the file, then hyphen, hyphen, Pager.
And it'll give you a nice textual style Pager.
Okay.
So this came together in, I think, two weekends.
At some point, I'll go back and polish it a bit more because there's a few issues, people asking for new features.
Okay.
Yeah, cool.
Two weekends.
Yeah, it came in the audience and says, Rich CLI has replaced cat, JQ, and markdown tooling for me with one tool.
Cool.
Yeah, very nice, Kim.
Well, how about a joke?
Oh, yeah.
A joke.
And then I've got one more thing.
Okay.
Well, I do have a joke, as you can imagine.
So here's an example of where somebody is using open source to help keep their account secure.
And this is some kind of list of like common passwords or really reused passwords that people want to, you know, somebody has posted these, says, here's a list of passwords that people seem to use a lot and get reused a lot.
So please don't use this as a password or check and don't let people use these passwords for their accounts, right?
So someone comes along to this repo and they remove the word dolphins as a PR.
And the message is, remove my password from list so hackers won't be able to hack me.
The list is 10 million password top 1,000 lists.
I mean, this is proactive business right here.
That might actually work if the hackers are very lazy and don't look at the Git history.
It might.
Actually, there may be a very small percentage of effectiveness to this.
You're also saying my email address is this and my password is that.
So please don't put them together.
And by the way, this is my credit card number.
So don't paste that anywhere.
Yeah.
Anyway, that's my joke.
Okay.
Well, the last thing I just wanted to say is I got a new hat recently.
So I wanted to show off my new hat.
Oh, yeah.
Let's see it.
It's a top hat.
I love it.
It's a top hat with like a five inch butterfly.
Oh, it's got lots of butterflies.
And they're all leather and it's custom made from a guy in Oakland.
So it's my new hat.
It's fantastic.
And it perfectly matches both your shirt and your background.
Did that on purpose.
Yeah.
So.
Yeah.
Or on purpose or on dolphin.
No.
Indeed.
So.
Fantastic.
All right.
Love the hat.
Thanks, Will, for joining us today.
It's been a pleasure.
Yeah.
Thanks for having me.
Thanks, Michael.
And.
You bet.
We'll see you all later.
See you later.