[th]

> Trey, if you're reading this, hello from a former TA!

Hi former TA! It's been a long time.

> Unfortunately in almost every case, dunder methods made it harder for me to collaborate with other people on the same codebase.

I see dunder methods as methods that should usually (with the exception of __init__, __repr__, and __eq__) be used much more often than they're read.

I typically use dunder methods when implementing a library or framework that's meant to be used by others who would be looking at its documentation but not necessarily its code.

For example the dramatic library I published over the weekend relies on __enter__, __exit__, and __del__ (which is a very uncommon one typically): https://pypi.org/project/dramatic/

Users of that code shouldn't need to look at the code.

For code that's modified by newer Python users often, using dunder methods might be more difficult to justify. Though you might be able to get away with making a library which that could could use.