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 i mean, i could certainly imagine rational (maybe even useful...?) ideas for ALL of these. can you imagine the endless discussion about what to do with the shiny new frozen operator, for every object under the sun? obviously it would to nothing by raise an error by default. but people would be asking to freeze everything and there would be mountains of ideas threads and it would never end. i'm not saying that reason means we don't have such an operator, but it seems to me this just shows the decision on PEP 315 was the right one. why have such a general operator, that could conceivably- and will be endlessly requested and argued- be expanded to apply MANY things that even though YAGNI for nearly all of them, when the only REAL need is only for a frozenset? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler