You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -378,6 +384,8 @@ In cases with mixed-resolution inputs, the highest resolution is used:
378
384
379
385
.. warning:: Many users will now get "M8[us]" dtype data in cases when they used to get "M8[ns]". For most use cases they should not notice a difference. One big exception is converting to integers, which will give integers 1000x smaller.
380
386
387
+
Similarly, the :class:`Timedelta` constructor and :func:`to_timedelta` with a string input now defaults to a microsecond unit, using nanosecond unit only in cases that actually have nanosecond precision.
Previously, when dealing with a nullable dtype (e.g. ``Float64Dtype`` or ``int64[pyarrow]``), ``NaN`` was treated as interchangeable with :class:`NA` in some circumstances but not others. This was done to make adoption easier, but caused some confusion (:issue:`32265`). In 3.0, an option ``"mode.nan_is_na"`` (default ``True``) controls whether to treat ``NaN`` as equivalent to :class:`NA`.
555
+
Previously, when dealing with a nullable dtype (e.g. ``Float64Dtype`` or ``int64[pyarrow]``),
556
+
``NaN`` was treated as interchangeable with :class:`NA` in some circumstances but not others.
557
+
This was done to make adoption easier, but caused some confusion (:issue:`32265`).
558
+
In 3.0, this behaviour is made consistent to by default treat ``NaN`` as equivalent
559
+
to :class:`NA` in all cases.
548
560
549
-
With ``pd.set_option("mode.nan_is_na", True)`` (again, this is the default), ``NaN`` can be passed to constructors, ``__setitem__``, ``__contains__`` and be treated the same as :class:`NA`. The only change users will see is that arithmetic and ``np.ufunc`` operations that previously introduced ``NaN`` entries produce :class:`NA` entries instead:
561
+
By default, ``NaN`` can be passed to constructors, ``__setitem__``, ``__contains__``
562
+
and will be treated the same as :class:`NA`. The only change users will see is
563
+
that arithmetic and ``np.ufunc`` operations that previously introduced ``NaN``
564
+
entries produce :class:`NA` entries instead.
550
565
551
566
*Old behavior:*
552
567
553
568
.. code-block:: ipython
554
569
555
-
In [2]: ser = pd.Series([0, None], dtype=pd.Float64Dtype())
570
+
# NaN in input gets converted to NA
571
+
In [1]: ser = pd.Series([0, np.nan], dtype=pd.Float64Dtype())
572
+
In [2]: ser
573
+
Out[2]:
574
+
0 0.0
575
+
1 <NA>
576
+
dtype: Float64
577
+
# NaN produced by arithmetic (0/0) remained NaN
556
578
In [3]: ser / 0
557
579
Out[3]:
558
580
0 NaN
559
581
1 <NA>
560
582
dtype: Float64
583
+
# the NaN value is not considered as missing
584
+
In [4]: (ser / 0).isna()
585
+
Out[4]:
586
+
0 False
587
+
1 True
588
+
dtype: bool
561
589
562
590
*New behavior:*
563
591
564
592
.. ipython:: python
565
593
566
-
ser = pd.Series([0, None], dtype=pd.Float64Dtype())
594
+
ser = pd.Series([0, np.nan], dtype=pd.Float64Dtype())
595
+
ser
567
596
ser /0
597
+
(ser /0).isna()
568
598
569
-
By contrast, with ``pd.set_option("mode.nan_is_na", False)``, ``NaN`` is always considered distinct and specifically as a floating-point value, so cannot be used with integer dtypes:
599
+
In the future, the intention is to consider ``NaN`` and :class:`NA` as distinct
600
+
values, and an option to control this behaviour is added in 3.0 through
601
+
``pd.options.future.distinguish_nan_and_na``. When enabled, ``NaN`` is always
602
+
considered distinct and specifically as a floating-point value. As a consequence,
603
+
it cannot be used with integer dtypes.
570
604
571
605
*Old behavior:*
572
606
@@ -580,13 +614,21 @@ By contrast, with ``pd.set_option("mode.nan_is_na", False)``, ``NaN`` is always
580
614
581
615
.. ipython:: python
582
616
583
-
pd.set_option("mode.nan_is_na", False)
584
-
ser = pd.Series([1, np.nan], dtype=pd.Float64Dtype())
585
-
ser[1]
617
+
with pd.option_context("future.distinguish_nan_and_na", True):
618
+
ser = pd.Series([1, np.nan], dtype=pd.Float64Dtype())
619
+
print(ser[1])
620
+
621
+
If we had passed ``pd.Int64Dtype()`` or ``"int64[pyarrow]"`` for the dtype in
622
+
the latter example, this would raise, as a float ``NaN`` cannot be held by an
623
+
integer dtype.
586
624
587
-
If we had passed ``pd.Int64Dtype()`` or ``"int64[pyarrow]"`` for the dtype in the latter example, this would raise, as a float ``NaN`` cannot be held by an integer dtype.
625
+
With ``"future.distinguish_nan_and_na"`` enabled, ``ser.to_numpy()`` (and
626
+
``frame.values`` and ``np.asarray(obj)``) will convert to ``object`` dtype if
627
+
:class:`NA` entries are present, where before they would coerce to
628
+
``NaN``. To retain a float numpy dtype, explicitly pass ``na_value=np.nan``
629
+
to :meth:`Series.to_numpy`.
588
630
589
-
With ``"mode.nan_is_na"`` set to ``False``, ``ser.to_numpy()`` (and ``frame.values`` and ``np.asarray(obj)``) will convert to ``object`` dtype if :class:`NA` entries are present, where before they would coerce to ``NaN``. To retain a float numpy dtype, explicitly pass ``na_value=np.nan`` to :meth:`Series.to_numpy`.
631
+
Note that the option is experimental and subject to change in future releases.
590
632
591
633
The ``__module__`` attribute now points to public modules
- :class:`IncompatibleFrequency` now subclasses ``TypeError`` instead of ``ValueError``. As a result, joins with mismatched frequencies now cast to object like other non-comparable joins, and arithmetic with indexes with mismatched frequencies align (:issue:`55782`)
747
789
- :class:`Series` "flex" methods like :meth:`Series.add` no longer allow passing a :class:`DataFrame` for ``other``; use the DataFrame reversed method instead (:issue:`46179`)
790
+
- :func:`date_range` and :func:`timedelta_range` no longer default to ``unit="ns"``, instead will infer a unit from the ``start``, ``end``, and ``freq`` parameters. Explicitly specify a desired ``unit`` to override these (:issue:`59031`)
748
791
- :meth:`CategoricalIndex.append` no longer attempts to cast different-dtype indexes to the caller's dtype (:issue:`41626`)
749
792
- :meth:`ExtensionDtype.construct_array_type` is now a regular method instead of a ``classmethod`` (:issue:`58663`)
793
+
- Arithmetic operations between a :class:`Series`, :class:`Index`, or :class:`ExtensionArray` with a ``list`` now consistently wrap that list with an array equivalent to ``Series(my_list).array``. To do any other kind of type inference or casting, do so explicitly before operating (:issue:`62552`)
750
794
- Comparison operations between :class:`Index` and :class:`Series` now consistently return :class:`Series` regardless of which object is on the left or right (:issue:`36759`)
751
795
- Numpy functions like ``np.isinf`` that return a bool dtype when called on a :class:`Index` object now return a bool-dtype :class:`Index` instead of ``np.ndarray`` (:issue:`52676`)
796
+
- Methods that can operate in-place (:meth:`~DataFrame.replace`, :meth:`~DataFrame.fillna`,
- Bug in :class:`DataFrame` and :class:`Series` ``repr`` of :py:class:`collections.abc.Mapping` elements. (:issue:`57915`)
1229
+
- Bug in :meth:`DataFrame.to_hdf` and :func:`read_hdf` with ``timedelta64`` dtypes with non-nanosecond resolution failing to round-trip correctly (:issue:`63239`)
1181
1230
- Fix bug in ``on_bad_lines`` callable when returning too many fields: now emits
1182
1231
``ParserWarning`` and truncates extra fields regardless of ``index_col`` (:issue:`61837`)
1183
1232
- Bug in :func:`pandas.json_normalize` inconsistently handling non-dict items in ``data`` when ``max_level`` was set. The function will now raise a ``TypeError`` if ``data`` is a list containing non-dict items (:issue:`62829`)
1233
+
- Bug in :func:`pandas.json_normalize` raising ``TypeError`` when ``meta`` contained a non-string key (e.g., ``int``) and ``record_path`` was specified, which was inconsistent with the behavior when ``record_path`` was ``None`` (:issue:`63019`)
1184
1234
- Bug in :meth:`.DataFrame.to_json` when ``"index"`` was a value in the :attr:`DataFrame.column` and :attr:`Index.name` was ``None``. Now, this will fail with a ``ValueError`` (:issue:`58925`)
1185
1235
- Bug in :meth:`.io.common.is_fsspec_url` not recognizing chained fsspec URLs (:issue:`48978`)
1186
1236
- Bug in :meth:`DataFrame._repr_html_` which ignored the ``"display.float_format"`` option (:issue:`59876`)
@@ -1234,6 +1284,7 @@ Plotting
1234
1284
- Bug in :meth:`Series.plot` preventing a line and bar from being aligned on the same plot (:issue:`61161`)
1235
1285
- Bug in :meth:`Series.plot` preventing a line and scatter plot from being aligned (:issue:`61005`)
1236
1286
- Bug in :meth:`Series.plot` with ``kind="pie"`` with :class:`ArrowDtype` (:issue:`59192`)
1287
+
- Bug in plotting with a :class:`TimedeltaIndex` with non-nanosecond resolution displaying incorrect labels (:issue:`63237`)
1237
1288
1238
1289
Groupby/resample/rolling
1239
1290
^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1264,7 +1315,8 @@ Groupby/resample/rolling
1264
1315
- Bug in :meth:`Rolling.apply` for ``method="table"`` where column order was not being respected due to the columns getting sorted by default. (:issue:`59666`)
1265
1316
- Bug in :meth:`Rolling.apply` where the applied function could be called on fewer than ``min_period`` periods if ``method="table"``. (:issue:`58868`)
1266
1317
- Bug in :meth:`Rolling.sem` computing incorrect results because it divided by ``sqrt((n - 1) * (n - ddof))`` instead of ``sqrt(n * (n - ddof))``. (:issue:`63180`)
1267
-
- Bug in :meth:`Rolling.skew` incorrectly computing skewness for windows following outliers due to numerical instability. The calculation now properly handles catastrophic cancellation by recomputing affected windows (:issue:`47461`)
1318
+
- Bug in :meth:`Rolling.skew` and in :meth:`Rolling.kurt` incorrectly computing skewness and kurtosis, respectively, for windows following outliers due to numerical instability. The calculation now properly handles catastrophic cancellation by recomputing affected windows (:issue:`47461`, :issue:`61416`)
1319
+
- Bug in :meth:`Rolling.skew` and in :meth:`Rolling.kurt` where results varied with input length despite identical data and window contents (:issue:`54380`)
1268
1320
- Bug in :meth:`Series.resample` could raise when the date range ended shortly before a non-existent time. (:issue:`58380`)
1269
1321
- Bug in :meth:`Series.resample` raising error when resampling non-nanosecond resolutions out of bounds for nanosecond precision (:issue:`57427`)
1270
1322
- Bug in :meth:`Series.rolling.var` and :meth:`Series.rolling.std` computing incorrect results due to numerical instability. (:issue:`47721`, :issue:`52407`, :issue:`54518`, :issue:`55343`)
@@ -1302,6 +1354,7 @@ Sparse
1302
1354
- Bug in :class:`SparseDtype` for equal comparison with na fill value. (:issue:`54770`)
1303
1355
- Bug in :meth:`DataFrame.sparse.from_spmatrix` which hard coded an invalid ``fill_value`` for certain subtypes. (:issue:`59063`)
1304
1356
- Bug in :meth:`DataFrame.sparse.to_dense` which ignored subclassing and always returned an instance of :class:`DataFrame` (:issue:`59913`)
1357
+
- Bug in :meth:`cumsum` for integer arrays Calling SparseArray.cumsum caused max recursion depth error. (:issue:`62669`)
0 commit comments