From time to time, when coding, we all run into weird behaviours of the programming language. Sometimes it's a "feature" we weren't aware of, sometimes it's just quirky behaviour of the language, and sometimes it's borderline bug. Python - as any other programming language - has these eyebrows-raising quirks, so here's a list of weird Python "features" that might catch you off-guard.
"Features"
Let's start with some odd behaviours, which some might consider "features". Such as:
class A:
def func(self):
print("A")
class B:
def func(self):
print("B")
a = A()
a.func() # A
a.__class__ = B
a.func() # B
In the above example we assigned B class to a.__class__ attribute, which changes as functions to the ones in B class.
This works because __class__ is just an attribute on an instance. You can reassign it however you like. Therefore, you can change the type of object just by merely assigning a different class to its __class__ attribute.
Next up are for loops. But for loops are so simple and basic, what surprising feature could they have?
values = "abc"
some_dict = {"key": ""}
for some_dict["key"] in values:
print(some_dict)
# {'key': 'a'}
# {'key': 'b'}
# {'key': 'c'}
Python interpreter doesn't really care about the variable you put in the first half of for loop statement, as long as it can assign values to it. In this case it simply assign the individual characters from the sequence (values) to the key in the dictionary.
While the above was surprising for me when I first saw it, it isn't that weird and is an actual feature, and there definitely are legitimate use-cases for it.
Tuples
We all (probably) know that tuples are immutable - you define them once and then can't change their contents - right?
some_tuple = ([1], [2])
some_tuple[0].append(2) # Worked!
print(some_tuple)
# ([1, 2], [2])
Well, not quite. While you cannot modify the tuple itself, you can modify its elements if they're mutable, which lists are.
Important thing to understand is that tuples only hold references to the objects, in this case lists. Therefore, you cannot change the reference, e.g. replace/delete the list, but you absolutely can change its value.
Also, to add to the confusion about tuple immutability, you can also run the following code without error:
some_tuple = ([1], [2])
print(id(some_tuple))
# 139997458815936
some_tuple += ([3],)
print(id(some_tuple)) # identity changed, therefore it's a new object
# 139997458018880
tuple implements both + and += operators, but they don't modify the tuple in-place. Rather, they create a new tuple object and replace the original one. We can see that by checking identity of the variable using id function.
And finally, if the previous two examples didn't surprise you, then this one will surely raise some eyebrows. This snippet works, but actually doesn't, huh?
x = ([1, 2],)
try:
x[0] += [3, 4]
except Exception as e:
print(e) # 'tuple' object does not support item assignment
# Traceback (most recent call last):
# File "/home/martin/Projects/learning-notes/posts/Python Weirdness/examples.py", line 4, in <module>
# x[0] += [3, 4]
# TypeError: 'tuple' object does not support item assignment
print(x)
# ([1, 2, 3, 4],)
In this snippet, we added [3, 4] to the first element of a tuple (x[0]) using in-place operator (+=) and we received TypeError. Yet when we look at the x variable afterwards, we can see that the 2 new elements ([3, 4]) were added anyway.
We already established that you can modify mutable elements in an immutable tuple. So what's happening here?
# Pseudo-code
class List:
def __iadd__(self, other):
self.extend(other)
return self
x = ([1, 2],)
x[0].extend([3, 4]); x[0] = x[0]
The problem is += operator, which calls the __iadd__ magic method of list in the background. This method first uses the extend method to add the elements to the existing list and then returns the list itself - effectively executing x[0].extend([3, 4]); x[0] = x[0]. The extend succeeds, because list is mutable, but the assignment fails, because tuple is not. We only needed to perform extend, but that's not how += is implemented on list class. Sometimes implementation details matter.
Recursion
Next area full of surprises is recursion, and when you pair it with lambda expression - naturally - weird things will happen:
(lambda x : x(x))(lambda x : x(x))
# Traceback (most recent call last):
# File "<stdin>", line 1, in <module>
# File "<stdin>", line 1, in <lambda>
# File "<stdin>", line 1, in <lambda>
# File "<stdin>", line 1, in <lambda>
# [Previous line repeated 996 more times]
# RecursionError: maximum recursion depth exceeded
I don't think that the fact that the above line of code causes stack overflow is really that surprising, it's more the fact that it's a valid piece of code in Python for whatever reason. I think there's no point trying to decipher it, because no sane person should write it.
A little less esoteric and possibly useful fact about recursion in Python is that you can create circular references:
a = [1, 2, 3]
a.append(a)
print(a)
# [1, 2, 3, [...]]
print(a[3])
# [1, 2, 3, [...]]
a = a[1:]
print(a)
# [2, 3, [1, 2, 3, [...]]]
Here we appended a list to itself, and Python even has nice way of representing it using [...]. If you try to access the self-referential element, you will - unsurprisingly - get the same thing. You can obviously perform any other operation on this list, such as slicing, which lands some interesting results as you can see above.
F-Strings
f-strings are great, they're very powerful and over the years they received a lot of useful features. To the point that you can do some weird things with them. Such as putting lambda expressions inside of them:
print(f"{(lambda x: x**2)(3)}")
# 9
And if you decide to pair f-strings with the recently introduced walrus operator (:=) then you can define variables inside f-string too:
from datetime import datetime
print(f"Today is: {(today:=datetime.today()):%Y-%m-%d}, which is {today:%A}")
# Today is: 2023-05-01, which is Monday
print(today)
# 2023-05-01 13:43:30.827182
And because the f-string doesn't have its own scope, the variable - today in the above example - can be used outside/beyond the f-string itself! Which makes sense I guess, but doesn't feel right or intuitive to me...
Borderline Bugs
One last Python "quirk", which I personally consider to be a bug, is a behavior of raw string literals. If you're not familiar with raw strings, then these are strings denoted/prefixed with r and they treat backslash as literal character rather than escape/special character.
Well, but what's the issue with these raw strings?
literal = r"some string\"
# SyntaxError: unterminated string literal (detected at line 1)
literal = r"some string\\" # 2 backslashes
print(literal) # some string\\
If you try to create a raw string ending with a backslash - r"...\" - you will receive a SyntaxError claiming that the string is not terminated. So clearly Python interpreter treats the backslash as an escape character for the closing quote sign, but that doesn't make sense, because it's raw string and backslash should be treated as literal character.
In fact this is common enough issue, that there is an entry for it in Python's design FAQ, as well as bug submission in a bug tracker.
Closing Thoughts
While you probably won't run into most of these oddities in your day-to-day coding, I think it's good to know about them and there's a lot we can learn from these weird language quirks. They force us to look a bit deeper and understand what's happening under the covers, which in turn makes us better Python developers.