)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1be78765f3aea6fcd3a22921b932fca3d0dee263","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"efe752e4_5e4770bd","updated":"2026-06-29 11:46:40.000000000","message":"please dont do this without wieder dicussion first.\n\nthe fixture is problematic for loder branches such as stable/2025.1 which still has to supprot python 3.9\n\n https://github.com/openstack/governance/blob/master/reference/runtimes/2025.1.rst\n\nenabling it does find cases where parmater do not match which is good but the behavior of autospec is differnt with the treament of self and how autospec handels when there are context managers that use functools.wraps\n\nhttps://github.com/openstack/cyborg/commit/23b1ad7c6ee0dc182965f47857d2e90c46c0af0b\n\non master this is perhaps something we coudl adopt but i also know that Stephen was having active discussion with the maintenance of the mock module in python about changing the behaviour.\n\nhttps://github.com/python/cpython/pull/146526\nwhich is related to your previous pr\nhttps://github.com/python/cpython/pull/4476\n\ni think doubling down on diverging form upstrema mock behaviour is not a good thing until this is resolved.\n\nwith or without oslo changes autospec is problematic when you have fucntion with multipel decorators today and trying to debug that when i was fixing a cve was very much not fun when this diffence is not really well docuemnted for each python verison.","commit_id":"387fd57c803e2bbab3b91c1bc0e528a7c0770786"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17c27d64a45cb3f1596ba6caa1e355e264110bec","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"517582f8_b5fc872c","in_reply_to":"3d3192ec_27b1bcad","updated":"2026-07-08 11:42:41.000000000","message":"so what i woudl generally prefer is to actully set autospec\u003dtrue and potentially have a hacking check or pre-commit hook to enfoce that rather then usign the oslo fixture that was only used in nova.\n\n\ni agree that usign that fixture finds bugs but its very hard to discover this behviro change as a new contibutor or a maintaenr that was not aware of this chagne. \n\nat the very lease if we proceed with this we need to modify the contibtor docs to call out this expclitly.","commit_id":"387fd57c803e2bbab3b91c1bc0e528a7c0770786"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"d56869e6b03ff6c398fc61ba2d035ed271b6654d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3d3192ec_27b1bcad","in_reply_to":"efe752e4_5e4770bd","updated":"2026-07-07 22:53:05.000000000","message":"Hi Sean,\n\nThanks for taking the time to bring me up to date with what has happened on this topic since this fixture was introduced, it\u0027s been very informative.\n\n``the fixture is problematic for loder branches such as stable/2025.1 which still has to supprot python 3.9`` - I see. Well, I intended to send these PRs only for the master branch of the projects. But if bugs would be surfaced by enforcing autospecs, I think only the fixes would be backported (I think it might be a bit too much to ask for to backport huge PRs for minor changes). Nonetheless, it seems that 2025.1 support is to be removed in October 2026, will this concern for Python 3.9 still be valid then? If we only submit these changes for master, is the Python 3.9 concern still relevant?\n\nI am aware of the differences between the oslotest mock fixture and upstream mock... those were meant to be temporary until they would be fixed upstream, but as you know (since you refenced my PR in cpython), my PRs upstream were not merged, and it\u0027s been a few years since I\u0027ve submitted them. Also, FYI, I\u0027ve since then discovered a few more issues / gaps (both in the mock library, and the fixture), before and after creating all those patches for the OpenStack projects. I\u0027ve created this repo, if you\u0027d like to take a look: https://github.com/claudiubelu/mockey (it\u0027s based on the oslotest mock fixture; more updates to come to it). I intend to update oslotest with fixture-related changes, and also send some of the fixes to cpython upstream, hoping they would land this time.\n\nThough, I was not aware of the `functools.wraps` issue. But for the cyborg scenario, as far as I can tell, this fixture was not being used there, so it\u0027s not the source of your problems; the problem lies with the vanila mock library and the autospec from it. So the fixture was not being a hindrance as it sounded like when reading your comment. IMO, if it\u0027s not actively harming in any way, I don\u0027t see a reason to block this fixture from being used.\n\nBut I\u0027ve also investigated the `functools.wraps` issue, and indeed, it exists in Python 3.9, and no longer exists in Python 3.10+. But the difference between the 2 Python versions does not lie in mock module, but in the inspect module (which is used by mock): https://github.com/python/cpython/issues/74044, issue which has been backported up to Python 3.10, and not Python 3.9. With the fix for this issue, you wouldn\u0027t have had that problem. You can check out this script for this issue: https://paste.openstack.org/show/bN0B210KBU5PZw3wxm3h/\n\n``i think doubling down on diverging form upstrema mock behaviour is not a good thing until this is resolved.`` - I agree. The original intent of the fixture was to basically just enforce `autospec\u003dTrue`, and add the autospec argument to `mock.Mock` and `mock.MagicMock`... anything else should probably be addressed upstream (though I\u0027d argue that even the `Mock` / `MagicMock` `autospec` argument belongs there; it seems there is a misconception that the argument already exists). But I\u0027m not familiar with their backport policies; if those fixes land upstream, could they be backported to older Python versions? If not, those fixes may still need to be in oslotest to cover for those differences between Python versions (I\u0027d say similar to how Python six was being used as a compatibility layer between Python 2 and 3).","commit_id":"387fd57c803e2bbab3b91c1bc0e528a7c0770786"}]}