From 77d7834f9fe02caa52995b405446ccae348f0f4e Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 14:08:52 -0500 Subject: [PATCH 01/14] DOC: PDP6 page bulleted list update #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 1 + 1 file changed, 1 insertion(+) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 325c25313af53..faf43dfaaf751 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -152,6 +152,7 @@ Possible options could be: 3. limit "banning upcasting" to when the upcasted dtype is ``object`` (i.e. preserve current behavior of upcasting the int64 Series to float64) . Let us compare with what other libraries do: + - ``numpy``: option 2 - ``cudf``: option 2 - ``polars``: option 2 From debf592478a4b1bb5c058c3d06afd58f84955d94 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 16:20:19 -0500 Subject: [PATCH 02/14] PDEP6 full format update #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index faf43dfaaf751..ec3e0a97015ad 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -75,18 +75,20 @@ It may be desirable to expand the top list to ``Series.replace`` and ``Series.up but to keep the scope of the PDEP down, they are excluded for now. Examples of operations which would not raise are: -- ``ser.diff()``; -- ``pd.concat([ser, ser.astype(object)])``; -- ``ser.mean()``; + +- ``ser.diff()`` +- ``pd.concat([ser, ser.astype(object)])`` +- ``ser.mean()`` - ``ser[0] = 3``; # same dtype - ``ser[0] = 3.``; # 3.0 is a 'round' float and so compatible with 'int64' dtype -- ``df['a'] = pd.date_range(datetime(2020, 1, 1), periods=3)``; -- ``df.index.intersection(ser.index)``. +- ``df['a'] = pd.date_range(datetime(2020, 1, 1), periods=3)`` +- ``df.index.intersection(ser.index)`` ## Detailed description Concretely, the suggestion is: -- if a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype; + +- if a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype. - if a ``setitem``-like operation would previously have changed a ``Series``' dtype, it would now raise. For a start, this would involve: @@ -105,11 +107,12 @@ For a start, this would involve: ``` 2. making a similar change in: - - ``Block.where``; - - ``Block.putmask``; - - ``EABackedBlock.setitem``; - - ``EABackedBlock.where``; - - ``EABackedBlock.putmask``; + + - ``Block.where`` + - ``Block.putmask`` + - ``EABackedBlock.setitem`` + - ``EABackedBlock.where`` + - ``EABackedBlock.putmask`` The above would already require several hundreds of tests to be adjusted. Note that once implementation starts, the list of locations to change may turn out to be slightly From ddf551a6fcdad4ae5205d57f975a6a8fcf9670b2 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 16:33:18 -0500 Subject: [PATCH 03/14] PDEP6 final bullet list updated #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index ec3e0a97015ad..8438c79e83bdf 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -89,7 +89,7 @@ Examples of operations which would not raise are: Concretely, the suggestion is: - if a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype. -- if a ``setitem``-like operation would previously have changed a ``Series``' dtype, it would now raise. +- if a ``setitem``-like operation would previously have changed a ``Series`` dtype, it would now raise. For a start, this would involve: @@ -169,6 +169,7 @@ if the objective of this PDEP is to prevent bugs, then this is also not desirabl someone might set ``1.5`` and later be surprised to learn that they actually set ``1``. There are several downsides to option ``3``: + - it would be inconsistent with the nullable dtypes' behaviour; - it would also add complexity to the codebase and to tests; - it would be hard to teach, as instead of being able to teach a simple rule, From b976bc5501f5cb21833a843b570d3e6fd96ce44c Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 17:49:14 -0500 Subject: [PATCH 04/14] Fix unintended deletion #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 8438c79e83bdf..f0ed2ae68e266 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -89,7 +89,7 @@ Examples of operations which would not raise are: Concretely, the suggestion is: - if a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype. -- if a ``setitem``-like operation would previously have changed a ``Series`` dtype, it would now raise. +- if a ``setitem``-like operation would previously have changed a ``Series``' dtype, it would now raise. For a start, this would involve: From 478e2e91e5f4a133ebcf4508ace2b4ef965a4fda Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 18:35:05 -0500 Subject: [PATCH 05/14] Grammar fix --- web/pandas/pdeps/0006-ban-upcasting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index f0ed2ae68e266..958f0b3fdddbf 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -9,7 +9,7 @@ ## Abstract The suggestion is that setitem-like operations would -not change a ``Series`` dtype (nor that of a ``DataFrame``'s column). +not change a ``Series``' dtype (nor that of a ``DataFrame``'s column). Current behaviour: ```python From 9f345e8d2f23aff2ba4c70538590dcf4a627b9ed Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 21:10:48 -0500 Subject: [PATCH 06/14] PDEP6 numbered list and object puncuation. #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 41 +++++++++++++------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 958f0b3fdddbf..5a050a25600d7 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -58,12 +58,12 @@ ser = df["a"].copy() ``` then the following would all raise: -- setitem-like operations: - - ``ser.fillna('foo', inplace=True)``; +* setitem-like operations: + - ``ser.fillna('foo', inplace=True)`` - ``ser.where(ser.isna(), 'foo', inplace=True)`` - - ``ser.fillna('foo', inplace=False)``; + - ``ser.fillna('foo', inplace=False)`` - ``ser.where(ser.isna(), 'foo', inplace=False)`` -- setitem indexing operations (where ``indexer`` could be a slice, a mask, +* setitem indexing operations (where ``indexer`` could be a slice, a mask, a single value, a list or array of values, or any other allowed indexer): - ``ser.iloc[indexer] = 'foo'`` - ``ser.loc[indexer] = 'foo'`` @@ -79,8 +79,8 @@ Examples of operations which would not raise are: - ``ser.diff()`` - ``pd.concat([ser, ser.astype(object)])`` - ``ser.mean()`` -- ``ser[0] = 3``; # same dtype -- ``ser[0] = 3.``; # 3.0 is a 'round' float and so compatible with 'int64' dtype +- ``ser[0] = 3`` # same dtype +- ``ser[0] = 3.`` # 3.0 is a 'round' float and so compatible with 'int64' dtype - ``df['a'] = pd.date_range(datetime(2020, 1, 1), periods=3)`` - ``df.index.intersection(ser.index)`` @@ -108,11 +108,11 @@ For a start, this would involve: 2. making a similar change in: - - ``Block.where`` - - ``Block.putmask`` - - ``EABackedBlock.setitem`` - - ``EABackedBlock.where`` - - ``EABackedBlock.putmask`` +- ``Block.where`` +- ``Block.putmask`` +- ``EABackedBlock.setitem`` +- ``EABackedBlock.where`` +- ``EABackedBlock.putmask`` The above would already require several hundreds of tests to be adjusted. Note that once implementation starts, the list of locations to change may turn out to be slightly @@ -150,9 +150,10 @@ numeric (without much regard for ``int`` vs ``float``) - ``'int64'`` is just wha when constructing it. Possible options could be: -1. only accept round floats (e.g. ``1.0``) and raise on anything else (e.g. ``1.01``); -2. convert the float value to ``int`` before setting it (i.e. silently round all float values); -3. limit "banning upcasting" to when the upcasted dtype is ``object`` (i.e. preserve current behavior of upcasting the int64 Series to float64) . + +1. Only accept round floats (e.g. ``1.0``) and raise on anything else (e.g. ``1.01``). +2. Convert the float value to ``int`` before setting it (i.e. silently round all float values). +3. Limit "banning upcasting" to when the upcasted dtype is ``object`` (i.e. preserve current behavior of upcasting the int64 Series to float64). Let us compare with what other libraries do: @@ -170,12 +171,12 @@ someone might set ``1.5`` and later be surprised to learn that they actually set There are several downsides to option ``3``: -- it would be inconsistent with the nullable dtypes' behaviour; -- it would also add complexity to the codebase and to tests; -- it would be hard to teach, as instead of being able to teach a simple rule, - there would be a rule with exceptions; -- there would be a risk of loss of precision and or overflow; -- it opens the door to other exceptions, such as not upcasting ``'int8'`` to ``'int16'``. +- It would be inconsistent with the nullable dtypes' behaviour. +- It would also add complexity to the codebase and to tests. +- It would be hard to teach, as instead of being able to teach a simple rule, + There would be a rule with exceptions. +- There would be a risk of loss of precision and or overflow. +- It opens the door to other exceptions, such as not upcasting ``'int8'`` to ``'int16'``. Option ``1`` is the maximally safe one in terms of protecting users from bugs, being consistent with the current behaviour of nullable dtypes, and in being simple to teach. From fa8cf3a34fd1b273b2cf2639eefdf6158fc48bfb Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 21:26:09 -0500 Subject: [PATCH 07/14] Update nested list in description section. --- web/pandas/pdeps/0006-ban-upcasting.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 5a050a25600d7..fde7a5d280270 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -108,11 +108,11 @@ For a start, this would involve: 2. making a similar change in: -- ``Block.where`` -- ``Block.putmask`` -- ``EABackedBlock.setitem`` -- ``EABackedBlock.where`` -- ``EABackedBlock.putmask`` + - ``Block.where`` + - ``Block.putmask`` + - ``EABackedBlock.setitem`` + - ``EABackedBlock.where`` + - ``EABackedBlock.putmask`` The above would already require several hundreds of tests to be adjusted. Note that once implementation starts, the list of locations to change may turn out to be slightly From 772218239ffd081d2e6a421838021edc76722763 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 22:22:43 -0500 Subject: [PATCH 08/14] PDEP6 Final Commit Proposal for Review. #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 59 ++++++++++++++------------ 1 file changed, 31 insertions(+), 28 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index fde7a5d280270..1f1898677e35d 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -51,7 +51,7 @@ In[11]: ser[2] = "2000-01-04x" # typo - but pandas does not error, it upcasts t ``` The scope of this PDEP is limited to setitem-like operations on Series (and DataFrame columns). -For example, starting with +For example, starting with: ```python df = DataFrame({"a": [1, 2, np.nan], "b": [4, 5, 6]}) ser = df["a"].copy() @@ -59,17 +59,20 @@ ser = df["a"].copy() then the following would all raise: * setitem-like operations: - - ``ser.fillna('foo', inplace=True)`` - - ``ser.where(ser.isna(), 'foo', inplace=True)`` - - ``ser.fillna('foo', inplace=False)`` - - ``ser.where(ser.isna(), 'foo', inplace=False)`` + + - ``ser.fillna('foo', inplace=True)`` + - ``ser.where(ser.isna(), 'foo', inplace=True)`` + - ``ser.fillna('foo', inplace=False)`` + - ``ser.where(ser.isna(), 'foo', inplace=False)`` + * setitem indexing operations (where ``indexer`` could be a slice, a mask, a single value, a list or array of values, or any other allowed indexer): - - ``ser.iloc[indexer] = 'foo'`` - - ``ser.loc[indexer] = 'foo'`` - - ``df.iloc[indexer, 0] = 'foo'`` - - ``df.loc[indexer, 'a'] = 'foo'`` - - ``ser[indexer] = 'foo'`` + + - ``ser.iloc[indexer] = 'foo'`` + - ``ser.loc[indexer] = 'foo'`` + - ``df.iloc[indexer, 0] = 'foo'`` + - ``df.loc[indexer, 'a'] = 'foo'`` + - ``ser[indexer] = 'foo'`` It may be desirable to expand the top list to ``Series.replace`` and ``Series.update``, but to keep the scope of the PDEP down, they are excluded for now. @@ -88,31 +91,31 @@ Examples of operations which would not raise are: Concretely, the suggestion is: -- if a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype. -- if a ``setitem``-like operation would previously have changed a ``Series``' dtype, it would now raise. +- If a ``Series`` is of a given dtype, then a ``setitem``-like operation should not change its dtype. +- If a ``setitem``-like operation would previously have changed a ``Series``' dtype, it would now raise. For a start, this would involve: -1. changing ``Block.setitem`` such that it does not have an ``except`` block in +1. changing ``Block.setitem`` such that it does not have an ``except`` block in: - ```python - value = extract_array(value, extract_numpy=True) - try: - casted = np_can_hold_element(values.dtype, value) - except LossySetitemError: - # current dtype cannot store value, coerce to common dtype - nb = self.coerce_to_target_dtype(value) - return nb.setitem(indexer, value) - else: - ``` + ```python + value = extract_array(value, extract_numpy=True) + try: + casted = np_can_hold_element(values.dtype, value) + except LossySetitemError: + # current dtype cannot store value, coerce to common dtype + nb = self.coerce_to_target_dtype(value) + return nb.setitem(indexer, value) + else: + ``` 2. making a similar change in: - - ``Block.where`` - - ``Block.putmask`` - - ``EABackedBlock.setitem`` - - ``EABackedBlock.where`` - - ``EABackedBlock.putmask`` + - ``Block.where`` + - ``Block.putmask`` + - ``EABackedBlock.setitem`` + - ``EABackedBlock.where`` + - ``EABackedBlock.putmask`` The above would already require several hundreds of tests to be adjusted. Note that once implementation starts, the list of locations to change may turn out to be slightly From 76a687f02f9e9267da0a7e12beeefa443d259635 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 23:08:56 -0500 Subject: [PATCH 09/14] PDEP6 update code block format FAQ. #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 1f1898677e35d..c0f6be3739c0d 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -225,13 +225,15 @@ at all. To keep this proposal focused, it is intentionally excluded from the sco **Q: What if I want ``1.0000000001`` to be inserted as ``1.0`` in an `'int8'` Series?** -**A**: You may want to define your own helper function, such as +**A**: You may want to define your own helper function, such as: + ```python - >>> def maybe_convert_to_int(x: int | float, tolerance: float): + def maybe_convert_to_int(x: int | float, tolerance: float): if np.abs(x - round(x)) < tolerance: return round(x) return x ``` + which you could adapt according to your needs. ## Timeline From 40639d99b8d6b11d553e96cb2a716a837c48a289 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Mon, 29 May 2023 23:31:47 -0500 Subject: [PATCH 10/14] PDEP6 whitespace cleanup #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index c0f6be3739c0d..fe179ccb35b77 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -64,10 +64,10 @@ then the following would all raise: - ``ser.where(ser.isna(), 'foo', inplace=True)`` - ``ser.fillna('foo', inplace=False)`` - ``ser.where(ser.isna(), 'foo', inplace=False)`` - + * setitem indexing operations (where ``indexer`` could be a slice, a mask, a single value, a list or array of values, or any other allowed indexer): - + - ``ser.iloc[indexer] = 'foo'`` - ``ser.loc[indexer] = 'foo'`` - ``df.iloc[indexer, 0] = 'foo'`` @@ -233,7 +233,7 @@ at all. To keep this proposal focused, it is intentionally excluded from the sco return round(x) return x ``` - + which you could adapt according to your needs. ## Timeline From c5ebaca15c80d0ca6fbefd2b9d8ed1985b677b2e Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Tue, 30 May 2023 12:20:50 -0500 Subject: [PATCH 11/14] PDEP6 FAQ code block update #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 32 +++++++++++++------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index fe179ccb35b77..573d8a208f504 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -98,16 +98,16 @@ For a start, this would involve: 1. changing ``Block.setitem`` such that it does not have an ``except`` block in: - ```python - value = extract_array(value, extract_numpy=True) - try: - casted = np_can_hold_element(values.dtype, value) - except LossySetitemError: - # current dtype cannot store value, coerce to common dtype - nb = self.coerce_to_target_dtype(value) - return nb.setitem(indexer, value) - else: - ``` + ```python + value = extract_array(value, extract_numpy=True) + try: + casted = no_can_hold_element(values.dtype, value) + except LossSetitemError: + # current dtype cannot store value, coerce to common dtype + nb = self.coerce_to_target_dtype(value) + return nb.setitem(index, value) + else: + ``` 2. making a similar change in: @@ -227,12 +227,12 @@ at all. To keep this proposal focused, it is intentionally excluded from the sco **A**: You may want to define your own helper function, such as: - ```python - def maybe_convert_to_int(x: int | float, tolerance: float): - if np.abs(x - round(x)) < tolerance: - return round(x) - return x - ``` +```python +def maybe_convert_to_int(x: int | float, tolerance: float): + if np.abs(x - round(x)) < tolerance: + return round(x) + return x +``` which you could adapt according to your needs. From e6175619d185c7548f30f556f09f828855c9314b Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Tue, 30 May 2023 14:55:01 -0500 Subject: [PATCH 12/14] PDEP6 format update for final review. #53414 --- web/pandas/pdeps/0006-ban-upcasting.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 573d8a208f504..c88417f24ca3f 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -97,18 +97,18 @@ Concretely, the suggestion is: For a start, this would involve: 1. changing ``Block.setitem`` such that it does not have an ``except`` block in: - - ```python + + + value = extract_array(value, extract_numpy=True) try: - casted = no_can_hold_element(values.dtype, value) - except LossSetitemError: + casted = np_can_hold_element(values.dtype, value) + except LossSetitiemError: # current dtype cannot store value, coerce to common dtype nb = self.coerce_to_target_dtype(value) return nb.setitem(index, value) else: - ``` - + 2. making a similar change in: - ``Block.where`` @@ -234,7 +234,8 @@ def maybe_convert_to_int(x: int | float, tolerance: float): return x ``` - which you could adapt according to your needs. +which you could adapt according to your needs. + ## Timeline From 0740005787aed84178cb08feb9e7bd7b1149c1d9 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Tue, 30 May 2023 15:10:58 -0500 Subject: [PATCH 13/14] PDEP6 final review with whitespace fix --- web/pandas/pdeps/0006-ban-upcasting.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index c88417f24ca3f..2fef3744d6f9a 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -97,9 +97,9 @@ Concretely, the suggestion is: For a start, this would involve: 1. changing ``Block.setitem`` such that it does not have an ``except`` block in: - + - + value = extract_array(value, extract_numpy=True) try: casted = np_can_hold_element(values.dtype, value) @@ -108,7 +108,7 @@ For a start, this would involve: nb = self.coerce_to_target_dtype(value) return nb.setitem(index, value) else: - + 2. making a similar change in: - ``Block.where`` From 3200655558f14c11ac03d2944f35d2fb2f950cc4 Mon Sep 17 00:00:00 2001 From: UmbertoFasci Date: Tue, 30 May 2023 19:22:39 -0500 Subject: [PATCH 14/14] PDEP6 FAQ section typo fix. --- web/pandas/pdeps/0006-ban-upcasting.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/web/pandas/pdeps/0006-ban-upcasting.md b/web/pandas/pdeps/0006-ban-upcasting.md index 2fef3744d6f9a..12e4c084cc826 100644 --- a/web/pandas/pdeps/0006-ban-upcasting.md +++ b/web/pandas/pdeps/0006-ban-upcasting.md @@ -217,13 +217,13 @@ at all. To keep this proposal focused, it is intentionally excluded from the sco **A**: The current behavior would be to upcast to ``int32``. So under this PDEP, it would instead raise. -**Q: What happens in setting ``16.000000000000001`` in an `int8`` Series?** +**Q: What happens in setting ``16.000000000000001`` in an ``int8`` Series?** **A**: As far as Python is concerned, ``16.000000000000001`` and ``16.0`` are the same number. So, it would be inserted as ``16`` and the dtype would not change (just like what happens now, there would be no change here). -**Q: What if I want ``1.0000000001`` to be inserted as ``1.0`` in an `'int8'` Series?** +**Q: What if I want ``1.0000000001`` to be inserted as ``1.0`` in an ``int8`` Series?** **A**: You may want to define your own helper function, such as: