Currently, NocaseDict is derived from object, but it should ideally be derived from dict. The issue is that it does not want to inherit the dict data, at least not the current implementation. This can probably be handled though with some changes in the implementation.

DISCUSSION: Do we want NocaseDict to be derived from dict, for type checking?

COMMENT/KS: It is confusing when it is not inherited and probably not very pythonic. Thought it over last night and we should not be calling it a dict if it does not inherit from dict.

PR #79 (targeted for 1.0.3) disabled pylint issue R0801 temporarily.

The circumvention should be transitioned into a final solution once pylint issue https://github.com/PyCQA/pylint/issues/4118 is addressed.

This PR is used to run the CI tests on the master branch, on the full set of OS / Python / package level combinations.

The test is scheduled to run on a weekly basis.

Do not merge this PR!!

The sys.getsizeof(obj) function returns the memory size of obj in Bytes. It does that by calling __sizeof__() on the object and adding the GC overhead if the object is GC-managed.

The rules for whether a user-defined class like NocaseDict has to implement __sizeof__() are not documented in the Python docs.

Here is a comparison between dict and NocaseDict that suggests that not implementing __sizeof__() is incorrect. On the other hand, dictionaries are referencing their key and value objects, so if multiple dictionaries reference the same objects it would not make too much sense to attribute their sizes to the dictionaries.

import sys
from nocasedict import NocaseDict
nd = NocaseDict()
d = dict()
print("len dict NocaseDict")
for x in range(0, 25):
    print(x, sys.getsizeof(d), sys.getsizeof(nd))
    key = 'key' + str(x)
    nd[key] = x
    d[key] = x

resulting in:

len dict NocaseDict
0 232 48
1 232 48
2 232 48
3 232 48
4 232 48
5 232 48
6 360 48
7 360 48
8 360 48
9 360 48
10 360 48
11 640 48
12 640 48
13 640 48
14 640 48
15 640 48
16 640 48
17 640 48
18 640 48
19 640 48
20 640 48
21 640 48
22 1176 48
23 1176 48
24 1176 48
25 1176 48

The current NocaseDict code supports a __hash__() method that calculates a hash value from the set of tuples of lower cased dict key and dict item value. That makes it a hashable object. Hashable objects can be used as members in sets or as keys in mappings (dicts).

NocaseDict objects are mutable, but the hash value is calculated under the assumption that the object does not change its value while used in a set or as a key, i.e. it is calculated just once for a particular object. For this reason, the mutable standard types in Python (e.g. dict) are not hashable. Changing the value while in a set or used as a key can have strange effects (there are forum threads full of that).

Right now, we document that the NocaseDict objects that are used in a set or as a mapping key must not change while being used that way. However, there is no enforcement about that.

Pywbem is using NocaseDict objects in sets (I believe, need to double check).

DISCUSSION: Should we continue supporting NocaseDict objects being hashable, or should we remove that functionality because it is considered too dangerous for the general user.

The current NocaseDict init method supports an iterable of pywbem CIM objects whose name attribute is used as dict key. That ability is very convenient for pywbem and needs to be retained.

Options are:

• NocaseDict continues to support the functionality, but in a cleaned up way. It would be an additional functionality on top of what the standard Python dict supports.
• NocaseDict no longer supports it, and the pywbem code handles it. That is possible because NocaseDict objects so far were not created by pywbem users.

COMMENT/ks: Actually it is used in pywbemcli but only in tests. The tests can be changed.; it is used to generate keybindings for test_instances.py and scopes for test_qualdecl.py

DISCUSSION

It would be nice to have stronger typing when using the package. Currently, Mypy does not find any types when importing from nocasedict:

A good first step would be to add the py.typed marker, and ensure that all function arguments and return values have type hints. The project could benefit from Mypy linting itself, but that is not required.

I am comparing various implementations of case-insensitive dictionaries in Python, and have found that this one uses str.lower() rather than str.casefold(). See e.g. pydicti, which uses casefold() is available, and falls back to lower() if not available. If both fail, the key is used verbatim.

The advantage of casefold is that is has better unicode support than lower.