[issue38769] generators are currently hashable

Steven D'Aprano added the comment: I can see that making generators unhashable would have found your bug earlier, but it is otherwise unjustified: generators are just objects that are compared by identity. It would break other people's code, which is a very invasive change to make just so

[issue38769] generators are currently hashable

Tim Peters added the comment: Yes, what Steven said. All kinds of functions (including, but not limited to, generator-iterators) are compared by object identity, nothing at all about internal state. The contract of hash() is that if a == b, then we must have that hash(a) == hash(b) too.

[issue38769] generators are currently hashable

Ammar Askar added the comment: An easier way to understand might be to just write out the generator expression "manually": def generator_expression(): for k, v in sorted(self.__dict__.items()): yield k return hash(my_generator_expression()) Would you say that

[issue38769] generators are currently hashable

Steven D'Aprano added the comment: Anthony, can you please explain what you mean when you describe generators as "mutable"? I don't understand what you mean. To *me*, the value of a generator, in so far as comparisons goes, is its identity, not its invisible internal state. You can test

[issue38769] generators are currently hashable

Anthony Sottile added the comment: I think I'm missing what you're saying, apologies I'm probably confused :( -- ___ Python tracker ___

[issue38769] generators are currently hashable

Tim Peters added the comment: What makes you think generator-iterator objects are mutable? -- ___ Python tracker ___ ___

[issue38769] generators are currently hashable

Anthony Sottile added the comment: function objects are immutable though -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38769] generators are currently hashable

Tim Peters added the comment: Function objects can be used as dict keys too. Given that, it would be _very_ surprising if generator-iterators weren't. I don't really see a good point to leaving this open. Live with it - it's a feature ;-) -- nosy: +tim.peters

[issue38769] generators are currently hashable

Serhiy Storchaka added the comment: I agree with Raymond. By default all objects are compared by identity and are hashable. User classes are hashable, files are hashable, iterators are hashable. Generator objects are just not special enough to be non-hashable. We can reconsider this. But it

[issue38769] generators are currently hashable

Raymond Hettinger added the comment: > there are other such mutable objects in python which do define > __hash__ = None such as list and dict Those objects compare on their contents, not on object identity. Take a look at how hashing works in dataclasses. You can have a mix of mutable and

[issue38769] generators are currently hashable

Anthony Sottile added the comment: :shrugs: it did go through a round of code review but was simply missed -- the testing bit is fair there are other such mutable objects in python which do define __hash__ = None such as list and dict -- ___

[issue38769] generators are currently hashable

Raymond Hettinger added the comment: > the author had forgotten the `tuple(...)` call (or incorrectly > assumed a parenthesized generator was a tuple comprehension) Presumably that will bite the author in many ways, not just hashability. There are many other places where substituting a

[issue38769] generators are currently hashable

Change by Ammar Askar : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38769] generators are currently hashable

New submission from Anthony Sottile : We recently found a bug in one of our codebases that looked ~roughly like this: class C: ... def __hash__(self): return hash((v for k, v in sorted(self.__dict__.items( which resulted in a production bug The *intention* was to hash a