curiousefficiency.orgCurious Efficiency

Skip to main content Toggle navigation About Archives Tags RSS Python Notes What does "x = a + b" mean? Nick Coghlan 2019-03-16 06:06 Comments Making sense of "x = a + b" Shorthand notations and shared context The original shared context: Algebra The corresponding Python context: Numbers Another mathematical context: Matrix algebra The corresponding Python context: NumPy Arrays Python's string concatenation context Python's immutable sequence concatenation context Python's mutable sequence concatenation context A brief digression back to mathematics: Multisets And back to Python once more: collections.Counter What does all this have to do with the idea of dictionary addition? Shorthand notations and shared context Guido van Rossum recently put together an excellent post talking about the value of infix binary operators in making certain kinds of operations easier to reason about correctly. The context inspiring that post is a python-ideas discussion regarding the possibility of adding a shorthand spelling ( x = a + b ) to Python for the operation: x = a.copy() x.update(b) The PEP for that proposal is still in development, so I'm not going to link to it directly [1] , but the paragraph above gives the gist of the idea. Guido's article came in response to the assertion that infix operators don't improve readability, when we have plenty of empirical evidence to show that they do. Where this article comes from is a key point that Guido's article mentions, but doesn't emphasise: that those readability benefits rely heavily on implicitly shared context between the author of an expression and the readers of that expression. Without a previous agreement on the semantics, the only possible general answer to the question "What does x = a + b mean?" is "I need more information to answer that". The original shared context: Algebra If the additional information supplied is "This is an algebraic expression", then x = a + b is expressing a constraint on the permitted values of x , a , and b . Specifying x = a - b as an additional constraint would then further allow the reader to infer that x = a and b = 0 . The corresponding Python context: Numbers The use case for + in Python that most closely corresponds with algebra is using it with numbers - the key differences lie in the meaning of = , rather than the meaning of + . So if the additional information supplied is "This is a Python assignment statement; a and b are both well-behaved finite numbers", then the reader will be able to infer that x will be the sum of the two numbers. Inferring the exact numeric type of x would require yet more information about the types of a and b , as types implementing the numeric + operator are expected to participate in a type coercion protocol that gives both operands a chance to carry out the operation, and only raises TypeError if neither type understands the other. The original algebraic meaning then gets expressed in Python as assert x == a + b , and successful execution of the assignment statement ensures that assertion will pass. In this context, types implementing the + operator are expected to provide all the properties that would be expected of the corresponding mathematical concepts ( a + b == b + a , a + (b + c) == (a + b) + c , etc), subject to the limitations of performing calculations on computers that actually exist. Another mathematical context: Matrix algebra If the given expression used uppercase letters, as in X = A + B , then the additional information supplied may instead be "This is a matrix algebra expression". (It's a notational convention in mathematics that matrices be assigned uppercase letters, while lowercase letters indicate scalar values) For matrices, addition and subtraction are defined as only being valid between matrices of the same size and shape, so if X = A - B were to be supplied as an additional constraint, then the implications would be: X , A and B are all the same size and shape B consists entirely of zeroes X = A The corresponding Python context: NumPy Arrays The numpy.ndarray type, and other types implementing the same API, bring the semantics of matrix algebra to Python programming, similar to the way that the builtin numeric types bring the semantics of scalar algebra. This means that if the additional information supplied is "This is a Python assignment statement; A and B are both matrices of the same size and shape containing well-behaved finite numbers", then the reader will be able to infer that X will be a new matrix of the same shape and size as matrices A and B , with each element in X being the sum of the corresponding elements in A and B . As with scalar algebra, inferring the exact numeric type of the elements of X would require more information about the types of the elements in A and B , the original algebraic meaning gets expressed in Python as assert X == A + B , successful execution of the assignment statement ensures that assertion will pass, and types implementing + in this context are expected to provide the properties that would be expected of a matrix in mathematics. Python's string concatenation context Mathematics doesn't provide a convenient infix notation for concatenating two strings together (aside from writing their names directly next to each other), so programming language designers are forced to choose one. While this does vary across languages, the most common choice is the one that Python uses: the + operator. This is formally a distinct operation from numeric addition, with different semantic expectations, and CPython's C API somewhat coincidentally ended up reflecting that distinction by offering two different ways of implementing + on a type: the tp_number->nb_add and tp_sequence->sq_concat slots. (This distinction is absent at the Python level: only __add__ , __radd__ and __iadd__ are exposed, and they always populate the relevant tp_number slots in CPython) The key semantic difference between algebraic addition and string concatenation is that in algebraic addition, the order of the operands doesn't matter ( a + b == b + a ), while in the string concatenation case, the order of the operands determines which items appear first in the result (e.g. "Hello" + "World" == "HelloWorld" vs "World" + "Hello" == "WorldHello" ). This means that a + b == b + a being true when concatenating strings indicates that either one or both strings are empty, or else the two strings are identical. Another less obvious semantic difference is that strings don't participate in the type coercion protocol that is defined for numbers: if the right hand operand isn't a string (or string subclass) instance, they'll raise TypeError immediately, rather than letting the other operand attempt the operation. Python's immutable sequence concatenation context Python goes further than merely allowing + to be used for string concatenation: it allows it to be used for arbitrary sequence concatenation. For immutable container types like tuple , this closely parallels the way that string concatenation works: a new immutable instance of the same type is created containing references to the same items referenced by the original operands: >>> a = 1, 2, 3 >>> b = 4, 5, 6 >>> x = a + b >>> a (1, 2, 3) >>> b (4, 5, 6) >>> x (1, 2, 3, 4, 5, 6) As for strings, immutable sequences will usually only interact with other instances of the same type (or subclasses), even when the x += b notation is used as an alternative to x = x + b . For example: >>> x = 1, 2, 3 >>> x += [4, 5, 6] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate tuple (not "list") to tuple >>> x += 4, 5, 6 >>> x (1, 2, 3, 4, 5, 6) In addition to str , the tuple , and bytes types implement these concatenation semantics. range and memoryview , while otherwise implementing the Sequence API, don't support concatenation operati...