Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement per-file strict Optional #3206
I don't think this is quite 100%, but I think it's close. In particular, suggestions for more tests would be very helpful.
This definitely feels a little hacky, but I'm not convinced there's much of a better way to do it. It currently runs cleanly against the smaller of our internal repos, and with only 6 errors against the larger.
What do you think of the idea of moving the context managers into the call sites? Much less code churn, which somehow is always high on my list of PR quality issues.
Regarding the roadmap, we all want this to become the default, but there are several roadblocks.
It would be acceptable to turn on the option by default only when we at least have decent tactics to prevent regressions in mypy itself and the Dropbox codebases. For mypy, that tactic could be to enable it only for a few files, and then gradually increase coverage. That's relatively straightforward (unlike actually getting 100% coverage).
For the Dropbox codebases it's a little more complicated, because we are already actively using the old strict-optional settings in some places, and we have a complicated setup where we run mypy twice, once without strict-optional, and once with it, but suppressing errors in those files that aren't yet strict-optional-clean. I want us to switch to the new approach represented by this PR first before we can even think of making it the default in mypy, just so we don't have a flag that the whole world uses except us (there would be serious quality concerns there).
Really, you could argue with all of this (why should Dropbox be the bar) but I'd like to have some more real-world experience before turning it on by default.
If you find it simple to make mypy itself strict-optional-clean, please be our guest, but hopefully you can submit many small PRs rather than huge one that causes merge conflicts everywhere else.
This is what I was thinking about. There are in total 547
Hmm. Sometimes fixing an error in one place makes several new errors appear. Yet I am optimistic.
I really would like to make another plea for doing the proper refactor (enabling the decorator-based solution) now rather than piling up tech debt.
Highly indented code is less readable.
You could make two decorators, one that uses self.options, the other uses options passed in.
This was referenced
Apr 26, 2017
Do I understand correctly that will only work after this PR is merged? Or can I continue working on making mypy strict-optional-clean without waiting for this PR?