Skip to content

Conversation

@JukkaL
Copy link
Collaborator

@JukkaL JukkaL commented Aug 28, 2020

Fixes #8768.

@JukkaL JukkaL merged commit ace084f into master Aug 28, 2020
@JukkaL JukkaL deleted the none-hashable branch August 28, 2020 17:14
@erictraut
Copy link

We received a similar feature request for pyright. I considered doing a spot fix specifically for __hash__, but this struck me as a bit hacky and not very generalizable, since there are other valid protocols that could also apply to None.

I thought of another approach that might work better. Could we define a NoneType in typing.pyi that defines the methods supported by None? Type checkers could then use this class definition when doing protocol validation. Interested in your thoughts.

If you're open to that approach, I'd be happy to submit a PR to typeshed that defines NoneType.

JukkaL added a commit that referenced this pull request Sep 7, 2020
@erictraut
Copy link

@JukkaL do you have any thoughts on my proposal above?

@JukkaL
Copy link
Collaborator Author

JukkaL commented Sep 9, 2020

It sounds reasonable, since the type of None is not available in the builtins or types in Python 3. I don't see a use case for making it available at runtime, however. It was removed from types in Python 3 (types.NoneType exists in Python 2.7), and I'd assume this happened for a reason. So maybe we should be name it _NoneType to make it more clear that it's an internal definition that's only supposed to be used by tools?

@erictraut
Copy link

Thanks, naming it _NoneType is a great suggestion. I'll submit a PR to typeshed.

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

Successfully merging this pull request may close these issues.

None is not considered Hashable

4 participants