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.
irods/access.py
Outdated
| def __lt__(self, other): | ||
| return ( | ||
| self.access_name < other.access_name | ||
| and self.user_name < other.user_name | ||
| and self.user_zone < other.user_zone | ||
| ) and iRODSPath(self.path) < iRODSPath(other.path) |
There was a problem hiding this comment.
How does this affect the Access class?
Do users need to know about this?
There was a problem hiding this comment.
Thanks for drawing my attention to it, as it was improperly defined.
Yes, it maybe should have a comment at least.
It mainly just gives the class a defined sorting order. Now, if someone attempts pretty-printing a mixed list of these items, they'll get something the eye is somewhat able to follow, although I guess if the two formats were more consistent and the permissions were in order it could be better.... Currently though , you can see they are sortable and end up alphabetical by permission, with the path being last in sort order and not significant for items not having a 'path' member.
>>> from pprint import pp; from irods.access import iRODSAccess,ACLOperation
>>> pp(sorted([ACLOperation('read_metadata','dan'),iRODSAccess('read_metadata','/t','bob'),ACLOperation('read','alice'),
iRODSAccess('write','/t','alice'),ACLOperation('own','rods')]))
[<ACLOperation: access_name='own' user_name='rods' user_zone=''>,
<ACLOperation: access_name='read' user_name='alice' user_zone=''>,
<iRODSAccess read_metadata /t bob >,
<ACLOperation: access_name='read_metadata' user_name='dan' user_zone=''>,
<iRODSAccess write /t alice >]
| return hash((self.access_name, iRODSPath(self.path), self.user_name, self.user_zone)) | ||
|
|
||
| def copy(self, decanonicalize=False): | ||
| def copy(self, decanonicalize=False, implied_zone=''): |
There was a problem hiding this comment.
What is implied_zone?
Do we expect users of the PRC to ever use this parameter?
There was a problem hiding this comment.
It's useful for comparison purposes if you can tell __eq__ that a null length zone field implies the current zone name.
There was a problem hiding this comment.
When would that case appear? Can you show an example?
There was a problem hiding this comment.
Here's one:
>>> from irods.access import ACLOperation
>>> session = irods.helpers.make_session()
>>> coll = session.collections.get('/tempZone/home/rods')
>>>
>>> # -- set a possible ACL operation for test/request
>>> aclo=ACLOperation('read_object', 'public')
>>> from pprint import pp
>>> # -- request current acls on the object
>>> got = session.acls.get(coll)
>>> pp(got)
[<iRODSAccess own /tempZone/home/rods rods(rodsadmin) tempZone>,
<iRODSAccess read_object /tempZone/home/rods public(rodsgroup) tempZone>]
>>>
# Failed attempt to see if acl already set (via direct equality test)
>>> aclo == got[1]
False
>>>
>>> modified_acl = aclo.copy(implied_zone='tempZone')
>>> modified_got = got[1].copy(implied_zone='tempZone')
>>>
>>> # Equality test now works due to zone "normalization"
>>> modified_acl == modified_got
True
>>> # therefore we'll also get:
>>> modified_acl in [acl.copy(implied_zone='tempZone') for acl in got]
TrueThere was a problem hiding this comment.
Is calling <object>.copy(implied_zone=<zone>) required for equality testing?
There was a problem hiding this comment.
Okay. Letting it ride.
Resolving.
There was a problem hiding this comment.
I could be over-engineering this...
There was a problem hiding this comment.
It's fine. We discussed it and reached a decision.
We can always change things later if someone finds a good reason for us to do so.
There was a problem hiding this comment.
Ok. I realize it causes confusion or at least a double take .... If you think it might need a readme section, just say it and I can write up a short one with example.
There was a problem hiding this comment.
A simple example showing the capability is all that's needed, I think.
Co-authored-by: Kory Draughn <korydraughn@ymail.com>
irods/access.py
Outdated
| def __lt__(self, other): | ||
| return ( | ||
| self.access_name < other.access_name | ||
| and self.user_name < other.user_name | ||
| and self.user_zone < other.user_zone | ||
| ) and iRODSPath(self.path) < iRODSPath(other.path) |
There was a problem hiding this comment.
Thanks for drawing my attention to it, as it was improperly defined.
Yes, it maybe should have a comment at least.
It mainly just gives the class a defined sorting order. Now, if someone attempts pretty-printing a mixed list of these items, they'll get something the eye is somewhat able to follow, although I guess if the two formats were more consistent and the permissions were in order it could be better.... Currently though , you can see they are sortable and end up alphabetical by permission, with the path being last in sort order and not significant for items not having a 'path' member.
>>> from pprint import pp; from irods.access import iRODSAccess,ACLOperation
>>> pp(sorted([ACLOperation('read_metadata','dan'),iRODSAccess('read_metadata','/t','bob'),ACLOperation('read','alice'),
iRODSAccess('write','/t','alice'),ACLOperation('own','rods')]))
[<ACLOperation: access_name='own' user_name='rods' user_zone=''>,
<ACLOperation: access_name='read' user_name='alice' user_zone=''>,
<iRODSAccess read_metadata /t bob >,
<ACLOperation: access_name='read_metadata' user_name='dan' user_zone=''>,
<iRODSAccess write /t alice >]
No test yet, will undraft when I have one.
Exercised now with this script: