Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Equality and truthiness of string#elems #285

Open
fmeum opened this issue Sep 25, 2024 · 1 comment
Open

Equality and truthiness of string#elems #285

fmeum opened this issue Sep 25, 2024 · 1 comment

Comments

@fmeum
Copy link
Contributor

fmeum commented Sep 25, 2024

The spec isn't clear on how equality and truthiness should behave for the value returned by string#elems (and similar Sequences).

The available implementations differ:

  • Java
>> bool("".elems())
False
>> "foo".elems() == "foo".elems()
True
  • Go
>>> bool("".elems())
True
>>> "foo".elems() == "foo".elems()
True
  • Rust
$> bool("".elems())
True
$> "foo".elems() == "foo".elems()
False

In Python, custom iterables (such as generator expressions) are often truthy regardless of whether they are non-empty and non-identical generator objects are distinct even if they yield the same elements (ignoring e.g. range, which is specced to determine equality as sequences), which matches the behavior of the Rust implementation.

@adonovan @stepancheg @brandjon What are your thoughts on this?

Edit: Noticed that Python generator expressions are always truthy, not just when non-empty.

@adonovan
Copy link
Contributor

adonovan commented Sep 25, 2024

The spec should probably take a position one way or another. I think making iterators non-equal even if their sequences are equal is probably the prudent course; even if in the string case it's easy either way, for other iterators, determining that they generate equal elements may not be a cheap computation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants