mark-todd
commented
8 months ago Once again thanks for working on developing the PEP for this. I think for a PEP to be accepted it will probably need to describe how it deals with the edge cases we've been discussing, but that doesn't mean we have to do it all in one go. If you have simple definition that is described well, that seems like a good starting point to me, and we can expand on it with edge cases and things that we think will provoke questions like TypedDicts.
We could even have a point of "FAQs" - things that we think aren't necessary to define it but will be useful to people trying to think about these edge cases.
I would suggest when you're happy with a basic structure for it (and perhaps some headings for the edge cases like typed dicts) we can iterate on it a bit. We could open PRs to suggest additional paragraphs/examples and discuss wording.
mikeshardmind
DiscordLiz
Maybe this is a "me issue" and not that this can't be done right now, but I'm unsure how to meaningfully make progress in specifying OrderedIntersection. As far as I'm concerned, it should be as simple as.
All of the rationale for that is already covered over in #38 , the rationale and explaining the rationale is not the issue I'm having.
Based on a lot of other discussions about the typing spec, I don't think it should be specified much more than what is above.
Examples of practical effects and comparisons, and why that's the decision? sure, but this should be extremely clear that these are examples based on the current state for the PEP process, and the examples should not be taken as limitation on intersections, and instead should be updated if the examples ever become wrong due to other changes to other types.
Based on the direction of other parts of typing, it doesn't seem like such a sparse definition will be accepted. I think overspecifying this is a road to compositional incompatabilities.
For instance, the discussion we had about this with TypedDicts. If we decided to say any more and actually say it can't compose TypedDicts with non-typed dicts only because there is no legal way to do this currently, then the spec for intersection has precluded a change to TypedDict that could allow it. The consistency based definition will allow a user to specify such an intersection, but they won't be able to create something to assign to that intersection (without a cast). Such uses then allow disovering what the use cases for expanding on TypedDict may be, and only the specification for typed dict would need to change for the use to be fully legal later on.
The consistency-based rule is rather simple and leaves what is and isn't compatible to the types within the intersection, but the entire direction of the typing spec seems to be trying to come up with increasingly precise, narrow, and even intentionally-limited definitions instead of definitions that state the minimum behavior and generalize, and It's been hard to find a way to describe intersections that doesn't feel wrong as a result, either for being out of place in the specification and unlikely to be accepted by those who want precise and narrow definitions, or for being precise and narrow when that's more limiting to all future constructs without needing to be.
I could use some other guidance here because if I'm off base, and I should just write the simpler definition and explicitly reject a more narrow one in the PEP itself to avoid the issues of composition and that is a direction we want, then I can finish the draft much sooner as there I need far less language to go this route, and I think I've been expending too much time trying to reconcile narrow definitions.