Closed pylint-bot closed 8 years ago
pylint-bot
commented
8 years ago Original comment by Florian Bruhin (BitBucket: The-Compiler, GitHub: @The-Compiler?):
FWIW, in PEP 484 (type hints), the somewhat similar thing is called "Any". I don't like InferenceFailure personally, it sounds too much like an exception...
Maybe Uninferred or Uninferrable or Something/Object/Thing?
pylint-bot
commented
8 years ago Original comment by Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore?):
How about Anything?
pylint-bot
commented
8 years ago Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?):
Any or Anything sound good
pylint-bot
commented
8 years ago Original comment by BitBucket: ceridwenv, GitHub: @ceridwen?:
Keep in mind that typing.Any represents a type, not a value, while inference returns, in general, values, as I understand it. This difference isn't always as well-defined in Python's type system as in others, because for instance classes, which are themselves types, are instances/values of metaclasses, but I think it's worth trying to keep this concept distinct from typing.Any. I'd prefer Undefined, Unknown, or Uninferrable.
pylint-bot
commented
8 years ago pylint-bot
commented
8 years ago Original comment by Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore?):
I also think that it should not be named Any, since it will definitely cause confusion. From the other alternatives, I prefer Anything or Unknown / Uninferrable. I don't like Undefined because it's not clear what's undefined, the result of the inference or something in the inference chain. Uninferrable suggests that something can't be inferred and has a negative conotation, whilst Anything suggests the same (to me at least) but has a positive connotation (in the sense that the inference engine can say that Anything can happen when inferring this node).
So either Uninferrable or Anything, your pick, @ceridwenv :-)
pylint-bot
commented
8 years ago Original comment by BitBucket: ceridwenv, GitHub: @ceridwen?:
I was thinking further about typing in connection with this. Type inference is really a form of a theorem prover about a program, proving either that the type of a return value is some type or that the types aren't consistent in the first place. The Any type in the typing stdlib module is what's called a https://en.wikipedia.org/wiki/Top_type , a type that's a supertype of all other types. However, I don't see how to provide inference results with relations like, "is a subtype of" or "is a supertype of," so I think that conceptually astroid inference results are different from types. Thus, my vote goes for Uninferable. (Note: I think the spelling "inferable" is more standard, so I think we should spell it thus: http://www.merriam-webster.com/thesaurus/inferable .)
pylint-bot
commented
8 years ago Original comment by Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore?):
Yes, we're more interested into what happens rather than what types are involved. I'm perfectly happy with Uninferable. The fix must leave YES as an alternative name to Uninferable, but it could mark it as deprecated. We'll remove YES in a couple of releases afterwards.
pylint-bot
commented
8 years ago
Originally reported by: BitBucket: ceridwenv, GitHub: @ceridwen?
The YES object represents some kind of indication that astroid's inference has failed, but the name gives no indication of this. Since we already have an InferenceError, maybe InferenceFailure or some such?