Pyright accepts an invalid ellipsis default value, outside of an interface or protocol

[maxime-didier]

Describe the bug

The following unsound definition is accepted by pyright 1.1.337 in strict mode while mypy 1.4.1 in strict mode rejects it:

def the_bad(x: list[int] = ...) -> list[int]:
    return x

mypy --strict outputs the following for this definition:

error: Incompatible default for argument "x" (default has type "ellipsis", argument has type "list[int]")  [assignment]

Pyright should reject this program.

[erictraut]

The current behavior is by design, so I don't consider this a bug. I'll change this to an enhancement request and consider it in that light.

The ellipsis is used in Python to represent a placeholder. In typing terms, it's used to represent Any or "unspecified".

Pyright allows ... to be used for the body of a function regardless of the return type annotation. That is, it doesn't enforce the return type in this case.

I think that not enforcing types for ... used as a default argument value is consistent with pyright's other handling of ....

An ellipsis is used frequently in code samples (e.g. on Stack Overflow, GitHub issues, and documentation sites) to demonstrate type-related concepts, and there's value in being able to simply paste these code samples into an editor or playground.

On the other hand, if this is a common source of runtime bugs, I can see why it might be useful for a type checker to report an error here. The question is whether this is actually a common source of runtime bug.

Out of curiosity, did you actually run into this case in real code and get bitten by it? Or did you simply notice the current behavior and think "I expected pyright to report this"?

[Azureblade3808]

I'd vote for keeping Pyright's current behavior.

I sometimes use ellipsis as a convenient sentinel in experimental code. Ellipsis, as a built-in object, has several advantages over custom sentinels --

• It doesn't require definition and importing.
• I don't need to worry about whether it is still the same instance after an auto-reloading which happens a lot in experiments.

In other aspects, it works almost no differently from a custom sentinel, no matter good or bad.

[maxime-didier]

@erictraut

I've been maintaining a python codebase and introducing typing annotations to it. I noticed this while discussing a coding pattern with a coworker.

I understand the use of ... as a placeholder in stubs files, protocols, abstract methods, etc..., either as a function body placeholder or as a placeholder for an unspecified default value. In the example I provided, I was in neither of those cases. The ellipsis was intended as a sentinel value but such code could also result from ie. copy-pasting a protocol definition to implement it and forgetting to remove the placeholders in default arguments.

@Azureblade3808

The problem here is that I was working with pyright in strict mode. I don't really care if basic mode lets me use ... as a sentinel value without checking it, but I need the strict mode to report such code because this is the kind of issues we've been having rather frequently in production with non-type-checked python code. Also, to me, one of the main selling points of having a strict type checking mode is to free me from having to think through such low-level logic details and focus more on how the code handles the business requirements.

I would prefer strict mode to behave like this:

# reportGeneralTypeIssues: Expression of type "EllipsisType" cannot be assigned to parameter of type "list[int]"
def missing_param_annotation(x: list[int] = ...) -> None:
   some(actual, code)

# reportGeneralTypeIssues: Expression of type "list[int] | EllipsisType" cannot be assigned to return type "list[int]"
def unchecked_sentinel(x: list[int] | EllipsisType = ...) -> list[int]:
  return x

This behavior could be controlled with a configuration switch in the style of strictParameterNoneValue and strictSetInference.

[Azureblade3808]

@maxime-didier Considering about "correctness", I support your point.

I just checked and found that Mypy disallows using ellipsis as default values when the function is implemented, so I think it should not be very common to use ellipsis as sentinels with type-checking. I myself also don't use it this way in production code, because of bad code smell.

If change should be made, I'd suggest Mypy's behavior be copied -- when a function has a body of a plain ... or pass (which I personally don't agree) or raise NotImplementedError, ellipsis is allowed to be used as argument default values, otherwise it should be forbidden without an explicit EllipsisType as argument type. In this way, accidental misuses could be prevented, but it could still be easy to build a prototype function without thinking what a default value should really be.

[erictraut]

That's a good idea — a nice compromise.

[erictraut]

This will be included in the next release.