Consider contracts when evaluating Optional
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- PR merge metrics
- PR metrics pending
Description
While mypy considers assert to infer properties (e.g., is not None for Optional's), it would be great if it could also take contracts into account. Some properties can be easily inferred from contracts, in particular exclusivity.
Here is an example:
@icontract.ensure(lambda result: (result[0] is None) ^ (result[1] is None))
def some_func() -> Tuple[Optional[str], Optional[str]]:
...
return something, errors
...
result, errors = some_func()
if errors is not None:
...
# We know here according to the contract that ``result`` can not be None.
The exclusivity is only but one example, and there are many more possible. I don't expect mypy to infer all the possible conclusions, but it would be already very nice to have at least some of the basic properties inferred.
There are a few contracts libraries around (e.g., icontract, for which I am the main author and maintainer, or deal) and they are gaining slowly some popularity.
I would be glad to help out on integration with icontract.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file, test, or entry point is named. Start by mapping mypy's existing Optional narrowing from assert statements and the proposed icontract/deal integration; done would mean defining and testing a limited set of contract-derived properties such as exclusivity.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100