This is inconsistent with what we're doing elsewhere in typeshed. That said, I can see us using that now that we include defaults in stubs. But if we do it we should do it consistently in typeshed, enforced by flake8-pyi.

Not everywhere, but mostly Incomplete | None = None yeah. For comparison:

vs

Some stubs might also use it in select places specifically to pass pyrightconfig.stricter.json

That being said, my opinion here is similar to #13765 and I would prefer this form.

Anyway, for now my motivation is mainly to reduce accidental changes of : Incomplete | None = None <--> =None as I am copying over (and validating) microsoft's definitions used in pylance. And felt that the form =None was both easier to standardize to and had more benefits.

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Not everywhere, but mostly Incomplete | None = None yeah.

That's what I meant.

Some stubs might also use it in select places specifically to pass pyrightconfig.stricter.json

That's not a valid reason to use Incomplete in my opinion. (I also have a long term plan to get rid of the stricter config and generate it automatically on the fly from METADATA.toml fields, which ties into this.)

That being said, my opinion here is similar to #13765 and I would prefer this form.

I agree, this form is more succinct and obviously equivalent.

This change appears to have led to the following new error:

error: Call to untyped function "add_edge" in typed context [no-untyped-call]

I'm not well-versed in the state of these stubs, as it does appear quite a few annotations are missing, but the above seems somewhat worse (i.e. always an error) than the prior state.

but the above seems somewhat worse (i.e. always an error) than the prior state.

It is "worse", because it is accurate. Your type checker is now warning you that by using this method, you are forgoing static type safety, because no one validated which type you should be able to pass in.

From here, you have two approaches:

1. If your project isn't too type safe to begin with, and you accept this loss, you can configure your type-checker to be less strict.
2. You can contribute to completing the stubs so that your code is now properly checked when calling this method. (and in the mean time, add an ignore comment as a temporary workaround if you don't want to change your type-checker configurations).