[SPARK-38483][PYTHON][CONNECT] Add Column._name property exposing a column's name

[AgenticSpark]

What changes were proposed in this pull request?

This adds a _name property to the PySpark Column class that returns the
column's name, alias, or expression as a string -- the same string shown inside
Column.__repr__ (Column<'...'>). It is implemented for both Spark Classic
(self._jc.toString()) and Spark Connect (self._expr.__repr__()).

>>> from pyspark.sql import functions as sf
>>> df = spark.createDataFrame([(2, "Alice")], ["age", "name"])
>>> df.age._name
'age'
>>> sf.col("value")._name
'value'
>>> sf.col("a").cast("int")._name
'CAST(a AS INT)'

The leading underscore intentionally avoids a collision with the existing
Column.name method, which is an alias for Column.alias.

Why are the changes needed?

Requested in SPARK-38483.
Having the name available as an attribute enables convenient patterns, e.g.
re-aliasing an expression with the source column's name, or branching on a
column's name inside a helper function:

values = sf.col("values")
distinct_values = sf.array_distinct(values).alias(values._name)

def custom_function(col):
    return col.cast("int") if col._name == "my_column" else col.cast("string")

Previously the name was only obtainable by parsing repr(col).

Does this PR introduce any user-facing change?

Yes -- a new Column._name property is available. There is no change to any
existing behavior.

How was this patch tested?

Added test_name_property to ColumnTestsMixin, so it runs under both the
classic (pyspark.sql.tests.test_column) and Spark Connect parity
(pyspark.sql.tests.connect.test_parity_column) suites. It checks concrete
values and the invariant repr(col) == "Column<'%s'>" % col._name. Doctests
were also added on the new property.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: GitHub Copilot CLI (Claude Opus 4.8)

[uros-b]

Suggested change

	.. versionadded:: 5.0.0
	.. versionadded:: 4.3.0

[uros-b]

Note: undocumented Classic/Connect output divergence. The docstring's cast("int") -> 'CAST(a AS INT)' happens to agree, but Spark's own CastExpression.repr (connect/expressions.py:1005-1008) documents cast("long") -> CAST(a AS BIGINT) (Classic) vs CAST(a AS LONG) (Connect). _name inherits this, so the PR's stated motivating use-case ("branch on the name inside a helper function") is backend-dependent and unreliable.

[uros-b]

Note: leading-underscore name on a documented, versionadded-tagged public API is a design smell (private by Python convention yet appears in docs/tab-completion). The collision-avoidance motivation vs Column.name is real, but an alternative (col_name / expr_name) would be cleaner.

[uros-b]

Suggested change

	return self._expr.__repr__()
	return repr(self._expr)

[uros-b]

The new test has one concrete assert (CAST(a AS INT)) plus a tautological invariant loop (repr(col) == "Column<'%s'>" % col._name); please consider adding a concrete expected string for alias/arithmetic (e.g. col("x").alias("y")._name == "x AS y").