Movie Database App: IMDb API

Thus begins the real first article in my new Movie Database App series. Today, we’ll start looking at how I’m working with the IMDb API. Keep in mind it’s still a work in progress and could potentially remain that way until the full application is done. For instance, I still don’t have any of the “safety” features put in yet, like timeouts, retries, and “circuit breakers” with maybe backups. Also keep in mind that, while I’ll tell you my process in order when it’s important, I may tell things out of order for clarity.

Subscript Operator Overloading: Python vs Kotlin

Being able to access items in collections using subscripting (i.e. with square brackets, like myCollection[2]) is a really big convenience for me. I hate typing method names for this functionality, especially the boring old get() method. Not only is get() boring, it’s incredibly nondescript. (On a tangent: In my opinion, it would be nice if the “default” name for a method like this was sub() or subscript(), but too few people even know the term “subscript”).

Both Python and Kotlin allow you to use operator overloading in order to get this functionality, and in this article, I’m going to do a medium dive into each one, comparing and contrasting their limitations and how they work.

Command and Command Handlers (and Why I Don’t Care Much For Them)

Introduction

I want to complain about the pattern of using Commands and Command Handlers in this article, but I don’t want to spend my time explaining what they are, so I’ll link you to another blog post. It’s pretty in-depth, so it may take a bit, but what I really like about it is that it’s part of a collection of posts related to the book, Architecture Patterns with Python: Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices. From what I’ve read in it so far, it’s a lot like the book I was about to write, but a little less in-depth on the product they’re building throughout and also not covering some of the more obscure practices. I’m greatly enjoying it so far, despite largely knowing it all already, so I’m here to plug it. You can purchase it, or you can read it for free on their web site.

Don’t Mock Your Domain

Hello again, everybody! Today’s article is made possible by Leonardo Giordani. He wrote a pretty good book called Clean Architectures in Python which is pay-what-you-want. I’m not quite done with it yet, but it’s a pretty good book so far, especially considering its cost. 

He opens up by talking about TDD for several chapters in order to make sure you know what’s going on for the latter half, where he builds a simple Clean application from the ground up giving you his unit tests before the code. He didn’t go step-by-step, so it’s not tedious in that way. But there’s a problem I have with a part of the book that I’d like to address. To do that, I need to do the most basic primer on Clean Architecture first.

Better Unbound Python Descriptors

Welcome back from another hiatus! This post is a facepalm post because I recently realized that I’ve been an idiot for so long. I have a tendency to make things more complicated than they need to be, as can be seen in my articles about instance properties.

I’ve briefly mentioned unbound attributes (Class.attr returns a function that you pass an instance into to look up the the value of that instance’s version of the attribute) with descriptors a time or two and they always ended up using a whole new object to represent the unbound attribute. In the example given, I returned a local function to use as the unbound attribute; in the descriptor-tools library that goes along with the book, I implemented it with an UnboundAttribute type, which allowed it to easily carry extra data (such as the descriptor object reference); then I discovered attrgetter in the operator module, so I substituted that in instead. But there was one big obvious solution I was missing.