As a starting point, you will probably find helpful this quote from PEP 8 – Style Guide For Python Code:

In addition, the following special forms using leading or trailing
underscores are recognized (these can generally be combined with any
case convention):

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

single_trailing_underscore_: used by convention to avoid conflicts
with Python keyword, e.g.
Tkinter.Toplevel(master, class_='ClassName')

__double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo; see
below).

__double_leading_and_trailing_underscore__: "magic" objects or attributes that live in user-controlled namespaces. E.g. __init__,
__import__ or __file__. Never invent such names; only use them as documented.

You asked in the context of class attributes, though, so let’s take a look at your specific examples:

Single leading underscore

Naming an attribute in your class self._var1 indicates to the user of the class that the attribute should only be accessed by the class’s internals (or perhaps those of a subclass) and that they need not directly access it and probably shouldn’t modify it. You should use leading underscores in the same places that you would use a private or protected field in Java or C#, but be aware that the language doesn’t actually enforce non-access – instead you trust your class’s user to not do anything stupid, and leave them the option of accessing (or modifying) your class’s private field if they’re really, really sure that they know what they’re doing and it makes sense.

Single leading and trailing underscore

self._var1_ isn’t something I’ve ever seen. I don’t think this naming style has any conventional meaning in the Python world.

Double leading underscore

This one actually has syntactical significance. Referring to self.__var1 from within the scope of your class invokes name mangling. From outside your class, the variable will appear to be at self._YourClassName__var1 instead of self.__var1. Not everyone uses this – we don’t at all where I work – and for simple classes it feels like a slightly absurd and irritating alternative to using a single leading underscore.

However, there is a justification for it existing; if you’re using lots of inheritance, if you only use single leading underscores then you don’t have a way of indicating to somebody reading your code the difference between ‘private’ and ‘protected’ variables – ones that aren’t even meant to be accessed by subclasses, and ones that subclasses may access but that the outside world may not. Using a single leading underscore to mean ‘protected’ and a double underscore to mean ‘private’ may therefore be a useful convention in this situation (and the name mangling will allow a subclasses to use a variable with the same name in their subclass without causing a collision).

Double leading and trailing underscore

self.__var1__ is something you should never create as I’ve literally written it, because the double leading and trailing underscore naming style is meant to be used only for names that have a special meaning defined by Python, like the __init__ or __eq__ methods of classes. You’re free to override those to change your class’s behavior (indeed, almost all classes will have a programmer-defined __init__), but you shouldn’t make up your own names in this style like self.__var1__.