Introduction

1..__truediv__ looks strange the first time you see it, and many people assume Python must have some special ".." syntax. It does not. The expression works because the first dot belongs to the floating-point literal 1., and the second dot is ordinary attribute access. In other words, Python reads it as 1.0.__truediv__.

Break the expression into tokens

The expression is easier to understand if you split it at the parser level:

• '1. is a valid floating-point literal'
• '.__truediv__ is normal attribute access'

So this:

print(1..__truediv__(2))

behaves the same as this:

print((1.0).__truediv__(2))

Both print 0.5.

That is the entire trick. There is no dot-dot operator and no hidden slice-like syntax involved.

Why 1.__truediv__(2) does not work

This is the part that makes the expression look inconsistent. 1.__truediv__(2) is a syntax error, even though 1..__truediv__(2) is valid.

The reason is that after the integer literal 1, the parser does not interpret the next dot as attribute access in that form. The token sequence is ambiguous with numeric literal parsing, so Python rejects it as an invalid decimal literal.

If you want to access an attribute on an integer literal directly, use parentheses or whitespace:

print((1).__truediv__(2))
print(1 .bit_length())

Those versions are unambiguous.

What __truediv__ actually is

__truediv__ is one of Python's special methods, sometimes called dunder methods. It implements the / operator.

So these two expressions are equivalent in normal numeric code:

print(6 / 3)
print((6).__truediv__(3))

For built-in numeric types you almost always use the operator form, not the dunder method directly. The dunder method form is mostly useful for understanding how operator overloading works or for debugging object behavior.

This is about literals, not a Python feature called ".."

Python does use dots in several ways:

• decimal points in numeric literals, such as 1.5
• attribute access, such as obj.name
• relative imports, where dots have a different meaning entirely

But there is no standalone ".." operator in Python syntax. The apparent double dot in 1..__truediv__ is just two ordinary dots serving two different roles next to each other.

That is why similar patterns show up with other float literals too:

print(2..real)
print(3..is_integer())

These work because 2. and 3. are valid floats before the attribute access begins.

When this knowledge is useful

Most of the time, this is a parser curiosity rather than a coding technique you should reach for deliberately. It comes up in three places:

• reading unusual code examples
• understanding the tokenizer and literal parsing rules
• learning how special methods map to operators

In production code, the clearer spelling is better. Prefer (1).__truediv__(2) if you really need the method form, or just write 1 / 2.

Common Pitfalls

The biggest mistake is thinking Python has a dot-dot operator like some other languages have range syntax. It does not.

Another common issue is assuming 1.__class__ should work because x.__class__ works for variables. Literal parsing rules make the direct integer-literal form special, so parentheses are safer.

Developers also sometimes overuse dunder methods directly. They are mainly protocol hooks for the interpreter; the ordinary operator or built-in function is usually the right public-facing syntax.

Finally, do not confuse this with relative import dots. The dots in from ..pkg import x are unrelated to numeric literals or attribute access.

Summary

• Python does not have a special ".." operator.
• '1..__truediv__ works because it is parsed as 1. plus normal attribute access.'
• '__truediv__ is the special method behind the / operator.'
• '1.__truediv__(2) is invalid, but (1).__truediv__(2) is fine.'
• Treat this mostly as a parsing detail, not a style you should prefer in normal code.