metaprogramming — descriptor, __init_subclass__ আর metaclass

১ · মূল ভাবনা — যে কোড অন্য কোডকে গড়ে

এ পর্যন্ত আপনি যে কোড লিখেছেন, তার কাজ ছিল ডেটা নিয়ে কাজ করা: দাম যোগ করা, ফাইল পড়া, list সাজানো। এবার একটি ভিন্ন প্রশ্ন। ধরুন একটি অনলাইন দোকানের সফটওয়্যারে চল্লিশটি class আছে, আর প্রতিটির দাম ধনাত্মক হতে হবে, স্টক ঋণাত্মক হতে পারবে না, মোবাইল নম্বর ১১ অঙ্কের হতে হবে। প্রতিটি class-এ একই যাচাই আলাদা করে লিখবেন? নাকি এমন কোড লিখবেন, যা অন্য class-গুলোকে গড়ে দেয় — নিয়ম একবার লিখে সব class-এ বসিয়ে দেয়?

দ্বিতীয় পথটির নাম metaprogramming: এমন কোড, যার কাজের বস্তু ডেটা নয়, বরং অন্য কোড — class, ফাংশন, attribute. পর্ব ৩৭-এর decorator ছিল এর প্রথম স্বাদ: একটি ফাংশন, যা আরেকটি ফাংশনকে বদলে দেয়। এই পর্বে আমরা আরও গভীরে যাব — class-এর জন্ম আর attribute পড়া-লেখার একেবারে ভেতরে।

ভিত্তি: class-ও একটি object

পর্ব ০৫-এ শিখেছেন, Python-এ সবকিছুই object. পর্ব ৩৪-এ দেখেছেন, class-ও এর বাইরে নয়: type(450) হলো int, আর type(int) হলো type. আপনার নিজের Product class-এর ক্ষেত্রেও type(Product) হলো type. অর্থাৎ type হলো সেই class, যার object-গুলো নিজেরাই class — একে বলে metaclass. আর type(type)? সেটিও type — শৃঙ্খলটি এখানে নিজের গায়ে এসে থামে।

এর একটি চমকপ্রদ ফল: class বাক্যটি আসলে type-কে ডাকার একটি সুন্দর লেখা। নিচের দুটি অংশ একই class বানায়:

# সাধারণ class বাক্য দিয়ে
class Bkash:
    fee = 1.85
    def charge(self, amount):
        return amount * self.fee / 100

# একই জিনিস, type() ডেকে — চলার সময়
def charge(self, amount):
    return amount * self.fee / 100

Bkash = type("Bkash", (object,), {"fee": 1.85, "charge": charge})
print(type(Bkash), Bkash().charge(1000))   # <class 'type'> 18.5

type-কে তিনটি argument দিলে সে নতুন class বানায়: নাম, parent class-গুলোর tuple, আর class-এর ভেতরের নাম ও মানের একটি dict — যাকে বলে class-এর namespace. বাস্তবে এভাবে class খুব কমই লেখা হয়, কিন্তু এটি জানলে একটি সত্য স্পষ্ট হয়: class তৈরি হয় প্রোগ্রাম চলার সময়, একটি সাধারণ ফাংশন-ডাকের মতো. আর যে প্রক্রিয়া চলার সময় ঘটে, তাতে নিজের কোড ঢোকানো যায়।

তিনটি জায়গায় হাত দেওয়া যায়

এগুলো কোনো তাত্ত্বিক খেলনা নয়। পর্ব ৩৪-এর @dataclass, পর্ব ৫১-এর FastAPI যে Pydantic-এর ওপর দাঁড়িয়ে, পর্ব ৫২-এর SQLAlchemy, আর Django-র model — এদের প্রত্যেকটি এই তিন হাতিয়ার দিয়েই বানানো। আপনি যখন class Customer(Model): name = Column(String) লেখেন, তখন পেছনে ঠিক এই পর্বের কৌশলগুলো চলে।

২ · obj.x লিখলে আসলে কী ঘটে — attribute খোঁজার পথ

পর্ব ৩৪-এ attribute খোঁজার ক্রমটি এক নজরে দেখেছেন। এখানে আমরা সেটিকে যন্ত্রের মতো খুলে দেখব, কারণ এই পর্বের প্রতিটি কৌশল এর ওপর দাঁড়িয়ে। মূল কথা: p.price লেখা একটি সরাসরি dict-খোঁজা নয়। Python আসলে ডাকে type(p).__getattribute__(p, "price") — আর সাধারণ object-এর __getattribute__ একটি নির্দিষ্ট নিয়ম মেনে চলে।

নিয়মটির কেন্দ্রে দুই রকম descriptor (পর্ব ৩৪): যার __set__ বা __delete__ আছে, সে data descriptor; যার শুধু __get__ আছে, সে non-data descriptor. খোঁজা শুরু হয় instance-এ নয়, class আর তার পূর্বপুরুষদের (MRO ক্রমে) দিয়ে — কারণ সেখানে data descriptor থাকলে সে-ই জিতবে। নিচের stepper-এ একটি class-এর চারটি নাম পড়া আর একটি নাম লেখা ধাপে ধাপে দেখুন:

1class Product:2    price = Field(...)     # data descriptor3    shop = "করিম স্টোর"     # সাধারণ মান4    def label(self): ...   # ফাংশন5    def __getattr__(self, name):6        return f"{name}?"78p = Product(450, 12, "01712345678")9p.shop = "রহিম স্টোর"     # instance-এর ঘরে1011p.price12p.shop13Product.shop14p.label15p.colour16p.price = 0

__getattribute__ বনাম __getattr__ — নাম প্রায় এক, কাজ আলাদা

দুটি নাম প্রায়ই গুলিয়ে যায়, অথচ পার্থক্যটি বিশাল:

• __getattribute__ প্রতিটি পড়ায় চলে। উপরের পুরো খোঁজার নিয়মটিই object.__getattribute__-এর ভেতরে লেখা। একে বদলালে আপনি প্রতিটি attribute পড়ায় ঢুকে পড়বেন — এমনকি নিজের method আর self.__dict__ পড়াতেও। ভেতরে self.কিছু লিখলে সেটি আবার __getattribute__ ডাকে, আর অসীম পুনরাবৃত্তি হয়ে আসে RecursionError: maximum recursion depth exceeded. তাই ভেতরে সবসময় super().__getattribute__(name) ব্যবহার করতে হয়। বাস্তবে এটি প্রায় কখনো বদলানোর দরকার হয় না।
• __getattr__ শুধু ব্যর্থ হলে চলে। সাধারণ খোঁজা AttributeError-এ শেষ হলেই Python এটি ডাকে। তাই এটি নিরাপদ আর সস্তা: যে attribute পাওয়া যায়, তার গতিতে কোনো প্রভাব নেই।

__getattr__-এর সবচেয়ে প্রচলিত ব্যবহার হলো proxy object — যে object নিজের কাছে না থাকা সব অনুরোধ আরেকটি object-এর কাছে পাঠিয়ে দেয়। যেমন একটি হিসাবের “শুধু-পড়া” রূপ, যা রিপোর্টে দেখানো যাবে কিন্তু বদলানো যাবে না:

class ReadOnly:
    def __init__(self, target):
        object.__setattr__(self, "_target", target)   # নিজের __setattr__ এড়িয়ে

    def __getattr__(self, name):          # নিজের কাছে না পেলে তবেই
        return getattr(self._target, name)

    def __setattr__(self, name, value):   # প্রতিটি লেখা আটকানো
        raise AttributeError(f"{name}: শুধু পড়া যায়")

view = ReadOnly(account)
view.balance          # account.balance পড়ে দেয়
view.balance = 0      # AttributeError: balance: শুধু পড়া যায়

লক্ষ করুন, __init__-এ self._target = target লেখা যায়নি, কারণ সেটিও আমাদের __setattr__ আটকে দিত। তাই object.__setattr__ দিয়ে সরাসরি মূল ব্যবস্থাকে ডাকা হয়েছে। এই ধরনের ছোট ফাঁদই metaprogramming-এর বৈশিষ্ট্য — সাধারণ নিয়মগুলো নিজের কোডের ওপরেও খাটে।

৩ · descriptor protocol — একবার লিখুন, সব class-এ বসান

পর্ব ৩৪-এ PositiveNumber দেখেছেন — একটি নির্দিষ্ট নিয়মের descriptor. এবার নিয়মটিকেও বাইরে থেকে নেওয়া যাক, যাতে একটি Field class দিয়েই দাম, স্টক আর মোবাইল নম্বর — তিন রকম যাচাই হয়। আগে descriptor protocol-এর চারটি method এক জায়গায়:

শেষেরটি, __set_name__, সমস্যার একটি পুরোনো সমাধান। price = Field(...) লাইনে ডান দিকের Field(...) আগে তৈরি হয়, তারপর নামটি বসে — তাই descriptor নিজে জানে না সে কোন নামে আছে। Python 3.6-এর আগে নামটি দুবার লিখতে হতো (price = Field("price", ...)), নইলে একটি metaclass লাগত। এখন class তৈরির সময় Python নিজেই প্রতিটি attribute দেখে: তার __set_name__ আছে কি না — থাকলে ডেকে নাম জানিয়ে দেয়।

প্রথম runnable প্রোগ্রাম। Field একটি যাচাই-ফাংশন আর একটি বার্তা নেয়; বাকিটা descriptor protocol সামলায়। চালানোর আগে অনুমান করুন — শেষ লাইনে price কত থাকবে?

class Field:
    def __init__(self, check, msg):
        self.check, self.msg = check, msg
    def __set_name__(self, owner, name):       # class তৈরির সময় একবার
        self.name = name
    def __get__(self, obj, owner=None):
        return self if obj is None else obj.__dict__[self.name]
    def __set__(self, obj, value):             # প্রতিটি লেখায়
        if not self.check(value):
            raise ValueError(f"{self.name}={value!r}: {self.msg}")
        obj.__dict__[self.name] = value        # একই নামে instance-এর ঘরে

class Product:
    price = Field(lambda v: v > 0, "দাম ০-এর বেশি হতে হবে")
    stock = Field(lambda v: v >= 0, "স্টক ঋণাত্মক হতে পারে না")
    phone = Field(lambda v: len(v) == 11 and v[:2] == "01" and v.isdigit(),
                  "১১ অঙ্কের BD মোবাইল নম্বর নয়")
    def __init__(self, price, stock, phone):
        self.price, self.stock, self.phone = price, stock, phone

p = Product(450, 12, "01712345678")
for name, bad in [("price", 0), ("stock", -3), ("phone", "0171")]:
    try:
        setattr(p, name, bad)
    except ValueError as e:
        print(e)
print(vars(p), type(Product.price).__name__)

৪ · ফাংশন, property, classmethod — সবই descriptor

এখন মডিউল ৫-এর একটি পুরোনো রহস্যের সমাধান। পর্ব ৩১-এ শিখেছেন, p.label() ডাকলে self আপনাআপনি p হয়ে যায়। কে বসায়? কোনো বিশেষ নিয়ম নয় — ফাংশন object-এর নিজের __get__ method. Python-এর প্রতিটি সাধারণ ফাংশন একটি non-data descriptor. দেখুন ধাপে ধাপে:

f = Product.__dict__["label"]
type(f)                  # <class 'function'>
hasattr(f, "__get__")    # True  → descriptor
hasattr(f, "__set__")    # False → non-data

# p.__dict__-এ 'label' নেই, তাই:
f.__get__(p, Product)
# Product.label লিখলে obj নেই:
f.__get__(None, Product)  # → ফাংশনটি নিজেই

m = p.label
type(m).__name__         # 'method'
m.__func__ is f          # True — আসল ফাংশন
m.__self__ is p          # True — বাঁধা object

p.label()
# = m()
# = m.__func__(m.__self__)
# = Product.label(p)

@classmethod  → __get__ বাঁধে class-কে (cls)
@staticmethod → __get__ দেয় খালি ফাংশন
@property     → __get__ ডাকে getter-কে
# নিয়ম একটাই: __get__ যা ফেরত দেয়, সেটাই উত্তর

এক টেবিলে Python-এর তৈরি descriptor-গুলো — যাদের আপনি এতদিন “বিশেষ নিয়ম” ভেবে এসেছেন:

শেষ সারিটি একটু ব্যাখ্যা চায়। __slots__ = ("a",) লিখলে (পর্ব ৩৪-এর slots=True) Python object-এর জন্য __dict__ বানায় না; বদলে প্রতিটি নামের জন্য object-এর ভেতরে একটি নির্দিষ্ট ঘর রাখে, আর class-এ বসায় একটি data descriptor, যে সেই ঘর পড়ে-লেখে। তালিকার বাইরের নাম লিখতে চাইলে বসানোর মতো কোনো __dict__ নেই, তাই আসে AttributeError. __slots__ নতুন কোনো ভাষা-বৈশিষ্ট্য নয় — descriptor ব্যবস্থার আরেকটি প্রয়োগ।

৫ · একটি class কীভাবে জন্মায় — class বাক্যের ভেতরের ধাপ

অংশ ১-এ দেখেছেন, class বাক্য আসলে type(...) ডাকা। কিন্তু মাঝে আরও কয়েকটি ধাপ আছে, আর প্রতিটি ধাপে একটি করে “হুক” — যেখানে আপনার কোড ঢোকানো যায়। নিচের stepper-এ একটি পেমেন্ট gateway class-এর জন্ম দেখুন। এখানে সব হুক একসাথে লাগানো হয়েছে, যাতে ক্রমটি পরিষ্কার হয় — বাস্তবে একসাথে এত হুক প্রায় কখনো লাগে না। ক্রমটি Python 3.14-এ প্রতিটি হুকে print বসিয়ে যাচাই করা।

1@register2class Bkash(Gateway, metaclass=Meta, code="bkash"):3    fee = Field(lambda v: v >= 0, "ফি ঋণাত্মক নয়")4    def pay(self, amount): ...56# Gateway-এর ভেতরে:7#   def __init_subclass__(cls, code=None, **kw): ...

এই ক্রম থেকে একটি ব্যবহারিক শিক্ষা: class decorator সবচেয়ে শেষে চলে, তাই সে সম্পূর্ণ তৈরি class দেখে — সব descriptor নাম পেয়ে গেছে, সব parent হুক চলে গেছে। আর __init_subclass__ চলে metaclass-এর __init__-এর আগে, যা অনেককে অবাক করে। কোন হুক কখন চলে, তা না জেনে দুটি একসাথে ব্যবহার করলে এমন বাগ হয়, যেখানে একটি হুক এমন জিনিস খোঁজে, যা অন্যটি তখনো বসায়নি।

৬ · সরল থেকে কঠিন — class decorator, __init_subclass__, metaclass

class তৈরির সময় কিছু করার তিনটি হাতিয়ার আছে। কোনটি কখন, সেটিই এই অংশের মূল প্রশ্ন।

ধাপ ১ — class decorator: একটি class, একবার

পর্ব ৩৭-এ দেখেছেন, @register class Plugin: ... মানে Plugin = register(Plugin). class decorator সবচেয়ে সরল আর সবচেয়ে স্পষ্ট: যে class-এর ওপরে @ লেখা, শুধু তার ওপরেই কাজ করে, আর পাঠক চোখের সামনেই দেখেন যে কিছু একটা হচ্ছে। @dataclass এর সবচেয়ে বড় উদাহরণ। এর সীমা একটাই: subclass-এ এটি আপনাআপনি চলে না। @register class Gateway লিখলে class Bkash(Gateway) নিবন্ধিত হবে না, যদি না প্রতিটি subclass-এর ওপরেও @register লেখেন — আর কেউ একজন ভুলবেনই।

ধাপ ২ — __init_subclass__: প্রতিটি subclass, আপনাআপনি

এখানেই __init_subclass__ (Python 3.6, PEP 487). parent class-এ একবার লিখলে, প্রতিটি নতুন subclass তৈরির সময় এটি নিজে থেকে চলে — নাতি-পুতি সব প্রজন্মে। পর্ব ৩৪-এ এর একটি ছোট রূপ দেখেছেন। এবার বাস্তবের মতো একটি plugin registry: প্রতিটি gateway নিজের কোড (code="bkash") দেয়, মাঝের সাধারণ class নিবন্ধিত হয় না, আর pay() না লিখলে class তৈরির মুহূর্তেই error:

class Gateway:
    registry = {}

    def __init_subclass__(cls, code=None, **kwargs):
        super().__init_subclass__(**kwargs)      # সহযোগিতা: অন্য parent-কেও সুযোগ
        if code is None:
            return                               # মাঝের সাধারণ class — নিবন্ধন নয়
        if not callable(getattr(cls, "pay", None)):
            raise TypeError(f"{cls.__name__}: pay() method নেই")
        Gateway.registry[code] = cls

class MobileWallet(Gateway):                     # code নেই, তাই তালিকায় নেই
    fee = 1.85

class Bkash(MobileWallet, code="bkash"):
    def pay(self, amount): return f"bKash: {amount} টাকা"

class Nagad(MobileWallet, code="nagad"):
    def pay(self, amount): return f"Nagad: {amount} টাকা"

class Card(Gateway, code="card"):
    def pay(self, amount): return f"Card: {amount} টাকা"

Gateway.registry["nagad"]().pay(500)             # 'Nagad: 500 টাকা'
class Rocket(Gateway, code="rocket"): pass       # TypeError: Rocket: pay() method নেই

তিনটি জিনিস লক্ষ করুন। (১) class লাইনের code="bkash" একটি সাধারণ keyword argument হয়ে __init_subclass__-এ পৌঁছায় — অংশ ৫-এর ধাপ ১ আর ৬। (২) Bkash সরাসরি Gateway-এর সন্তান নয়, নাতি; তবু হুকটি চলেছে। (৩) super().__init_subclass__(**kwargs) লাইনটি বাদ দেবেন না: একাধিক parent থাকলে প্রত্যেকের হুক চলার সুযোগ এভাবেই আসে (পর্ব ৩৩-এর cooperative super())। নতুন পেমেন্ট পদ্ধতি যোগ করতে এখন শুধু একটি class লিখলেই হয় — কোনো কেন্দ্রীয় তালিকা হাতে বদলাতে হয় না। একে বলে plugin architecture.

এবার দ্বিতীয় runnable প্রোগ্রাম: __set_name__ আর __init_subclass__ মিলিয়ে একটি খুদে ORM, যা class-এর field পড়ে নিজে থেকে SQL টেবিলের সংজ্ঞা লেখে আর একটি সাধারণ __init__ দেয় — পর্ব ৫২-এর SQLAlchemy যা করে, তার একটি খেলনা রূপ।

class Column:
    def __init__(self, sql_type):
        self.sql_type = sql_type
    def __set_name__(self, owner, name):     # descriptor না হলেও ডাক আসে
        self.name = name

class Model:
    def __init_subclass__(cls, table=None, **kwargs):
        super().__init_subclass__(**kwargs)
        cls.columns = [v for v in vars(cls).values() if isinstance(v, Column)]
        cols = ", ".join(f"{c.name} {c.sql_type}" for c in cls.columns)
        cls.ddl = f"CREATE TABLE {table or cls.__name__.lower()} ({cols})"
    def __init__(self, **values):
        for col in self.columns:
            setattr(self, col.name, values.get(col.name))

class Customer(Model, table="customers"):
    name = Column("TEXT")
    phone = Column("TEXT")
    due = Column("REAL")

print(Customer.ddl)
c = Customer(name="রহিম", due=250.0)
print(c.name, c.phone, c.due, Customer.due.sql_type)
print(vars(c))

ধাপ ৩ — metaclass: class তৈরির পুরো প্রক্রিয়ার মালিকানা

metaclass হলো type-এর একটি subclass. এর চারটি method, প্রতিটি অংশ ৫-এর একটি ধাপের মালিক:

• __prepare__(mcls, name, bases, **kw): body-র জন্য খাতা দেয়। একটি বিশেষ mapping দিয়ে body-তে একই নাম দুবার লেখা ধরা যায়, বা লেখার ক্রম মনে রাখা যায়।
• __new__(mcls, name, bases, ns, **kw): class object তৈরি করে; খাতা বদলানো যায়।
• __init__(cls, name, bases, ns, **kw): তৈরি class-কে সাজায়।
• __call__(cls, *args, **kwargs): এটি class তৈরিতে নয়, object তৈরিতে চলে। Config() লেখা মানে type(Config).__call__(Config), যা ভেতরে __new__ আর __init__ ডাকে। এটি বদলালে object তৈরির নিয়মই বদলে যায়।

শেষেরটির একটি প্রচলিত উদাহরণ singleton — যে class-এর object পুরো প্রোগ্রামে একটিই হবে, যেমন একটি কনফিগারেশন:

class SingletonMeta(type):
    _instances = {}
    def __call__(cls, *args, **kwargs):          # Config() লিখলে এটি চলে
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class Config(metaclass=SingletonMeta):
    def __init__(self):
        print("config loaded")

a = Config()     # config loaded
b = Config()     # কিছুই ছাপা হয় না — আগেরটিই ফেরত
print(a is b)    # True

কাজ করে — কিন্তু সৎভাবে বলতে গেলে, Python-এ singleton-এর জন্য metaclass প্রায় কখনো সেরা উত্তর নয়। একটি module নিজেই singleton (প্রথম import-এর পর cache হয়, পর্ব ২২), তাই config.py-তে একটি object বানিয়ে রাখা, বা functools.cache দেওয়া একটি get_config() ফাংশন অনেক সরল আর পরীক্ষায় সহজে বদলানো যায়। উদাহরণটি দেখানো হলো __call__ বোঝাতে।

metaclass-এর লড়াই — conflict

metaclass-এর একটি বড় ব্যবহারিক সমস্যা: দুটি লাইব্রেরি নিজের নিজের metaclass ব্যবহার করলে তাদের class মিলিয়ে একটি class বানানো যায় না।

class M1(type): pass
class M2(type): pass
class A(metaclass=M1): pass
class B(metaclass=M2): pass

class C(A, B): pass

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

বার্তাটির মানে: C-এর metaclass এমন হতে হবে, যা M1 আর M2 দুটিরই subclass (বা তাদের একটি নিজেই)। এখানে এমন কেউ নেই, তাই Python সিদ্ধান্ত নিতে পারে না কোনটি C বানাবে। সমাধান হলো class M3(M1, M2) বানিয়ে metaclass=M3 দেওয়া — কিন্তু তখন দুটি অপরিচিত metaclass একসাথে ঠিকঠাক চলবে, এর কোনো নিশ্চয়তা নেই। এই সমস্যাকে বলে metaclass conflict, আর এটিই PEP 487 আনার একটি বড় কারণ: __init_subclass__ সাধারণ method, তাই সাধারণ inheritance-এর নিয়মে মিলেমিশে চলে।

তাহলে metaclass কখন সত্যিই লাগে?

Zen of Python-এর লেখক Tim Peters-এর নামে একটি উক্তি বহুল প্রচলিত, যা পর্ব ৩৪-এও দেখেছেন: “Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don't.” আধুনিক Python-এ metaclass লাগে মূলত তখন, যখন __init_subclass__ বা decorator সেই ধাপে পৌঁছাতে পারে না:

• body চলার আগে বা চলার সময় নিয়ন্ত্রণ: __prepare__ দিয়ে বিশেষ খাতা দেওয়া। Python-এর নিজের enum এটি ব্যবহার করে — Enum-এর metaclass (EnumType, 3.11-এর আগে নাম ছিল EnumMeta) body-তে একই নাম দুবার দিলে ধরতে পারে।
• class-এর নিজের আচরণ বদলানো: যেমন len(Color) বা for c in Color — class-এর ওপর dunder method কাজ করাতে সেগুলো metaclass-এ লিখতে হয়, কারণ পর্ব ৩২-এর নিয়মে Python dunder খোঁজে object-এর type-এ, আর class-এর type হলো তার metaclass.
• isinstance/issubclass-এর নিয়ম বদলানো: পর্ব ৩৫-এর ABCMeta এভাবেই “virtual subclass” সম্ভব করে।

৭ · introspection — চলার সময় নিজেকে দেখা আর বদলানো

metaprogramming-এর তৃতীয় হাতিয়ার: object-কে প্রশ্ন করা — এর কী কী attribute আছে, এই ফাংশন কী কী argument নেয়? প্রোগ্রামের নিজের গঠন পড়াকে বলে introspection, আর পড়ার সঙ্গে বদলানোও যোগ হলে অনেকে বলেন reflection.

নাম যখন একটি string

সাধারণ কোডে attribute-এর নাম আপনি লেখার সময়ই জানেন: p.price. কিন্তু নামটি যদি আসে একটি ফাইল, ফর্ম বা কমান্ড থেকে, string হিসেবে? তখন চারটি built-in ফাংশন:

• getattr(obj, "price") = obj.price; তৃতীয় argument দিলে না পেলে সেটি ফেরত দেয়: getattr(obj, "discount", 0).
• setattr(obj, "price", 500) = obj.price = 500 (descriptor থাকলে __set__ সহ — প্রথম runnable প্রোগ্রামের লুপ এটিই করেছে)।
• hasattr(obj, "price") — আসলে getattr চেষ্টা করে দেখে AttributeError আসে কি না। তাই property-র ভেতরে অন্য কোনো AttributeError হলে এটি ভুল করে False বলতে পারে।
• vars(obj) = obj.__dict__; আর dir(obj) দেয় ব্যবহারযোগ্য সব নামের তালিকা, class-এর আর পূর্বপুরুষদের নামসহ।

inspect — ফাংশনের নকশা পড়া

স্ট্যান্ডার্ড লাইব্রেরির inspect module আরও গভীরে দেখে। inspect.signature(func) (Python 3.3 থেকে, PEP 362) একটি ফাংশনের পুরো signature দেয় — parameter-এর নাম, default, annotation. inspect.getmembers(cls, inspect.isfunction) একটি class-এর সব ফাংশন নামসহ (বর্ণানুক্রমে) দেয়। এগুলো দিয়ে একটি ছোট CLI কমান্ড-ব্যবস্থা বানানো যায়, যেখানে ফাংশনের annotation দেখে ব্যবহারকারীর লেখা string আপনাআপনি সঠিক type-এ বদলায় — পর্ব ৫৩-এর Typer লাইব্রেরি ঠিক এই ধারণায় চলে:

import inspect

COMMANDS = {}
def command(func):                       # পর্ব ৩৭-এর registry decorator
    COMMANDS[func.__name__] = func
    return func

@command
def send(to: str, amount: int = 100):
    return f"{amount} টাকা → {to}"

def run(line):
    name, *words = line.split()
    func = COMMANDS[name]
    sig = inspect.signature(func)        # (to: str, amount: int = 100)
    bound = sig.bind(*words)             # শব্দগুলো parameter-এ বসানো
    for pname, text in bound.arguments.items():
        bound.arguments[pname] = sig.parameters[pname].annotation(text)
    return func(*bound.args, **bound.kwargs)

run("send 01712345678 500")    # '500 টাকা → 01712345678'  (500 এখন int)
run("send")                    # TypeError: missing a required argument: 'to'

sig.bind ঠিক সেই নিয়মে argument মেলায়, যে নিয়মে Python নিজে ফাংশন ডাকে — কম বা বেশি argument হলে একই রকম TypeError. একই কৌশলে ছোট একটি dependency injection ব্যবস্থাও বানানো যায়: ফাংশনের parameter-এর নাম পড়ে (db, notifier) সেই নামের জিনিস খুঁজে দেওয়া। FastAPI-র Depends আর pytest-এর fixture (পর্ব ৪২) এভাবে parameter-এর নাম দেখেই ঠিক করে কী পাঠাতে হবে।

monkeypatching — চলন্ত প্রোগ্রামে অন্যের কোড বদলানো

Python-এ module আর class-ও object, তাই চলার সময় তাদের attribute বদলে দেওয়া যায়: math.sqrt = lambda x: 42 লিখলে এরপর পুরো প্রোগ্রামে, যে module math.sqrt ডাকে, সবাই 42 পাবে। অন্যের কোড এভাবে চলার সময় বদলানোকে বলে monkeypatching. এর একটি বৈধ জায়গা আছে — টেস্ট: পর্ব ৪২-এ pytest-এর monkeypatch fixture দেখবেন, যা টেস্টের সময় একটি ফাংশন নকল দিয়ে বদলায় আর টেস্ট শেষে নিজে থেকে আগের অবস্থায় ফিরিয়ে দেয়. বাকি সব জায়গায় এটি বিপজ্জনক:

• দূরের প্রভাব: বদলটি পুরো প্রক্রিয়ায় সবার জন্য, এমনকি সেই লাইব্রেরিগুলোর জন্যও, যারা কিছুই জানে না।
• অদৃশ্য: math.sqrt-এর ডকুমেন্টেশন পড়ে আপনি বুঝবেন না কেন 42 আসছে; IDE-ও জানে না।
• ভঙ্গুর: লাইব্রেরির পরের সংস্করণে ভেতরের নাম বদলালে patch নিঃশব্দে কাজ করা বন্ধ করে, বা ভুল জিনিস বদলায়।

eval আর exec — সবচেয়ে ধারালো ছুরি

eval() একটি string-কে Python expression হিসেবে চালায় (eval("2 + 3") → 5), আর exec() পুরো statement বা ফাংশন-সংজ্ঞাও চালাতে পারে। অর্থাৎ চলার সময় নতুন কোড লিখে চালানো — metaprogramming-এর চূড়ান্ত রূপ। স্ট্যান্ডার্ড লাইব্রেরি নিজেও সাবধানে এটি ব্যবহার করে: dataclasses ভেতরে __init__-এর source লেখা string হিসেবে তৈরি করে exec দিয়ে ফাংশন বানায়।

৮ · বড় লাইব্রেরির ভেতরে — আর জাদুর দাম

এই পর্বের হাতিয়ারগুলো আপনি নিজে হয়তো কম লিখবেন, কিন্তু প্রতিদিন ব্যবহার করবেন। ধারণাগতভাবে দেখুন বড় লাইব্রেরিগুলো কোনটি কোথায় লাগায় (ভেতরের খুঁটিনাটি সংস্করণভেদে বদলায়):

খেয়াল করুন, Pydantic আর Django এখনো metaclass ব্যবহার করে, কারণ তারা __init_subclass__-এর আগের যুগে জন্ম নিয়েছে বা class-এর ওপর এমন নিয়ন্ত্রণ চায়, যা হুক দিয়ে পাওয়া যায় না। আপনার নিজের কোডে সেই যুক্তি প্রায় কখনো খাটে না।

জাদুর তিনটি দাম

• পড়া আর ডিবাগ: c.due দেখে মনে হয় একটি সাধারণ attribute; আসলে হয়তো একটি descriptor ডেটাবেসে প্রশ্ন পাঠাচ্ছে। Zen of Python বলে, “Explicit is better than implicit.” যত জাদু, তত বেশি জায়গায় খুঁজতে হয় আসলে কী ঘটছে।
• টুলের অন্ধত্ব: setattr, type(...) বা exec দিয়ে চলার সময় বানানো নাম IDE-র autocomplete আর mypy-র মতো type checker দেখতে পায় না — তাদের কাছে সেগুলো ভুল বা অস্তিত্বহীন। এজন্য Python 3.11-এ typing.dataclass_transform (PEP 681) এসেছে, যাতে লাইব্রেরি type checker-কে জানাতে পারে “আমার class dataclass-এর মতো আচরণ করে”.
• গতি: descriptor-ওয়ালা attribute পড়া মানে প্রতিবার একটি Python ফাংশন ডাক, যা সাধারণ attribute পড়ার চেয়ে কয়েক গুণ ধীর। সাধারণ কাজে এটি নগণ্য, কিন্তু লক্ষ লক্ষ বার চলা লুপে টের পাওয়া যায় — পর্ব ৪৬-এ মেপে দেখার পদ্ধতি।

৯ · AI-এর যুগে — AI-এর লেখা “জাদু” যাচাই করা

“প্রতিটি subclass নিবন্ধন করার ব্যবস্থা করে দাও” বললে AI প্রায়ই সরাসরি একটি metaclass লিখে দেয় — কারণ পুরোনো টিউটোরিয়াল আর Stack Overflow উত্তরে, যা তার শেখার ডেটার বড় অংশ, এটাই প্রচলিত ছিল। কোডটি চলে, কিন্তু তিন লাইনের __init_subclass__-এর জায়গায় বিশ লাইনের জাদু, আর পরে অন্য লাইব্রেরির সাথে মেলাতে গেলে metaclass conflict. AI-এর লেখা metaprogramming-এ বারবার যে ভুলগুলো দেখা যায়:

AI-এর লেখা metaprogramming পেলে — যাচাইয়ের চেকলিস্ট

• metaclass থাকলে প্রশ্ন করেছি: decorator বা __init_subclass__ দিয়ে কি হতো? (প্রায় সবসময় হ্যাঁ)
• descriptor-এর মান object-এর ঘরে থাকে — দুটি object বানিয়ে আলাদা মান দিয়ে মিলিয়ে দেখেছি
• __get__ class থেকে পড়া (obj is None) সামলায়; help(Product) চালিয়ে দেখেছি crash হয় না
• __getattribute__ নেই, বা থাকলে ভেতরে শুধু super().__getattribute__
• কোথাও eval/exec নেই; থাকলে ইনপুট কোথা থেকে আসে, তা নিশ্চিতভাবে জানি
• চলার সময় বানানো নামগুলো IDE-তে autocomplete হয় আর mypy চালিয়ে কোনো অজানা-attribute error আসে না