From a9879ceaae586b436d48e8246a28ec6dc91d080e Mon Sep 17 00:00:00 2001 From: Joris Van den Bossche Date: Fri, 6 Oct 2023 14:26:48 +0200 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Irv Lustig --- web/pandas/pdeps/0007-copy-on-write.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/web/pandas/pdeps/0007-copy-on-write.md b/web/pandas/pdeps/0007-copy-on-write.md index f96ab463274b2..5c8d6b7b932ee 100644 --- a/web/pandas/pdeps/0007-copy-on-write.md +++ b/web/pandas/pdeps/0007-copy-on-write.md @@ -39,7 +39,7 @@ returning views vs. copies. We also care about performance. Returning views from indexing operations is faster and reduces memory usage. The same is true for several methods that don't modify the data -such as setting/resetting the index, renaming columns, etc that can be used in a method +such as setting/resetting the index, renaming columns, etc. that can be used in a method chaining workflow and currently return a new copy at each step. Finally, there are API / usability issues around views. It can be challenging to know @@ -65,9 +65,9 @@ There are two possible behaviours the user might intend: Today, pandas' inconsistency means _neither_ of these workflows is really possible. The first is difficult, because indexing operations often (though not always) return copies, -and even when a view is returned you sometimes get a SettingWithCopyWarning when +and even when a view is returned you sometimes get a `SettingWithCopyWarning` when mutating. The second is somewhat possible, but requires many defensive copies (to avoid -SettingWithCopyWarnings, or to ensure that you have a copy when a view _was_ returned). +`SettingWithCopyWarning`, or to ensure that you have a copy when a view _was_ returned). ## Proposal @@ -95,7 +95,7 @@ modified is a view on another dataframe (or is being viewed by another dataframe is, then we would copy the data before mutating. Taking the example from above, if the user wishes to not mutate the parent, we no longer -require a defensive copy just to avoid a SettingWithCopyWarning. +require a defensive copy just to avoid a `SettingWithCopyWarning`. ```python # Case 2: The user does not want mutating df2 to mutate the parent df, via CoW @@ -303,7 +303,7 @@ See the GitHub comment with some more detailed argumentation: ## Disadvantages Other than the fact that this proposal would result in a backwards incompatible, -breaking change in behaviour (see next section), there some other potential +breaking change in behaviour (see next section), there are some other potential disadvantages: * Deviation from NumPy: NumPy uses the copy and view concepts, while in this proposal @@ -403,7 +403,7 @@ cases will stop working (e.g. the case above but switching the order): ``` These cases will raise a warning ``ChainedAssignmentError``, because they can never -accomplished what the user intended. There will be false-positive cases when these +accomplish what the user intended. There will be false-positive cases when these operations are triggered from Cython, because Cython uses a different reference counting mechanism. These cases should be rare, since calling pandas code from Cython does not have any performance benefits.