Skip to content

Latest commit

 

History

History
1113 lines (884 loc) · 75.2 KB

v1.4.0.rst

File metadata and controls

1113 lines (884 loc) · 75.2 KB

What's new in 1.4.0 (January 22, 2022)

These are the changes in pandas 1.4.0. See :ref:`release` for a full changelog including other versions of pandas.

{{ header }}

Enhancements

Improved warning messages

Previously, warning messages may have pointed to lines within the pandas library. Running the script setting_with_copy_warning.py

import pandas as pd

df = pd.DataFrame({'a': [1, 2, 3]})
df[:2].loc[:, 'a'] = 5

with pandas 1.3 resulted in:

.../site-packages/pandas/core/indexing.py:1951: SettingWithCopyWarning:
A value is trying to be set on a copy of a slice from a DataFrame.

This made it difficult to determine where the warning was being generated from. Now pandas will inspect the call stack, reporting the first line outside of the pandas library that gave rise to the warning. The output of the above script is now:

setting_with_copy_warning.py:4: SettingWithCopyWarning:
A value is trying to be set on a copy of a slice from a DataFrame.

Index can hold arbitrary ExtensionArrays

Until now, passing a custom :class:`ExtensionArray` to pd.Index would cast the array to object dtype. Now :class:`Index` can directly hold arbitrary ExtensionArrays (:issue:`43930`).

Previous behavior:

.. ipython:: python

   arr = pd.array([1, 2, pd.NA])
   idx = pd.Index(arr)

In the old behavior, idx would be object-dtype:

Previous behavior:

In [1]: idx
Out[1]: Index([1, 2, <NA>], dtype='object')

With the new behavior, we keep the original dtype:

New behavior:

.. ipython:: python

   idx

One exception to this is SparseArray, which will continue to cast to numpy dtype until pandas 2.0. At that point it will retain its dtype like other ExtensionArrays.

Styler

:class:`.Styler` has been further developed in 1.4.0. The following general enhancements have been made:

Additionally there are specific enhancements to the HTML specific rendering:

There are also some LaTeX specific enhancements:

Multi-threaded CSV reading with a new CSV Engine based on pyarrow

:func:`pandas.read_csv` now accepts engine="pyarrow" (requires at least pyarrow 1.0.1) as an argument, allowing for faster csv parsing on multicore machines with pyarrow installed. See the :doc:`I/O docs </user_guide/io>` for more info. (:issue:`23697`, :issue:`43706`)

Rank function for rolling and expanding windows

Added rank function to :class:`Rolling` and :class:`Expanding`. The new function supports the method, ascending, and pct flags of :meth:`DataFrame.rank`. The method argument supports min, max, and average ranking methods. Example:

.. ipython:: python

    s = pd.Series([1, 4, 2, 3, 5, 3])
    s.rolling(3).rank()

    s.rolling(3).rank(method="max")

Groupby positional indexing

It is now possible to specify positional ranges relative to the ends of each group.

Negative arguments for :meth:`.DataFrameGroupBy.head`, :meth:`.SeriesGroupBy.head`, :meth:`.DataFrameGroupBy.tail`, and :meth:`.SeriesGroupBy.tail` now work correctly and result in ranges relative to the end and start of each group, respectively. Previously, negative arguments returned empty frames.

.. ipython:: python

    df = pd.DataFrame([["g", "g0"], ["g", "g1"], ["g", "g2"], ["g", "g3"],
                       ["h", "h0"], ["h", "h1"]], columns=["A", "B"])
    df.groupby("A").head(-1)


:meth:`.DataFrameGroupBy.nth` and :meth:`.SeriesGroupBy.nth` now accept a slice or list of integers and slices.

.. ipython:: python

    df.groupby("A").nth(slice(1, -1))
    df.groupby("A").nth([slice(None, 1), slice(-1, None)])

:meth:`.DataFrameGroupBy.nth` and :meth:`.SeriesGroupBy.nth` now accept index notation.

.. ipython:: python

    df.groupby("A").nth[1, -1]
    df.groupby("A").nth[1:-1]
    df.groupby("A").nth[:1, -1:]

DataFrame.from_dict and DataFrame.to_dict have new 'tight' option

A new 'tight' dictionary format that preserves :class:`MultiIndex` entries and names is now available with the :meth:`DataFrame.from_dict` and :meth:`DataFrame.to_dict` methods and can be used with the standard json library to produce a tight representation of :class:`DataFrame` objects (:issue:`4889`).

.. ipython:: python

    df = pd.DataFrame.from_records(
        [[1, 3], [2, 4]],
        index=pd.MultiIndex.from_tuples([("a", "b"), ("a", "c")],
                                        names=["n1", "n2"]),
        columns=pd.MultiIndex.from_tuples([("x", 1), ("y", 2)],
                                          names=["z1", "z2"]),
    )
    df
    df.to_dict(orient='tight')

Other enhancements

Notable bug fixes

These are bug fixes that might have notable behavior changes.

Inconsistent date string parsing

The dayfirst option of :func:`to_datetime` isn't strict, and this can lead to surprising behavior:

.. ipython:: python
    :okwarning:

    pd.to_datetime(["31-12-2021"], dayfirst=False)

Now, a warning will be raised if a date string cannot be parsed accordance to the given dayfirst value when the value is a delimited date string (e.g. 31-12-2012).

Ignoring dtypes in concat with empty or all-NA columns

Note

This behaviour change has been reverted in pandas 1.4.3.

When using :func:`concat` to concatenate two or more :class:`DataFrame` objects, if one of the DataFrames was empty or had all-NA values, its dtype was sometimes ignored when finding the concatenated dtype. These are now consistently not ignored (:issue:`43507`).

.. ipython:: python
    :okwarning:

    df1 = pd.DataFrame({"bar": [pd.Timestamp("2013-01-01")]}, index=range(1))
    df2 = pd.DataFrame({"bar": np.nan}, index=range(1, 2))
    res = pd.concat([df1, df2])

Previously, the float-dtype in df2 would be ignored so the result dtype would be datetime64[ns]. As a result, the np.nan would be cast to NaT.

Previous behavior:

In [4]: res
Out[4]:
         bar
0 2013-01-01
1        NaT

Now the float-dtype is respected. Since the common dtype for these DataFrames is object, the np.nan is retained.

New behavior:

In [4]: res
Out[4]:
                   bar
0  2013-01-01 00:00:00
1                  NaN

Null-values are no longer coerced to NaN-value in value_counts and mode

:meth:`Series.value_counts` and :meth:`Series.mode` no longer coerce None, NaT and other null-values to a NaN-value for np.object_-dtype. This behavior is now consistent with unique, isin and others (:issue:`42688`).

.. ipython:: python

    s = pd.Series([True, None, pd.NaT, None, pd.NaT, None])
    res = s.value_counts(dropna=False)

Previously, all null-values were replaced by a NaN-value.

Previous behavior:

In [3]: res
Out[3]:
NaN     5
True    1
dtype: int64

Now null-values are no longer mangled.

New behavior:

.. ipython:: python

    res

mangle_dupe_cols in read_csv no longer renames unique columns conflicting with target names

:func:`read_csv` no longer renames unique column labels which conflict with the target names of duplicated columns. Already existing columns are skipped, i.e. the next available index is used for the target column name (:issue:`14704`).

.. ipython:: python

    import io

    data = "a,a,a.1\n1,2,3"
    res = pd.read_csv(io.StringIO(data))

Previously, the second column was called a.1, while the third column was also renamed to a.1.1.

Previous behavior:

In [3]: res
Out[3]:
    a  a.1  a.1.1
0   1    2      3

Now the renaming checks if a.1 already exists when changing the name of the second column and jumps this index. The second column is instead renamed to a.2.

New behavior:

.. ipython:: python

    res

unstack and pivot_table no longer raises ValueError for result that would exceed int32 limit

Previously :meth:`DataFrame.pivot_table` and :meth:`DataFrame.unstack` would raise a ValueError if the operation could produce a result with more than 2**31 - 1 elements. This operation now raises a :class:`errors.PerformanceWarning` instead (:issue:`26314`).

Previous behavior:

In [3]: df = DataFrame({"ind1": np.arange(2 ** 16), "ind2": np.arange(2 ** 16), "count": 0})
In [4]: df.pivot_table(index="ind1", columns="ind2", values="count", aggfunc="count")
ValueError: Unstacked DataFrame is too big, causing int32 overflow

New behavior:

In [4]: df.pivot_table(index="ind1", columns="ind2", values="count", aggfunc="count")
PerformanceWarning: The following operation may generate 4294967296 cells in the resulting pandas object.

groupby.apply consistent transform detection

:meth:`.DataFrameGroupBy.apply` and :meth:`.SeriesGroupBy.apply` are designed to be flexible, allowing users to perform aggregations, transformations, filters, and use it with user-defined functions that might not fall into any of these categories. As part of this, apply will attempt to detect when an operation is a transform, and in such a case, the result will have the same index as the input. In order to determine if the operation is a transform, pandas compares the input's index to the result's and determines if it has been mutated. Previously in pandas 1.3, different code paths used different definitions of "mutated": some would use Python's is whereas others would test only up to equality.

This inconsistency has been removed, pandas now tests up to equality.

.. ipython:: python

    def func(x):
        return x.copy()

    df = pd.DataFrame({'a': [1, 2], 'b': [3, 4], 'c': [5, 6]})
    df

Previous behavior:

In [3]: df.groupby(['a']).apply(func)
Out[3]:
     a  b  c
a
1 0  1  3  5
2 1  2  4  6

In [4]: df.set_index(['a', 'b']).groupby(['a']).apply(func)
Out[4]:
     c
a b
1 3  5
2 4  6

In the examples above, the first uses a code path where pandas uses is and determines that func is not a transform whereas the second tests up to equality and determines that func is a transform. In the first case, the result's index is not the same as the input's.

New behavior:

In [5]: df.groupby(['a']).apply(func)
Out[5]:
   a  b  c
0  1  3  5
1  2  4  6

In [6]: df.set_index(['a', 'b']).groupby(['a']).apply(func)
Out[6]:
     c
a b
1 3  5
2 4  6

Now in both cases it is determined that func is a transform. In each case, the result has the same index as the input.

Backwards incompatible API changes

Increased minimum version for Python

pandas 1.4.0 supports Python 3.8 and higher.

Increased minimum versions for dependencies

Some minimum supported versions of dependencies were updated. If installed, we now require:

Package Minimum Version Required Changed
numpy 1.18.5 X X
pytz 2020.1 X X
python-dateutil 2.8.1 X X
bottleneck 1.3.1   X
numexpr 2.7.1   X
pytest (dev) 6.0    
mypy (dev) 0.930   X

For optional libraries the general recommendation is to use the latest version. The following table lists the lowest version per library that is currently being tested throughout the development of pandas. Optional libraries below the lowest tested version may still work, but are not considered supported.

Package Minimum Version Changed
beautifulsoup4 4.8.2 X
fastparquet 0.4.0  
fsspec 0.7.4  
gcsfs 0.6.0  
lxml 4.5.0 X
matplotlib 3.3.2 X
numba 0.50.1 X
openpyxl 3.0.3 X
pandas-gbq 0.14.0 X
pyarrow 1.0.1 X
pymysql 0.10.1 X
pytables 3.6.1 X
s3fs 0.4.0  
scipy 1.4.1 X
sqlalchemy 1.4.0 X
tabulate 0.8.7  
xarray 0.15.1 X
xlrd 2.0.1 X
xlsxwriter 1.2.2 X
xlwt 1.3.0  

See :ref:`install.dependencies` and :ref:`install.optional_dependencies` for more.

Other API changes

  • :meth:`Index.get_indexer_for` no longer accepts keyword arguments (other than target); in the past these would be silently ignored if the index was not unique (:issue:`42310`)

  • Change in the position of the min_rows argument in :meth:`DataFrame.to_string` due to change in the docstring (:issue:`44304`)

  • Reduction operations for :class:`DataFrame` or :class:`Series` now raising a ValueError when None is passed for skipna (:issue:`44178`)

  • :func:`read_csv` and :func:`read_html` no longer raising an error when one of the header rows consists only of Unnamed: columns (:issue:`13054`)

  • Changed the name attribute of several holidays in USFederalHolidayCalendar to match official federal holiday names specifically:

    • "New Year's Day" gains the possessive apostrophe
    • "Presidents Day" becomes "Washington's Birthday"
    • "Martin Luther King Jr. Day" is now "Birthday of Martin Luther King, Jr."
    • "July 4th" is now "Independence Day"
    • "Thanksgiving" is now "Thanksgiving Day"
    • "Christmas" is now "Christmas Day"
    • Added "Juneteenth National Independence Day"

Deprecations

Deprecated Int64Index, UInt64Index & Float64Index

:class:`Int64Index`, :class:`UInt64Index` and :class:`Float64Index` have been deprecated in favor of the base :class:`Index` class and will be removed in Pandas 2.0 (:issue:`43028`).

For constructing a numeric index, you can use the base :class:`Index` class instead specifying the data type (which will also work on older pandas releases):

# replace
pd.Int64Index([1, 2, 3])
# with
pd.Index([1, 2, 3], dtype="int64")

For checking the data type of an index object, you can replace isinstance checks with checking the dtype:

# replace
isinstance(idx, pd.Int64Index)
# with
idx.dtype == "int64"

Currently, in order to maintain backward compatibility, calls to :class:`Index` will continue to return :class:`Int64Index`, :class:`UInt64Index` and :class:`Float64Index` when given numeric data, but in the future, an :class:`Index` will be returned.

Current behavior:

In [1]: pd.Index([1, 2, 3], dtype="int32")
Out [1]: Int64Index([1, 2, 3], dtype='int64')
In [1]: pd.Index([1, 2, 3], dtype="uint64")
Out [1]: UInt64Index([1, 2, 3], dtype='uint64')

Future behavior:

In [3]: pd.Index([1, 2, 3], dtype="int32")
Out [3]: Index([1, 2, 3], dtype='int32')
In [4]: pd.Index([1, 2, 3], dtype="uint64")
Out [4]: Index([1, 2, 3], dtype='uint64')

Deprecated DataFrame.append and Series.append

:meth:`DataFrame.append` and :meth:`Series.append` have been deprecated and will be removed in a future version. Use :func:`pandas.concat` instead (:issue:`35407`).

Deprecated syntax

In [1]: pd.Series([1, 2]).append(pd.Series([3, 4])
Out [1]:
<stdin>:1: FutureWarning: The series.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.
0    1
1    2
0    3
1    4
dtype: int64

In [2]: df1 = pd.DataFrame([[1, 2], [3, 4]], columns=list('AB'))
In [3]: df2 = pd.DataFrame([[5, 6], [7, 8]], columns=list('AB'))
In [4]: df1.append(df2)
Out [4]:
<stdin>:1: FutureWarning: The series.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.
   A  B
0  1  2
1  3  4
0  5  6
1  7  8

Recommended syntax

.. ipython:: python

    pd.concat([pd.Series([1, 2]), pd.Series([3, 4])])

    df1 = pd.DataFrame([[1, 2], [3, 4]], columns=list('AB'))
    df2 = pd.DataFrame([[5, 6], [7, 8]], columns=list('AB'))
    pd.concat([df1, df2])


Other Deprecations

Performance improvements

Bug fixes

Categorical

Datetimelike

Timedelta

Time Zones

Numeric

Conversion

Strings

  • Bug in checking for string[pyarrow] dtype incorrectly raising an ImportError when pyarrow is not installed (:issue:`44276`)

Interval

Indexing

Missing

MultiIndex

I/O

Period

Plotting

Groupby/resample/rolling

Reshaping

Sparse

ExtensionArray

Styler

Other

Contributors

.. contributors:: v1.3.5..v1.4.0