pyAutoGui: Correct Return Type of position() to Match Actual Behavior

[codekoriko]

Point being a Tuple of float it does not match the actual behavior of the position() function:

def position(x=None, y=None):
    """
    Returns the current xy coordinates of the mouse cursor as a two-integer tuple.

    Args:
      x (int, None, optional) - If not None, this argument overrides the x in
        the return value.
      y (int, None, optional) - If not None, this argument overrides the y in
        the return value.

    Returns:
      (x, y) tuple of the current xy coordinates of the mouse cursor.

    NOTE: The position() function doesn't check for failsafe.
    """
    posx, posy = platformModule._position()
    posx = int(posx)
    posy = int(posy)
    if x is not None:  # If set, the x parameter overrides the return value.
        posx = int(x)
    if y is not None:  # If set, the y parameter overrides the return value.
        posy = int(y)
    return Point(posx, posy)

[Avasam]

My concern is that this will cause additional casting being needed when a Point is expected and you loose property access:

from math import hypot

def distance_from_origin(point: Point) -> float:
    return hypot(point.x, point.y)

int_point = position(5, 10)

distance = distance_from_origin(int_point)  # (variable) int_point: tuple[int, int]
# Argument of type "tuple[int, int]" cannot be assigned to parameter "point" of type "Point" in function "distance_from_origin"
#  "tuple[int, int]" is incompatible with "Point" Pylance(reportGeneralTypeIssues)

# Argument 1 to "distance_from_origin" has incompatible type "Tuple[int, int]"; expected "Point" Mypy(arg-type)

I think that by using a covariant Generic this can be solved:

from typing import Generic, NamedTuple, TypeVar

_T = TypeVar("_T", int, float, default=float, covariant=True)

class Point(NamedTuple, Generic[_T]):
    x: _T
    y: _T

def position(x: int | None = None, y: int | None = None) -> Point[int]: ...

###

# Downstream code example

from math import hypot

def distance_from_origin(point: Point):  # Same as Point[float]
    return hypot(point.x, point.y)

int_point = position(5, 10)

distance = distance_from_origin(int_point)

This makes possible to pass a Point[int] to a method expecting a Point[float]. And still disallows passing a Point[float] to a method expecting a Point[int].

Once implemented, we could probably improve other methods that are also known to always return a Point[int]. I vaguely remember screen positions being a float only on a single platform (linux?).

The use of default reduces required changes (especially downstream), given this is an edge case. I'm not sure what's the current state of https://peps.python.org/pep-0696/ support. But typeshed's tests should fail if a supported type-checker is not ready for TypeVar defaults.

(CC @AlexWaygood in case you see any issue with my proposal, but it seems sound to me and my quick testing)

[AlexWaygood]

CC @AlexWaygood in case you see any issue with my proposal, but it seems sound to me and my quick testing

(I'm super busy this week unfortunately, so probably won't be able to take a proper look at this until after the 20th, but I trust your judgement!)

[JelleZijlstra]

I don't think we're quite ready for PEP 696 in typeshed. Until then, the current annotation is probably best; int is a subtype of float in the type system, after all.

[srittau]

TypeVar defaults are now available in typeshed.

[Avasam]

@codekoriko Are you willing to update this PR to make use of generic defaults as per #11267 (review) ? If not, I can probably take it over.

[codekoriko]

@codekoriko Are you willing to update this PR to make use of generic defaults as per #11267 (review) ? If not, I can probably take it over.

please go ahead 👍🏻

[JelleZijlstra]

@Avasam are you still interested in continuing this PR?

[Avasam]

I forgot about this. I just applied my previous suggestion.

Although, looking back into this. It looks like PyAutoGUI's Point is only ever used with int, and only ever exposed through position's return type.

So OP's original PR might've been fine as-is.

[github-actions]

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