SubType and SubInstance

[sirkonst]

Hi,

I trying check with mypy following code:

import abc
from typing import Type

class Base(abc.ABC):
    @abc.abstractmethod
    def foo(self) -> None:
        pass

class Foo(Base):
    def foo(self):
        pass

def make_obj(cls: Type[Base]) -> Base:
    inst = cls()  # line 15
    return inst

make_obj(Foo)

And got errors:

subtype.py: note: In function "make_obj":
subtype.py:15: error: Cannot instantiate abstract class 'Base' with abstract attribute 'foo'

I want have some expression for define that variable type is one of subclasses of Base but not Base, somethink like this:

def make_obj(cls: SubType[Base]) -> SubInstance[Base]:
    inst = cls()
    return inst

Is it possible now?

[sirkonst]

I guess I found solution:

import abc
from typing import Type, TypeVar


class BaseABC(abc.ABC):
    @abc.abstractmethod
    def foo(self) -> None:
        pass

class Foo(BaseABC):
    def foo(self):
        pass

Base = TypeVar('Base', bound=BaseABC)
def make_obj(cls: Type[Base]) -> Base:
    inst = cls()
    return inst


make_obj(Foo)

But maybe open new bugs:

def make_obj_2(cls: Type[Base]=Foo) -> Base:  # -- line 23
    inst = cls()
    return inst

class Bar:
    foo = None  # type: Base                    -- line 29

subtype.py: note: In function "make_obj_2":
subtype.py:23: error: Incompatible types in assignment (expression has type "Foo", variable has type Type[Base])
subtype.py: note: At top level:
subtype.py:29: error: Invalid type "subtype.Base"

[refi64]

What if you do:

T = TypeVar('T', bound=Base)
def make_obj(cls: Type[T]) -> T:
    inst = cls()  # line 15
    return inst

[gvanrossum]

IIRC we have another bug for this issue already. IMO mypy should not forbid construction of an abstract class if the class is an argument declared using Type[] -- it should assume you are passing it a concrete class. But maybe we need a check that you call this thing with a concrete subclass; and for that we would need some additional notation (unless maybe we could just say that whenever there's an argument of Type[A] where A is abstract, that the argument must be a concrete subclass. But for that we'd need some experiment to see if there's much real-world code that passes abstract classes around. (If there is, we'd need to have a way to indicate the need in the signature.)

[aomader]

I just stumbled upon this while implementing a generic parser over concrete types of an abstract base class. So, there is an actual real-world use case for this.

Basically, the following should type check flawlessly in my opinion:

import abc
import typing

class Base(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def foo(self) -> None:
        raise NotImplementedError

def Concrete(Base):
    def foo(self) -> None:
        print('bar')

def create(cls: typing.Type[Base]) -> Base:
    return cls()

[gvanrossum]

Agreed.

--Guido (mobile)

On Sep 23, 2016 7:58 AM, "Oliver Mader" notifications@github.com wrote:

I just stumbled upon this while implementing a generic parser over
concrete types of an abstract base class. So, there is an actual real-world
use case for this.

Basically, the following should type check flawlessly in my opinion:

import abcimport typing
class Base(metaclass=abc.ABCMeta):
@abc.abstractmethod
def foo(self) -> None:
raise NotImplementedError
def Concrete(Base):
def foo(self) -> None:
print('bar')
def create(cls: typing.Type[Base]) -> Base:
return cls()

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2169 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACwrMhr2uLWSKd3aTMMKsVczdEiCWsaZks5qs-kegaJpZM4KDmd3
.

[elazarg]

I don't understand why should it typecheck. It looks unsafe to me.

[gvanrossum]

@elazarg Mypy doesn't need to flag everything that looks unsafe. It must be a useful tool, and some code that is theoretically unsafe is both common and useful in practice and the unsafe scenario never occurs, so complaining about it is unhelpful. In general there is no single concrete subclass of an ABC like Base in the example, so there is no easy way to state "any concrete subclass of Base".

I would much rather have an occasional unsafe piece of code pass without error (a false negative) than require users to add extra markup to code that is almost always fine in practice (a false positive), if the annoyance of false positives outweighs the cost of false negatives. This is one of those cases. This is a different philosophy from most typed languages, and it is Python's runtime type checking that gives us this luxury.

[elazarg]

I am not sure that in practice unsafe scenarios never occur. It is not unlikely to forget adding an override to a new abstract method, and this is the place where it can be caught.

I understand the reasoning however: it is unsafe, but not yet possible to express in a useful way, so we err towards flexibility, avoiding false positives. Fair enough.

(The reason I say "yet" relates to my pending proposal in python-ideas. An easy and clear way to write it would be

def create(cls: typing.Type[Base] and cls(...) ) -> Base:
    return cls()

It is easily understood but unfortunately not reasonable to use as things currently stand)

[gvanrossum]

This is a dup of #1843.