stockanna.blogg.se

1. #IMDB RAW DATA SET MOVIE#
2. #IMDB RAW DATA SET FULL#
3. #IMDB RAW DATA SET CODE#
4. #IMDB RAW DATA SET SERIES#

#IMDB RAW DATA SET CODE#

I was completely okay with high-level code referencing low-level code, but it shouldn’t be the other way around. The high-level module used the poster and image classes to do their translation work to create themselves, and the API class was creating and returning the high-level data classes. Anything that directly dealt with creating URLs was put into what I dubbed the bareapi module, along with a few of the other poster and image classes dealing with size details.īut that ended up with circular references between the high-level and low-lowel modules. So I started to separate the more technical API stuff from the data the app would actually use. Splitting Things UpĪt this point, I had a pile of stuff all in one file, and it was getting too long for my taste. The base class is the only “public” one, and it has several factory methods for creating a new ImageSizes from a url, a string version of widthx height, or more directly asking for specific dimensions or the original. Original is kind of a singleton, though not enforced because it’s not necessary – it’s more of a caching optimization. To deal with handling two completely different ways to size images, I created a base ImageSize class with two subclasses: Dimensions and Original. So I created a similar class for generating urls, but it has several methods that allow you to request images that “fit” or “fill” certain areas, give specific dimensions, or just ask for the original. There’s their id, aspect ratio (which is part of the id), and the size (which is either “original” or widthx height for custom resolutions). But there’s plenty of information inside the url. Then there’s images, which are only given to you as a url to the original picture.

#IMDB RAW DATA SET SERIES#

You either get the “original”, which has those given dimensions, or you can request one of a series of options of resolutions that come in either a square cutout or “wide”, which is 16:9 or 9:16, depending on whether the original poster was portrait or landscape.Īnyway, I put together an enum that contained all the size options and a class that stored the “base” url and a single method that could take a given poster id and size option and return a new url to download that image from. But all that sizing information is nearly useless, since you can’t ask for custom sizes. They come with their aspect ratio, width, height, id, link to the “original”, and even their language for whatever language might be written on it. Posters are extremely limited in different sizes available, yet they’re the ones that come with all the extra information. Instead of storing them as simple dicts (in the case of posters) or string urls (in the case of images), I wanted them to have separate pieces of data that could be used to request the other sizes provided as well. Then I wanted to beef up the features of a couple of the other data types, namely posters and images (which are separate and work differently on their site).

#IMDB RAW DATA SET FULL#

This worked well, so I did similar things with a few other API calls where you can get full data on a specific movie, tv show, season, or episode. I put together a Python dataclass called Title to hold it in and gave it a classmethod that could take in the json data and pull out only what I wanted. Next thing I did was to dig through that data and figure out what data I cared about from it.

I used requests to do a simple lookup, and it sent back a big ol’ pile of unformatted json data.

I started with just doing their basic search for what they call “titles”, which includes movies and tv shows. The first thing I did was make an ImdbApi class to house everything I needed, which is the api key and methods that invoke the web API’s “methods”. If you’d like to kind of follow along a little, you can find the repo here. 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. For instance, I still don’t have any of the “safety” features put in yet, like timeouts, retries, and “circuit breakers” with maybe backups. Keep in mind it’s still a work in progress and could potentially remain that way until the full application is done. Today, we’ll start looking at how I’m working with the IMDb API.

#IMDB RAW DATA SET MOVIE#

Thus begins the real first article in my new Movie Database App series.