Frozendict is broken on Python 3.8, warns on 3.7

Closing because this repo is abandoned in favor of https://github.com/Marco-Sulla/python-frozendict

Hi! FYI, the following line is emitting deprecation warnings, and will break on Python 3.8:

python-frozendict/frozendict/__init__.py

Line 16 in c5d16ba

class frozendict(collections.Mapping):

That's because all of the abstract base classes have been moved from collections in Python 2, to collections.abc in Python 3. The warning was added in python/cpython#5460. Could you try to import from collections.abc and fall back to the existing style?

There's a PR for this (#23) but I'm worried that the owner has more-or-less abandoned this project.

Hi! First, thx for the great python module :)

Is it possible to get PR (#23) and subsequent update on pip? Would really help, especially for those that treat warning as errors in testing pipelines. If the author is no longer interested in maintaining the project, I'm happy to help out, dm me!

Cheers, m

Seems like that: the author has abandoned this project :(

If anyone is interested, I released a fork on PyPI which supports Python 3.8 : https://pypi.org/project/immutabledict

@slezica

@slezica Hi Santiago! Thank you very much for this project!

As you see, the code won't work on Python 3.9 (they actually delayed it from 3.8). This project is widely used (163k downloads last month according to https://pypistats.org/packages/frozendict!) and it would be a shame for it to have to be removed or replaced in projects.

I understand if you've moved on and have other interests. Please would you consider giving merge and PyPI rights to another maintainer?

I'd suggest @corenting if they're willing, who took initiative to make a fork, and perhaps @ppolewicz, @lurch and @eugene-eeo who were pinged for review in #15, and @mskoenz volunteered above. It's always sensible to have more than one maintainer, to reduce the bus factor and burden. I would be happy to help with some of the maintenance tasks too to help get a new release out.

Additionally to consider, a transfer to https://jazzband.co, which provides additional maintainer backup.

What do you think?

Again, thank you for this project!

@mskoenz

Yeah like @mskoenz I can help maintain the project and put the changes from my fork back into the repository if necessary.

I've also emailed Santiago the above in case he doesn't get notifications here.

@slezica

EDIT new repo is here:
https://github.com/Marco-Sulla/python-frozendict/

OLD ANSWER:

If you are interested, I reimplemented frozendict starting from forking the @slezica 's code. I asked Lezica to became co-admin of Pypi project and he consented, but since we are both very busy we have to do it yet... :-P

Major differences:

Compatible with Python 3.6+ (tested also on Python 3.9)
+ and - operands are supported. + with a dict-like creates a new frozendict merged with the other object. - creates a new frozendict without the keys included in the second operand, that can be any iterable. Addition of the operator + (or |) is also in an official PEP for dict, that seems to be very popular.
repr() returns an eval-friendly string. Use it with caution :-D
Added a unit test (requires pytest) and a benchmark script
a __version__ variable is in the frozendict module
All the dict immutable API is supported, fromkeys() included
pickle is supported (don't know if it was already supported before)
copy() and frozendict(another_frozendict) does not create another object, but returns the same instance. This is the same behaviour of all CPython immutables.
you can't call __init__ again after the object is instantiated
monkey-patching is disabled and attributes and methods are read-only (in teory...)

PS: I'm working also to a CPython version of frozendict. I had only to support pickle, but now I'm very busy. I hope it will be accepted by CPython devs.

That sounds great! Any idea when you'll get PyPI admin? In #29 (comment) you say you've not had any response in a while, perhaps send another ping? It doesn't take long to add someone to PyPI: log in and go to https://pypi.org/manage/project/frozendict/collaboration/

As you're also very busy, and as best practice in general for an important library, I'd recommend having more maintainers on your fork as well, otherwise we may end up in this situation again.

Thanks!

@slezica

Well, the problem is @slezica wrote me some days ago, and I missed the mail :-P So I responded to him yesterday.
And yes, I think that's no problem for me and Lezica to accept maintainers.

@Marco-Sulla

@Marco-Sulla Is your new frozendict implementation deliberately not Python2 compatible?
I realise Python2 is now EOL, but I guess if your implementation doesn't support Python2 then it's not quite a drop-in replacement for @slezica 's version? 🤷‍♂️

I think it's fine to drop Python EOL, as that's normal dev practice, but would suggest first making a final release of current master (perhaps with some of the remaining PRs, if not too drastic).

Then bump the major version and release from the fork.

Will you get merge rights here, or will development happen in your fork?

@hugovk

@hugovk In my fork. Personally I think the last version, the 1.4.0, is stable. It passed many tests I wrote personally and the benchs are good. Maybe I have to rewrite the benchs with pyperf, when I have time.

It's slow only in parts that seem impossible to speed up: it's a problem with Python itself, that probably I have to report to the maintainers of dict and pickle. Well, to be honest, I'll report them when I'll be 5 sigma sure of what I'm affirming here :-D

@lurch Yes, it's not a drop-in replacement. As you can see in the code, it's completely changed, since I do not use Mapping but I inherit dict directly, for speed-up and for improving immutability.

Anyway the API is the same, with only some addings and a little change: copy() simply returns the object itself, it does not accept any arguments, to completely adhere to dict API. To create new, modified versions of a frozendict, you can use +, -, += and -=.

Note that those operators are provisional. They can change and also their behaviour can change. It depends from PEP 584.

I tried to use the Lezica's code with MappingProxyType for _dict, to improve immutability, but it was a disaster. The code was very slow, since MappingProxyType is very, very slow. Furthermore, Mapping subclasses are slow when you want to use them with dict.update(). So I ended up with this ugly but performant decision.

I know, no one should extend a class that do more for doing less, since the API of the parent class can change and you'll have magically a method that will change your "not-so-immutable" :-D

Furthermore I must admit frozendict and any "immutable" in Python can be easily changed. You have only to use ctypes.pythonapi or object.__setattr__().

Anyway it's more difficult, and even Java and C++ can't prevent the use of Reflections or const_cast. But at least it's not so easy.

About Python 2, I think it's a pity that is not compatible with Python 3. But I think the Py devs have done the right decision: UTF-8 by default makes thinks a lot more easy.

I could easily extend the support to 2.6+ but, honestly, I do not want to do it. As you said, Python 2 is at the End Of Life, and continuing to support it will be counterproductive.

@Marco-Sulla

@Marco-Sulla Cool, as long as your new version (which sounds pretty good) is explicitly not a drop-in replacement for @slezica 's frozendict, then I agree it doesn't make sense to add Python2 support to your new version 👍

Replace frozendict by immutabledict

Well, I opened pypi/support#530 but everything is stuck. It's a pity, since I also experimented with CPython and I implemented a frozendict that seems to be faster than dict: Marco-Sulla/python-frozendict#18

In the meanwhile Pypi mods decide, I created a C Extension for Python 3.9 and Linux. It's faster than dict in some operations. Other versions and OSes are planned. The wheel is here:
https://github.com/Marco-Sulla/python-frozendict/releases
Feedbacks are appreciated :)

Migrate from frozendict to immutabledict.

Fix a whole bunch of deprecation warnings

Remove use of frozendict in language manual

Fix a whole bunch of deprecation warnings

Looks like the PyPI transfer has happened!

Well, finally :)
Now I'm a bit busy, in the weekend I'll release v2.0.1: https://github.com/Marco-Sulla/python-frozendict/releases/tag/v2.0.1

Version 2.0.2 released. Unluckily, Pypi supports only manylinux builds, so there's only the pure py version for now.
For any problems, please write here: https://github.com/Marco-Sulla/python-frozendict/issues/new/choose

@Marco-Sulla

Now that @Marco-Sulla has taken over the PyPI project (congrats!), perhaps @slezica could update his README.rst to mention that this repo is now deprecated, and pointing people at the new repo instead? 🙂

Closing because this repo is abandoned in favor of https://github.com/Marco-Sulla/python-frozendict

@Zac-HD

@Zac-HD Could you please add the link to your first post?

Navigation Menu

Repository navigation

Frozendict is broken on Python 3.8, warns on 3.7 #25

3 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Frozendict is broken on Python 3.8, warns on 3.7 #25

Description

Activity

austin1howard commented on Mar 1, 2019

mskoenz commented on Nov 20, 2019

v-hunt commented on Dec 29, 2019

corenting commented on Jan 11, 2020

hugovk commented on Jan 23, 2020

corenting commented on Jan 23, 2020

hugovk commented on Jan 24, 2020

Marco-Sulla commented on Jan 26, 2020

hugovk commented on Jan 26, 2020

Marco-Sulla commented on Jan 26, 2020

lurch commented on Jan 26, 2020

hugovk commented on Jan 26, 2020

Marco-Sulla commented on Jan 26, 2020

lurch commented on Jan 27, 2020

3 remaining items

Marco-Sulla commented on Aug 29, 2020

Marco-Sulla commented on Oct 22, 2020

ulope commented on Apr 27, 2021

Marco-Sulla commented on Apr 27, 2021

Marco-Sulla commented on May 2, 2021

lurch commented on May 2, 2021

Zac-HD commented on Oct 23, 2023

Marco-Sulla commented on Oct 23, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions