It is possible to construct classes without __firstlineno__:

def f():
    __firstlineno__ = 1
    class X:
        nonlocal __firstlineno__
    return X
print(f().__firstlineno__)  # AttributeError

Or:

class Y:
    global __firstlineno__
print(Y.__firstlineno__)  # AttributeError

This is obviously an extreme edge case though. You could also do this by manipulating locals() in the class body or the metaclass.

Is it worth it to make inspect smarter in the presence of classes without __firstlineno__?

  File "/Users/jelle/py/cpython/insp.py", line 18, in <module>
    print(inspect.findsource(X))
          ~~~~~~~~~~~~~~~~~~^^^
  File "/Users/jelle/py/cpython/Lib/inspect.py", line 1070, in findsource
    return lines, object.__firstlineno__ - 1
                  ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'X' has no attribute '__firstlineno__'

Good point. I thought that it is the same as for __module__ and __qualname__, but it turned out that they are set implicitly in the type constructor even when not specified in the class dict. They are set even for type('A', (), {}).

We can try to set __firstlineno__ to the current line number in the top Python frame, but it is safer to not set it at all. Setting __firstlineno__ for classes created by the type() call rather than in the class statement does not help in the only use case for this attribute.

I think that for backward compatibility getsource() should convert an AttributeError into OSError which was raised before for classes created by the type() call.