HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tobgu
pyrsistent
Python2014–2025
tobgu / pyrsistent

pyrsistent

Persistent/Immutable/Functional data structures for Python

10Distinct people
11Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Persistent/Immutable/Functional data structures for Python

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2014-12-14 21:15:57 UTC to 2025-12-11 19:09:06 UTC.

0122014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC211
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC211
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

What Hacker News says

11 sources
PMap and PVector, functional Python libraries, "PEP 351 – The freeze protocol" (2005, rejected) https://peps.python.org/pep-0351/ ; IIUC the freeze protocol proposed basically: def freeze(obj) return cache.setsefault(hash(obj), obj.__freeze__()) /? "Existing threads re: consts and applications thereof" I wasn't able to find a URL to this post (2021) from the python-ideas mailing list archives using a double quoted search term today; I had to use the python mailing list search engine? Did something break crawling of mailing lists? Old mailman HTML archives were very simple to crawl.. ENH: pypa: add a sitemap.xml for/of mailing list archives, forums; @pypa: ask for search engine indexing advice: "How do we make sure that the python mailing list archives will be search indexed?" (as they traditionally were) How to find the .t
Read the rest
xt of mailing list archives posts these days? From "[Python-ideas] Re: Introduce constant variables in Python" (2021) https://mail.python.org/archives/list/python-ideas@python.or... : - pyrsistent: PMap, PVector I'm out of time for this; (reformatting this for HN so that URLs will be auto-linkified but newlines won't be eliminated) here's the full email as .txt, the mailing list archive has a hyperlinkified version with newlines preserved. GH Markdown and CommonMark Markdown also preserve newlines and auto-linkify: From: [@westurner] Date: Thu, Jun 17, 2021, 10:43 AM Subject: Re: [Python-ideas] Re: Introduce constant variables in Python Cc: python-ideas <python-ideas@python.org> On Mon, May 24, 2021 at 5:43 PM Chris Angelico <rosuav@gmail.com> wrote: Requiring that a name not be rebound is well-defined and testable. Requiring that an object not change is either trivial (in the case of, say, an integer) or virtually impossible (in the case of most objects). What would be the advantage of such a declaration? ChrisA ## Existing threads re: consts and applications thereof So, `/? from:me pyrsistent` I found a few results: - "[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)" 2016-04 https://mail.python.org/pipermail/python-dev/2016-April/143958.html - ~Sandboxing python within python is nontrivial to impossible; consts might help a bit - https://mail.python.org/pipermail/python-dev/2016-April/143958.html - "Proposal to add const-ness type hints to PEP-484" https://mail.python.org/archives/list/python-ideas@python.org/thread/OVPF5I6IOVF6G… - https://github.com/python/typing/issues/242 - "Final names and attributes" https://github.com/python/mypy/pull/5522 This is where `typing.Final` comes from. - "[Python-ideas] "Immutable Builder" Pattern and Operator" https://mail.python.org/pipermail/python-ideas/2017-January/044374.html - [pyrsistent] and "fn.py [do] immutables: https://github.com/kachayev/fn.py/blob/master/README.rst#persistent-data-structures " - "[Python-ideas] Add recordlcass to collections module" https://groups.google.com/g/python-ideas/c/9crHfcCBgYs/m/6_EEaWJAAgAJ - ORMs (e.g. Django, SQLAlchemy) require "dirty state" checking to know which object attributes have changed and need an SQL statement to be executed to synchronize the state; this is relevant because when we're asking for mutable namedtuple we're often trying to do exactly this pattern. - "[Python-ideas] Suggestions: dict.flow_update and dict.__add__" https://www.google.com/search?q=%22%5BPython-ideas%5D+Suggestions%3A+dict.flow_upd… > dicttoolz has functions for working with these objects; including dicttoolz.merge (which returns a reference to the merged dicts but does not mutate the arguments passed). > > https://toolz.readthedocs.io/en/latest/api.html#dicttoolz > https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.merge > > pyrsistent has a PRecord class with invariants and type checking that precedes dataclasses. pyrsistent also has 'freeze' and 'thaw' functions for immutability. PRecord extends PMap, which implements __add__ as self.update(arg) (which does not mutate self) https://github.com/tobgu/pyrsistent/blob/master/README.rst#precord > > https://github.com/tobgu/pyrsistent/blob/master/pyrsistent/_pmap.py - "[Python-ideas] How to prevent shared memory from being corrupted ?" https://www.google.com/search?q=%22How+to+prevent+shared+memory+from+being+corrupt… > PyArrow Plasma object ids, "sealing" makes an object immutable, pyristent > > https://arrow.apache.org/docs/python/plasma.html#object-ids > https://arrow.apache.org/docs/python/plasma.html#creating-an-object-buffer > > Objects are created in Plasma in two stages. First, they are created, which allocates a buffer for the object. At this point, the client can write to the buffer and construct the object within the allocated buffer. [...] - [Python-ideas] Experimenting with dict performance, and an immutable dict https://mail.python.org/archives/list/python-ideas@python.org/message/DNBGUJHDH4UT… > https://pyrsistent.readthedocs.io/en/latest/intro.html#pyrsistent : > >> Pyrsistent is a number of persistent collections (by some referred to as functional data structures). Persistent in the sense that they are immutable. >> >> All methods on a data structure that would normally mutate it instead return a new copy of the structure containing the requested updates. The original structure is left untouched. >> >> This will simplify the reasoning about what a program does since no hidden side effects ever can take place to these data structures. You can rest assured that the object you hold a reference to will remain the same throughout its lifetime and need not worry that somewhere five stack levels below you in the darkest corner of your application someone has decided to remove that element that you expected to be there. >> >> Pyrsistent is influenced by persistent data structures such as those found in the standard library of Clojure. The data structures are designed to share common elements through path copying. It aims at taking these concepts and make them as pythonic as possible so that they can be easily integrated into any python program without hassle. > What would be the advantage of such a declaration? Constants don't need to be locked or unlocked; which is advantageous for parallelism and reasoning about program correctness. True consts (wherein everything referred to in that object is 'frozen' and immutable or at least only modifiable with e.g. copy-on-write) wouldn't require locks, which would be post-GIL advantageous. You could do consts by never releasing a threading.Lock (or similar): - https://docs.python.org/3/library/asyncio-sync.html#locks - https://docs.python.org/3/library/threading.html#lock-objects - This from https://docs.python.org/2/library/sets.html?highlight=immutable#immutable-transforms re ImmutableSet/FrozenSet is not present in the python 3 docs: https://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset Though - even if Python enforced normal consts in the language - all of the other code objects would still be mutable, so you still have the impossibility of sandboxing python. Functional and contracts coding styles rely upon invariance; which can be accomplished with various third-party packages that enforce const-ness throughout what may be an object tree behind that reference that would otherwise need to be copy.deepcopy()'d. ## pyrsistent Src: https://github.com/tobgu/pyrsistent > - PVector, similar to a python list > - PMap, similar to dict > - PSet, similar to set > - PRecord, a PMap on steroids with fixed fields, optional type and invariant checking and much more > - PClass, a Python class fixed fields, optional type and invariant checking and much more > - Checked collections, PVector, PMap and PSet with optional type and invariance checks and more > - PBag, similar to collections.Counter > - PList, a classic singly linked list > - PDeque, similar to collections.deque > - Immutable object type (immutable) built on the named tuple > - freeze and thaw functions to convert between python standard collections and pyrsistent collections. > - Flexible transformations of arbitrarily complex structures built from PMaps and PVectors. ## icontract Src: https://github.com/Parquery/icontract > icontract provides design-by-contract to Python3 with informative violation messages and inheritance. > > It also gives a base for a flourishing of a wider ecosystem: > > - A linter pyicontract-lint, > - A sphinx plug-in sphinx-icontract, > - A tool icontract-hypothesis for automated testing and ghostwriting test files which infers Hypothesis strategies based on the contracts, together with IDE integrations such as icontract-hypothesis-vim, icontract-hypothesis-pycharm, and icontract-hypothesis-vscode, > - Directly integrated into CrossHair, a tool for automatic verification of Python programs, together with IDE integrations such as crosshair-pycharm and crosshair-vscode, and > - An integration with FastAPI through fastapi-icontract to enforce contracts on your HTTP API and display them in OpenAPI 3 schema and Swagger UI. https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invari... [ https://en.wikipedia.org/wiki/Class_invariant ] > What is the difference between "invariant" and "constant" and "final"?
In A “frozen” dictionary for Python
It still is, and Cython is great for accelerating critical Python code. A C extension is far preferable when you want to code in C, either to write a new data type[1], or write a Python frontend to a C library[2] that is too complex to be well supported by simple FFI. I think people use Cython more internally when they value the maintainability of "mostly Python" over the fact that it's slower than what native C would get them. [1]: https://github.com/tobgu/pyrsistent [2]: https://github.com/libgit2/pygit2
In Hello, HPy
Wow: C++ > Garbage collection was never added into C++. Manual memory management is extremely error prone. C++ has memory management simplification: reference couting via shared_ptr/unique_ptr. The trade-offs are different, but in C++ manually managing memory is not necessary unless you have a good reason. > C++ is notorious for its slow compilation time. Significantly slower than Java, not as bad as Scala. That depends on what you use and how you use it. However, this is tricky to figure out what slows down the compilation. > In C++, all references are nullable. Looks like this guy really needs to read up on C++. References can point to null, but not so easily. I think he means pointers. > Catching/throwing errors is the preferred error handling mechanism. I think he should really watch Herb Sutters Video[see 1] on the improvements of ex
Read the rest
ception handling that are in the pipeline. Herb also discusses the alternatives to exception handling. C# > Multi-paradigm? C# has Pattern matching since 8.0 [see 2] Python > Python is dynamically typed, there’s not much more to say about the type system. Dynamically but strongly typed one could say. > In comparison, NPM in JavaScript is the only tool you’ll ever need. JS has Yarn as well... > I don’t recommend using Python for large projects, the language was not built with serious software engineering in mind. no arguments provided... and in fact there are very large python projects out there in the wild. Also, pytest is one of the best test frameworks that i have seen. Rust > Rust was designed from the ground up to be fast. Compilation of Rust programs takes longer than compilation of Go programs. i don't understand why he bashes C++ for slow compilation times and not rust. According to [see 3] rust is twice as slow on some benchmarks... > Rust is the only modern language on our list with no garbage collection. > This forces the developers to think about low-level memory management, and makes developer productivity suffer. No mention of the borrow checker etc, I find extremely disappointing. > Rust has no built-in support for immutable data structures. Discussions like [4] should be referenced - i think when discussing this topic. JS > JavaScript has good libraries for working with immutable data (like Rambda/Immutable.js). Weird that he doesn't mention the library efforts in C++ [5] and Rust [6] and Python for immutable data-structures [7][8] ---- [1] CppCon 2019: Herb Sutter “De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable” https://www.youtube.com/watch?v=ARYP83yNAWk [2] https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... [3] https://users.rust-lang.org/t/are-there-any-compilation-time... [4] https://users.rust-lang.org/t/persistent-data-structure-supp... [5] https://github.com/arximboldi/immer [6] https://github.com/orium/rpds [7] https://github.com/MagicStack/immutables [8] https://github.com/tobgu/pyrsistent
In These Modern Programming Languages Will Make You Suffer
Most semi-primitive types in python is immutable, yes (int, float, char, str, and DateTime), but all of the collections are mutable (List, Dict, Set). I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked. I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
In Python past, present, and future with Guido van Rossum [audio]

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.