Skip to content

Bug in Chapter 3.01 #443

Description

@pglushko

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

  1. wafir645fcqs49 commented on Aug 5, 2026

    @wafir645fcqs49
  2. bsoua8745s12 commented on Aug 10, 2026

    @bsoua8745s12
  3. bsoua8745s12 commented on Aug 16, 2026

    @bsoua8745s12
  4. gustavocastillo5 commented on Sep 2, 2026

    @gustavocastillo5

    The core problem in the "Index as ordered set" section is that indA & indB ends up returning Index([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.

  5. UfBt12qJNZKcw commented on Sep 11, 2026

    @UfBt12qJNZKcw

    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 prioritize indA.intersection(indB) is the right move, but we should also explicitly warn readers that & behavior on pd.Index objects depends heavily on the underlying dtype.

  6. jadayaanaliah26 commented on Sep 14, 2026

    @jadayaanaliah26

    This behavior changed in pandas 1.0.0 where the & operator on integer Index objects was deprecated for

  7. heenll68 commented on Sep 27, 2026

    @heenll68

    Since the & operator behavior on pandas indices depends on the underlying dtype and often defaults to bitwise operations, we should explicitly document that intersection is the only reliable method for set operations to avoid these silent numeric misinterpretations.

  8. edinakama commented on Oct 4, 2026

    @edinakama

    Since pd.Index behavior for & defaults to bitwise operations on underlying numeric data, we should add a note explaining that intersection is the only safe method for set-like logic to avoid these silent, incorrect results.

  9. melina-karleen commented on Oct 5, 2026

    @melina-karleen

    Since the & operator behaves as a bitwise AND on underlying integer data, we should update the text to explicitly demonstrate indA.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?

  10. zeniatison commented on Oct 7, 2026

    @zeniatison

    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.

  11. sayradekayla26 commented on Oct 11, 2026

    @sayradekayla26

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions