bpo-45756: do not execute @property descrs while creating mock autospecs

[sobolevn]

In this PR I am trying to solve this corner case with inspect.getattr_static, so atrtibutes won't be actually resolved.

I guess @property is special enough to skip it there.
Any other similar cases, that we would need to fix (probably in the upcoming PRs)?

https://bugs.python.org/issue45756

Related: https://bugs.python.org/issue41768

[sobolevn]

I am going to friendly ping @serhiy-storchaka to review this 🙂

[sobolevn]

CC @corona10

Maybe you will be interested to review this? 🙂

[kumaraditya303]

LGTM, Thanks!

[kumaraditya303]

Suggested change

	We no longer execute ``@property`` descriptors while creating autospecs in
	Fixed :class:`property` decorators executing descriptors while creating autospecs in

[kumaraditya303]

Suggested change

	``mock.py``. This was not safe and could affect user's code in unknown way.
	:mod:`unittest.mock`. This was not safe and could affect user's code in unknown ways.

[rhettinger]

Is this potentially a breaking change (can some mocks be relying on running a property)?

In general, it is a good idea to avoid accidentally running code; however, mocks are advanced case where users are already doing something invasive, and properties are also a special case where programmers are intentionally running behavior upon access.

Long ago, In a slightly related issue, it was decided that hasattr() would be left as-is rather than making perhap futile efforts to avoid running a descriptor.

[carljm]

@rhettinger

Is this potentially a breaking change (can some mocks be relying on running a property)?

It is possible. However, the execution of properties by specced mocks was introduced relatively recently (3.8) along with AsyncMock, not intentionally but as an accidental side effect of looking for async methods. This was an unintentional breaking change at the time, and it was reported reasonably promptly in #85934. Although we've failed to fix it promptly, it seems to me that it should still be fixed and restored to the long-term established behavior.

The current PR to fix it is #22209.