Update after Erik's feedback

[rchiodo]

Hope this works. Please feel free to comment.

[debonte]

Maybe this first code block could be removed since the second one is identical except for adding the else block?

[rchiodo]

I think it should be there cause I didn't want to introduce the else case until after the user had seen the if case.

[debonte]

Just want to make sure we're talking about the same thing. I was envisioning the following. And maybe to mention in the if block comment that the "val is a str" behavior is already defined by PEP 647.

`TypeGuards` are used throughout Python libraries to allow a
type checker to narrow the type of something when the ``TypeGuard``
returns true. However, in the ``else`` clause, :pep:`647` didn't prescribe
what the type might be:

    def is_str(val: str | int) -> TypeGuard[str]:
        return isinstance(val, str)

    def func(val: str | int):
        if is_str(val):
            # Type checkers can assume val is a 'str' in this branch
        else:
            # Type here is not narrowed. It is still 'str | int' 

[debonte]

Type checker assumes PosInt here

This is true even though val is int | str (i.e. it doesn't include PosInt)?

[rchiodo]

Yes that's true. This works because PosInt is an int.

[rchiodo]

You should be able to try it yourself in the latest pylance.

Create a pyrightconfig.json with this in it:

{
    "enableExperimentalFeatures" : true
}

Then the TypeGuard will behave as I described here.

[debonte]

I believe that that's how Pyright works. I guess I'm wondering:

a) Is this correct?

b) What would be the behavior if PosInt was unrelated to any of the types in the val union? Consider the following example. Within the if block, is val considered to be datetime because is_datetime returned true? Or is it Never because the intersection of datetime and int | str is empty? Oh, I guess this might be the multiple inheritance thing again. Maybe the val passed into func is derived from both int and datetime?

def is_datetime(val: datetime | int | str) -> TypeGuard[datetime]:
    return isinstance(val, datetime)

def func(val: int | str):
    if is_datetime(val):
        # Is val a datetime here or Never?

c) Should the PEP call more attention to these issues?

[rchiodo]

I believe the TypeGuard pep says that if the TypeGuard returns something nonsensical, that's the user's fault. It will just happily presume that's the actual type if the TypeGuard returns true.

This is exactly what Pyright does at the moment.

[rchiodo]

It's mentioned here:
https://peps.python.org/pep-0647/#enforcing-strict-narrowing

[debonte]

Just want to make sure we're talking about the same thing. I was envisioning the following. And maybe to mention in the if block comment that the "val is a str" behavior is already defined by PEP 647.

`TypeGuards` are used throughout Python libraries to allow a
type checker to narrow the type of something when the ``TypeGuard``
returns true. However, in the ``else`` clause, :pep:`647` didn't prescribe
what the type might be:

    def is_str(val: str | int) -> TypeGuard[str]:
        return isinstance(val, str)

    def func(val: str | int):
        if is_str(val):
            # Type checkers can assume val is a 'str' in this branch
        else:
            # Type here is not narrowed. It is still 'str | int' 

[debonte]

I believe that that's how Pyright works. I guess I'm wondering:

a) Is this correct?

b) What would be the behavior if PosInt was unrelated to any of the types in the val union? Consider the following example. Within the if block, is val considered to be datetime because is_datetime returned true? Or is it Never because the intersection of datetime and int | str is empty? Oh, I guess this might be the multiple inheritance thing again. Maybe the val passed into func is derived from both int and datetime?

def is_datetime(val: datetime | int | str) -> TypeGuard[datetime]:
    return isinstance(val, datetime)

def func(val: int | str):
    if is_datetime(val):
        # Is val a datetime here or Never?

c) Should the PEP call more attention to these issues?

[rchiodo]

I was thinking "Specification". Counter examples don't strike me as part of the motivation for this PEP.

Sounds good. I'll move it.