Conversation
|
How would the team feel about my deprecating |
|
The leading underscore indicates that symbol is private to the implementation. If that's the case, no objections here. |
|
Then again, if it's an implementation detail, then we don't have to deprecate it. We can just remove it. |
|
Ready for review. |
|
Spotted this in the type checking workflow. |
korydraughn
left a comment
There was a problem hiding this comment.
Looking good so far.
|
Sorry for the forced push... just put some ruff changes through and added a structure that maps all permission keys to their respective codes - including all synonyms. It will help someone that say wants to do this: which would sort the whole list of retrieved permissions and new applicable ACLOperations together, ordering by increasing numeric permission code. Yes, I know - very niche. But it affords the customer some pretty good flexibility. |
|
linters and tests are queued up. Code is ready for final review, I think. |
alanking
left a comment
There was a problem hiding this comment.
Looks like we're rounding the corner. Still see a couple unresolved comments
… casual corruption. RUF012 points out that instances of the class can casually modify an unmutable class variable, eg.: class A: value = [] def f(self,*y): self.value += [*y]
|
I think it's ready for final eyes.... Squashing. |
korydraughn
left a comment
There was a problem hiding this comment.
We're in the final stretch.
| class _deprecated: | ||
| class _iRODSAccess_pre_4_3_0(_iRODSAccess_base): | ||
| codes = collections.OrderedDict( | ||
| (key.replace("_", " "), value) | ||
| for key, value in iRODSAccess.codes.items() | ||
| if key in ("own", "write", "modify_object", "read", "read_object", "null") | ||
| ) | ||
| strings = collections.OrderedDict((number, string) for string, number in codes.items()) | ||
| def __init__(self, *args, **kwargs): | ||
| warnings.warn( | ||
| "_iRODSAccess_pre_4_3_0 is deprecated and will be removed in a future version. Use iRODSAccess instead.", | ||
| DeprecationWarning, | ||
| stacklevel=2 | ||
| ) | ||
| super().__init__(*args,**kwargs) | ||
|
|
||
| _deprecated_names = {'_iRODSAccess_pre_4_3_0':_deprecated._iRODSAccess_pre_4_3_0} | ||
|
|
||
| def __getattr__(name): | ||
| if name in _deprecated_names: | ||
| warnings.warn(f"{name} is deprecated", DeprecationWarning, stacklevel=2) | ||
| return _deprecated_names[name] | ||
| raise AttributeError(f"module {__name__!r} has no attribute {name!r}") |
There was a problem hiding this comment.
Does this do what's intended?
There was a problem hiding this comment.
I've tested it manually only. I wonder if a test is in order to make sure; wouldn't be that difficult.
There was a problem hiding this comment.
A manual test is likely good enough, but if it's trivial to add a test, feel free to do so. Keep in mind that it's going to be removed in the next major release.
There was a problem hiding this comment.
I'm satisfied it works. A formal test is not necessary.
I've noticed however that because of this line, accessing the available_permissions property could invoke the deprecation message. Investigating....
There was a problem hiding this comment.
Hm . apparently importing it into the current module namespace is a way to circumvent the deprecations message. Direct use e.g. irods.access_iRODSAccess_pre_4_3_0 will however issue the deprecation warning.
There was a problem hiding this comment.
Is the thing we're attempting to deprecate a thing which python supports as a deprecation target?
Getting the interpreter to tell the user about a less known symbol is probably overkill. What you think?
There was a problem hiding this comment.
I don't know. Would it be acceptable then to simply add a comment saying the class is deprecated?
There was a problem hiding this comment.
If it's not easy to get python to report the deprecation in 99% of the cases, then a comment sounds perfectly reasonable to me.
4c99900 to
968d9cd
Compare
No test yet, will undraft when I have one.
Exercised now with this script: