I'm starting this thread as a fresh start on the Intersection PEP. We've come across various difficulties in formulating the Intersection PEP, and it's been a long road of discussion - I'm keen for all that hard work not to go to waste.
What's the idea?
This PEP will build a lot on the ideas of the "Ordered Intersection" that's been discussed a lot over the past few weeks, but conceptually is perhaps slightly different. I'm hoping that perhaps these differences will offer solutions to some of the issues we've been facing. The main concepts:
Intersection can be thought of a series of structural layers - Intersection[A,B] is A layered on top of B. There will be more details on exactly what I mean by layering to follow.
For all non-structural types, the intersection must be an instance of all intersection components. They must appear in the same order in the intersection as in the MRO.
What isn't part of this PEP
LSP Violations are not a consideration of this PEP. While they may be invalid at the point of inheritance, intersection will not consider if there is a violation or otherwise, and there may be examples that feature such violations.
Any will be treated like any other class. My hope is that the rules above are sufficient to mean no special casing will be required for the Any class if we consider it by it's structure.
Syntax using & will not be considered, to avoid confusion with unordered intersections. While it may be possible to include, as in the previous PEP there was a subcase dealing with this, for a first PEP I think it will be simpler to exclude this from discussion. It's always possible to add this syntax at a later date, but I leave this to a future PEP.
Other considerations
TypedDict, Callable and Protocol will be considered "structural types", and will not have the instance restriction. Callable will act exactly as a form of the __call__ method, and TypedDict will effectively define the type for the __getitem__ method.
What is layering?
The concept of layering is inspired by the way a lot of photo editing software works. Layers are built up - where features overlap the highest priority layer appears in the final image. In this analogy each class/type is effectively a layer, and the stack of layers is the intersection. A layer does not need to a concrete class and can be a protocol. It only represents the exposed method and attribute types of the class/protocol.
This might be quite controversial, but it seems to me so far that the two concepts at the core of the idea deal with a lot of the discussed edge cases. The PEP will put quite a lot of emphasis on the "How to teach" section as these concepts will be at the very heart of the idea.
Summary
I'm starting this thread as a fresh start on the Intersection PEP. We've come across various difficulties in formulating the Intersection PEP, and it's been a long road of discussion - I'm keen for all that hard work not to go to waste.
What's the idea?
This PEP will build a lot on the ideas of the "Ordered Intersection" that's been discussed a lot over the past few weeks, but conceptually is perhaps slightly different. I'm hoping that perhaps these differences will offer solutions to some of the issues we've been facing. The main concepts:
Intersection[A,B]is A layered on top of B. There will be more details on exactly what I mean by layering to follow.What isn't part of this PEP
&will not be considered, to avoid confusion with unordered intersections. While it may be possible to include, as in the previous PEP there was a subcase dealing with this, for a first PEP I think it will be simpler to exclude this from discussion. It's always possible to add this syntax at a later date, but I leave this to a future PEP.Other considerations
TypedDict,CallableandProtocolwill be considered "structural types", and will not have the instance restriction.Callablewill act exactly as a form of the__call__method, andTypedDictwill effectively define the type for the__getitem__method.What is layering?
The concept of layering is inspired by the way a lot of photo editing software works. Layers are built up - where features overlap the highest priority layer appears in the final image. In this analogy each class/type is effectively a layer, and the stack of layers is the intersection. A layer does not need to a concrete class and can be a protocol. It only represents the exposed method and attribute types of the class/protocol.
This might be quite controversial, but it seems to me so far that the two concepts at the core of the idea deal with a lot of the discussed edge cases. The PEP will put quite a lot of emphasis on the "How to teach" section as these concepts will be at the very heart of the idea.