GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — `__eq__` raises TypeError on cross-type comparison instead of returning NotImplemented · Issue #6636 · feast-dev/feast

__eq__ raises TypeError on cross-type comparison instead of returning NotImplemented #6636

New issue
Copy link
New issue
Copy link
Closed
#6637
Closed
__eq__ raises TypeError on cross-type comparison instead of returning NotImplemented#6636
#6637
Copy link

Description

@larrysingleton007
larrysingleton007
opened on Jul 23, 2026
Issue body actions

Expected Behavior

Comparing two Feast objects of different concrete types (e.g. FileSource vs SnowflakeSource)
returns False, per Python's data model. In particular, changing a feature view's data source
type and re-running feast apply over an existing registry succeeds.

Current Behavior

__eq__ raises TypeError on a cross-type comparison instead of returning False. Because the
apply/diff path compares registered objects against incoming ones, changing a source type and
re-applying crashes:

TypeError: Comparisons should only involve FileSource class objects.

Minimal repro:

from feast import FileSource
from feast.infra.offline_stores.snowflake_source import SnowflakeSource
a = FileSource(name="x", path="/tmp/x.parquet", timestamp_field="ts")
b = SnowflakeSource(name="x", database="D", schema="S", table="T", timestamp_field="ts")
a == b   # TypeError — should be False

Root cause: the affected __eq__ methods do
if not isinstance(other, X): raise TypeError("Comparisons should only involve X class objects.").
Python's data model requires __eq__ to return NotImplemented for an unrecognized operand (so
the interpreter can try the reflected op and fall back to identity → False), never raise.

This is systemic — the pattern appears in ~35 __eq__ methods across the object model:
DataSource and its Kafka/Request/Kinesis subclasses; all offline sources (file,
snowflake, bigquery, redshift, and the ray/couchbase/trino/oracle/athena/mssql/
postgres contrib sources); plus Entity, FeatureView, BaseFeatureView, OnDemandFeatureView,
StreamFeatureView, FeatureService, SavedDataset, Project, ProjectMetadata, the four
transformation/* classes, Aggregation, LabelView, Permission, and the RoleBasedPolicy /
GroupBasedPolicy / NamespaceBasedPolicy / CombinedGroupNamespacePolicy policies.
PushSource.__eq__ already does the right thing (return False), so the correct pattern is
already in-tree.

Steps to reproduce

Run the snippet above, or: define a feature view on a FileSource and feast apply; change that
feature view's source to a SnowflakeSource (same name) and feast apply again → crash.

Specifications

  • Version: 0.64.0 and 0.65.0 / master (verified; pattern unchanged)
  • Subsystem: core object model (sdk/python/feast)

Possible Solution

Replace each raise TypeError("Comparisons should only involve …") in these __eq__ methods with
return False, matching PushSource.__eq__, which already handles a cross-type comparison this
way. PushSource is the one __eq__ that does this correctly today, and there is no
return NotImplemented anywhere in the codebase, so return False keeps a single consistent
convention rather than introducing a new one. (NotImplemented would be the stricter data-model
answer and would also let a reflected/matcher __eq__ participate, but the codebase already
forgoes that everywhere.)

Add a unit test asserting cross-type equality returns False (not a raise). This can be one sweep
across all 35 sites (uniform and mechanical) or scoped to the DataSource hierarchy (where the
crash reproduces) with a follow-up for the rest — happy to do whichever the maintainers prefer.
PR incoming.

Reacted by Shumin Z

Activity

  1. ShumzZzZz commented on Jul 28, 2026

    @ShumzZzZz
    ShumzZzZz
    on Jul 28, 2026
    Contributor
    More actions

    Good finding, hope your PR gets merged soon. I ran into the same issue when trying to update the data source from FileSource to SparkSource for the same FeatureView.

    Reacted by Larry Singleton
  2. larrysingleton007
    added a commit that references this issue on Jul 28, 2026

    fix: Guard SparkSource, Feature, and data format __eq__ against cross…

    7e226c4
  3. larrysingleton007 commented on Jul 28, 2026

    @larrysingleton007
    larrysingleton007
    on Jul 28, 2026
    ContributorAuthor
    More actions

    @ShumzZzZz thanks for confirming. Your exact case (FileSource swapped to SparkSource on the same FeatureView) turned out to only be half covered, SparkSource compared in the other direction still blew up with an AttributeError. Just pushed a guard for that to the PR along with a test reproducing your scenario, so both directions now compare False.

    Reacted by Shumin Z
  4. larrysingleton007 commented on Jul 28, 2026

    @larrysingleton007
    larrysingleton007
    on Jul 28, 2026
    ContributorAuthor
    More actions

    @ntkathole @franciscojavierarceo @jyejare @aniketpalu pinging here as well since a second user has now hit this (see the comment above, swapping a FeatureView source from FileSource to SparkSource). The fix is ready in #6637 with green checks and covers that scenario too, it just needs a reviewer.

  5. ntkathole
    added 3 commits that reference this issue on Jul 29, 2026

    fix: Guard SparkSource, Feature, and data format __eq__ against cross…

    1af5c88

    fix: Guard SparkSource, Feature, and data format __eq__ against cross…

    d2fc30b

    fix: Return False from __eq__ on cross-type comparison (#6637)

    0f149a9
  6. ntkathole
    closed this as completedin #6637on Jul 30, 2026
  7. franciscojavierarceo
    added a commit that references this issue on Aug 21, 2026

    chore(release): release 0.66.0

    1d5be95
  8. Michie-hub
    added a commit that references this issue on Aug 31, 2026

    chore(release): release 0.66.0

    a29c923
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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.