Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate optional items when joining typed dicts #2713

Closed
JukkaL opened this issue Jan 19, 2017 · 1 comment
Closed

Generate optional items when joining typed dicts #2713

JukkaL opened this issue Jan 19, 2017 · 1 comment

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Jan 19, 2017

After we support optional items (#2632), the join of two typed dicts should perhaps have the combined set of items from both dicts, but items not in both dicts would be optional. For example, consider these typed dicts:

A = TypedDict('A', {'x': int, 'y': str})
B = TypedDict('B', {'x': int, 'z': str})

Now I think that the join of A and B should be this:

{'x': int, 'y': OptionalItem[str], 'z': OptionalItem[str]}

This wouldn't be be type-safe, since it's possible that a value with type A also has a runtime 'z' key with an incompatible value type such as int, but this is not visible to the type checker due to structural subtyping. This doesn't feel like a huge problem to me, but it's something to keep in mind.

Consider a concrete example where this would be useful:

B = TypedDict('B', {'a': int})
A = TypedDict('A', {'x': int, 'y': OptionalItem[B]})
a: A = ...
a.get('y', {})

Now the type of the final expression would be {'a': OptionalItem[int]} -- the result of joining B and an empty typed dict {}. For this to work in general, union simplification also needs to use joins when combining two items.

An alternative approach would be just special case a {} argument to get to produce the same result as this proposal, and not do this elsewhere where it would be unsafe to do so. This would be a little less flexible, but maybe the benefits of the general solution would not be worth the unsafety. We could also start with this restricted approach and only introduce the general solution if we find evidence that special casing get is not good enough in real code.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jun 15, 2017

I no longer think that this is a good idea since this is not type safe. Closing this -- we can reconsider if it seems that this would be very useful for type checking real code.

@JukkaL JukkaL closed this as completed Jun 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant