mark-todd

Thanks @CarliJoy, it's a good idea. I feel like we're getting somewhere - the proposal currently on the table seems to have few disadvantages. I'll prepare something in the repo...

Thanks - I think actually this one is quite relevant: https://github.com/pydantic/pydantic/issues/4850 If we had access to extra attrs like this I suppose the warnings could be raised from there

@baluyotraf If you're interested in picking this up again, I might recommend reading this version of the spec too: https://github.com/CarliJoy/intersection_examples/blob/intersection-pep-new/docs/specification.rst We all went back and forth on these quite a...

Most up to date discussion is on this issue: https://github.com/CarliJoy/intersection_examples/issues/48 - so I would probably start there. I wouldn't try reading all of the old issues tbh as there's just...

Also re `Required`/`NotRequired` I think these weren't in Python last time around so may be new discussion. Re `Annotated` I think we might have discussed this before but only briefly...

> `Required[A] & NotRequired[B] isn't possible in my interpretation no matter what A and B are due to the nature of structural subtyping, and NotRequired saying it's possible to remove...

> A & B needs to be detected as invalid here in some way, otherwise this "looks" fine to the user until they go to access x. I suppose I'm...

> I can start drafting a rougher form of what should become the formal proposal as it would exist under the assumption the hashability question will have a usable resolution...

> Yeah, I'm aware of that problem, but I think we need to start with the sound version and leave this as a known place for ergonomic improvement, such as...

Re hashing, I think `__hash__` overrides have to maintain the return type from the supertype or else it's an LSP violation? Notwithstanding that I think basically the rule is: `[1,2,3].__hash__...