URL:
https://github.com/SSSD/sssd/pull/369
Title: #369: pysss_nss_idmap: remove unnecessary python2/3 ifdef
sumit-bose commented:
"""
I tested the patch with python2 and it looks like python2 is a bit more relaxed with key
types. Although the type of the keys in the returned dict changed from:
>> pysss_nss_idmap.getsidbyname('new_name(a)ad.devel')
{'new_name(a)ad.devel': {'type': 3, 'sid':
u'S-1-5-21-3692237560-1981608775-3610128199-1104'}}
to
>> pysss_nss_idmap.getsidbyname('new_name(a)ad.devel')
{'new_name(a)ad.devel': {u'type': 3, u'sid':
u'S-1-5-21-3692237560-1981608775-3610128199-1104'}}
the values can still be accessed with all kind of key types:
>> a['new_name(a)ad.devel'][pysss_nss_idmap.SID_KEY]
u'S-1-5-21-3692237560-1981608775-3610128199-1104'
>> a['new_name(a)ad.devel']['sid']
u'S-1-5-21-3692237560-1981608775-3610128199-1104'
>> a['new_name(a)ad.devel'][u'sid']
u'S-1-5-21-3692237560-1981608775-3610128199-1104'
>> a['new_name(a)ad.devel'][b'sid']
u'S-1-5-21-3692237560-1981608775-3610128199-1104'
Of course if this module is used somewhere where the actual type of the returned key is
tested this would break and we would have to fix the regression. But I think the chances
are low that the module is used this way and we can wait to think about this until a bug
about it is opened.
In my test using 'bytes' with python2 and python3 by just removing the #ifdef and
PyModule_AddStringConstant() calls from 9375eae59550437c85ada9212be430a4242b25a4 works as
well in my testing.
After talking with python developers it seems to me that using strings/unicode here is
more the python way of doing things. It would be possible to force users to only use the
constants defined by the module but this would require defining our own class for the keys
which imo is too much for this simple use case. So ACK.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/369#issuecomment-328540887