Bug: False positive `bad-argument-count` for PySpark `Column` methods

[feliblo]

Describe the Bug

Description

Pyrefly incorrectly reports bad-argument-count for zero-argument PySpark Column methods, claiming each call is missing one positional argument.

Affected methods

• .isNull()
• .isNotNull()
• .asc()
• .desc()
• .eqNullSafe(other)

Example

from pyspark.sql import functions as F

F.col("x").isNull()       # ERROR: Expected 1 more positional argument
F.col("x").isNotNull()    # ERROR: Expected 1 more positional argument
F.col("x").asc()          # ERROR: Expected 1 more positional argument
F.col("x").desc()         # ERROR: Expected 1 more positional argument
F.col("x").eqNullSafe(F.col("y"))  # ERROR: Expected 1 more positional argument

Expected behavior

No errors. These are valid zero-argument (or single-argument) methods on pyspark.sql.Column.

Environment

pyrefly: >=1.0.0
pyspark: 3.5.5
preset: legacy

Workaround

[tool.pyrefly.errors]
bad-argument-count = "ignore"

Sandbox Link

No response

(Only applicable for extension issues) IDE Information

No response

[ANU-2524]

Hi! I’d like to work on this issue. I’ll start by reproducing the bug locally and investigating the method binding/signature handling for PySpark Column methods.

[yangdanny97]

didn't have time to dig more into this, but this is the declaration in pyspark

https://github.com/apache/spark/blob/e40d17535e6b52c71e5fde9de3e23dc9680b7c41/python/pyspark/sql/column.py#L1069

maybe a decorator handling issue for us?

[yangdanny97]

@ANU-2524 curious to hear what you find in your investigations

[ANU-2524]

@yangdanny97, I was able to reproduce the issue locally on current main.

Using pyspark==3.5.5 and preset = "legacy", I can consistently reproduce the false-positive bad-argument-count errors for Column methods (isNull, isNotNull, asc, desc, eqNullSafe).

The error pattern seems consistent with self being treated as an unbound positional argument for methods decorated with @dispatch_col_method. I’m now tracing how decorated method signatures are resolved during call analysis.

[ANU-2524]

@yangdanny97, I've created a PR to fix this: #3597

The issue was that decorated methods in stubs become Type::Callable,
but the is_method() function only recognized Type::Function. The PR
adds a 4-line fix to treat Callable as a method when initialized in class body.

See the PR for full details!