rusackas commented on PR #45325:
URL: https://github.com/apache/superset/pull/45325#issuecomment-6332077613
Went through this one. `requirements/base.txt`/`development.txt` were
already regenerated, but the actual code needed real fixes, not just a version
bump — pandas 3.0 flips a handful of defaults that broke non-mechanical parts
of the stack:
- `stack()`'s `dropna`/`sort` kwargs are gone (the "future" implementation
never introduces rows to drop), so pivot's `combine_value_with_metric` reshape
didn't need `dropna=False` anymore.
- `resample`'s `asfreq(fill_value=...)`/`interpolate()` now reject writing a
number into a non-numeric column instead of silently coercing it, so those are
scoped to numeric columns only.
- `boxplot`'s numeric coercion only checked `is_object_dtype`, missing the
new default `StringDtype`.
- `contribution`'s all-null/Decimal object columns no longer get silently
downcast to float by `fillna()`, so a 0/0 cell divides as plain Python ints and
raises `ZeroDivisionError` instead of producing `NaN`.
- `histogram` and `utils._append_columns` both had a `.loc[:, col] =`
assignment that now raises instead of coercing when the dtype actually needs to
change (e.g. an int64 column overwritten by a rolling sum that introduces NaN).
- `rolling`'s `quantile` option got renamed to `q` upstream; translated at
the call site so our own `rolling_type_options` API doesn't change.
- `_parse_temporal_join_values` now falls back to element-wise parsing when
pandas refuses to unify a column of differently-offset datetime strings into
one dtype ("Mixed timezones detected").
- `result_set`'s tzinfo fix-up for `FixedOffsetTimezone` values hardcoded
`"ns"` resolution, which could either overflow (far-future dates) or lose
precision (nanosecond-precision values in a column pandas infers more coarsely)
depending on the data — now matches whatever resolution the just-converted
series itself picked, which pandas already chose losslessly.
Also worth flagging: pandas 3 genuinely improved round-tripping a
fixed-offset tz dtype string (`"UTC-04:00"`) through `pd.Series(dtype=...)`
with no sample value to infer it from — pandas 2 used an unparseable
`pytz.FixedOffset(-240)`-style repr there. One of the SQL result-cache tests
assumed the old failure mode as a cache-miss case; updated it since it's just a
straight improvement.
Everything else was test-only: dtype assertions checking literally `==
object` (now `StringDtype`), and a couple of dates that no longer overflow
pandas' widened non-nanosecond `datetime64` range.
Full local run is clean (29756 passed) modulo two pre-existing ARM64-only
failures unrelated to this bump (`np.longdouble` is just `float64` on Apple
Silicon, so a `1e400` literal overflows locally but not on the x86_64 CI
runners).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
