{"action":"created","issue":{"url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/183","repository_url":"https://api.github.com/repos/UGentBiomath/wwdata","labels_url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/183/labels{/name}","comments_url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/183/comments","events_url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/183/events","html_url":"https://github.com/UGentBiomath/wwdata/pull/183","id":304360954,"number":183,"title":"Bug #12345 Scheduled daily dependency update on monday","user":{"login":"pyup-bot","id":16239342,"avatar_url":"https://avatars0.githubusercontent.com/u/16239342?v=4","gravatar_id":"","url":"https://api.github.com/users/pyup-bot","html_url":"https://github.com/pyup-bot","followers_url":"https://api.github.com/users/pyup-bot/followers","following_url":"https://api.github.com/users/pyup-bot/following{/other_user}","gists_url":"https://api.github.com/users/pyup-bot/gists{/gist_id}","starred_url":"https://api.github.com/users/pyup-bot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pyup-bot/subscriptions","organizations_url":"https://api.github.com/users/pyup-bot/orgs","repos_url":"https://api.github.com/users/pyup-bot/repos","events_url":"https://api.github.com/users/pyup-bot/events{/privacy}","received_events_url":"https://api.github.com/users/pyup-bot/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-03-12T12:58:31Z","updated_at":"2018-03-13T12:58:31Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/UGentBiomath/wwdata/pulls/183","html_url":"https://github.com/UGentBiomath/wwdata/pull/183","diff_url":"https://github.com/UGentBiomath/wwdata/pull/183.diff","patch_url":"https://github.com/UGentBiomath/wwdata/pull/183.patch"},"body":"\n\n\n\n\n### Update [pandas](https://pypi.python.org/pypi/pandas) from **0.22.0** to **0.22.0**.\n\n\n<details>\n  <summary>Changelog</summary>\n  \n  \n   ### 0.22.0\n   ```\n   ---------------------------\n\nThis is a major release from 0.21.1 and includes a single, API-breaking change.\nWe recommend that all users upgrade to this version after carefully reading the\nrelease note (singular!).\n\n.. _whatsnew_0220.api_breaking:\n\nBackwards incompatible API changes\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nPandas 0.22.0 changes the handling of empty and all-*NA* sums and products. The\nsummary is that\n\n* The sum of an empty or all-*NA* ``Series`` is now ``0``\n* The product of an empty or all-*NA* ``Series`` is now ``1``\n* We&#39;ve added a ``min_count`` parameter to ``.sum()`` and ``.prod()`` controlling\n  the minimum number of valid values for the result to be valid. If fewer than\n  ``min_count`` non-*NA* values are present, the result is *NA*. The default is\n  ``0``. To return ``NaN``, the 0.21 behavior, use ``min_count=1``.\n\nSome background: In pandas 0.21, we fixed a long-standing inconsistency\nin the return value of all-*NA* series depending on whether or not bottleneck\nwas installed. See :ref:`whatsnew_0210.api_breaking.bottleneck`. At the same\ntime, we changed the sum and prod of an empty ``Series`` to also be ``NaN``.\n\nBased on feedback, we&#39;ve partially reverted those changes.\n\nArithmetic Operations\n^^^^^^^^^^^^^^^^^^^^^\n\nThe default sum for empty or all-*NA* ``Series`` is now ``0``.\n\n*pandas 0.21.x*\n\n.. code-block:: ipython\n\n   In [1]: pd.Series([]).sum()\n   Out[1]: nan\n\n   In [2]: pd.Series([np.nan]).sum()\n   Out[2]: nan\n\n*pandas 0.22.0*\n\n.. ipython:: python\n\n   pd.Series([]).sum()\n   pd.Series([np.nan]).sum()\n\nThe default behavior is the same as pandas 0.20.3 with bottleneck installed. It\nalso matches the behavior of NumPy&#39;s ``np.nansum`` on empty and all-*NA* arrays.\n\nTo have the sum of an empty series return ``NaN`` (the default behavior of\npandas 0.20.3 without bottleneck, or pandas 0.21.x), use the ``min_count``\nkeyword.\n\n.. ipython:: python\n\n   pd.Series([]).sum(min_count=1)\n\nThanks to the ``skipna`` parameter, the ``.sum`` on an all-*NA*\nseries is conceptually the same as the ``.sum`` of an empty one with\n``skipna=True`` (the default).\n\n.. ipython:: python\n\n   pd.Series([np.nan]).sum(min_count=1)   skipna=True by default\n\nThe ``min_count`` parameter refers to the minimum number of *non-null* values\nrequired for a non-NA sum or product.\n\n:meth:`Series.prod` has been updated to behave the same as :meth:`Series.sum`,\nreturning ``1`` instead.\n\n.. ipython:: python\n\n   pd.Series([]).prod()\n   pd.Series([np.nan]).prod()\n   pd.Series([]).prod(min_count=1)\n\nThese changes affect :meth:`DataFrame.sum` and :meth:`DataFrame.prod` as well.\nFinally, a few less obvious places in pandas are affected by this change.\n\nGrouping by a Categorical\n^^^^^^^^^^^^^^^^^^^^^^^^^\n\nGrouping by a ``Categorical`` and summing now returns ``0`` instead of\n``NaN`` for categories with no observations. The product now returns ``1``\ninstead of ``NaN``.\n\n*pandas 0.21.x*\n\n.. code-block:: ipython\n\n   In [8]: grouper = pd.Categorical([&#39;a&#39;, &#39;a&#39;], categories=[&#39;a&#39;, &#39;b&#39;])\n\n   In [9]: pd.Series([1, 2]).groupby(grouper).sum()\n   Out[9]:\n   a    3.0\n   b    NaN\n   dtype: float64\n\n*pandas 0.22*\n\n.. ipython:: python\n\n   grouper = pd.Categorical([&#39;a&#39;, &#39;a&#39;], categories=[&#39;a&#39;, &#39;b&#39;])\n   pd.Series([1, 2]).groupby(grouper).sum()\n\nTo restore the 0.21 behavior of returning ``NaN`` for unobserved groups,\nuse ``min_count&gt;=1``.\n\n.. ipython:: python\n\n   pd.Series([1, 2]).groupby(grouper).sum(min_count=1)\n\nResample\n^^^^^^^^\n\nThe sum and product of all-*NA* bins has changed from ``NaN`` to ``0`` for\nsum and ``1`` for product.\n\n*pandas 0.21.x*\n\n.. code-block:: ipython\n\n   In [11]: s = pd.Series([1, 1, np.nan, np.nan],\n      ...:                index=pd.date_range(&#39;2017&#39;, periods=4))\n      ...:  s\n   Out[11]:\n   2017-01-01    1.0\n   2017-01-02    1.0\n   2017-01-03    NaN\n   2017-01-04    NaN\n   Freq: D, dtype: float64\n\n   In [12]: s.resample(&#39;2d&#39;).sum()\n   Out[12]:\n   2017-01-01    2.0\n   2017-01-03    NaN\n   Freq: 2D, dtype: float64\n\n*pandas 0.22.0*\n\n.. ipython:: python\n\n   s = pd.Series([1, 1, np.nan, np.nan],\n                 index=pd.date_range(&#39;2017&#39;, periods=4))\n   s.resample(&#39;2d&#39;).sum()\n\nTo restore the 0.21 behavior of returning ``NaN``, use ``min_count&gt;=1``.\n\n.. ipython:: python\n\n   s.resample(&#39;2d&#39;).sum(min_count=1)\n\nIn particular, upsampling and taking the sum or product is affected, as\nupsampling introduces missing values even if the original series was\nentirely valid.\n\n*pandas 0.21.x*\n\n.. code-block:: ipython\n\n   In [14]: idx = pd.DatetimeIndex([&#39;2017-01-01&#39;, &#39;2017-01-02&#39;])\n\n   In [15]: pd.Series([1, 2], index=idx).resample(&#39;12H&#39;).sum()\n   Out[15]:\n   2017-01-01 00:00:00    1.0\n   2017-01-01 12:00:00    NaN\n   2017-01-02 00:00:00    2.0\n   Freq: 12H, dtype: float64\n\n*pandas 0.22.0*\n\n.. ipython:: python\n\n   idx = pd.DatetimeIndex([&#39;2017-01-01&#39;, &#39;2017-01-02&#39;])\n   pd.Series([1, 2], index=idx).resample(&quot;12H&quot;).sum()\n\nOnce again, the ``min_count`` keyword is available to restore the 0.21 behavior.\n\n.. ipython:: python\n\n   pd.Series([1, 2], index=idx).resample(&quot;12H&quot;).sum(min_count=1)\n\nRolling and Expanding\n^^^^^^^^^^^^^^^^^^^^^\n\nRolling and expanding already have a ``min_periods`` keyword that behaves\nsimilar to ``min_count``. The only case that changes is when doing a rolling\nor expanding sum with ``min_periods=0``. Previously this returned ``NaN``,\nwhen fewer than ``min_periods`` non-*NA* values were in the window. Now it\nreturns ``0``.\n\n*pandas 0.21.1*\n\n.. code-block:: ipython\n\n   In [17]: s = pd.Series([np.nan, np.nan])\n\n   In [18]: s.rolling(2, min_periods=0).sum()\n   Out[18]:\n   0   NaN\n   1   NaN\n   dtype: float64\n\n*pandas 0.22.0*\n\n.. ipython:: python\n\n   s = pd.Series([np.nan, np.nan])\n   s.rolling(2, min_periods=0).sum()\n\nThe default behavior of ``min_periods=None``, implying that ``min_periods``\nequals the window size, is unchanged.\n\nCompatibility\n~~~~~~~~~~~~~\n\nIf you maintain a library that should work across pandas versions, it\nmay be easiest to exclude pandas 0.21 from your requirements. Otherwise, all your\n``sum()`` calls would need to check if the ``Series`` is empty before summing.\n\nWith setuptools, in your ``setup.py`` use::\n\n    install_requires=[&#39;pandas!=0.21.*&#39;, ...]\n\nWith conda, use\n\n.. code-block:: yaml\n\n    requirements:\n      run:\n        - pandas !=0.21.0,!=0.21.1\n\nNote that the inconsistency in the return value for all-*NA* series is still\nthere for pandas 0.20.3 and earlier. Avoiding pandas 0.21 will only help with\nthe empty case.\n\n\n.. _whatsnew_0211:\n   ```\n   \n  \n  \n   ### 0.21.1\n   ```\n   ---------------------------\n\nThis is a minor bug-fix release in the 0.21.x series and includes some small regression fixes,\nbug fixes and performance improvements.\nWe recommend that all users upgrade to this version.\n\nHighlights include:\n\n- Temporarily restore matplotlib datetime plotting functionality. This should\n  resolve issues for users who implicitly relied on pandas to plot datetimes\n  with matplotlib. See :ref:`here &lt;whatsnew_0211.converters&gt;`.\n- Improvements to the Parquet IO functions introduced in 0.21.0. See\n  :ref:`here &lt;whatsnew_0211.enhancements.parquet&gt;`.\n\n\n.. contents:: What&#39;s new in v0.21.1\n    :local:\n    :backlinks: none\n\n\n.. _whatsnew_0211.converters:\n\nRestore Matplotlib datetime Converter Registration\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nPandas implements some matplotlib converters for nicely formatting the axis\nlabels on plots with ``datetime`` or ``Period`` values. Prior to pandas 0.21.0,\nthese were implicitly registered with matplotlib, as a side effect of ``import\npandas``.\n\nIn pandas 0.21.0, we required users to explicitly register the\nconverter. This caused problems for some users who relied on those converters\nbeing present for regular ``matplotlib.pyplot`` plotting methods, so we&#39;re\ntemporarily reverting that change; pandas 0.21.1 again registers the converters on\nimport, just like before 0.21.0.\n\nWe&#39;ve added a new option to control the converters:\n``pd.options.plotting.matplotlib.register_converters``. By default, they are\nregistered. Toggling this to ``False`` removes pandas&#39; formatters and restore\nany converters we overwrote when registering them (:issue:`18301`).\n\nWe&#39;re working with the matplotlib developers to make this easier. We&#39;re trying\nto balance user convenience (automatically registering the converters) with\nimport performance and best practices (importing pandas shouldn&#39;t have the side\neffect of overwriting any custom converters you&#39;ve already set). In the future\nwe hope to have most of the datetime formatting functionality in matplotlib,\nwith just the pandas-specific converters in pandas. We&#39;ll then gracefully\ndeprecate the automatic registration of converters in favor of users explicitly\nregistering them when they want them.\n\n.. _whatsnew_0211.enhancements:\n\nNew features\n~~~~~~~~~~~~\n\n.. _whatsnew_0211.enhancements.parquet:\n\nImprovements to the Parquet IO functionality\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n- :func:`DataFrame.to_parquet` will now write non-default indexes when the\n  underlying engine supports it. The indexes will be preserved when reading\n  back in with :func:`read_parquet` (:issue:`18581`).\n- :func:`read_parquet` now allows to specify the columns to read from a parquet file (:issue:`18154`)\n- :func:`read_parquet` now allows to specify kwargs which are passed to the respective engine (:issue:`18216`)\n\n.. _whatsnew_0211.enhancements.other:\n\nOther Enhancements\n^^^^^^^^^^^^^^^^^^\n\n- :meth:`Timestamp.timestamp` is now available in Python 2.7. (:issue:`17329`)\n- :class:`Grouper` and :class:`TimeGrouper` now have a friendly repr output (:issue:`18203`).\n\n.. _whatsnew_0211.deprecations:\n\nDeprecations\n~~~~~~~~~~~~\n\n- ``pandas.tseries.register`` has been renamed to\n  :func:`pandas.plotting.register_matplotlib_converters`` (:issue:`18301`)\n\n.. _whatsnew_0211.performance:\n\nPerformance Improvements\n~~~~~~~~~~~~~~~~~~~~~~~~\n\n- Improved performance of plotting large series/dataframes (:issue:`18236`).\n\n.. _whatsnew_0211.bug_fixes:\n\nBug Fixes\n~~~~~~~~~\n\nConversion\n^^^^^^^^^^\n\n- Bug in :class:`TimedeltaIndex` subtraction could incorrectly overflow when ``NaT`` is present (:issue:`17791`)\n- Bug in :class:`DatetimeIndex` subtracting datetimelike from DatetimeIndex could fail to overflow (:issue:`18020`)\n- Bug in :meth:`IntervalIndex.copy` when copying and ``IntervalIndex`` with non-default ``closed`` (:issue:`18339`)\n- Bug in :func:`DataFrame.to_dict` where columns of datetime that are tz-aware were not converted to required arrays when used with ``orient=&#39;records&#39;``, raising``TypeError` (:issue:`18372`)\n- Bug in :class:`DateTimeIndex` and :meth:`date_range` where mismatching tz-aware ``start`` and ``end`` timezones would not raise an err if ``end.tzinfo`` is None (:issue:`18431`)\n- Bug in :meth:`Series.fillna` which raised when passed a long integer on Python 2 (:issue:`18159`).\n\nIndexing\n^^^^^^^^\n\n- Bug in a boolean comparison of a ``datetime.datetime`` and a ``datetime64[ns]`` dtype Series (:issue:`17965`)\n- Bug where a ``MultiIndex`` with more than a million records was not raising ``AttributeError`` when trying to access a missing attribute (:issue:`18165`)\n- Bug in :class:`IntervalIndex` constructor when a list of intervals is passed with non-default ``closed`` (:issue:`18334`)\n- Bug in ``Index.putmask`` when an invalid mask passed (:issue:`18368`)\n- Bug in masked assignment of a ``timedelta64[ns]`` dtype ``Series``, incorrectly coerced to float (:issue:`18493`)\n\nI/O\n^^^\n\n- Bug in class:`~pandas.io.stata.StataReader` not converting date/time columns with display formatting addressed (:issue:`17990`). Previously columns with display formatting were normally left as ordinal numbers and not converted to datetime objects.\n- Bug in :func:`read_csv` when reading a compressed UTF-16 encoded file (:issue:`18071`)\n- Bug in :func:`read_csv` for handling null values in index columns when specifying ``na_filter=False`` (:issue:`5239`)\n- Bug in :func:`read_csv` when reading numeric category fields with high cardinality (:issue:`18186`)\n- Bug in :meth:`DataFrame.to_csv` when the table had ``MultiIndex`` columns, and a list of strings was passed in for ``header`` (:issue:`5539`)\n- Bug in parsing integer datetime-like columns with specified format in ``read_sql`` (:issue:`17855`).\n- Bug in :meth:`DataFrame.to_msgpack` when serializing data of the ``numpy.bool_`` datatype (:issue:`18390`)\n- Bug in :func:`read_json` not decoding when reading line deliminted JSON from S3 (:issue:`17200`)\n- Bug in :func:`pandas.io.json.json_normalize` to avoid modification of ``meta`` (:issue:`18610`)\n- Bug in :func:`to_latex` where repeated multi-index values were not printed even though a higher level index differed from the previous row (:issue:`14484`)\n- Bug when reading NaN-only categorical columns in :class:`HDFStore` (:issue:`18413`)\n- Bug in :meth:`DataFrame.to_latex` with ``longtable=True`` where a latex multicolumn always spanned over three columns (:issue:`17959`)\n\nPlotting\n^^^^^^^^\n\n- Bug in ``DataFrame.plot()`` and ``Series.plot()`` with :class:`DatetimeIndex` where a figure generated by them is not pickleable in Python 3 (:issue:`18439`)\n\nGroupby/Resample/Rolling\n^^^^^^^^^^^^^^^^^^^^^^^^\n\n- Bug in ``DataFrame.resample(...).apply(...)`` when there is a callable that returns different columns (:issue:`15169`)\n- Bug in ``DataFrame.resample(...)`` when there is a time change (DST) and resampling frequecy is 12h or higher (:issue:`15549`)\n- Bug in ``pd.DataFrameGroupBy.count()`` when counting over a datetimelike column (:issue:`13393`)\n- Bug in ``rolling.var`` where calculation is inaccurate with a zero-valued array (:issue:`18430`)\n\nReshaping\n^^^^^^^^^\n\n- Error message in ``pd.merge_asof()`` for key datatype mismatch now includes datatype of left and right key (:issue:`18068`)\n- Bug in ``pd.concat`` when empty and non-empty DataFrames or Series are concatenated (:issue:`18178` :issue:`18187`)\n- Bug in ``DataFrame.filter(...)`` when :class:`unicode` is passed as a condition in Python 2 (:issue:`13101`)\n- Bug when merging empty DataFrames when ``np.seterr(divide=&#39;raise&#39;)`` is set (:issue:`17776`)\n\nNumeric\n^^^^^^^\n\n- Bug in ``pd.Series.rolling.skew()`` and ``rolling.kurt()`` with all equal values has floating issue (:issue:`18044`)\n\nCategorical\n^^^^^^^^^^^\n\n- Bug in :meth:`DataFrame.astype` where casting to &#39;category&#39; on an empty ``DataFrame`` causes a segmentation fault (:issue:`18004`)\n- Error messages in the testing module have been improved when items have different ``CategoricalDtype`` (:issue:`18069`)\n- ``CategoricalIndex`` can now correctly take a ``pd.api.types.CategoricalDtype`` as its dtype (:issue:`18116`)\n- Bug in ``Categorical.unique()`` returning read-only ``codes``  array when all categories were ``NaN`` (:issue:`18051`)\n- Bug in ``DataFrame.groupby(axis=1)`` with a ``CategoricalIndex`` (:issue:`18432`)\n\nString\n^^^^^^\n\n- :meth:`Series.str.split()` will now propagate ``NaN`` values across all expanded columns instead of ``None`` (:issue:`18450`)\n\n\n.. _whatsnew_060:\n   ```\n   \n  \n  \n   ### 0.21.0\n   ```\n   --------------------------\n\nThis is a major release from 0.20.3 and includes a number of API changes, deprecations, new features,\nenhancements, and performance improvements along with a large number of bug fixes. We recommend that all\nusers upgrade to this version.\n\nHighlights include:\n\n- Integration with `Apache Parquet &lt;https://parquet.apache.org/&gt;`__, including a new top-level :func:`read_parquet` function and :meth:`DataFrame.to_parquet` method, see :ref:`here &lt;whatsnew_0210.enhancements.parquet&gt;`.\n- New user-facing :class:`pandas.api.types.CategoricalDtype` for specifying\n  categoricals independent of the data, see :ref:`here &lt;whatsnew_0210.enhancements.categorical_dtype&gt;`.\n- The behavior of ``sum`` and ``prod`` on all-NaN Series/DataFrames is now consistent and no longer depends on whether `bottleneck &lt;http://berkeleyanalytics.com/bottleneck&gt;`__ is installed, and ``sum`` and ``prod`` on empty Series now return NaN instead of 0, see :ref:`here &lt;whatsnew_0210.api_breaking.bottleneck&gt;`.\n- Compatibility fixes for pypy, see :ref:`here &lt;whatsnew_0210.pypy&gt;`.\n- Additions to the ``drop``, ``reindex`` and ``rename`` API to make them more consistent, see :ref:`here &lt;whatsnew_0210.enhancements.drop_api&gt;`.\n- Addition of the new methods ``DataFrame.infer_objects`` (see :ref:`here &lt;whatsnew_0210.enhancements.infer_objects&gt;`) and ``GroupBy.pipe`` (see :ref:`here &lt;whatsnew_0210.enhancements.GroupBy_pipe&gt;`).\n- Indexing with a list of labels, where one or more of the labels is missing, is deprecated and will raise a KeyError in a future version, see :ref:`here &lt;whatsnew_0210.api_breaking.loc&gt;`.\n\nCheck the :ref:`API Changes &lt;whatsnew_0210.api_breaking&gt;` and :ref:`deprecations &lt;whatsnew_0210.deprecations&gt;` before updating.\n\n.. contents:: What&#39;s new in v0.21.0\n    :local:\n    :backlinks: none\n    :depth: 2\n\n.. _whatsnew_0210.enhancements:\n\nNew features\n~~~~~~~~~~~~\n\n.. _whatsnew_0210.enhancements.parquet:\n\nIntegration with Apache Parquet file format\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIntegration with `Apache Parquet &lt;https://parquet.apache.org/&gt;`__, including a new top-level :func:`read_parquet` and :func:`DataFrame.to_parquet` method, see :ref:`here &lt;io.parquet&gt;` (:issue:`15838`, :issue:`17438`).\n\n`Apache Parquet &lt;https://parquet.apache.org/&gt;`__ provides a cross-language, binary file format for reading and writing data frames efficiently.\nParquet is designed to faithfully serialize and de-serialize ``DataFrame`` s, supporting all of the pandas\ndtypes, including extension dtypes such as datetime with timezones.\n\nThis functionality depends on either the `pyarrow &lt;http://arrow.apache.org/docs/python/&gt;`__ or `fastparquet &lt;https://fastparquet.readthedocs.io/en/latest/&gt;`__ library.\nFor more details, see see :ref:`the IO docs on Parquet &lt;io.parquet&gt;`.\n\n\n.. _whatsnew_0210.enhancements.infer_objects:\n\n``infer_objects`` type conversion\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe :meth:`DataFrame.infer_objects` and :meth:`Series.infer_objects`\nmethods have been added to perform dtype inference on object columns, replacing\nsome of the functionality of the deprecated ``convert_objects``\nmethod. See the documentation :ref:`here &lt;basics.object_conversion&gt;`\nfor more details. (:issue:`11221`)\n\nThis method only performs soft conversions on object columns, converting Python objects\nto native types, but not any coercive conversions. For example:\n\n.. ipython:: python\n\n   df = pd.DataFrame({&#39;A&#39;: [1, 2, 3],\n                      &#39;B&#39;: np.array([1, 2, 3], dtype=&#39;object&#39;),\n                      &#39;C&#39;: [&#39;1&#39;, &#39;2&#39;, &#39;3&#39;]})\n   df.dtypes\n   df.infer_objects().dtypes\n\nNote that column ``&#39;C&#39;`` was not converted - only scalar numeric types\nwill be converted to a new type.  Other types of conversion should be accomplished\nusing the :func:`to_numeric` function (or :func:`to_datetime`, :func:`to_timedelta`).\n\n.. ipython:: python\n\n   df = df.infer_objects()\n   df[&#39;C&#39;] = pd.to_numeric(df[&#39;C&#39;], errors=&#39;coerce&#39;)\n   df.dtypes\n\n.. _whatsnew_0210.enhancements.attribute_access:\n\nImproved warnings when attempting to create columns\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nNew users are often puzzled by the relationship between column operations and\nattribute access on ``DataFrame`` instances (:issue:`7175`). One specific\ninstance of this confusion is attempting to create a new column by setting an\nattribute on the ``DataFrame``:\n\n.. code-block:: ipython\n\n   In[1]: df = pd.DataFrame({&#39;one&#39;: [1., 2., 3.]})\n   In[2]: df.two = [4, 5, 6]\n\nThis does not raise any obvious exceptions, but also does not create a new column:\n\n.. code-block:: ipython\n\n   In[3]: df\n   Out[3]:\n       one\n   0  1.0\n   1  2.0\n   2  3.0\n\nSetting a list-like data structure into a new attribute now raises a ``UserWarning`` about the potential for unexpected behavior. See :ref:`Attribute Access &lt;indexing.attribute_access&gt;`.\n\n.. _whatsnew_0210.enhancements.drop_api:\n\n``drop`` now also accepts index/columns keywords\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe :meth:`~DataFrame.drop` method has gained ``index``/``columns`` keywords as an\nalternative to specifying the ``axis``. This is similar to the behavior of ``reindex``\n(:issue:`12392`).\n\nFor example:\n\n.. ipython:: python\n\n    df = pd.DataFrame(np.arange(8).reshape(2,4),\n                      columns=[&#39;A&#39;, &#39;B&#39;, &#39;C&#39;, &#39;D&#39;])\n    df\n    df.drop([&#39;B&#39;, &#39;C&#39;], axis=1)\n     the following is now equivalent\n    df.drop(columns=[&#39;B&#39;, &#39;C&#39;])\n\n.. _whatsnew_0210.enhancements.rename_reindex_axis:\n\n``rename``, ``reindex`` now also accept axis keyword\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe :meth:`DataFrame.rename` and :meth:`DataFrame.reindex` methods have gained\nthe ``axis`` keyword to specify the axis to target with the operation\n(:issue:`12392`).\n\nHere&#39;s ``rename``:\n\n.. ipython:: python\n\n   df = pd.DataFrame({&quot;A&quot;: [1, 2, 3], &quot;B&quot;: [4, 5, 6]})\n   df.rename(str.lower, axis=&#39;columns&#39;)\n   df.rename(id, axis=&#39;index&#39;)\n\nAnd ``reindex``:\n\n.. ipython:: python\n\n   df.reindex([&#39;A&#39;, &#39;B&#39;, &#39;C&#39;], axis=&#39;columns&#39;)\n   df.reindex([0, 1, 3], axis=&#39;index&#39;)\n\nThe &quot;index, columns&quot; style continues to work as before.\n\n.. ipython:: python\n\n   df.rename(index=id, columns=str.lower)\n   df.reindex(index=[0, 1, 3], columns=[&#39;A&#39;, &#39;B&#39;, &#39;C&#39;])\n\nWe *highly* encourage using named arguments to avoid confusion when using either\nstyle.\n\n.. _whatsnew_0210.enhancements.categorical_dtype:\n\n``CategoricalDtype`` for specifying categoricals\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n:class:`pandas.api.types.CategoricalDtype` has been added to the public API and\nexpanded to include the ``categories`` and ``ordered`` attributes. A\n``CategoricalDtype`` can be used to specify the set of categories and\norderedness of an array, independent of the data. This can be useful for example,\nwhen converting string data to a ``Categorical`` (:issue:`14711`,\n:issue:`15078`, :issue:`16015`, :issue:`17643`):\n\n.. ipython:: python\n\n   from pandas.api.types import CategoricalDtype\n\n   s = pd.Series([&#39;a&#39;, &#39;b&#39;, &#39;c&#39;, &#39;a&#39;])   strings\n   dtype = CategoricalDtype(categories=[&#39;a&#39;, &#39;b&#39;, &#39;c&#39;, &#39;d&#39;], ordered=True)\n   s.astype(dtype)\n\nOne place that deserves special mention is in :meth:`read_csv`. Previously, with\n``dtype={&#39;col&#39;: &#39;category&#39;}``, the returned values and categories would always\nbe strings.\n\n.. ipython:: python\n   :suppress:\n\n   from pandas.compat import StringIO\n\n.. ipython:: python\n\n   data = &#39;A,B\\na,1\\nb,2\\nc,3&#39;\n   pd.read_csv(StringIO(data), dtype={&#39;B&#39;: &#39;category&#39;}).B.cat.categories\n\nNotice the &quot;object&quot; dtype.\n\nWith a ``CategoricalDtype`` of all numerics, datetimes, or\ntimedeltas, we can automatically convert to the correct type\n\n.. ipython:: python\n\n   dtype = {&#39;B&#39;: CategoricalDtype([1, 2, 3])}\n   pd.read_csv(StringIO(data), dtype=dtype).B.cat.categories\n\nThe values have been correctly interpreted as integers.\n\nThe ``.dtype`` property of a ``Categorical``, ``CategoricalIndex`` or a\n``Series`` with categorical type will now return an instance of\n``CategoricalDtype``. While the repr has changed, ``str(CategoricalDtype())`` is\nstill the string ``&#39;category&#39;``. We&#39;ll take this moment to remind users that the\n*preferred* way to detect categorical data is to use\n:func:`pandas.api.types.is_categorical_dtype`, and not ``str(dtype) == &#39;category&#39;``.\n\nSee the :ref:`CategoricalDtype docs &lt;categorical.categoricaldtype&gt;` for more.\n\n.. _whatsnew_0210.enhancements.GroupBy_pipe:\n\n``GroupBy`` objects now have a ``pipe`` method\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n``GroupBy`` objects now have a ``pipe`` method, similar to the one on\n``DataFrame`` and ``Series``, that allow for functions that take a\n``GroupBy`` to be composed in a clean, readable syntax. (:issue:`17871`)\n\nFor a concrete example on combining ``.groupby`` and ``.pipe`` , imagine having a\nDataFrame with columns for stores, products, revenue and sold quantity. We&#39;d like to\ndo a groupwise calculation of *prices* (i.e. revenue/quantity) per store and per product.\nWe could do this in a multi-step operation, but expressing it in terms of piping can make the\ncode more readable.\n\nFirst we set the data:\n\n.. ipython:: python\n\n   import numpy as np\n   n = 1000\n   df = pd.DataFrame({&#39;Store&#39;: np.random.choice([&#39;Store_1&#39;, &#39;Store_2&#39;], n),\n                      &#39;Product&#39;: np.random.choice([&#39;Product_1&#39;, &#39;Product_2&#39;, &#39;Product_3&#39;], n),\n                      &#39;Revenue&#39;: (np.random.random(n)*50+10).round(2),\n                      &#39;Quantity&#39;: np.random.randint(1, 10, size=n)})\n   df.head(2)\n\nNow, to find prices per store/product, we can simply do:\n\n.. ipython:: python\n\n   (df.groupby([&#39;Store&#39;, &#39;Product&#39;])\n      .pipe(lambda grp: grp.Revenue.sum()/grp.Quantity.sum())\n      .unstack().round(2))\n\nSee the :ref:`documentation &lt;groupby.pipe&gt;` for more.\n\n\n.. _whatsnew_0210.enhancements.reanme_categories:\n\n``Categorical.rename_categories`` accepts a dict-like\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n:meth:`~Series.cat.rename_categories` now accepts a dict-like argument for\n``new_categories``. The previous categories are looked up in the dictionary&#39;s\nkeys and replaced if found. The behavior of missing and extra keys is the same\nas in :meth:`DataFrame.rename`.\n\n.. ipython:: python\n\n   c = pd.Categorical([&#39;a&#39;, &#39;a&#39;, &#39;b&#39;])\n   c.rename_categories({&quot;a&quot;: &quot;eh&quot;, &quot;b&quot;: &quot;bee&quot;})\n\n.. warning::\n\n    To assist with upgrading pandas, ``rename_categories`` treats ``Series`` as\n    list-like. Typically, Series are considered to be dict-like (e.g. in\n    ``.rename``, ``.map``). In a future version of pandas ``rename_categories``\n    will change to treat them as dict-like. Follow the warning message&#39;s\n    recommendations for writing future-proof code.\n\n    .. code-block:: ipython\n\n        In [33]: c.rename_categories(pd.Series([0, 1], index=[&#39;a&#39;, &#39;c&#39;]))\n        FutureWarning: Treating Series &#39;new_categories&#39; as a list-like and using the values.\n        In a future version, &#39;rename_categories&#39; will treat Series like a dictionary.\n        For dict-like, use &#39;new_categories.to_dict()&#39;\n        For list-like, use &#39;new_categories.values&#39;.\n        Out[33]:\n        [0, 0, 1]\n        Categories (2, int64): [0, 1]\n\n\n.. _whatsnew_0210.enhancements.other:\n\nOther Enhancements\n^^^^^^^^^^^^^^^^^^\n\nNew functions or methods\n&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;\n\n- :meth:`~pandas.core.resample.Resampler.nearest` is added to support nearest-neighbor upsampling (:issue:`17496`).\n- :class:`~pandas.Index` has added support for a ``to_frame`` method (:issue:`15230`).\n\nNew keywords\n&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;\n\n- Added a ``skipna`` parameter to :func:`~pandas.api.types.infer_dtype` to\n  support type inference in the presence of missing values (:issue:`17059`).\n- :func:`Series.to_dict` and :func:`DataFrame.to_dict` now support an ``into`` keyword which allows you to specify the ``collections.Mapping`` subclass that you would like returned.  The default is ``dict``, which is backwards compatible. (:issue:`16122`)\n- :func:`Series.set_axis` and :func:`DataFrame.set_axis` now support the ``inplace`` parameter. (:issue:`14636`)\n- :func:`Series.to_pickle` and :func:`DataFrame.to_pickle` have gained a ``protocol`` parameter (:issue:`16252`). By default, this parameter is set to `HIGHEST_PROTOCOL &lt;https://docs.python.org/3/library/pickle.htmldata-stream-format&gt;`__\n- :func:`read_feather` has gained the ``nthreads`` parameter for multi-threaded operations (:issue:`16359`)\n- :func:`DataFrame.clip()` and :func:`Series.clip()` have gained an ``inplace`` argument. (:issue:`15388`)\n- :func:`crosstab` has gained a ``margins_name`` parameter to define the name of the row / column that will contain the totals when ``margins=True``. (:issue:`15972`)\n- :func:`read_json` now accepts a ``chunksize`` parameter that can be used when ``lines=True``. If ``chunksize`` is passed, read_json now returns an iterator which reads in ``chunksize`` lines with each iteration. (:issue:`17048`)\n- :func:`read_json` and :func:`~DataFrame.to_json` now accept a ``compression`` argument which allows them to transparently handle compressed files. (:issue:`17798`)\n\nVarious enhancements\n&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;&quot;\n\n- Improved the import time of pandas by about 2.25x.  (:issue:`16764`)\n- Support for `PEP 519 -- Adding a file system path protocol\n  &lt;https://www.python.org/dev/peps/pep-0519/&gt;`_ on most readers (e.g.\n  :func:`read_csv`) and writers (e.g. :meth:`DataFrame.to_csv`) (:issue:`13823`).\n- Added a ``__fspath__`` method to ``pd.HDFStore``, ``pd.ExcelFile``,\n  and ``pd.ExcelWriter`` to work properly with the file system path protocol (:issue:`13823`).\n- The ``validate`` argument for :func:`merge` now checks whether a merge is one-to-one, one-to-many, many-to-one, or many-to-many. If a merge is found to not be an example of specified merge type, an exception of type ``MergeError`` will be raised. For more, see :ref:`here &lt;merging.validation&gt;` (:issue:`16270`)\n- Added support for `PEP 518 &lt;https://www.python.org/dev/peps/pep-0518/&gt;`_ (``pyproject.toml``) to the build system (:issue:`16745`)\n- :func:`RangeIndex.append` now returns a ``RangeIndex`` object when possible (:issue:`16212`)\n- :func:`Series.rename_axis` and :func:`DataFrame.rename_axis` with ``inplace=True`` now return ``None`` while renaming the axis inplace. (:issue:`15704`)\n- :func:`api.types.infer_dtype` now infers decimals. (:issue:`15690`)\n- :func:`DataFrame.select_dtypes` now accepts scalar values for include/exclude as well as list-like. (:issue:`16855`)\n- :func:`date_range` now accepts &#39;YS&#39; in addition to &#39;AS&#39; as an alias for start of year. (:issue:`9313`)\n- :func:`date_range` now accepts &#39;Y&#39; in addition to &#39;A&#39; as an alias for end of year. (:issue:`9313`)\n- :func:`DataFrame.add_prefix` and :func:`DataFrame.add_suffix` now accept strings containing the &#39;%&#39; character. (:issue:`17151`)\n- Read/write methods that infer compression (:func:`read_csv`, :func:`read_table`, :func:`read_pickle`, and :meth:`~DataFrame.to_pickle`) can now infer from path-like objects, such as ``pathlib.Path``. (:issue:`17206`)\n- :func:`read_sas` now recognizes much more of the most frequently used date (datetime) formats in SAS7BDAT files. (:issue:`15871`)\n- :func:`DataFrame.items` and :func:`Series.items` are now present in both Python 2 and 3 and is lazy in all cases. (:issue:`13918`, :issue:`17213`)\n- :meth:`pandas.io.formats.style.Styler.where` has been implemented as a convenience for :meth:`pandas.io.formats.style.Styler.applymap`. (:issue:`17474`)\n- :func:`MultiIndex.is_monotonic_decreasing` has been implemented.  Previously returned ``False`` in all cases. (:issue:`16554`)\n- :func:`read_excel` raises ``ImportError`` with a better message if ``xlrd`` is not installed. (:issue:`17613`)\n- :meth:`DataFrame.assign` will preserve the original order of ``**kwargs`` for Python 3.6+ users instead of sorting the column names. (:issue:`14207`)\n- :func:`Series.reindex`, :func:`DataFrame.reindex`, :func:`Index.get_indexer` now support list-like argument for ``tolerance``. (:issue:`17367`)\n\n.. _whatsnew_0210.api_breaking:\n\nBackwards incompatible API changes\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n.. _whatsnew_0210.api_breaking.deps:\n\nDependencies have increased minimum versions\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nWe have updated our minimum supported versions of dependencies (:issue:`15206`, :issue:`15543`, :issue:`15214`).\nIf installed, we now require:\n\n   +--------------+-----------------+----------+\n   | Package      | Minimum Version | Required |\n   +==============+=================+==========+\n   | Numpy        | 1.9.0           |    X     |\n   +--------------+-----------------+----------+\n   | Matplotlib   | 1.4.3           |          |\n   +--------------+-----------------+----------+\n   | Scipy        | 0.14.0          |          |\n   +--------------+-----------------+----------+\n   | Bottleneck   | 1.0.0           |          |\n   +--------------+-----------------+----------+\n\nAdditionally, support has been dropped for Python 3.4 (:issue:`15251`).\n\n\n.. _whatsnew_0210.api_breaking.bottleneck:\n\nSum/Prod of all-NaN or empty Series/DataFrames is now consistently NaN\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n.. note::\n\n   The changes described here have been partially reverted. See\n   the :ref:`v0.22.0 Whatsnew &lt;whatsnew_0220&gt;` for more.\n\n\nThe behavior of ``sum`` and ``prod`` on all-NaN Series/DataFrames no longer depends on\nwhether `bottleneck &lt;http://berkeleyanalytics.com/bottleneck&gt;`__ is installed, and return value of ``sum`` and ``prod`` on an empty Series has changed (:issue:`9422`, :issue:`15507`).\n\nCalling ``sum`` or ``prod`` on an empty or all-``NaN`` ``Series``, or columns of a ``DataFrame``, will result in ``NaN``. See the :ref:`docs &lt;missing_data.numeric_sum&gt;`.\n\n.. ipython:: python\n\n   s = Series([np.nan])\n\nPreviously WITHOUT ``bottleneck`` installed:\n\n.. code-block:: ipython\n\n   In [2]: s.sum()\n   Out[2]: np.nan\n\nPreviously WITH ``bottleneck``:\n\n.. code-block:: ipython\n\n   In [2]: s.sum()\n   Out[2]: 0.0\n\nNew Behavior, without regard to the bottleneck installation:\n\n.. ipython:: python\n\n   s.sum()\n\nNote that this also changes the sum of an empty ``Series``. Previously this always returned 0 regardless of a ``bottlenck`` installation:\n\n.. code-block:: ipython\n\n   In [1]: pd.Series([]).sum()\n   Out[1]: 0\n\nbut for consistency with the all-NaN case, this was changed to return NaN as well:\n\n.. ipython:: python\n\n   pd.Series([]).sum()\n\n\n.. _whatsnew_0210.api_breaking.loc:\n\nIndexing with a list with missing labels is Deprecated\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nPreviously, selecting with a list of labels, where one or more labels were missing would always succeed, returning ``NaN`` for missing labels.\nThis will now show a ``FutureWarning``. In the future this will raise a ``KeyError`` (:issue:`15747`).\nThis warning will trigger on a ``DataFrame`` or a ``Series`` for using ``.loc[]``  or ``[[]]`` when passing a list-of-labels with at least 1 missing label.\nSee the :ref:`deprecation docs &lt;indexing.deprecate_loc_reindex_listlike&gt;`.\n\n\n.. ipython:: python\n\n   s = pd.Series([1, 2, 3])\n   s\n\nPrevious Behavior\n\n.. code-block:: ipython\n\n   In [4]: s.loc[[1, 2, 3]]\n   Out[4]:\n   1    2.0\n   2    3.0\n   3    NaN\n   dtype: float64\n\n\nCurrent Behavior\n\n.. code-block:: ipython\n\n   In [4]: s.loc[[1, 2, 3]]\n   Passing list-likes to .loc or [] with any missing label will raise\n   KeyError in the future, you can use .reindex() as an alternative.\n\n   See the documentation here:\n   http://pandas.pydata.org/pandas-docs/stable/indexing.htmldeprecate-loc-reindex-listlike\n\n   Out[4]:\n   1    2.0\n   2    3.0\n   3    NaN\n   dtype: float64\n\nThe idiomatic way to achieve selecting potentially not-found elements is via ``.reindex()``\n\n.. ipython:: python\n\n  s.reindex([1, 2, 3])\n\nSelection with all keys found is unchanged.\n\n.. ipython:: python\n\n   s.loc[[1, 2]]\n\n\n.. _whatsnew_0210.api.na_changes:\n\nNA naming Changes\n^^^^^^^^^^^^^^^^^\n\nIn order to promote more consistency among the pandas API, we have added additional top-level\nfunctions :func:`isna` and :func:`notna` that are aliases for :func:`isnull` and :func:`notnull`.\nThe naming scheme is now more consistent with methods like ``.dropna()`` and ``.fillna()``. Furthermore\nin all cases where ``.isnull()`` and ``.notnull()`` methods are defined, these have additional methods\nnamed ``.isna()`` and ``.notna()``, these are included for classes ``Categorical``,\n``Index``, ``Series``, and ``DataFrame``. (:issue:`15001`).\n\nThe configuration option ``pd.options.mode.use_inf_as_null`` is deprecated, and ``pd.options.mode.use_inf_as_na`` is added as a replacement.\n\n\n.. _whatsnew_0210.api_breaking.iteration_scalars:\n\nIteration of Series/Index will now return Python scalars\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nPreviously, when using certain iteration methods for a ``Series`` with dtype ``int`` or ``float``, you would receive a ``numpy`` scalar, e.g. a ``np.int64``, rather than a Python ``int``. Issue (:issue:`10904`) corrected this for ``Series.tolist()`` and ``list(Series)``. This change makes all iteration methods consistent, in particular, for ``__iter__()`` and ``.map()``; note that this only affects int/float dtypes. (:issue:`13236`, :issue:`13258`, :issue:`14216`).\n\n.. ipython:: python\n\n   s = pd.Series([1, 2, 3])\n   s\n\nPreviously:\n\n.. code-block:: ipython\n\n   In [2]: type(list(s)[0])\n   Out[2]: numpy.int64\n\nNew Behaviour:\n\n.. ipython:: python\n\n   type(list(s)[0])\n\nFurthermore this will now correctly box the results of iteration for :func:`DataFrame.to_dict` as well.\n\n.. ipython:: python\n\n   d = {&#39;a&#39;:[1], &#39;b&#39;:[&#39;b&#39;]}\n   df = pd.DataFrame(d)\n\nPreviously:\n\n.. code-block:: ipython\n\n   In [8]: type(df.to_dict()[&#39;a&#39;][0])\n   Out[8]: numpy.int64\n\nNew Behaviour:\n\n.. ipython:: python\n\n   type(df.to_dict()[&#39;a&#39;][0])\n\n\n.. _whatsnew_0210.api_breaking.loc_with_index:\n\nIndexing with a Boolean Index\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nPreviously when passing a boolean ``Index`` to ``.loc``, if the index of the ``Series/DataFrame`` had ``boolean`` labels,\nyou would get a label based selection, potentially duplicating result labels, rather than a boolean indexing selection\n(where ``True`` selects elements), this was inconsistent how a boolean numpy array indexed. The new behavior is to\nact like a boolean numpy array indexer. (:issue:`17738`)\n\nPrevious Behavior:\n\n.. ipython:: python\n\n   s = pd.Series([1, 2, 3], index=[False, True, False])\n   s\n\n.. code-block:: ipython\n\n   In [59]: s.loc[pd.Index([True, False, True])]\n   Out[59]:\n   True     2\n   False    1\n   False    3\n   True     2\n   dtype: int64\n\nCurrent Behavior\n\n.. ipython:: python\n\n   s.loc[pd.Index([True, False, True])]\n\n\nFurthermore, previously if you had an index that was non-numeric (e.g. strings), then a boolean Index would raise a ``KeyError``.\nThis will now be treated as a boolean indexer.\n\nPreviously Behavior:\n\n.. ipython:: python\n\n    s = pd.Series([1,2,3], index=[&#39;a&#39;, &#39;b&#39;, &#39;c&#39;])\n    s\n\n.. code-block:: ipython\n\n    In [39]: s.loc[pd.Index([True, False, True])]\n    KeyError: &quot;None of [Index([True, False, True], dtype=&#39;object&#39;)] are in the [index]&quot;\n\nCurrent Behavior\n\n.. ipython:: python\n\n   s.loc[pd.Index([True, False, True])]\n\n\n.. _whatsnew_0210.api_breaking.period_index_resampling:\n\n``PeriodIndex`` resampling\n^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn previous versions of pandas, resampling a ``Series``/``DataFrame`` indexed by a ``PeriodIndex`` returned a ``DatetimeIndex`` in some cases (:issue:`12884`). Resampling to a multiplied frequency now returns a ``PeriodIndex`` (:issue:`15944`). As a minor enhancement, resampling a ``PeriodIndex`` can now handle ``NaT`` values (:issue:`13224`)\n\nPrevious Behavior:\n\n.. code-block:: ipython\n\n   In [1]: pi = pd.period_range(&#39;2017-01&#39;, periods=12, freq=&#39;M&#39;)\n\n   In [2]: s = pd.Series(np.arange(12), index=pi)\n\n   In [3]: resampled = s.resample(&#39;2Q&#39;).mean()\n\n   In [4]: resampled\n   Out[4]:\n   2017-03-31     1.0\n   2017-09-30     5.5\n   2018-03-31    10.0\n   Freq: 2Q-DEC, dtype: float64\n\n   In [5]: resampled.index\n   Out[5]: DatetimeIndex([&#39;2017-03-31&#39;, &#39;2017-09-30&#39;, &#39;2018-03-31&#39;], dtype=&#39;datetime64[ns]&#39;, freq=&#39;2Q-DEC&#39;)\n\nNew Behavior:\n\n.. ipython:: python\n\n   pi = pd.period_range(&#39;2017-01&#39;, periods=12, freq=&#39;M&#39;)\n\n   s = pd.Series(np.arange(12), index=pi)\n\n   resampled = s.resample(&#39;2Q&#39;).mean()\n\n   resampled\n\n   resampled.index\n\nUpsampling and calling ``.ohlc()`` previously returned a ``Series``, basically identical to calling ``.asfreq()``. OHLC upsampling now returns a DataFrame with columns ``open``, ``high``, ``low`` and ``close`` (:issue:`13083`). This is consistent with downsampling and ``DatetimeIndex`` behavior.\n\nPrevious Behavior:\n\n.. code-block:: ipython\n\n   In [1]: pi = pd.PeriodIndex(start=&#39;2000-01-01&#39;, freq=&#39;D&#39;, periods=10)\n\n   In [2]: s = pd.Series(np.arange(10), index=pi)\n\n   In [3]: s.resample(&#39;H&#39;).ohlc()\n   Out[3]:\n   2000-01-01 00:00    0.0\n                   ...\n   2000-01-10 23:00    NaN\n   Freq: H, Length: 240, dtype: float64\n\n   In [4]: s.resample(&#39;M&#39;).ohlc()\n   Out[4]:\n            open  high  low  close\n   2000-01     0     9    0      9\n\nNew Behavior:\n\n.. ipython:: python\n\n   pi = pd.PeriodIndex(start=&#39;2000-01-01&#39;, freq=&#39;D&#39;, periods=10)\n\n   s = pd.Series(np.arange(10), index=pi)\n\n   s.resample(&#39;H&#39;).ohlc()\n\n   s.resample(&#39;M&#39;).ohlc()\n\n\n.. _whatsnew_0210.api_breaking.pandas_eval:\n\nImproved error handling during item assignment in pd.eval\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n:func:`eval` will now raise a ``ValueError`` when item assignment malfunctions, or\ninplace operations are specified, but there is no item assignment in the expression (:issue:`16732`)\n\n.. ipython:: python\n\n   arr = np.array([1, 2, 3])\n\nPreviously, if you attempted the following expression, you would get a not very helpful error message:\n\n.. code-block:: ipython\n\n  In [3]: pd.eval(&quot;a = 1 + 2&quot;, target=arr, inplace=True)\n  ...\n  IndexError: only integers, slices (`:`), ellipsis (`...`), numpy.newaxis (`None`)\n  and integer or boolean arrays are valid indices\n\nThis is a very long way of saying numpy arrays don&#39;t support string-item indexing. With this\nchange, the error message is now this:\n\n.. code-block:: python\n\n   In [3]: pd.eval(&quot;a = 1 + 2&quot;, target=arr, inplace=True)\n   ...\n   ValueError: Cannot assign expression output to target\n\nIt also used to be possible to evaluate expressions inplace, even if there was no item assignment:\n\n.. code-block:: ipython\n\n  In [4]: pd.eval(&quot;1 + 2&quot;, target=arr, inplace=True)\n  Out[4]: 3\n\nHowever, this input does not make much sense because the output is not being assigned to\nthe target. Now, a ``ValueError`` will be raised when such an input is passed in:\n\n.. code-block:: ipython\n\n   In [4]: pd.eval(&quot;1 + 2&quot;, target=arr, inplace=True)\n   ...\n   ValueError: Cannot operate inplace if there is no assignment\n\n\n.. _whatsnew_0210.api_breaking.dtype_conversions:\n\nDtype Conversions\n^^^^^^^^^^^^^^^^^\n\nPreviously assignments, ``.where()`` and ``.fillna()`` with a ``bool`` assignment, would coerce to same the type (e.g. int / float), or raise for datetimelikes. These will now preserve the bools with ``object`` dtypes. (:issue:`16821`).\n\n.. ipython:: python\n\n   s = Series([1, 2, 3])\n\n.. code-block:: python\n\n   In [5]: s[1] = True\n\n   In [6]: s\n   Out[6]:\n   0    1\n   1    1\n   2    3\n   dtype: int64\n\nNew Behavior\n\n.. ipython:: python\n\n   s[1] = True\n   s\n\nPreviously, as assignment to a datetimelike with a non-datetimelike would coerce the\nnon-datetime-like item being assigned (:issue:`14145`).\n\n.. ipython:: python\n\n   s = pd.Series([pd.Timestamp(&#39;2011-01-01&#39;), pd.Timestamp(&#39;2012-01-01&#39;)])\n\n.. code-block:: python\n\n   In [1]: s[1] = 1\n\n   In [2]: s\n   Out[2]:\n   0   2011-01-01 00:00:00.000000000\n   1   1970-01-01 00:00:00.000000001\n   dtype: datetime64[ns]\n\nThese now coerce to ``object`` dtype.\n\n.. ipython:: python\n\n   s[1] = 1\n   s\n\n- Inconsistent behavior in ``.where()`` with datetimelikes which would raise rather than coerce to ``object`` (:issue:`16402`)\n- Bug in assignment against ``int64`` data with ``np.ndarray`` with ``float64`` dtype may keep ``int64`` dtype (:issue:`14001`)\n\n\n.. _whatsnew_210.api.multiindex_single:\n\nMultiIndex Constructor with a Single Level\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe ``MultiIndex`` constructors no longer squeezes a MultiIndex with all\nlength-one levels down to a regular ``Index``. This affects all the\n``MultiIndex`` constructors. (:issue:`17178`)\n\nPrevious behavior:\n\n.. code-block:: ipython\n\n   In [2]: pd.MultiIndex.from_tuples([(&#39;a&#39;,), (&#39;b&#39;,)])\n   Out[2]: Index([&#39;a&#39;, &#39;b&#39;], dtype=&#39;object&#39;)\n\nLength 1 levels are no longer special-cased. They behave exactly as if you had\nlength 2+ levels, so a :class:`MultiIndex` is always returned from all of the\n``MultiIndex`` constructors:\n\n.. ipython:: python\n\n   pd.MultiIndex.from_tuples([(&#39;a&#39;,), (&#39;b&#39;,)])\n\n.. _whatsnew_0210.api.utc_localization_with_series:\n\nUTC Localization with Series\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nPreviously, :func:`to_datetime` did not localize datetime ``Series`` data when ``utc=True`` was passed. Now, :func:`to_datetime` will correctly localize ``Series`` with a ``datetime64[ns, UTC]`` dtype to be consistent with how list-like and ``Index`` data are handled. (:issue:`6415`).\n\nPrevious Behavior\n\n.. ipython:: python\n\n   s = Series([&#39;20130101 00:00:00&#39;] * 3)\n\n.. code-block:: ipython\n\n   In [12]: pd.to_datetime(s, utc=True)\n   Out[12]:\n   0   2013-01-01\n   1   2013-01-01\n   2   2013-01-01\n   dtype: datetime64[ns]\n\nNew Behavior\n\n.. ipython:: python\n\n   pd.to_datetime(s, utc=True)\n\nAdditionally, DataFrames with datetime columns that were parsed by :func:`read_sql_table` and :func:`read_sql_query` will also be localized to UTC only if the original SQL columns were timezone aware datetime columns.\n\n.. _whatsnew_0210.api.consistency_of_range_functions:\n\nConsistency of Range Functions\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIn previous versions, there were some inconsistencies between the various range functions: :func:`date_range`, :func:`bdate_range`, :func:`period_range`, :func:`timedelta_range`, and :func:`interval_range`. (:issue:`17471`).\n\nOne of the inconsistent behaviors occurred when the ``start``, ``end`` and ``period`` parameters were all specified, potentially leading to ambiguous ranges.  When all three parameters were passed, ``interval_range`` ignored the ``period`` parameter, ``period_range`` ignored the ``end`` parameter, and the other range functions raised.  To promote consistency among the range functions, and avoid potentially ambiguous ranges, ``interval_range`` and ``period_range`` will now raise when all three parameters are passed.\n\nPrevious Behavior:\n\n.. code-block:: ipython\n\n  In [2]: pd.interval_range(start=0, end=4, periods=6)\n  Out[2]:\n  IntervalIndex([(0, 1], (1, 2], (2, 3]]\n                closed=&#39;right&#39;,\n                dtype=&#39;interval[int64]&#39;)\n\n  In [3]: pd.period_range(start=&#39;2017Q1&#39;, end=&#39;2017Q4&#39;, periods=6, freq=&#39;Q&#39;)\n  Out[3]: PeriodIndex([&#39;2017Q1&#39;, &#39;2017Q2&#39;, &#39;2017Q3&#39;, &#39;2017Q4&#39;, &#39;2018Q1&#39;, &#39;2018Q2&#39;], dtype=&#39;period[Q-DEC]&#39;, freq=&#39;Q-DEC&#39;)\n\nNew Behavior:\n\n.. code-block:: ipython\n\n  In [2]: pd.interval_range(start=0, end=4, periods=6)\n  ---------------------------------------------------------------------------\n  ValueError: Of the three parameters: start, end, and periods, exactly two must be specified\n\n  In [3]: pd.period_range(start=&#39;2017Q1&#39;, end=&#39;2017Q4&#39;, periods=6, freq=&#39;Q&#39;)\n  ---------------------------------------------------------------------------\n  ValueError: Of the three parameters: start, end, and periods, exactly two must be specified\n\nAdditionally, the endpoint parameter ``end`` was not included in the intervals produced by ``interval_range``.  However, all other range functions include ``end`` in their output.  To promote consistency among the range functions, ``interval_range`` will now include ``end`` as the right endpoint of the final interval, except if ``freq`` is specified in a way which skips ``end``.\n\nPrevious Behavior:\n\n.. code-block:: ipython\n\n  In [4]: pd.interval_range(start=0, end=4)\n  Out[4]:\n  IntervalIndex([(0, 1], (1, 2], (2, 3]]\n                closed=&#39;right&#39;,\n                dtype=&#39;interval[int64]&#39;)\n\n\nNew Behavior:\n\n.. ipython:: python\n\n   pd.interval_range(start=0, end=4)\n\n.. _whatsnew_0210.api.mpl_converters:\n\nNo Automatic Matplotlib Converters\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nPandas no longer registers our ``date``, ``time``, ``datetime``,\n``datetime64``, and ``Period`` converters with matplotlib when pandas is\nimported. Matplotlib plot methods (``plt.plot``, ``ax.plot``, ...), will not\nnicely format the x-axis for ``DatetimeIndex`` or ``PeriodIndex`` values. You\nmust explicitly register these methods:\n\n.. ipython:: python\n\n   from pandas.tseries import converter\n   converter.register()\n\n   fig, ax = plt.subplots()\n   plt.plot(pd.date_range(&#39;2017&#39;, periods=6), range(6))\n\nPandas built-in ``Series.plot`` and ``DataFrame.plot`` *will* register these\nconverters on first-use (:issue:17710).\n\n.. _whatsnew_0210.api:\n\nOther API Changes\n^^^^^^^^^^^^^^^^^\n\n- The Categorical constructor no longer accepts a scalar for the ``categories`` keyword. (:issue:`16022`)\n- Accessing a non-existent attribute on a closed :class:`~pandas.HDFStore` will now\n  raise an ``AttributeError`` rather than a ``ClosedFileError`` (:issue:`16301`)\n- :func:`read_csv` now issues a ``UserWarning`` if the ``names`` parameter contains duplicates (:issue:`17095`)\n- :func:`read_csv` now treats ``&#39;null&#39;`` and ``&#39;n/a&#39;`` strings as missing values by default (:issue:`16471`, :issue:`16078`)\n- :class:`pandas.HDFStore`&#39;s string representation is now faster and less detailed. For the previous behavior, use ``pandas.HDFStore.info()``. (:issue:`16503`).\n- Compression defaults in HDF stores now follow pytables standards. Default is no compression and if ``complib`` is missing and ``complevel`` &gt; 0 ``zlib`` is used (:issue:`15943`)\n- ``Index.get_indexer_non_unique()`` now returns a ndarray indexer rather than an ``Index``; this is consistent with ``Index.get_indexer()`` (:issue:`16819`)\n- Removed the ``slow`` decorator from ``pandas.util.testing``, which caused issues for some downstream packages&#39; test suites. Use ``pytest.mark.slow`` instead, which achieves the same thing (:issue:`16850`)\n- Moved definition of ``MergeError`` to the ``pandas.errors`` module.\n- The signature of :func:`Series.set_axis` and :func:`DataFrame.set_axis` has been changed from ``set_axis(axis, labels)`` to ``set_axis(labels, axis=0)``, for consistency with the rest of the API. The old signature is deprecated and will show a ``FutureWarning`` (:issue:`14636`)\n- :func:`Series.argmin` and :func:`Series.argmax` will now raise a ``TypeError`` when used with ``object`` dtypes, instead of a ``ValueError`` (:issue:`13595`)\n- :class:`Period` is now immutable, and will now raise an ``AttributeError`` when a user tries to assign a new value to the ``ordinal`` or ``freq`` attributes (:issue:`17116`).\n- :func:`to_datetime` when passed a tz-aware ``origin=`` kwarg will now raise a more informative ``ValueError`` rather than a ``TypeError`` (:issue:`16842`)\n- :func:`to_datetime` now raises a ``ValueError`` when format includes ``%W`` or ``%U`` without also including day of the week and calendar year (:issue:`16774`)\n- Renamed non-functional ``index`` to ``index_col`` in :func:`read_stata` to improve API consistency (:issue:`16342`)\n- Bug in :func:`DataFrame.drop` caused boolean labels ``False`` and ``True`` to be treated as labels 0 and 1 respectively when dropping indices from a numeric index. This will now raise a ValueError (:issue:`16877`)\n- Restricted DateOffset keyword arguments.  Previously, ``DateOffset`` subclasses allowed arbitrary keyword arguments which could lead to unexpected behavior.  Now, only valid arguments will be accepted. (:issue:`17176`).\n\n.. _whatsnew_0210.deprecations:\n\nDeprecations\n~~~~~~~~~~~~\n\n- :meth:`DataFrame.from_csv` and :meth:`Series.from_csv` have been deprecated in favor of :func:`read_csv()` (:issue:`4191`)\n- :func:`read_excel()` has deprecated ``sheetname`` in favor of ``sheet_name`` for consistency with ``.to_excel()`` (:issue:`10559`).\n- :func:`read_excel()` has deprecated ``parse_cols`` in favor of ``usecols`` for consistency with :func:`read_csv` (:issue:`4988`)\n- :func:`read_csv()` has deprecated the ``tupleize_cols`` argument. Column tuples will always be converted to a ``MultiIndex`` (:issue:`17060`)\n- :meth:`DataFrame.to_csv` has deprecated the ``tupleize_cols`` argument. Multi-index columns will be always written as rows in the CSV file (:issue:`17060`)\n- The ``convert`` parameter has been deprecated in the ``.take()`` method, as it was not being respected (:issue:`16948`)\n- ``pd.options.html.border`` has been deprecated in favor of ``pd.options.display.html.border`` (:issue:`15793`).\n- :func:`SeriesGroupBy.nth` has deprecated ``True`` in favor of ``&#39;all&#39;`` for its kwarg ``dropna`` (:issue:`11038`).\n- :func:`DataFrame.as_blocks` is deprecated, as this is exposing the internal implementation (:issue:`17302`)\n- ``pd.TimeGrouper`` is deprecated in favor of :class:`pandas.Grouper` (:issue:`16747`)\n- ``cdate_range`` has been deprecated in favor of :func:`bdate_range`, which has gained ``weekmask`` and ``holidays`` parameters for building custom frequency date ranges. See the :ref:`documentation &lt;timeseries.custom-freq-ranges&gt;` for more details (:issue:`17596`)\n- passing ``categories`` or ``ordered`` kwargs to :func:`Series.astype` is deprecated, in favor of passing a :ref:`CategoricalDtype &lt;whatsnew_0210.enhancements.categorical_dtype&gt;` (:issue:`17636`)\n- ``.get_value`` and ``.set_value`` on ``Series``, ``DataFrame``, ``Panel``, ``SparseSeries``, and ``SparseDataFrame`` are deprecated in favor of using ``.iat[]`` or ``.at[]`` accessors (:issue:`15269`)\n- Passing a non-existent column in ``.to_excel(..., columns=)`` is deprecated and will raise a ``KeyError`` in the future (:issue:`17295`)\n- ``raise_on_error`` parameter to :func:`Series.where`, :func:`Series.mask`, :func:`DataFrame.where`, :func:`DataFrame.mask` is deprecated, in favor of ``errors=`` (:issue:`14968`)\n- Using :meth:`DataFrame.rename_axis` and :meth:`Series.rename_axis` to alter index or column *labels* is now deprecated in favor of using ``.rename``. ``rename_axis`` may still be used to alter the name of the index or columns (:issue:`17833`).\n- :meth:`~DataFrame.reindex_axis` has been deprecated in favor of :meth:`~DataFrame.reindex`. See :ref:`here &lt;whatsnew_0210.enhancements.rename_reindex_axis&gt;` for more (:issue:`17833`).\n\n.. _whatsnew_0210.deprecations.select:\n\nSeries.select and DataFrame.select\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe :meth:`Series.select` and :meth:`DataFrame.select` methods are deprecated in favor of using ``df.loc[labels.map(crit)]`` (:issue:`12401`)\n\n.. ipython:: python\n\n   df = DataFrame({&#39;A&#39;: [1, 2, 3]}, index=[&#39;foo&#39;, &#39;bar&#39;, &#39;baz&#39;])\n\n.. code-block:: ipython\n\n   In [3]: df.select(lambda x: x in [&#39;bar&#39;, &#39;baz&#39;])\n   FutureWarning: select is deprecated and will be removed in a future release. You can use .loc[crit] as a replacement\n   Out[3]:\n        A\n   bar  2\n   baz  3\n\n.. ipython:: python\n\n   df.loc[df.index.map(lambda x: x in [&#39;bar&#39;, &#39;baz&#39;])]\n\n\n.. _whatsnew_0210.deprecations.argmin_min:\n\nSeries.argmax and Series.argmin\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe behavior of :func:`Series.argmax` and :func:`Series.argmin` have been deprecated in favor of :func:`Series.idxmax` and :func:`Series.idxmin`, respectively (:issue:`16830`).\n\nFor compatibility with NumPy arrays, ``pd.Series`` implements ``argmax`` and\n``argmin``. Since pandas 0.13.0, ``argmax`` has been an alias for\n:meth:`pandas.Series.idxmax`, and ``argmin`` has been an alias for\n:meth:`pandas.Series.idxmin`. They return the *label* of the maximum or minimum,\nrather than the *position*.\n\nWe&#39;ve deprecated the current behavior of ``Series.argmax`` and\n``Series.argmin``. Using either of these will emit a ``FutureWarning``. Use\n:meth:`Series.idxmax` if you want the label of the maximum. Use\n``Series.values.argmax()`` if you want the position of the maximum. Likewise for\nthe minimum. In a future release ``Series.argmax`` and ``Series.argmin`` will\nreturn the position of the maximum or minimum.\n\n.. _whatsnew_0210.prior_deprecations:\n\nRemoval of prior version deprecations/changes\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n- :func:`read_excel()` has dropped the ``has_index_names`` parameter (:issue:`10967`)\n- The ``pd.options.display.height`` configuration has been dropped (:issue:`3663`)\n- The ``pd.options.display.line_width`` configuration has been dropped (:issue:`2881`)\n- The ``pd.options.display.mpl_style`` configuration has been dropped (:issue:`12190`)\n- ``Index`` has dropped the ``.sym_diff()`` method in favor of ``.symmetric_difference()`` (:issue:`12591`)\n- ``Categorical`` has dropped the ``.order()`` and ``.sort()`` methods in favor of ``.sort_values()`` (:issue:`12882`)\n- :func:`eval` and :func:`DataFrame.eval` have changed the default of ``inplace`` from ``None`` to ``False`` (:issue:`11149`)\n- The function ``get_offset_name`` has been dropped in favor of the ``.freqstr`` attribute for an offset (:issue:`11834`)\n- pandas no longer tests for compatibility with hdf5-files created with pandas &lt; 0.11 (:issue:`17404`).\n\n\n\n.. _whatsnew_0210.performance:\n\nPerformance Improvements\n~~~~~~~~~~~~~~~~~~~~~~~~\n\n- Improved performance of instantiating :class:`SparseDataFrame` (:issue:`16773`)\n- :attr:`Series.dt` no longer performs frequency inference, yielding a large speedup when accessing the attribute (:issue:`17210`)\n- Improved performance of :meth:`~Series.cat.set_categories` by not materializing the values (:issue:`17508`)\n- :attr:`Timestamp.microsecond` no longer re-computes on attribute access (:issue:`17331`)\n- Improved performance of the :class:`CategoricalIndex` for data that is already categorical dtype (:issue:`17513`)\n- Improved performance of :meth:`RangeIndex.min` and :meth:`RangeIndex.max` by using ``RangeIndex`` properties to perform the computations (:issue:`17607`)\n\n.. _whatsnew_0210.docs:\n\nDocumentation Changes\n~~~~~~~~~~~~~~~~~~~~~\n\n- Several ``NaT`` method docstrings (e.g. :func:`NaT.ctime`) were incorrect (:issue:`17327`)\n- The documentation has had references to versions &lt; v0.17 removed and cleaned up (:issue:`17442`, :issue:`17442`, :issue:`17404` &amp; :issue:`17504`)\n\n.. _whatsnew_0210.bug_fixes:\n\nBug Fixes\n~~~~~~~~~\n\nConversion\n^^^^^^^^^^\n\n- Bug in assignment against datetime-like data with ``int`` may incorrectly convert to datetime-like (:issue:`14145`)\n- Bug in assignment against ``int64`` data with ``np.ndarray`` with ``float64`` dtype may keep ``int64`` dtype (:issue:`14001`)\n- Fixed the return type of ``IntervalIndex.is_non_overlapping_monotonic`` to be a Python ``bool`` for consistency with similar attributes/methods.  Previously returned a ``numpy.bool_``. (:issue:`17237`)\n- Bug in ``IntervalIndex.is_non_overlapping_monotonic`` when intervals are closed on both sides and overlap at a point (:issue:`16560`)\n- Bug in :func:`Series.fillna` returns frame when ``inplace=True`` and ``value`` is dict (:issue:`16156`)\n- Bug in :attr:`Timestamp.weekday_name` returning a UTC-based weekday name when localized to a timezone (:issue:`17354`)\n- Bug in ``Timestamp.replace`` when replacing ``tzinfo`` around DST changes (:issue:`15683`)\n- Bug in ``Timedelta`` construction and arithmetic that would not propagate the ``Overflow`` exception (:issue:`17367`)\n- Bug in :meth:`~DataFrame.astype` converting to object dtype when passed extension type classes (`DatetimeTZDtype``, ``CategoricalDtype``) rather than instances. Now a ``TypeError`` is raised when a class is passed (:issue:`17780`).\n- Bug in :meth:`to_numeric` in which elements were not always being coerced to numeric when ``errors=&#39;coerce&#39;`` (:issue:`17007`, :issue:`17125`)\n- Bug in ``DataFrame`` and ``Series`` constructors where ``range`` objects are converted to ``int32`` dtype on Windows instead of ``int64`` (:issue:`16804`)\n\nIndexing\n^^^^^^^^\n\n- When called with a null slice (e.g. ``df.iloc[:]``), the ``.iloc`` and ``.loc`` indexers return a shallow copy of the original object. Previously they returned the original object. (:issue:`13873`).\n- When called on an unsorted ``MultiIndex``, the ``loc`` indexer now will raise ``UnsortedIndexError`` only if proper slicing is used on non-sorted levels (:issue:`16734`).\n- Fixes regression in 0.20.3 when indexing with a string on a ``TimedeltaIndex`` (:issue:`16896`).\n- Fixed :func:`TimedeltaIndex.get_loc` handling of ``np.timedelta64`` inputs (:issue:`16909`).\n- Fix :func:`MultiIndex.sort_index` ordering when ``ascending`` argument is a list, but not all levels are specified, or are in a different order (:issue:`16934`).\n- Fixes bug where indexing with ``np.inf`` caused an ``OverflowError`` to be raised (:issue:`16957`)\n- Bug in reindexing on an empty ``CategoricalIndex`` (:issue:`16770`)\n- Fixes ``DataFrame.loc`` for setting with alignment and tz-aware ``DatetimeIndex`` (:issue:`16889`)\n- Avoids ``IndexError`` when passing an Index or Series to ``.iloc`` with older numpy (:issue:`17193`)\n- Allow unicode empty strings as placeholders in multilevel columns in Python 2 (:issue:`17099`)\n- Bug in ``.iloc`` when used with inplace addition or assignment and an int indexer on a ``MultiIndex`` causing the wrong indexes to be read from and written to (:issue:`17148`)\n- Bug in ``.isin()`` in which checking membership in empty ``Series`` objects raised an error (:issue:`16991`)\n- Bug in ``CategoricalIndex`` reindexing in which specified indices containing duplicates were not being respected (:issue:`17323`)\n- Bug in intersection of ``RangeIndex`` with negative step (:issue:`17296`)\n- Bug in ``IntervalIndex`` where performing a scalar lookup fails for included right endpoints of non-overlapping monotonic decreasing indexes (:issue:`16417`, :issue:`17271`)\n- Bug in :meth:`DataFrame.first_valid_index` and :meth:`DataFrame.last_valid_index` when no valid entry (:issue:`17400`)\n- Bug in :func:`Series.rename` when called with a callable, incorrectly alters the name of the ``Series``, rather than the name of the ``Index``. (:issue:`17407`)\n- Bug in :func:`String.str_get` raises ``IndexError`` instead of inserting NaNs when using a negative index. (:issue:`17704`)\n\nI/O\n^^^\n\n- Bug in :func:`read_hdf` when reading a timezone aware index from ``fixed`` format HDFStore (:issue:`17618`)\n- Bug in :func:`read_csv` in which columns were not being thoroughly de-duplicated (:issue:`17060`)\n- Bug in :func:`read_csv` in which specified column names were not being thoroughly de-duplicated (:issue:`17095`)\n- Bug in :func:`read_csv` in which non integer values for the header argument generated an unhelpful / unrelated error message (:issue:`16338`)\n- Bug in :func:`read_csv` in which memory management issues in exception handling, under certain conditions, would cause the interpreter to segfault (:issue:`14696`, :issue:`16798`).\n- Bug in :func:`read_csv` when called with ``low_memory=False`` in which a CSV with at least one column &gt; 2GB in size would incorrectly raise a ``MemoryError`` (:issue:`16798`).\n- Bug in :func:`read_csv` when called with a single-element list ``header`` would return a ``DataFrame`` of all NaN values (:issue:`7757`)\n- Bug in :meth:`DataFrame.to_csv` defaulting to &#39;ascii&#39; encoding in Python 3, instead of &#39;utf-8&#39; (:issue:`17097`)\n- Bug in :func:`read_stata` where value labels could not be read when using an iterator (:issue:`16923`)\n- Bug in :func:`read_stata` where the index was not set (:issue:`16342`)\n- Bug in :func:`read_html` where import check fails when run in multiple threads (:issue:`16928`)\n- Bug in :func:`read_csv` where automatic delimiter detection caused a ``TypeError`` to be thrown when a bad line was encountered rather than the correct error message (:issue:`13374`)\n- Bug in :meth:`DataFrame.to_html` with ``notebook=True`` where DataFrames with named indices or non-MultiIndex indices had undesired horizontal or vertical alignment for column or row labels, respectively (:issue:`16792`)\n- Bug in :meth:`DataFrame.to_html` in which there was no validation of the ``justify`` parameter (:issue:`17527`)\n- Bug in :func:`HDFStore.select` when reading a contiguous mixed-data table featuring VLArray (:issue:`17021`)\n- Bug in :func:`to_json` where several conditions (including objects with unprintable symbols, objects with deep "},"comment":{"url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/comments/372656246","html_url":"https://github.com/UGentBiomath/wwdata/pull/183#issuecomment-372656246","issue_url":"https://api.github.com/repos/UGentBiomath/wwdata/issues/183","id":372656246,"user":{"login":"pyup-bot","id":16239342,"avatar_url":"https://avatars0.githubusercontent.com/u/16239342?v=4","gravatar_id":"","url":"https://api.github.com/users/pyup-bot","html_url":"https://github.com/pyup-bot","followers_url":"https://api.github.com/users/pyup-bot/followers","following_url":"https://api.github.com/users/pyup-bot/following{/other_user}","gists_url":"https://api.github.com/users/pyup-bot/gists{/gist_id}","starred_url":"https://api.github.com/users/pyup-bot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pyup-bot/subscriptions","organizations_url":"https://api.github.com/users/pyup-bot/orgs","repos_url":"https://api.github.com/users/pyup-bot/repos","events_url":"https://api.github.com/users/pyup-bot/events{/privacy}","received_events_url":"https://api.github.com/users/pyup-bot/received_events","type":"User","site_admin":false},"created_at":"2018-03-13T12:58:31Z","updated_at":"2018-03-13T12:58:31Z","author_association":"NONE","body":"Closing this in favor of #184"}}
{"actor":{"display_login":"pyup-bot"}}