Repository navigation
Bug in Chapter 3.01 #443
Description
Error is located in "Index as ordered set" section
indA = pd.Index([1, 3, 5, 7, 9])
indB = pd.Index([2, 3, 5, 7, 11])
indA & indB # intersection
returns
Index([0, 3, 5, 7, 9], dtype='int64')
but for intersection result should be [3, 5, 7], instead pandas performs logical AND
indA.intersection(indB) # Index([3, 5, 7], dtype='int64')
P.S. I can open PR, but then section would look more organically if for examples object methods would be presented, with comment that boolean ops are also supported
Activity
wafir645fcqs49 commentedon Aug 5, 2026
bsoua8745s12 commentedon Aug 10, 2026
bsoua8745s12 commentedon Aug 16, 2026
gustavocastillo5 commentedon Sep 2, 2026
The core problem in the "Index as ordered set" section is that
indA & indBends up returningIndex([0, 3, 5, 7, 9], dtype='int64')for the listed values instead of performing the intersection.Showing
indA.intersection(indB)as the primary way to get [3, 5, 7] would resolve this directly.UfBt12qJNZKcw commentedon Sep 11, 2026
The
&operator is currently performing a bitwise AND on the integer values rather than a set intersection because pandas treats these indices as numeric arrays rather than sets. Updating the text to prioritizeindA.intersection(indB)is the right move, but we should also explicitly warn readers that&behavior onpd.Indexobjects depends heavily on the underlying dtype.jadayaanaliah26 commentedon Sep 14, 2026
This behavior changed in pandas 1.0.0 where the
&operator on integer Index objects was deprecated forheenll68 commentedon Sep 27, 2026
Since the
&operator behavior on pandas indices depends on the underlying dtype and often defaults to bitwise operations, we should explicitly document thatintersectionis the only reliable method for set operations to avoid these silent numeric misinterpretations.edinakama commentedon Oct 4, 2026
Since
pd.Indexbehavior for&defaults to bitwise operations on underlying numeric data, we should add a note explaining thatintersectionis the only safe method for set-like logic to avoid these silent, incorrect results.melina-karleen commentedon Oct 5, 2026
Since the
&operator behaves as a bitwise AND on underlying integer data, we should update the text to explicitly demonstrateindA.intersection(indB)for set operations. Would it be helpful to add a note explaining that&only acts as a set intersection when the index contains non-numeric data types like strings?zeniatison commentedon Oct 7, 2026
Updating the text to emphasize
indA.intersection(indB)is correct, but we should also explicitly note that&on numeric indices triggers element-wise bitwise operations rather than set logic to prevent users from assuming consistent set behavior across different dtype indices.sayradekayla26 commentedon Oct 11, 2026
To prevent further confusion, we should also add a note explaining that the
&operator behaves as a bitwise operation on Index objects, which causes the unexpected output when values are interpreted as integers.dredonjaquana26 commentedon Oct 15, 2026
Since bitwise
&on Index objects behaves as an element-wise operation rather than set intersection, we should replace the current example withindA.intersection(indB)and add a note that the&operator is reserved for bitwise logic in pandas.cherryrodney26 commentedon Oct 19, 2026
To clarify the behavior for readers, we should note that
indA & indBis executing a bitwise operation on the underlyingint64data, which is why the output reflects index-wise matching rather than set intersection. I suggest adding a sidebar or note explaining that while the bitwise operators are supported, they do not behave as set operators on numeric Index objects. We could also include a snippet demonstratingindA.intersection(indB)alongside the current example to explicitly show the expected set output ofIndex([3, 5, 7]).