Partials Using the let over lambda pattern with lexical binding allows us to return functions, because functions are first class objects in Python and they are values like any other in lisp languages like Common Lips or Emacs Lisp. This means that, as we have seen in the previous article, we can inject data in the functions by exploiting their scope with closures and we can also wrap extra behavior around them.

I recently read part of a pretty awesome book called Let Over Lambda by Doug Hoyte. Full of nice examples, wisdom and funnily opinionated remarks. I was also working on a personal project involving a couple of libraries where I suddenly saw how I could use one of the first patterns explained in the book. Let Over Lambda In lisp and lisp like languages you can rely on lexical binding to manage scope in a way that is for today's standards (at least to me) intuitive.

As some will know because I never stop talking about it, I am the proud owner of a Kinesis 360, which has helped me improve my productivity, ergonomics, health and bragging in the last year. However, as someone who travels a lot as well, I have had to leave it at home several times, thinking about it longingly, like Wolverine with Phoenix's picture. But this was the past, as I have managed to make my trusty braggalicious keyboard portable by using one of the many rarely sold items at MediaMarkt (BestBuy for my fellow Americans):

The factory pattern is one of my favorites when working with applications that require dynamically instantiated classes based on varying conditions, things can get out of hand as time passes and new classes are added and new parameters pop up. The factory pattern often allows to have a solution to these issues with a simple implementation that can stand longer the test of time and reduce the quantity of spaghetti-code you will generate.

The other day I was putting together some code for a silly personal project, I was setting up a service to allow users to query magic the gathering cards using the MTG public API. Well, while setting up the prompts for the user, I realized I wanted to have a generic way to provide the user a set of option given an enum, and return an instance of the enum chosen by the user.

Recently I have had to take a look into using pcase for pattern matching in elisp. To be quite frank, I had no idea there even was pattern matching support in elisp and always used cond, which is more like a simple switch statement. The more I got into pcase, the more I saw what a powerful tool it was and how much it could simplify a lot of the code I was writing for my emacs packages.

While attempting to start a new project that I knew I would never finish, I found out a pretty interesting module in the curses library. I was planning on picking a project from a pretty cool aggregator of side project ideas: https://github.com/codecrafters-io/build-your-own-x . As you can see, there are a lot of different projects that go from very low level things to more abstract or complex systems. I decided to go with creating my own text editor.

Emacs offers some features for editing and managing your workspace and workflow that other editors usually do not not have. Some of these features may have similar correspondents in VSCode or the JetBrains editors, some like Vim may offer plugins with similar functionalities, but the following are all built-in to Emacs, and for most of them no extra package is necessary to get the most out of them. Registers You can think of registers as keybindings (key combinations) in which you can store almost anything.

What is Polars? Polars is a Rust library for dataframe operations that comes with a Python wrapper package. It is similar to Pandas but has some neat features that set it aside and which is reportedly more performant than pandas by having parallel and lazy operations. Although I have been aware of Polars for a couple of years, I have never found myself using it. However since it is growing in popularity and I only ever read very good things about it I decided to jump on the hype wagon and write a bit of the few things I have already picked up and noticed since implementing it in a personal project.

APIs and contracts Lately I have been playing more with FastAPI and its integration with awesome libraries such as pydantic and sqlalchemy. One thing I noticed by contributing and looking at some projects that use FastAPI is the fact that DTOs and DAOs are use quite often. DTOs in particular reminded me of how protobufs can be used in GoLang to define API endpoints and the objects needed as a contract when end users interact with the API.