Challenge 1: Enforced Payment Interface — Possible Solution
====================================================================

from abc import ABC, abstractmethod

class PaymentMethod(ABC):
    @abstractmethod
    def process(self, amount):
        pass

class CreditCard(PaymentMethod):
    def process(self, amount):
        return f"Charged ${amount} to credit card"

print(CreditCard().process(50))

try:
    PaymentMethod()
except TypeError as e:
    print(f"Error: {e}")

Output:
Charged $50 to credit card
Error: Can't instantiate abstract class PaymentMethod with abstract method process

WHY THIS WORKS AS AN ANSWER
------------------------------
class PaymentMethod(ABC): with @abstractmethod above process(self,
amount): reuses this chapter's own Shape/area() example exactly — a
class inheriting from ABC, declaring a method with no real body
(pass) other than the contract itself.

class CreditCard(PaymentMethod): mirrors the chapter's own
Square(Shape) subclass — it provides a real, working process() method,
satisfying the contract PaymentMethod declared. Because CreditCard
actually implements every abstract method it inherited, CreditCard()
can be instantiated and process(50) runs normally, printing the
confirmation string.

PaymentMethod() reuses the chapter's own Shape() example directly —
attempting to instantiate the abstract base class itself, which still
has an unimplemented abstract method (process), raises a TypeError
immediately. Wrapping it in try/except TypeError as e: (from Course 2,
Chapter 3) catches that error and prints its message, proving the
enforcement is real rather than just theoretical — Python actively
blocks creating a PaymentMethod instance, it doesn't just document
that you shouldn't.