Pretty good!

Overall you have reasonable types, especially Array (though that should only be declared once). But your use of kwargs and setattr interferes with that type safety. There are type-safe ways around this: one way would be for Rational to be a @dataclass, and for its super to call into fields() or asdict(). Or without dataclasses, maybe __dict__ would work (so long as Rational stores offset, enumerator and denominator as members from its own constructor).

Though it's unlikely for eval to collide with the built-in eval, it's enough to confuse some syntax highlighters etc. Probably best to rename this.

This:

    powers_of_x = [x**i for i in range(len(self.enumerator))]

can be vectorised as

    powers_of_x = x ** np.arange(len(self.enumerator))

The __main__ guard is not enough to exclude P, etc. from the global namespace. That code should be moved to a main function.

Don't assert in production code; raise an exception instead.

It's worse than you think. Abstract methods are tracked by name only, so you don't even have to make quack a method in order to instantiate the child class.

class SurrealDuck(Quacker):
    quack = 3

d = SurrealDuck()
print d.quack   # Shows 3

There is nothing in the system that enforces that quack is even a callable object, let alone one whose arguments match the abstract method's original. At best, you could subclass ABCMeta and add code yourself to compare type signatures in the child to the originals in the parent, but this would be nontrivial to implement.

(Currently, marking something as "abstract" essentially just adds the name to a frozen set attribute in the parent (Quacker.__abstractmethods__). Making a class instantiable is as simple as setting this attribute to an empty iterable, which is useful for testing.)

What you're trying to do will just work—but it's a very bad idea.

In general, you don't want to change the signature of a method in incompatible ways when overriding. That's part of the Liskov Substitution Principle.

In Python, there are often good reasons to violate that—inheritance isn't always about subtyping.

But when you're using ABCs to define an interface, that's explicitly about subtyping. That's the sole purpose of ABC subclasses and abstractmethod decorators, so using them to mean anything else is at best highly misleading.

In more detail:

By inheriting from Agent, you are declaring that any instance of Clever_Agent can be used as if it were an Agent. That includes being able to call my_clever_agent.perceive_world(my_observation). In fact, it doesn't just include that; that's the entirely of what it means! If that call will always fail, then no Clever_Agent is an Agent, so it shouldn't claim to be.

In some languages, you occasionally need to fake your way around interface checking, so you can later type-switch and/or "dynamic-cast" back to the actual type. But in Python, that's never necessary. There's no such thing as "a list of Agents", just a list of anything-at-alls. (Unless you're using optional static type checking—but in that case, if you need to get around the static type checking, don't declare a static type just to give yourself a hurdle to get around.)

In Python, you can extend a method beyond its superclass method by adding optional parameters, and that's perfectly valid, because it's still compatible with the explicitly-declared type. For example, this would be a perfectly reasonable thing to do:

class Clever_Agent(Agent):
    def perceive_world(self, observation, prediction=None):
        print('I see %s' % observation)
        if prediction is None:
            print('I have no predictions about what will happen next')
        else:
            print('I think I am going to see %s happen next' % prediction)

Or even this might be reasonable:

class Agent(ABC):
    @abstractmethod
    def perceive_world(self, observation, prediction):
        pass

class Dumb_agent(Agent):
    def perceive_world(self, observation, prediction=None):
        print('I see %s' % observation)
        if prediction is not None:
            print('I am too dumb to make a prediction, but I tried anyway')

class Clever_Agent(Agent):
    def perceive_world(self, observation, prediction):
        print('I see %s' % observation)
        print('I think I am going to see %s happen next' % prediction)

No checks are done on how many arguments concrete implementations take. So there is nothing stopping your from doing this already.

Just define those methods to take whatever parameters you need to accept:

class View(metaclass=ABCMeta):
    @abstractmethod
    def set(self):
        pass

    @abstractmethod
    def get(self):
        pass


class ConcreteView1(View):
    def set(self, param1):
        # implemenation

    def get(self, param1, param2):
        # implemenation


class ConcreteView2(View):
    def set(self):
        # implemenation

    def get(self, param1, param2):
        # implemenation

Other tools, such as linters, are a different matter. They could (rightly) claim that the above code violates the Livkov Substitution Principle, because you the subclasses and parent class take different arguments. But it is not Python itself that then tells you about this.

In the end, I settled on providing the following:

class BaseAsyncSocketHandler:

    async def _send(self, data: bytes) -> int:
        ...

    @abc.abstractmethod
    async def send(self, *args, **kwargs) -> int:
        pass

This way the user can implement subsets of the send method while using the base send method provided by the socket wrapper. As to why I wanted to use send instead of just creating another class method like send_event, I think I mostly just wanted the interface to the class to remain compact and usable while allowing for different socket methodologies.

Giving an override a more restrictive signature violates the Liskov Substitution Principle. But that's not what you should be doing here.

Your code should actually look like this:

from abc import ABC, abstractmethod

class Manager(ABC):
    @abstractmethod
    def connect(self) -> Handle:
        raise NotImplementedError()

class DefaultManager(Manager):
    def connect(self, *, thread_safe: bool = False) -> Handle:
        if thread_safe:
            return ThreadSafeHandle()
        else:
            return DefaultHandle()

(I'm assuming you've got something appropriate to annotate the return types with.)

Manager.connect's signature should reflect the kinds of calls that all subclass connect implementations should accept. It should be the intersection of all valid subclass signatures, not the union.

The signature specified by Manager.connect reflects what Manager promises all Manager instances can do. It promises that they can accept a connect call with 0 arguments. It doesn't promise anything about what they can't do. This Manager.connect signature doesn't accept a thread_safe argument, but that doesn't mean it promises subclasses won't accept that argument.