[ModernMech]

I dunno, as someone who doesn't program in Python, I find dunders to be very confusing. Like, how is this readable?

_foo

foo_

__foo

_Foo__bar

__foo__

foo__bar

All of that is valid Python, and some of those forms mean different things depending on where they are used.

[AndrewOMartin]

The second, fourth, and sixth form is options aren't used AFAIK.

Otherwise, a leading underscore indicates a private method but isn't enforced. A double leading underscore is also a private method but is "enforced" by giving it an unpredictable name. Double underscore (on both sides) means the function is digging in to python's API, like if you want to give a class some behaviour with + or = or [].

It's not trivial, and not particularly intuitive, but it's not necessarily terribly confusing.

[msm_]

The second form has no built-in meaning, but is frequently used in the wild. Often in local variables to avoid shadowing builtin types (`id_ = get_id()`) and in various libraries. Out of the top of my head, ORMs also use it to mangle reserved names.

edit: I googled a bit and PEP8 explicitly says "Thus class_ is better than clss". and "single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g..."

The fourth form is the mangling used for __x names internally (__x field in class Foo is actually _Foo__x

I don't know where GP saw sixth form, but considering all other forms are from real-world usage, someone probably uses it too.

[seunosewa]

What do you mean? Those are valid identifiers but programmers aren't required to use them.

[dust-jacket]

I don't doubt that valid Python can include hard to read code. You xcan write gnarly Python, for sure.

But I'd still argue the average Python codebase tends to be pretty legible and simple to read.