{"title":"Duck Typing","description":"","content":"\"If it walks like a duck and quacks like a duck, it's a duck.\" That single sentence captures Python's whole attitude toward types. The language doesn't care what class an object came from; it cares whether the object can do what the next call requires. This lesson covers how duck typing works, why Python relies on it so heavily, where it works well, where it causes problems, and the tools available to make it safer without giving up the flexibility.\n\n---\n\n# What Duck Typing Actually Means\n\nDuck typing is a style of polymorphism where an object's suitability is decided by the methods and attributes it has, not by any declared type or inheritance relationship. If a function calls `item.calculate_shipping()`, any object with that method works. The function doesn't know the class and doesn't need to ask.\n\n\n```python\nclass Book:\n def calculate_shipping(self):\n return 3.50\n\nclass CoffeeMug:\n def calculate_shipping(self):\n return 5.99\n\nclass Subscription:\n def calculate_shipping(self):\n return 0.00\n\ndef total_shipping(items):\n return sum(item.calculate_shipping() for item in items)\n\ncart = [Book(), CoffeeMug(), Subscription()]\nprint(f\"Total: ${total_shipping(cart):.2f}\")\n```\n\n\nThree unrelated classes. No common parent, no shared base, no `implements` clause. The function still works because all three classes answer the same call with a number. The \"contract\" between the function and its inputs lives entirely in the methods being called, not in any type declaration.\n\nThis is the opposite of how languages like Java or C# work, where every type has to declare what interfaces it implements before it can be used in a polymorphic context. Python skips that step. The bargain is: classes can be defined however suits the design, as long as they respond to the right calls when the time comes.\n\n\n```mermaid\nflowchart LR\n Caller[\"total_shipping(items)\"]:::cyan\n Loop[\"for item in items\"]:::orange\n Book[\"Book
calculate_shipping()\"]:::green\n Mug[\"CoffeeMug
calculate_shipping()\"]:::green\n Sub[\"Subscription
calculate_shipping()\"]:::green\n Sum[\"sum results\"]:::teal\n\n Caller --> Loop\n Loop --> Book\n Loop --> Mug\n Loop --> Sub\n Book --> Sum\n Mug --> Sum\n Sub --> Sum\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the shape every duck-typed call has. The caller asks for a behavior, the loop dispatches to whatever object it has, and the object decides how to answer. The classes in green don't need to know about each other, and the caller doesn't need to know which classes exist.\n\n---\n\n# File-Like Objects and Iterables: Duck Typing in the Standard Library\n\nDuck typing isn't a niche pattern for handwritten code. It's how big chunks of Python's standard library work. The \"file-like object\" is the classic example: any object with a `.read()` method that returns text or bytes can be treated as a file by most code that expects one.\n\n\n```python\nimport io\n\ndef count_words(source):\n \"\"\"Count words in any object that supports .read().\"\"\"\n text = source.read()\n return len(text.split())\n\n# A real file works\nwith open(\"orders.txt\", \"w\") as f:\n f.write(\"apple banana cherry mango\")\n\nwith open(\"orders.txt\") as f:\n print(count_words(f))\n\n# An in-memory string buffer also works\nbuffer = io.StringIO(\"apple banana cherry mango\")\nprint(count_words(buffer))\n\n# Any object with a read() method works\nclass FakeFile:\n def __init__(self, content):\n self.content = content\n\n def read(self):\n return self.content\n\nprint(count_words(FakeFile(\"apple banana cherry\")))\n```\n\n\n`count_words` doesn't check whether its input is a real file. It calls `.read()` and trusts the answer. A real file from `open()` works. A `StringIO` buffer works. A handwritten class with a `read` method works. None of them share a parent class with the others, and the function never required it.\n\nThe same pattern shows up with iterables. Anything with an `__iter__` method (or even a `__getitem__` that accepts integer indices starting at zero) can be used in a `for` loop:\n\n\n```python\nclass CartCounter:\n \"\"\"An object that yields category counts when iterated.\"\"\"\n def __init__(self, items):\n self.items = items\n\n def __iter__(self):\n counts = {}\n for item in self.items:\n counts[item] = counts.get(item, 0) + 1\n return iter(counts.items())\n\ncart = CartCounter([\"book\", \"book\", \"mug\", \"book\", \"shirt\", \"mug\"])\n\nfor category, count in cart:\n print(f\"{category}: {count}\")\n```\n\n\nThe `for` loop doesn't care whether `cart` is a list, a dict, a generator, or a custom class. It calls `iter(cart)` and expects something back. `CartCounter` provides `__iter__`, so the loop succeeds. The standard library is built around these implicit protocols: `read()`, `__iter__`, `__len__`, `__getitem__`, `__call__`. Any class can opt into them by defining the right method.\n\nA duck-typed function has to call a method to find out if it works. There's no way to ask \"would this work?\" without trying. `hasattr(obj, \"read\")` checks the name but not the signature, and protocols are the only way to verify the shape ahead of time.\n\n---\n\n# Duck Typing vs Nominal Typing\n\nSome languages use **nominal typing**, where a value's compatibility depends on its declared type name. Java, C#, and Go (with named types) all work this way. A class must declare that it implements the right interface up front; the compiler then checks the relationship by name.\n\nPython uses **structural typing** with duck typing: compatibility is decided by shape, not by name. The same trade-off shows up in `typing.Protocol`, which brings structural typing into Python's type hints. The shape decides; the declared name does not.\n\n\n| Aspect | Nominal Typing (Java, C#) | Duck Typing (Python) |\n| --- | --- | --- |\n| Compatibility decided by | Declared type name and explicit `implements` | Methods and attributes the object has |\n| When mismatches are caught | Compile time | Runtime, at the moment of the call |\n| Adding a new type | Must declare every interface it implements | Just make sure the methods exist |\n| Mixing types from different libraries | Often requires adapters or wrappers | Works directly if the methods line up |\n| Refactoring safety | Strong: rename an interface and the compiler tells you | Weak: rename a method and only tests catch it |\n\n\nThe trade is real. Duck typing buys flexibility at the cost of late-detected bugs. Nominal typing buys early detection at the cost of more upfront declarations. Python doesn't pick a side: duck typing is the default, but `Protocol`, `ABC`, and type hints are all available for stronger guarantees.\n\nA small example shows the difference in practice. In a nominally-typed language, plugging in a third-party logger means writing an adapter that declares \"this class implements my `Logger` interface\". In Python, a logger with the right methods can be passed directly:\n\n\n```python\nclass StdoutLogger:\n def info(self, msg):\n print(f\"[INFO] {msg}\")\n\nclass ThirdPartyLogger:\n \"\"\"From some package outside the codebase.\"\"\"\n def info(self, msg):\n print(f\"[3rd] {msg}\")\n\ndef run_with_logging(logger, task):\n logger.info(f\"Starting {task}\")\n logger.info(f\"Finished {task}\")\n\nrun_with_logging(StdoutLogger(), \"checkout\")\nrun_with_logging(ThirdPartyLogger(), \"refund\")\n```\n\n\nNeither logger inherits from anything special. The function works with both because both have `info`. A nominally-typed system would require a `Logger` interface that both classes declared. Here, the methods are the only contract.\n\n---\n\n# EAFP vs LBYL: The Style That Goes With Duck Typing\n\nTwo style names show up everywhere in Python writing. **EAFP** stands for \"Easier to Ask Forgiveness than Permission\". **LBYL** stands for \"Look Before You Leap\". They describe two ways to handle the question \"will this operation work?\"\n\nLBYL checks first and only attempts the operation if the check passes. EAFP tries the operation and catches the exception if it fails. EAFP is the natural style for duck-typed code, and using LBYL with duck typing undermines what duck typing is for.\n\nCompare two ways to process a payment method that may or may not support refunds:\n\n\n```python\nclass CreditCard:\n def charge(self, amount):\n return f\"Charged ${amount:.2f}\"\n\n def refund(self, amount):\n return f\"Refunded ${amount:.2f}\"\n\nclass StoreCredit:\n def charge(self, amount):\n return f\"Deducted ${amount:.2f} from store credit\"\n # No refund method.\n\n# LBYL: check first\ndef process_refund_lbyl(method, amount):\n if hasattr(method, \"refund\"):\n return method.refund(amount)\n return \"Refunds not supported\"\n\nprint(process_refund_lbyl(CreditCard(), 25.00))\nprint(process_refund_lbyl(StoreCredit(), 25.00))\n```\n\n\nThis works, but it has subtle problems. `hasattr` does its check by looking up the attribute and discarding any exception that comes out, so a property that raises on access is treated as \"missing\" without warning. If a future class implements `refund` as a property that throws when the user isn't authorized, the LBYL code reports \"refunds not supported\" instead of surfacing the real error.\n\nThe EAFP version sidesteps that problem:\n\n\n```python\ndef process_refund_eafp(method, amount):\n try:\n return method.refund(amount)\n except AttributeError:\n return \"Refunds not supported\"\n\nprint(process_refund_eafp(CreditCard(), 25.00))\nprint(process_refund_eafp(StoreCredit(), 25.00))\n```\n\n\nSame output, different mechanics. EAFP only catches the exact failure it cares about, doesn't do the work twice (`hasattr` plus the actual call versus a single attempt), and isn't fooled by properties or `__getattr__` implementations that have side effects.\n\nThere's a more practical reason EAFP fits duck typing: duck typing trusts that an object will respond to the right call. LBYL goes back to \"check first whether this is a duck\", which is the opposite of the duck-typing mindset. Checking the type first is closer to `isinstance(obj, Duck)` and nominal typing.\n\nRaising and catching an exception is more expensive than not raising one. EAFP loses its edge in tight loops where failures are the common case; in normal code, the difference is invisible.\n\n---\n\n# When Duck Typing Is Great\n\nDuck typing is useful in three situations that come up constantly in Python code.\n\nThe first is **flexible code that handles many input shapes**. Functions that work with \"any iterable\" or \"any file-like object\" or \"any callable\" benefit directly. The standard library is full of them. `sum`, `min`, `max`, `len`, `iter`, `list`, `tuple`, `set`, `sorted`, all accept anything that fits a protocol. The result is that Python code composes well: data from one library flows into a function from another library without adapters.\n\n\n```python\nfrom collections import Counter\n\n# All three work with the same Counter constructor.\nprint(Counter([\"a\", \"b\", \"a\", \"c\"])) # list\nprint(Counter(\"banana\")) # string\nprint(Counter({\"apple\": 3, \"banana\": 2})) # dict\n```\n\n\n`Counter` doesn't have separate constructors for lists, strings, and dicts. It expects an iterable, and every input here is one.\n\nThe second is **testing**. Duck typing makes test doubles trivial to write. If a function needs an object with `.send(message)`, a test can pass a tiny class with a `.send` method that records what was sent. No mocking framework needed, no interface to declare, no inheritance to set up:\n\n\n```python\nclass FakeNotifier:\n def __init__(self):\n self.messages = []\n\n def send(self, message):\n self.messages.append(message)\n\ndef notify_customer(notifier, order_id):\n notifier.send(f\"Order {order_id} confirmed\")\n\n# In a test:\nfake = FakeNotifier()\nnotify_customer(fake, \"ORD-123\")\nassert fake.messages == [\"Order ORD-123 confirmed\"]\nprint(\"Test passed\")\n```\n\n\n`FakeNotifier` doesn't inherit from anything. It has a `send` method that records, and `notify_customer` accepts it. A nominally-typed language would require a `Notifier` interface that both production and test classes implement, or a mocking library to generate the implementation.\n\nThe third is **gluing libraries together**. When two libraries weren't designed to know about each other, duck typing lets them cooperate as long as their methods happen to line up. A logging library that calls `.info()` and `.error()` on its input can accept a stdlib `logging.Logger`, a structlog logger, or a handwritten class. None of them inherit from anything in the logging library. They have the right methods.\n\n---\n\n# When Duck Typing Bites\n\nDuck typing's costs are real, and ignoring them leads to bugs that hide until they're expensive to fix. Three failure modes come up often enough to be worth naming.\n\nThe first is **failures from name mismatches that produce no error**. A typo in a method name, or a subclass that names its method differently from the parent, produces wrong behavior instead of an error. The classic example is a missing override that falls through to the parent's method without any warning:\n\n\n```python\nclass Product:\n def calculate_shipping(self):\n return 4.99\n\nclass HeavyAppliance(Product):\n def caclulate_shipping(self): # typo: caclulate\n return 19.99\n\ncart = [Product(), HeavyAppliance()]\nprint(sum(item.calculate_shipping() for item in cart))\n```\n\n\nThe total is wrong. `HeavyAppliance` doesn't override `calculate_shipping`; it defines a separate method called `caclulate_shipping` (with a typo) that no caller ever invokes. Every `HeavyAppliance` uses the parent's `4.99` shipping without any indication. No exception, no warning, only a broken total. A nominal type system would have caught this at compile time because the parent's interface declared `calculate_shipping` and the child failed to implement it.\n\nThe second is **errors that surface far from their cause**. Duck typing only finds out about a missing method when the method is called. If the call sits in a rarely-hit branch (a refund flow, a holiday-only promo, a particular admin tool), the bug can live in the code for months and only fire when a customer triggers the unlucky path:\n\n\n```python\ndef total_shipping(items):\n return sum(item.calculate_shipping() for item in items)\n\nclass Book:\n def calculate_shipping(self):\n return 3.50\n\nclass GiftCard:\n \"\"\"Oops, no calculate_shipping.\"\"\"\n pass\n\n# This runs fine most of the time, but...\ncart = [Book(), Book()]\nprint(total_shipping(cart))\n\n# ...and then one day someone adds a gift card.\ncart_with_gift = [Book(), GiftCard()]\ntotal_shipping(cart_with_gift)\n```\n\n\nThe first call works because no `GiftCard` was in the cart. The second call fails at the moment `calculate_shipping` is invoked on the `GiftCard`, which could happen far from where the `GiftCard` was originally added to the cart. Debugging means tracing backwards from the exception to find which code path introduced an object that didn't fit the implicit contract.\n\nThe third is **APIs that \"work\" but produce nonsense**. Two methods might share a name and a signature but mean different things. A `send` method on a logger versus a `send` method on a socket: same name, very different semantics. Duck-typed code that calls `obj.send(message)` could accept either and produce output that looks reasonable on the surface.\n\n\n```python\nclass EmailSender:\n def send(self, content):\n return f\"Email sent: {content}\"\n\nclass Logger:\n def send(self, content):\n # This logger thinks \"send\" means \"log to file\".\n return f\"Logged: {content}\"\n\ndef notify_customer(notifier, message):\n return notifier.send(message)\n\n# Both work, but only one actually emails the customer.\nprint(notify_customer(EmailSender(), \"Order shipped\"))\nprint(notify_customer(Logger(), \"Order shipped\"))\n```\n\n\n`notify_customer` ran successfully both times. The second call did not email anyone; it wrote to a log. Duck typing has no way to express \"this needs a sender, not a logger\" beyond what the method name implies. The fix is usually clearer names, narrower interfaces, or a `Protocol` that pins down enough of the contract to make the misuse a type error.\n\nTests are the cheap fix for late duck-typing failures. A test that exercises each polymorphic branch catches the missing-method case before production does. Type hints (via `Protocol` or `ABC`) catch it earlier still, at type-check time.\n\n---\n\n# Making Duck Typing Safer\n\nPython offers several tools to recover the safety that duck typing trades away, without giving up the flexibility that makes duck typing useful in the first place. Three options cover most cases.\n\n### Option 1: `typing.Protocol`\n\n`typing.Protocol` (added in Python 3.8) describes a duck-typed contract that static type checkers can verify. A class inherits from `Protocol` and lists the methods and attributes the protocol requires. Any class with matching methods satisfies the protocol, without any inheritance:\n\n\n```python\nfrom typing import Protocol\n\nclass Shippable(Protocol):\n def calculate_shipping(self) -> float: ...\n\nclass Book:\n def calculate_shipping(self) -> float:\n return 3.50\n\nclass Tshirt:\n def calculate_shipping(self) -> float:\n return 4.99\n\ndef total_shipping(items: list[Shippable]) -> float:\n return sum(item.calculate_shipping() for item in items)\n\nprint(total_shipping([Book(), Tshirt()]))\n```\n\n\nNeither `Book` nor `Tshirt` inherits from `Shippable`. They satisfy the protocol because they have the right method. A type checker (mypy, pyright) catches a class without `calculate_shipping` at check time, before the code runs. Protocols keep duck typing's flexibility while letting a type checker verify the contract.\n\n### Option 2: `@runtime_checkable` for `isinstance` Checks\n\nBy default, a `Protocol` is a type-check-time construct only; `isinstance(obj, Shippable)` raises an error. The `@runtime_checkable` decorator makes `isinstance` work, but only by checking that the names exist (not the signatures):\n\n\n```python\nfrom typing import Protocol, runtime_checkable\n\n@runtime_checkable\nclass Shippable(Protocol):\n def calculate_shipping(self) -> float: ...\n\nclass Book:\n def calculate_shipping(self):\n return 3.50\n\nclass GiftCard:\n pass\n\nprint(isinstance(Book(), Shippable))\nprint(isinstance(GiftCard(), Shippable))\n```\n\n\n`@runtime_checkable` gives a fast \"does this object have the right method names?\" check at runtime. It does not check that the method signature is right or that the return type is correct, which is why it's a backup, not a replacement, for a proper type check. Use it for input validation or fast-fail at API boundaries.\n\n### Option 3: `abc.ABC` With Virtual Subclasses\n\nAbstract base classes give the strongest runtime guarantee: a class that doesn't implement the required methods can't be instantiated. The technique below makes `ABC` and `@abstractmethod` play with duck typing.\n\n`ABCMeta` allows an existing class to be **registered** as a virtual subclass of an abstract base, without modifying that class:\n\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass Shippable(ABC):\n @abstractmethod\n def calculate_shipping(self):\n pass\n\nclass ThirdPartyBook:\n \"\"\"From a library outside the codebase.\"\"\"\n def calculate_shipping(self):\n return 3.50\n\n# Register ThirdPartyBook as a virtual subclass of Shippable.\nShippable.register(ThirdPartyBook)\n\nbook = ThirdPartyBook()\nprint(isinstance(book, Shippable))\nprint(issubclass(ThirdPartyBook, Shippable))\n```\n\n\n`ThirdPartyBook` does not inherit from `Shippable` in any normal sense. The `register` call tells Python's ABC machinery to treat it as a subclass for the purposes of `isinstance` and `issubclass` checks. The class itself is unchanged. This is the bridge between duck typing and abstract base classes: the original class stays in use, it's registered once, and code that does `isinstance(obj, Shippable)` now accepts it.\n\nThe trade-off is that `register` doesn't check that `ThirdPartyBook` has the right methods. It's a promise to Python: \"this class fits\". If the class is missing a method, the failure mode is the same as without `ABC`: an `AttributeError` at call time. For full safety, combine `register` with tests, or prefer `Protocol` with `@runtime_checkable` when the check should run for real.\n\n\n```mermaid\nflowchart LR\n Code[\"Your code: isinstance(obj, Shippable)\"]:::cyan\n Check[\"ABCMeta checks
registered subclasses\"]:::orange\n Yes[\"Returns True
(virtual subclass)\"]:::green\n Real[\"ThirdPartyBook
no inheritance,
just registered\"]:::teal\n\n Code --> Check\n Check --> Yes\n Real --> Check\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows how virtual subclassing fits in: `register` updates a private set of \"classes the ABC counts as subclasses\", and `isinstance` consults that set in addition to the normal inheritance chain. The registered class itself doesn't change, doesn't gain a new base, and doesn't have to know it's been registered.\n\n\n| Tool | What it provides | When it runs | Trade-off |\n| --- | --- | --- | --- |\n| Bare duck typing | Maximum flexibility, no setup | Runtime, at the call site | Errors surface late and far from the cause |\n| `typing.Protocol` | Structural typing the type checker verifies | Type-check time (mypy, pyright) | No runtime check by default |\n| `@runtime_checkable` Protocol | Adds an `isinstance` check for protocol membership | Runtime | Only checks method names, not signatures |\n| `abc.ABC` with subclassing | Runtime guarantee that abstract methods are implemented | Instantiation time | Requires explicit `class C(ABC)` declaration |\n| `ABCMeta.register` | Treat an existing class as a virtual subclass of an ABC | Registration time, then runtime | Doesn't verify methods; trusts the promise |\n\n\nThe Python ecosystem doesn't expect a single tool for every situation. Plain duck typing is fine for small functions and tests. `Protocol` is the default for typed code. `ABC` fits when the codebase controls the class hierarchy and a hard guarantee at instantiation is needed. `register` is the bridge that lets the strict tools work with classes the codebase doesn't own.","pageType":"python"}

Duck Typing

Get Premium