Abstract

I propose introducing a new construct named Trait. Unlike an ABC or Protocol, a Trait acts as a strict constraint that prevents the type solver from "widening" a TypeVar to the base type. This specifically solves the long-standing issue of defining binary operations (like Semigroups) on subclasses without violating the Liskov Substitution Principle (LSP).

The Problem: The "Binary Operation" Paradox

In current Python typing, if we want to define a generic binary operation, we often run into a conflict between type safety and LSP.

from abc import ABC, abstractmethod
from typing import Self
class Semigroup(ABC):
 @abstractmethod
 def op(self, other: Self) -> Self: ...
class IntSemigroup(Semigroup):
 def __init__(self, value: int) -> None:
 self.value = value
 def op(self, other: "IntSemigroup") -> "IntSemigroup":
 # ⚠️ This is technically an LSP violation. 
 # Semigroup.op promised to accept ANY Semigroup, 
 # but IntSemigroup only accepts IntSemigroup.
 return IntSemigroup(self.value + other.value)
class StringSemigroup(Semigroup):
 def __init__(self, value: str) -> None:
 self.value = value
 def op(self, other: "StringSemigroup") -> "StringSemigroup":
 return StringSemigroup(self.value + other.value)
def combine[T: Semigroup](a: T, b: T) -> T:
 return a.op(b)
# ❌ The Runtime Failure
combine(IntSemigroup(1), StringSemigroup("2")) 

Why this fails today:

1. Widen-to-Bound: When combine is called with an Int and a String, the type checker sees both satisfy Semigroup. It resolves T to Semigroup.
2. LSP Conflict: To be type-safe, Semigroup.op must accept any other Semigroup. But for concrete logic (like addition), it must only accept its own type.

The Solution: Trait

If we define Semigroup as a Trait, we change the rules of engagement. A Trait is not a "parent type" that objects can be widened to; it is a requirement that a concrete type must satisfy.

from typing import Trait # Proposed new construct
class Semigroup(Trait):
 @abstractmethod
 def op(self, other: Self) -> Self: ...
def combine[T: Semigroup](a: T, b: T) -> T:
 return a.op(b)
# HOW IT WORKS:
# 1. T can NEVER resolve to "Semigroup" itself. It must be a concrete leaf type.
# 2. Since T must be a single concrete type, the solver attempts to unify 
# IntSemigroup and StringSemigroup.
# 3. Unification fails because they are different concrete types.
# ✅ Type Checker Error: 
# "Cannot unify 'IntSemigroup' and 'StringSemigroup' for strict Trait-bound 'T'"
combine(IntSemigroup(1), StringSemigroup("2")) 

Why this is better

1. LSP Preservation: Since Semigroup is a Trait and not a base class, we are not saying "Int is a Semigroup" in a way that requires substitution. We are saying "Int implements the Semigroup interface."
2. No More Runtime TypeError: The type checker catches "mixed implementation" calls that currently pass when using ABC bounds.
3. Rust-like Traits: It brings the safety of Rust traits or Haskell typeclasses to Python’s generic functions.

Proposed Semantics

• Non-Reifiable: You cannot instantiate a Trait, and a TypeVar bound by a Trait cannot resolve to that Trait.
• Strict Unification: When a TypeVar is bound by a Trait, all arguments associated with that TypeVar must unify to the exact same concrete type.

Note: "Protocols also suffer from the widening issue. If I have def f[T: MyProtocol](a: T, b: T), the checker will still happily resolve T to the Protocol itself if I pass two different objects that both happen to implement it. I am looking for a way to force concrete type unification."