IDEA: inheriting from 'Any' should create a new 'Any' type

[gvanrossum]

Currently, in mypy, class M(Any): is an error, because Any is not an actual class. (Note that this is different from class M(A): where A has type Any. I'm talking about explicitly inheriting from Any only here.)

In mypy, if we ignore the error, we obtain a class that is a subclass of all other classes. (At runtime it still fails, but in a stub file this will work.) Example:

class M(Any):  # type: ignore
    pass
class A: pass
def foo(a: A): pass
foo(M())  # No error

However, M does not have the other important property of Any, that it is a superclass of all other classes. If we add the following to the above example, we get an error:

def bar(a: M): pass
bar(A())  # error: Argument 1 to "bar" has incompatible type "A"; expected "M"

As a feature, it might be nice to allow explicitly subclassing Any and make the resulting class behave more like Any, so that the bar(A()) call above actually works.

Why would this be useful? Why not just make M an object with type Any? Because we can still endow M with specific methods, which will be type-checked as usual:

class M(Any):  # type: ignore
    def m(self) -> None: pass
M().m()  # OK
M().m(12)  # error: Too many arguments for "m" of "M"

If M were just an object with type Any, we wouldn't get that error.

Real-world use case: Mock; see the thread started at python/typeshed#2173 (comment).

[srittau]

In our internal test code we are often using "fakes" (a bit like mocks, only with canned values and behaviour and no dynamic behaviour) in place of real domain objects that are difficult to set up:

# Implementation:
class Foo:  # domain class with side effects
    ...

def do_interesting_stuff(foo: Foo): ...

# Test
class FakeFoo:  # simple class
    ...

foo = FakeFoo()
do_interesting_stuff(cast(Foo, foo))

If I understand the proposal correctly, this would allow us to instead derive FakeFoo from Any and do away with the cast? This would be helpful.

[gvanrossum]

Yes, but by inheriting from Any with a type ignore comment will accomplish the same thing.

…

On Fri, Jun 22, 2018, 13:51 Sebastian Rittau ***@***.***> wrote: In our internal test code we are often using "fakes" (a bit like mocks, only with canned values and behaviour and no dynamic behaviour) in place of real domain objects that are difficult to set up: # Implementation:class Foo: # domain class with side effects ... def do_interesting_stuff(foo: Foo): ... # Testclass FakeFoo: # simple class ... foo = FakeFoo() do_interesting_stuff(cast(Foo, foo)) If I understand the proposal correctly, this would allow us to instead derive FakeFoo from Any and do away with the cast? This would be helpful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#567 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACwrMkaN5wq5Pi6hCGrPYXJIIq45Mce9ks5t_VjPgaJpZM4U0Y8o> .

[ilevkivskyi]

I like this idea. We can preserve the current behaviour for unimported bases etc., while have the both-ways-Any for an explicit Any base. Also I actually think it is OK this fails at runtime, we can just reserve this feature for stubs (it is only useful for highly magic classes, that are anyway hard to annotate inline).

@JukkaL what do you think?

[JukkaL]

I'm not sure if this is important enough for the extra complexity to work on at least in the near term. This would add a new kind of type, and from experience we know that these sorts of changes tend to result in all kinds of unanticipated corner cases that may take a lot of work to get right, even for supposedly simple features. They also complicate the internals of all type checking tools, all/most of which are still lagging behind PEP 484 in supported features (including mypy).

For non-stub code, the fact that the Any base class would fail at runtime makes this pretty hard to use, and the current way of using casts may not be significantly worse.

[ilevkivskyi]

This would add a new kind of type

On one hand this may be just Any, but with an attribute like fallback_instance, which will be used only by checkmember. But on other hand I agree we have more important things to do.

[Kentzo]

What is a particular use case when this is useful?

[srittau]

Is this still relevant? In typeshed we derive NonCallableMock from Any and it seems to work fine.

[emmatyping]

As nice as this would be, I fear it may break too much code. I think this is definitely something that should be experimented on in a type checker first.