Please consider using composition over inheritance

[NeilGirdhar]

In my opinion, frozendict shouldn't inherit from dict and therefore MutableMapping. Ideally, you would inherit from Mapping, and use composition over inheritance. I realize that may be a significant change, but it would make the code more correct.

from collections.abc import Mapping, MutableMapping
print(issubclass(frozendict, Mapping))  # True :)
print(issubclass(frozendict, MutableMapping))  # True, unfortunately.

This means doing something like:

class frozendict(Mapping):
    def __init__(...) -> ...:
        self._dict = dict(...)
    # Delegate __getitem__, __iter__, and __len__ to self._dict, along with any methods that would benefit like __contains__.

[Marco-Sulla]

First of all, this is not true for the C Extension.

About the pure py implementation, originally it was designed this way. But accessing _dict is very simple, and this makes the immutability really easy to circumvent.

So I tried to use MappingProxyType instead of dict for _dict. It was really slow. This is why I decided in the end to use inheritance.

PS: usually I prefer composition

[NeilGirdhar]

But accessing _dict is very simple, and this makes the immutability really easy to circumvent.

I don't think it's a reasonable requirement for the immutabilty to be impossible to circumvent. No other Python library goes to such an extent of preventing users from circumventing guarantees. In Python, this is known as the principle of consenting adults.

However, it is a problem for frozendict to inherit from MutableMapping. It will make static type checking not detect problems when a frozendict is passed to a function that requires a MutableMapping, and it will make things like singledispatch to fail.

So I tried to use MappingProxyType instead of dict for _dict. It was really slow. This is why I decided in the end to use inheritance.

I figured that was the reason. I'm surprised that even with a C extension, it's still too slow to use composition.

[Marco-Sulla]

I don't think it's a reasonable requirement for the immutabilty to be impossible to circumvent.

I think it's more than resonable, is a must-have for an immutable type.

No other Python library goes to such an extent of preventing users from circumventing guarantees.

The other libraries does not implements immutable types.

However, it is a problem for frozendict to inherit from MutableMapping. It will make static type checking not detect problems when a frozendict is passed to a function that requires a MutableMapping, and it will make things like singledispatch to fail.

Do you have practical use cases?

I'm surprised that even with a C extension, it's still too slow to use composition.

The C Extension does not need composition, since.... well, is written in C.

All you said applies only to the pure py version. The C extension is not affected by this problem:

$ python
Python 3.10.0 (heads/3.10-dirty:f6e8b80d20, Nov 18 2021, 19:16:18) [GCC 10.1.1 20200718] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import frozendict
>>> frozendict.c_ext
True
>>> from frozendict import frozendict as fd
>>> from collections.abc import MutableMapping
>>> issubclass(fd, MutableMapping)
False
>>> fd.__mro__
(<class 'frozendict.frozendict'>, <class 'object'>)
>>> 

[NeilGirdhar]

The other libraries does not implements immutable types.

I believe you're mistaken here. For example, a frozen dataclass, which is part of the standard library can have immutability circumvented using object.__setattr__.

The C Extension does not need composition, since.... well, is written in C.

Then what's the cost of fixing the Python version so that it's a Mapping but not a MutableMapping? If the C version is fast, what does it matter how the Python version is implemented?

All you said applies only to the pure py version. The C extension is not affected by this problem:

Great! So, you should at least register frozendict with Mapping: collections.abc.Mapping.register(frozendict). It costs nothing and it will answer isinstance checks correctly.

[Marco-Sulla]

I believe you're mistaken here. For example, a frozen dataclass, which is part of the standard library can have immutability circumvented using object.__setattr__.

Indeed I use it in my py code, or I can't even set private attributes. But there's a huge difference in using object.__setattr__, that is known only by few people, and be able to change a simple _dict attribute.

Then what's the cost of fixing the Python version so that it's a Mapping but not a MutableMapping? If the C version is fast, what does it matter how the Python version is implemented?

The C extension does not build on Windows, for example.

Great! So, you should at least register frozendict with Mapping: collections.abc.Mapping.register(frozendict). It costs nothing and it will answer isinstance checks correctly.

Already done, but thank you.

[NeilGirdhar]

Indeed I use it in my py code, or I can't even set private attributes. But there's a huge difference in using object.setattr, that is known only by few people, and simply be able to change a _dict attribute.

I don't think there's a difference. If your goal is to build some kind of security by obfuscation, then you can call the private variable _klajsdflkjas.

The C extension does not build on Windows, for example.

But this means that you different behavior on Windows then? isinstance(frozendict, MutableMapping) gives a different value depending on the platform?

Already done, but thank you.

Awesome!

[Marco-Sulla]

I don't think there's a difference. If your goal is to build some kind of security by obfuscation, then you can call the private variable _klajsdflkjas.

I'm quite sure that this is not "security by obscurity". Since this is Python, this is the best I found to create a reasonably immutable dict without sacrificing speed. Consider that also inheriting from Mapping and using a _dict is much more slow than inheriting from dict.

You can always use MappingProxyType. It's really slow, but it does not have this problem.

But this means that you different behavior on Windows then? isinstance(frozendict, MutableMapping) gives a different value depending on the platform?

This means that the pure py version has this problem, and, as I already said, I don't see any real and practical reasons to change that.

[Marco-Sulla]

MutableMapping fixed, thanks to @d-maurer: ad449be

[NeilGirdhar]

It's better than nothing, but that's a very flimsy way of fixing the problem. If another library comes along and tries that approach, it will clobber your change.

But I understand your desire for speed.

[Marco-Sulla]

If another library comes along and tries that approach, it will clobber your change.

How?

[Marco-Sulla]

If another library comes along and tries that approach, it will clobber your change.

How?

Now that I have more time I understand what you intended.

Listen to me. There are some points that maybe are not clear:

1. The pure py version is only here for the unlucky case the C Extension is not available to your machine and you can't compile it. It's a toy. I created a refactor branch that will make it possible to have a frozendict in C from Python 3.6+ on Linux, Windows and MacOS. And it's faster than dict in some cases, while it has the same speed in many others. The pure py version is the past, the C extension is the future.
2. This is not the only frozendict implementation in the world. If you don't like it, you can consider another package, or
3. this project is FOSS. You can create your fork and do whatever you want.

Good holidays.