# Union syntax

DevFeed: [Union syntax](<https://devfeed.tech/articles/union-syntax-38898.md>)

Original publisher: [Read original article](<http://neopythonic.blogspot.com/2016/05/union-syntax.html>)

Author: Guido van Rossum (noreply@blogger.com)

Published: 2016-05-18T18:55:00Z

Content type: opinion

Language: en

Sources: [Guido van Rossum](<https://devfeed.tech/sources/guido-van-rossum.md>)

Topics: [Python](<https://devfeed.tech/topics/python.md>), [union types](<https://devfeed.tech/topics/union-types.md>), [syntax](<https://devfeed.tech/topics/syntax.md>)

Tags: [python](<https://devfeed.tech/tags/python.md>), [syntax](<https://devfeed.tech/tags/syntax.md>), [types](<https://devfeed.tech/tags/types.md>), [union](<https://devfeed.tech/tags/union.md>)

## AI overview

The article explains why PEP 484 uses Union[X, Y, Z] for expressing union types in Python. It argues that alternatives such as X|Y|Z, {X, Y, Z}, and (X, Y, Z) would create compatibility or semantic confusion, while Union[] works with existing Python versions and type-checking behavior.

## Source excerpt

Union syntax (I'm trying to do this as a quick post in response to some questions I received on this topic. I realize this will probably reopen the whole discussion about the best syntax for types, but sorry folks, PEP 484 was accepted nearly a year ago, after many months of discussions and hundreds of messages. It's unlikely that any idea you can think of here would be new. This post just explains the rationale of one particular decision and tries to put it in some context.) I've heard some grumbling about the union syntax in PEP 484: Union[X, Y, Z] (where X, Y and Z are arbitrary type expressions). In the past people have suggested X|Y|Z for this, or (X, Y, Z) or {X, Y, Z}. Why did we go with the admittedly clunkier Union[X, Y, Z]? First of all, despite all the attention drawn to it, unions are actually a pretty minor feature, and you shouldn't be using them much. So you also shouldn't care that much. Why not X|Y|Z? This won't fly because we want compatibility with versions of Python 3 that were already frozen (see below). We want to be able to express e.g. a union of int and str, which under this notation would be written as int|str. But for that to fly we'd have to modify the builtin 'type' class to implement __or__ -- and that wouldn't fly on already-frozen Python versions. Supporting X|Y only for types (like List) imported from the typing module and some other notation for builtin types would only sow confusion. So X|Y|Z is out. Why not {X, Y, Z}? That's the set with elements X, Y and Z, using the builtin set notation. We can usefully consider types to be sets of values, and this makes a union a set of values too (that's why it's called union :-). However, {X, Y, Z} confuses the set of types with the set of values, which I consider a mortal sin. This would just cause endless confusion. This notation would also confuse things when taking the union of several classes that overlap, e.g. if we have classes B and C, where C inherits from B, then the union of B and