Duck Typing
Duck typing is a style of dynamic typing in which an object's suitability for use is determined by the presence of the methods and properties it supports, rather than by its explicit type or class — summarized by the phrase 'if it walks…
Definition
Duck typing is a style of dynamic typing in which an object's suitability for use is determined by the presence of the methods and properties it supports, rather than by its explicit type or class — summarized by the phrase 'if it walks like a duck and quacks like a duck, it's a duck.'
Overview
Duck typing describes a way of thinking about types that is common in dynamically typed languages such as Python, Ruby, and JavaScript. Rather than requiring an object to declare that it implements a specific interface or inherits from a particular base class before it can be used in a given context, duck typing evaluates compatibility purely based on whether the object actually has the methods or attributes being called on it at the moment they're called. If a function iterates over an argument by calling `.next()` or using a `for` loop, any object supporting that iteration protocol works, regardless of its declared type or class hierarchy — the function doesn't check `isinstance()` or require a specific base class, it simply calls the method and lets the object either respond correctly or raise an error if it can't. The term comes from the aphorism 'if it walks like a duck and it quacks like a duck, then it must be a duck,' and is generally attributed, in a programming context, to a 1970s-2000s tradition of dynamic-language communities, with the phrase becoming particularly associated with Python and Ruby culture in the 2000s. In Python specifically, duck typing underlies many of the language's core protocols — the iterator protocol (`__iter__`/`__next__`), the context manager protocol (`__enter__`/`__exit__`), and operator overloading (`__add__`, `__eq__`) — any object implementing the right 'dunder' methods can be used wherever that protocol is expected, without any formal interface declaration or inheritance relationship required. The main tradeoff duck typing accepts is deferring type-compatibility errors from compile time (as in statically typed languages with structural or nominal typing) to runtime — if an object is passed to a function expecting different behavior, the failure surfaces only when the mismatched method is actually called, potentially deep inside execution, rather than being caught upfront. Statically typed languages address a related but distinct concept, 'structural typing' (as in TypeScript or Go's interfaces), which achieves similar flexibility — an object satisfies a type based on its shape/structure rather than explicit declaration — but does so with compile-time checking rather than runtime discovery, sometimes described as 'static duck typing.'
Key Concepts
- Object compatibility is determined by present methods/attributes, not declared type
- No requirement to explicitly implement an interface or inherit from a specific base class
- Common in dynamically typed languages: Python, Ruby, JavaScript
- Underlies Python protocols like iteration (__iter__/__next__) and context managers (__enter__/__exit__)
- Errors from incompatible objects surface at runtime, not compile time
- Encourages writing code against behavior/protocol rather than concrete type
- Related to 'structural typing' in statically typed languages (TypeScript, Go interfaces)
- Named from the aphorism about identifying a duck by its walk and quack, not its label