[AIRFLOW-5359] Update type annotations in BaseOperator

[TobKed]

Make sure you have checked all steps below.

Jira

• My PR addresses the following Airflow Jira issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"
  • https://issues.apache.org/jira/browse/AIRFLOW-5359
  • In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a Jira issue.
  • In case you are proposing a fundamental code change, you need to create an Airflow Improvement Proposal (AIP).
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Description

• Here are some details about my PR, including screenshots of any UI changes:

Tests

• My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

• My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain docstrings that explain what it does
  • If you implement backwards incompatible changes, please leave a note in the Updating.md so we can assign it to a appropriate release

Code Quality

• Passes flake8

[TobKed]

CC: @ashb

[kaxil]

This should be Optional[Callable], all the callbacks are optional so they can take None or a callable function

[TobKed]

I've raised question about Optional type on Airflow Slack here.
It was pointed there that arguments with a None default value are having an implicit Optional[...] type. It is default mypy behavior until it is not configured differently. Documentation about it here: The mypy command line - None and Optional handling and here: The mypy configuration file - None and Optional handling.
Due to this I assumed less code is better and I wanted to make annotations to be more consistent (some of them have Optional and some not). I had the same approach in another PR [AIRFLOW-5360] Type annotations for BaseSensorOperator and some future ones on which I am currently working.

[kaxil]

Hmm. I am in favor of having Optional even if we have None as default.
But again that is my preference.

I will leave it to other committers @mik-laj @potiuk

[potiuk]

There is a huge discussion here: python/typing#275

[kaxil]

Thanks @potiuk for that link.

Following discussion in python/typing#275, there is a consensus that it is better to require optional types to be made explicit. This PR changes the wording of PEP 484 to allow, but not require, type checkers to treat a None default as implicitly making an argument Optional.

So please let's not change this

[kaxil]

python/peps#689 for you reference @TobKed

[potiuk]

Yeah. I read a bit more in detail and actually what I think now (I changed my mind) since there is this "trend" and possible future breaking change to disallow implicit Optional, maybe we should do more than that - namely we should convert all implicit Optionals and add '--disable-implicit-optional' flag to mypy and prevent anyone from ever adding implicit Optional?

[TobKed]

Thanks @kaxil and @potiuk. I've read all your references and I've changed my mind as well. I will change it accordingly. Changing no_implicit_optional mypy flag seems good way to go.

[kaxil]

Same here

[TobKed]

@kaxil @potiuk I've applied changes.

[TobKed]

cc @mik-laj @potiuk