In this post, I explain what typeclasses are (an alternative to subtyping polymorphism) and how to use them. I give examples in 4 very different languages to show that this concept is universal. I also show that this idea is very pythonic by comparing our classes implementation with functools.singledispatch.

Check how easy it is to define a typeclass with classes:

from classes import AssociatedType, Supports, typeclass

class Greet(AssociatedType):
    """Special type to represent that some instance can `greet`."""

@typeclass(Greet)
def greet(instance) -> str:
    """No implementation needed."""

@greet.instance(str)
def _greet_str(instance: str) -> str:
    return 'Hello, {0}!'.format(instance)

def greet_and_print(instance: Supports[Greet]) -> None:
    print(greet(instance))

greet_and_print('world')
# Hello, world!

Check it out!

Here’s a pretty useful idea for library authors and their users: there are better ways to test your code!

I give three examples of how user projects can be self-tested without actually writing any real test cases by the end-user. One is hypothetical about django and two examples are real and working: featuring deal and dry-python/returns. A brief example with deal:

import deal

@deal.pre(lambda a, b: a >= 0 and b >= 0)
@deal.raises(ZeroDivisionError)  # this function can raise if `b=0`, it is ok
def div(a: int, b: int) -> float:
    if a > 50:  # Custom, in real life this would be a bug in our logic:
        raise Exception('Oh no! Bug happened!')
    return a / b

This bug can be automatically found by writing a single line of test code: test_div = deal.cases(div). As easy as it gets! From this article you will learn:

• How to use property-based testing on the next level
• How a simple decorator @deal.pre(lambda a, b: a >= 0 and b >= 0) can help you to generate hundreds of test cases with almost no effort
• What “Monad laws as values” is all about and how dry-python/returns helps its users to build their own monads

I really like this idea! And I would appreciate your feedback on it.

I am happy to announce that the first version of Higher Kinded Types emulation is released with full mypy support. In this post I will explain:

• What Higher Kinded Types (HKTs) are and why they are useful
• How they are implemented and what limitations there are
• How can you use them in your own projects

Without further ado, let’s talk about typing!

Nikita Sobolev:

Your sync and async code can be identical, but still, can work differently. It is a matter of right abstractions. In this article, I will show how one can write sync code to create async programs in Python.

Almost every week I accidentally get into this logging argument. Here’s the problem: people tend to log different things and call it a best-practice. And I am not sure why. When I start discussing this with other people I always end up repeating the exact same ideas over and over again.

So. Today I want to criticize the whole logging culture and provide a bunch of alternatives.

When talking about “bad code” people almost certainly mean “complex code” among other popular problems. The thing about complexity is that it comes out of nowhere. One day you start your fairly simple project, the other day you find it in ruins. And no one knows how and when did it happen.

This is a deep-dive into where complexity comes from and finishes with some great advice on fighting it off.

This is not another “setting up” a new project with Vue and TypeScript tutorial. Let’s do some deep dive into more complex topics that are usually not covered but are totally required in real-life projects.

Almost 6 months ago I have made a decision to move all our frontend projects from Flow to TypeScript. It was a tough battle inside my head. So, I have decided to write it down to help other people to choose the right tool. And not to make my mistakes.

Look at this user story:

As a user
I want to receive issue webhooks from Gitlab
So that I can list all current tasks

Seem valid to you? If you can’t see 8 mistakes in it, you need to read this excellent article by Nikita Sobolev.

“Dependent types” might sound complex, but it is not. Instead, it is a useful feature and I am going to show how it works and when you should rely on it.

Cool new feature in Python. Nikita’s on the case 👍

This is a great article that covers the 🐛 gamut:

1. spotting bugs
2. reporting bugs
3. reproducing bugs
4. fixing bugs

I love the “lifehack” snippets Nikita sprinkles in as well. Like this little gem right here:

Lifehack: sometimes you might want to submit a broken code to your branch so it will trigger a CI build. After the build, it will be saved in your project. And your colleagues will be able to link to this problem. Your next commit will have to solve the issue.

While .env files are very simple it is required to keep them consistent. This tool offers a wide range of consistency rules and best practices. And it integrates perfectly to any existing workflow.

Check the docs for the full list of violations.

Many languages like java and php share a concept of final entities.
final entity is something that can not be changed. We did not have this feature in python. Until two events happened recently…

Nikita Sobolev:

Optional static typing with flow, jest for unit and e2e testing, docker and gitlab CI, and meaningful docs - is a good recipe for success.

If you agree with 👆, then you probably want to give this a spin.

Nikita Sobolev outlines why they’re a self-described “mediocre developer” and how they survive in such a state. What follows is a bunch of excellent advice on practical steps toward success as a developer.

Ironically, Nikita’s self-professed mediocrity and clear path toward defeating it makes them an outstanding developer in my eyes. 🤩

Go and do likewise.

The main idea of this project is to provide a fully configured template for django projects, where code quality, testing, documentation, security, and scalability are number one priorities.