# Duck Typing

## Summary


Duck Typing is a way of programming in which an object passed into a function or method supports all method signatures and attributes expected of that object at run time. The object's type itself is not important. Rather, the object should support all methods/attributes called on it. For this reason, duck typing is sometimes seen as "a way of thinking rather than a type system". 

In duck typing, we don't declare the argument types in function prototypes or methods. This implies that compilers can't do type checking. What really matters is if the object has the particular methods/attributes at run time. Duck typing is therefore often supported by dynamic languages. However, some static languages are beginning to "mimic" it via structural typing.

## Discussion

### What's the origin of the phrase "duck typing"?

The phrase originates from an old saying, 

> If it walks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

What does this mean? Even a non-duck entity that behaves like a duck can be considered a duck because emphasis is on behaviour. By analogy, for computing languages, the type of an object is not important so long as it behaves as expected. This behaviour is defined by the object's methods/properties/attributes while expectations are set by those who invoke the methods/properties/attributes.

For example, a `Book` class is expected to have an attribute `numPages` and a method `getPage(number)`, where `number` is an integer. Let's say a function `searchPhrase(book, phrase)` is meant to search for a given phrase in a book. This function calls `book.getPage()` for all `book.numPages` of the book. A `Newspaper` is obviously not a book but with duck typing this doesn't matter. If `Newspaper` has implemented `numPages` and `getPage(number)`, it can be passed into `searchPhrase(book, phrase)` as if it's a book. Though it's not a book, it's sufficient that it behaves like one within the context of `searchPhrase`.


### What's the advantage of having duck typing?

It's been said that dynamic typing in general cuts down development time. There's less boilerplate code. Code is easier to hack. With static typing, compile-time checks slow down the development process. Static typing could be used at a later point to get better performance. Others recommend duck typing only for prototyping and never for production. 

While it's true that compile-time checks are useful to catch potential problems early, duck typing enforces following coding conventions, documentation and test-driven methodologies. 

Since duck typing isn't exactly a type system, it gives programmers flexibility. In Python, for example, common things are simpler to code. While static typed languages use interfaces, such interfaces may involve excessive refactoring of client code. 


### Isn't duck typing more like late binding than a type system?

It can be argued that duck typing is not really a type system in the sense of run-time or compile-time type systems. Type systems typically prescribe rules for defining types, for deducing types from expressions, for determining legality of expressions or storage based on types, and so on. Duck typing doesn't do any of these. Joe Esposito has commented that, "Duck typing is based around conventions, written in the docs instead of code. This allows the language to defer the type system". 

Late binding is when an object or method is bound to a name at run time. Duck typing looks similar to late binding except for a subtle difference that it's based on behaviour rather than declared type. 

One way to understand this is to recognize that C# (a static typed language) allows for method overloading where methods differ only by their arguments types. This is not possible in Python (dynamic typed language) but duck typing fills in since run-time behaviour is emphasized rather than the type of the object passed to the method. Also, because it's interpreted and does late binding, duck typing is easy to do. 


### Can you compare duck typing with structural typing?

Joe Esposito makes a distinction between static duck typing and dynamic duck typing. With the latter, compile-time checks are skipped and this is what we mean when we refer to duck typing. Static duck typing is similar to structural typing that some static typed languages (Scala, F#) support. Structural typing allows for some compile-time checks, not on types but on the supported methods/attributes. Structural typing may be seen as a compiler-enforced subset of duck typing. However, we should also note that structural typing is essentially static typing while duck typing is dynamic. 

Just as duck typing is for dynamic typed languages, so is structural typing for static typed languages. Erlang's Behaviours can be seen as static duck typing, that is, with compile-time checking. 

Among the languages that support structural typing are Scala, OCaml, Go, Elm and PureScript. 


### Can we say that duck typing is another name for implied interfaces?

Static typed languages use explicit interfaces. In C#, we use interfaces: any type that implements an interface can be passed into a method/function that accepts that interface. This was how flexibilty was built into static typed languages but this required upfront interface declaration. 

Python doesn't have explicit interfaces: interfaces are implied. For Python, this is not different from duck typing. However, implied interfaces are supported by C++ (for example) in its STL library. Given that C++ does compile-time checks, we can't say in general that implied interfaces is the same as duck typing. Note that when interfaces are implied, there's no formal interface definition, and at best, it may be a shared documentation. 


### What is goose typing?

In Python, duck typing is an implied or informal interface. This is sometimes called a **protocol**. For instance, any class or object that implements `&lowbar;&lowbar;len&lowbar;&lowbar;` and `&lowbar;&lowbar;getitem&lowbar;&lowbar;` is said to conform to the sequence protocol. Therefore, it can be accessed as if it's a sequence. The sequence can be indexed or sliced. 

With **goose typing**, the interface or protocol is made explicit. This is done using an Abstract Base Class (ABC). In the call `isinstance(obj, cls)`, the second argument must be an ABC. The ABC class itself can't be instantiated but another class provides an implementation of the expected interfaces. However, this other class is simply registered (via a decorator) as conforming to the ABC's interface; that is, it's not explicitly derived from the ABC. For this reason, we call goose typing as "virtual subclassing of Python ABCs." 

Among the languages supporting goose typing are Python, TypeScript and Go. 


### What languages support duck typing?

    + Python and Ruby support duck typing, both of which are dynamic typed languages. In general, dynamic typed languages such as JavaScript and TypeScript support duck typing. While C# doesn't, some parts of .NET use duck typing.
    + In Ruby, for example, `StringIO` doesn't have `IO` in its class hierarchy. Yet, it behaves like an `IO` due to duck typing. In fact, we may say that `StringIO` and `IO` share a common *protocol*, which is exactly how the duck typing concept is seen in OOP languages such as Smalltalk and ObjectiveC. This can be said of Python as well. For example, an iterable is one that supports the iterator protocol, which is nothing more than implementing necessary methods for an object.
    + In PHP, PHP's dynamic typing system and object-oriented features enable duck typing to a certain extent.
    + It's interesting to note that duck typing has inspired the creation of a [new language called Duck].(http://ducklang.org/).

### How is duck typing related to LBYL and EAFP?

LBYL expands to *Look Before You Leap* while EAFP expands to *Easy to Ask for Forgiveness than Permission*. Both these concepts are typically discussed in Python (and possibly other languages as well). Python prefers the EAFP approach, which is the opposite of LBYL. 

With LBYL, we typically check if an object is of a compatible type before performing operations on it, such as calling its method. Python has a built-in function `isinstance()` to do this. With EAFP, we simply call the object's method, expecting that method to be present. If it's not, an exception will be thrown by the Python interpreter, which the code is expected to handle. 

With duck typing, validating an object's type is not Pythonic. Thus, duck typing plays well with Python's preference for EAFP though the use of `hasattr()` can be used instead. 

## Milestones

1946

Emil Mazey states at a meeting that "I can’t prove you are a Communist. But when I see a bird that quacks like a duck, walks like a duck, has feathers and webbed feet and associates with ducks—I’m certainly going to assume that he is a duck." The phrase might have originated earlier from James Whitcomb Riley (1849–1916). 

1980

Languages of the 1980s such as Smalltalk-80 and Objective-C have the concept of **protocols**, where the interface is more relevant than the class. In 1992, with reference to Smalltalk-80, William R. Cook of Apple Computer states that *interface hierarchy* is more useful that *inheritance hierarchy*. 

Jul  
2000

What may be the one of the earliest use of the term "duck typing" among programmers, Alex Martelli discusses it on the `comp.lang.python` Google Group as an alternative to method overloading of C++. He states that duck typing is closer in spirit to polymorphism of C++. He clarifies,

> You don't really care for IS-A -- you really only care for BEHAVES-LIKE-A-(in-this-specific-context), so, if you do test, this behaviour is what you should be testing for.

2015

Alex Martelli coins the term **goose typing** in the first edition of his book titled *Fluent Python*. 

Mar  
2017

PEP 544 proposes to introduce structural subtyping to Python. This is subsequently accepted into Python 3.8 (October 2019).