Author lunixbochs2
Recipients Mark.Shannon, ammar2, christian.heimes, lunixbochs2, steve.dower, vstinner
Date 2021-01-23.00:01:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I agree that READ_RESTRICTED would work, and I'm strongly in support of refactoring my patch around that kind of flag, as it simplifies it quite a bit and the if statement is already there.

However, using the seemingly legacy RESTRICTED flag names for audit is confusing in my opinion:

- The audit subsystem does something entirely different from the long deprecated "Restricted execution" feature (removed in 3.0?)
- Nothing in the stdlib uses RESTRICTED that I can see.
- The documentation for RESTRICTED flags (Doc/extending/newtypes.rst) doesn't say anything about the audit system for READ_RESTRICTED, and talks about restricted mode as though it still exists.
- RESTRICTED only supports __getattr__ (PY_WRITE_RESTRICTED does nothing at all, and there is no delattr equivalent). This doesn't actually matter for this patch, it's just confusing in the context of audit, as there are `object.__setattr__` and `object.__delattr__` audit points but no corresponding flags.

I think it could make sense to:
1. Alias READ_RESTRICTED to a new READ_AUDIT flag and use the latter instead, as it is more clear.
2. Update the newtype docs to mention READ_AUDIT and remove documentation for the the unused RESTRICTED flags.
3. Deprecate the non-functional RESTRICTED flags if that's possible?
4. Only cross the setattr/delattr audit flag bridge if a future refactor calls for it.
Date User Action Args
2021-01-23 00:01:01lunixbochs2setrecipients: + lunixbochs2, vstinner, christian.heimes, Mark.Shannon, steve.dower, ammar2
2021-01-23 00:01:01lunixbochs2setmessageid: <>
2021-01-23 00:01:01lunixbochs2linkissue42800 messages
2021-01-23 00:01:00lunixbochs2create