Before abc was introduced you would see this frequently.
class Base(object):
def go(self):
raise NotImplementedError("Please Implement this method")
class Specialized(Base):
def go(self):
print "Consider me implemented"
Answer from kevpie on Stack OverflowBefore abc was introduced you would see this frequently.
class Base(object):
def go(self):
raise NotImplementedError("Please Implement this method")
class Specialized(Base):
def go(self):
print "Consider me implemented"
Something along these lines, using ABC
import abc
class Shape(object):
__metaclass__ = abc.ABCMeta
@abc.abstractmethod
def method_to_implement(self, input):
"""Method documentation"""
return
Also read this good tutorial: https://pymotw.com/3/abc/
You can also check out zope.interface which was used prior to introduction of ABC in python.
- http://pypi.python.org/pypi/zope.interface
- https://zopeinterface.readthedocs.io/en/latest/README.html
Videos
Hello. In this first example, I have a short and straightforward code w/ a class for interface. It doesn't inherit from ABC and doesn't have any abstract methods.
class Abs():
def __init__(self, name, age):
self.name = name
self.age = age
def go_to(self):
return f"{self.name} is going to {self.place}."
class Teacher(Abs):
place = "work"
class Student(Abs):
place = "school"
t1 = Teacher("James", 56)
s1 = Student("Tim", 15)
print(t1.go_to())
print(s1.go_to())In this second example, it's the exact opposite.
from abc import ABC, abstractmethod
class Abs(ABC):
def __init__(self, name, age):
self.name = name
self.age = age
@abstractmethod
def go_to(self):
...
class Teacher(Abs):
place = "work"
def go_to(self):
return f"{self.name} is going to {self.place}."
class Student(Abs):
place = "school"
def go_to(self):
return f"{self.name} is going to {self.place}."
t1 = Teacher("James", 56)
s1 = Student("Tim", 15)
print(t1.go_to())
print(s1.go_to())Both examples have the same output. In the tutorials/articles I've read, most times the second example is preferred. In the abstract class, abstract methods get defined and decorated, and then in the inheriting classes they all get redefined with the rest of the logic. What's the point of creating a class w/ abstract methods which later on we redefine? What issue does that solve? Why not just proceed as in the first example - simple, less code, one parent class for the interface, if we need to add other details, we do so in the base class once and handle the extra logic with that additional info there. Doesn't the first code present a better example of loose coupling - just one connection between parent and child classes, where in the second code, we get connections between parent/child in every method that we redefine? I feel like I'm missing something, because to me, the second example is much more spaghetti-like. If anyone can explain why it's a good practice to redefine abstract methods that would be nice. Also, is it a bad practice to write code as in the first example, w/o ABC+@abstractmethod in the parent class?
Thanks.