Open dmcooke opened 7 years ago
Why are you using the __class__
cell? While it is indeed documented, it's really just meant as a hack so that argument-less super()
can find the current class; other use cases are pretty esoteric IMO. Unless you have a particularly bad habit of frequently renaming your classes you're better off just naming the class explicitly (always assuming that self.__class__
doesn't do it for you).
I prefer it to using the name, as __class__
is determined by the lexical scope, whereas by name is by the dynamic scope. I am probably overusing it, but it does give a measure of safety with regards to renaming or assigning something else to the class name (such as the somewhat common practice of making singletons by Foo = Foo()
).
Regardless, still a bug (either in mypy, or the Python documentation).
There are two items here:
__class__
is undefined.isinstance(x, __class__)
.whereas by name is by the dynamic scope
Not sure what you mean by "dynamic scope" here -- certainly the call site doesn't enter into it.
Anyway, this is a low priority feature request. (I count the mere presence of __class__
a feature request -- adding it to typeshed isn't enough since it is only defined inside a class.
Are there any news on that?
Doesn't look like it! If you care about this issue, feel free to submit a PR; it's unlikely to be picked up by a core team member any time soon.
Consider the following (Python 3, of course)
mypy gives the following error:
It should assume
__class__
to beFoo
(as per the language documentation).I usually work around this by adding
at the top of files that use
__class__
, but that's not ideal.