On Fri, 21 Jan 2022 at 22:52, Ricky Teachey <ricky@teachey.org> wrote:
On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
Paired with a __freeze__ dunder method, this applies to any type, not just sets. (Where appropriate of course.)
So:
|{1,2,3}| frozen set |[1,2,3]| tuple! |any-iterable| tuple! |{1:2, 3:4}| frozen dict
A frozen "any iterable" is not necessarily a tuple.
For example, a frozen binary tree should probably keep the tree structure and methods; a frozen dict.keys() should be a frozen set; and its not clear what a frozen iterator should do. Should it run the iterator to exhaustion? Seems odd.
What about non-collections? What's a frozen re.MatchObject?
-- Steve
lord have mercy, what a can of worms this could end up being!:
frozen iostream frozen property frozen function object frozen module object frozen iterator frozen datetime
Let's be fair here... The idea of freezing is to make it hashable, so there's no point talking about freezing a function, module, or datetime, since they are already hashable. Don't saddle the proposal with issues it doesn't have :) (Technically this applies to an re.Match object too, actually, although I had to check to be sure. I've never once wanted to use one as a dict key. In contrast, I most certainly *have* used functions as dict keys, and it's safe and dependable.) ChrisA