Python কীভাবে চলে — interpreter, bytecode আর সবকিছুই object

১ · Run চাপলে আসলে কী ঘটে

আগের পর্বে আপনি প্রথম প্রোগ্রাম লিখেছেন, চালিয়েছেন, error-ও পড়েছেন। টার্মিনালে python hello.py লিখে Enter চাপলেন, আর মুহূর্তেই লেখা ভেসে উঠল। মনে হয় যেন Python সরাসরি আপনার লেখা পড়ে কাজ করে ফেলল। আসলে ভেতরে কয়েকটি ধাপ ঘটে গেছে — এত দ্রুত যে আপনি টেরই পাননি।

এই পর্বটি একটু আলাদা। এখানে নতুন কোনো syntax শিখবেন না। বরং একটি মানসিক মডেল তৈরি করবেন — Python ভেতরে কীভাবে ভাবে। পরের প্রতিটি পর্ব (ভ্যারিয়েবল, list, ফাংশন, class) এই মডেলের ওপর দাঁড়াবে। এখানে যা বুঝবেন, তা দিয়েই পরে অনেক “অদ্ভুত” আচরণের ব্যাখ্যা পাবেন।

প্রথম প্রশ্ন: CPU কি Python বোঝে? না। CPU বোঝে শুধু নিজের machine code. আপনার print("Hi") আর CPU-র মাঝখানে একজন মধ্যস্থতাকারী আছে। সেই মধ্যস্থতাকারী হলো interpreter — একটি প্রোগ্রাম, যা আপনার Python কোড পড়ে চালায়। আপনি যে python কমান্ড চালান, সেটিই এই interpreter.

২ · Source থেকে bytecode — ভেতরের পাইপলাইন

C কোর্সের টুলচেইনে চারটি আলাদা প্রোগ্রাম (preprocessor, compiler, assembler, linker) পরপর কাজ করে। Python-এ সব ধাপ একই python প্রোগ্রামের ভেতরে ঘটে, তাই চোখে পড়ে না। কিন্তু ধাপগুলো ঠিকই আছে। নিচের ছোট প্রোগ্রামটির দ্বিতীয় লাইন total = qty * 40 কীভাবে রূপ বদলায়, দেখুন। “পরে” চাপুন:

qty = 3
total = qty * 40
print(total)

NAME    'total'
OP      '='
NAME    'qty'
OP      '*'
NUMBER  '40'
NEWLINE

Assign
 ├─ target: Name 'total'  (এখানে রাখো)
 └─ value:  BinOp  *
             ├─ Name 'qty'   (মান আনো)
             └─ Constant 40

LOAD_NAME       qty
LOAD_SMALL_INT  40
BINARY_OP       5 (*)
STORE_NAME      total

$ python shop.py
120

এই পাইপলাইন জানার সবচেয়ে বড় ব্যবহারিক লাভ — error-এর ধরন দেখে বোঝা যায় সমস্যা কোথায়। নিচের টেবিলটি আগের পর্বের error পড়ার কৌশলের সাথে মিলিয়ে দেখুন:

৩ · Bytecode নিজের চোখে দেখুন — dis আর __pycache__

কথায় না, প্রমাণে বিশ্বাস করুন। Python-এর সাথেই আসে dis (disassembler) module, যা যেকোনো ফাংশনের bytecode পড়ে দেখায়। নিচের কোডটি চালান:

import dis

def add(a, b):
    total = a + b
    return total

dis.dis(add)
print(add(2, 3))
print(type(add.__code__))

Constant folding — compiler আগেই হিসাব সেরে রাখে

Python-এর compiler কিছু ছোট বুদ্ধিও খাটায়। আপনি x = 2 + 3 লিখলে 3.14-এর bytecode-এ কোনো যোগের নির্দেশই থাকে না — compiler নিজেই হিসাব করে সরাসরি 5 বসিয়ে দেয়। একে বলে constant folding. এজন্যই SECONDS_PER_DAY = 60 * 60 * 24 লিখলে চালানোর সময় কোনো খরচ নেই। পড়ার সুবিধার জন্য হিসাবটা খুলে লিখুন; গতি নিয়ে চিন্তা করবেন না।

__pycache__ আর .pyc — অনুবাদ জমিয়ে রাখা

প্রতিবার প্রোগ্রাম চালানোর সময় সব ফাইল নতুন করে compile করলে সময় নষ্ট। তাই আপনার প্রোগ্রাম যখন অন্য কোনো ফাইল import করে, CPython সেই ফাইলের bytecode একটি .pyc ফাইলে লিখে রাখে, __pycache__ নামের ফোল্ডারে। পরের বার ফাইলটি না বদলালে সরাসরি .pyc থেকে bytecode পড়ে নেয় — অনুবাদের ধাপ বাদ।

myshop/
├── main.py
├── billing.py
└── __pycache__/
    └── billing.cpython-314.pyc

• নামের মাঝে cpython-314 কেন? কারণ bytecode version অনুযায়ী বদলায়। 3.13 আর 3.14 একই ফোল্ডারে পাশাপাশি নিজের নিজের .pyc রাখতে পারে। এই নিয়ম এসেছে Python 3.2 থেকে।
• main.py-এর .pyc কোথায়? যে ফাইলটি আপনি সরাসরি চালান (python main.py), তার .pyc সাধারণত লেখা হয় না — শুধু import করা module-গুলোর হয়।
• ফাইল বদলালে? .pyc-এর ভেতরে source ফাইলের সময় আর আকারের তথ্য থাকে। মিল না হলে CPython নিজেই নতুন করে compile করে।
• মুছে ফেললে কি ক্ষতি? একদম না। পরের বার আবার তৈরি হবে। তবে git-এ এটি রাখা উচিত নয় — .gitignore-এ __pycache__/ যোগ করা প্রচলিত নিয়ম।

৪ · Virtual machine — এক নির্দেশ এক নির্দেশ করে

“Virtual machine” শুনে VirtualBox-এর মতো পুরো কম্পিউটার ভাববেন না। এখানে এর মানে অনেক সরল: C-তে লেখা একটি বড় লুপ, যা বারবার একই কাজ করে — পরের bytecode নির্দেশ পড়ো, সেটি কী তা দেখো, সেই অনুযায়ী কাজ করো, আবার পরের নির্দেশে যাও। CPython-এর সোর্সে এই লুপের ফাইলটির নাম ceval.c (“evaluate”). আপনার পুরো Python প্রোগ্রাম আসলে এই লুপের ঘূর্ণন।

CPython-এর VM একটি stack machine. হিসাবের জন্য সে একটি স্তূপ (stack) ব্যবহার করে — যেন টেবিলে একটার ওপর একটা প্লেট রাখা। নতুন মান আসে ওপরে, কাজের সময় ওপর থেকে তোলা হয়। ধরুন a আগে থেকেই 2, b 3. এবার x = a + b-এর চারটি নির্দেশ দেখুন:

1LOAD_NAME   a2LOAD_NAME   b3BINARY_OP   0 (+)4STORE_NAME  x

ধাপ ৩ খেয়াল করুন — এটাই Python-এর ধীরগতির একটি বড় কারণ, আবার নমনীয়তারও উৎস। C-তে a + b compile হওয়ার সময়েই জানা থাকে দুটি int, তাই একটি CPU নির্দেশেই যোগ হয়ে যায়। Python-এ প্রতিবার VM-কে চলার সময় দেখতে হয় এগুলো কোন type-এর, তারপর সেই type-এর নিয়ম খুঁজতে হয়। এই প্রতিবারের খোঁজাখুঁজিই খরচ।

Python 3.11-এর বড় লাফ — নিজেকে মানিয়ে নেওয়া interpreter

সেই খরচ কমাতে Python 3.11 (২০২২)-এ এসেছে specializing adaptive interpreter (PEP 659). মূল চিন্তা সহজ: বাস্তবে একটি লাইন সাধারণত বারবার একই type-এর মান পায়। লুপে total + price হাজারবার চললে প্রায় প্রতিবারই দুটি int. তাই কয়েকবার চলার পর VM সেই জায়গার সাধারণ BINARY_OP-কে বদলে দেয় একটি বিশেষ নির্দেশে — যা ধরে নেয় “দুটিই int”, শুধু একবার ছোট্ট যাচাই করে, সোজা যোগ করে ফেলে। হঠাৎ অন্য type এলে আবার সাধারণ নির্দেশে ফিরে যায়। ফলাফল ঠিক একই থাকে, শুধু দ্রুত হয়। Python-এর অফিসিয়াল হিসাবে 3.11 আগের version-এর চেয়ে গড়ে প্রায় ২৫% দ্রুত (কাজভেদে ১০ থেকে ৬০%).

JIT — পরীক্ষামূলক পর্যায়ে

পরের ধাপ JIT (Just-In-Time) compiler: বারবার চলা bytecode অংশকে চলার সময়েই আসল machine code-এ বদলে ফেলা। Python 3.13-এ CPython-এ একটি পরীক্ষামূলক JIT যোগ হয়েছে (PEP 744), যা “copy-and-patch” কৌশলে তৈরি। এটি ডিফল্টে বন্ধ, আর বিশেষভাবে build বা চালু না করলে পাবেন না; 3.14-এও এটি পরীক্ষামূলক। এখন পর্যন্ত এর গতির লাভ সীমিত — এটি ভবিষ্যতের ভিত্তি, আজকের জাদু নয়। AI বা পুরোনো ব্লগে “Python-এর কোনো JIT নেই” বা “Python এখন JIT দিয়ে C-র মতো দ্রুত” — দুটো কথাই ভুল।

৫ · এক ভাষা, অনেক implementation

এখানে একটি গুরুত্বপূর্ণ পার্থক্য বুঝে নিন। “Python” হলো একটি ভাষা — নিয়মের একটি বই (Python Language Reference). আর CPython হলো সেই নিয়ম মেনে বানানো একটি প্রোগ্রাম, বা implementation. যেমন “ক্রিকেট” একটি খেলার নিয়ম, আর মিরপুরের শের-ই-বাংলা স্টেডিয়ামের ম্যাচ সেই নিয়মে খেলা একটি আসর — অন্য মাঠেও একই নিয়মে খেলা যায়। CPython হলো reference implementation: নতুন ফিচার প্রথমে এখানেই আসে, আর python.org থেকে এটিই পান।

ইতিহাসে আরও দুটি নাম পাবেন: Jython (Python কোড Java-র JVM-এ চালাত) আর IronPython (Microsoft-এর .NET-এ)। দুটোই দীর্ঘদিন Python 2-এর জগতে আটকে ছিল, তাই আজকের নতুন প্রজেক্টে খুব কম দেখা যায়। এই কোর্সে “Python” বললে আমরা CPython 3.14 বোঝাব, আর যেখানে implementation-ভেদে আচরণ বদলায় সেখানে আলাদা করে বলব।

৬ · সবকিছুই object — type, identity আর value

এবার পর্বের দ্বিতীয় বড় ধারণা — সম্ভবত পুরো কোর্সের সবচেয়ে গুরুত্বপূর্ণ বাক্য: Python-এ প্রতিটি মান একটি object. সংখ্যা 42 একটি object. লেখা "ঢাকা" একটি object. একটি list, একটি ফাংশন, একটি module, এমনকি int নিজেও (যা একটি class) — সবাই object.

Object মানে মেমরিতে থাকা একটি জিনিস, যার তিনটি বৈশিষ্ট্য আছে:

“সবকিছুই object” কথাটির সবচেয়ে মজার ফল — ফাংশনও একটি মান. আপনি ফাংশনকে নতুন নাম দিতে পারেন, list-এ রাখতে পারেন, অন্য ফাংশনে পাঠাতে পারেন। sorted(names, key=len)-এ আপনি len ফাংশনটিকেই একটি মান হিসেবে পাঠাচ্ছেন। পরে decorator (পর্ব ৩৫) আর functional tool (পর্ব ৩৮) পুরোটাই এই ধারণার ওপর দাঁড়িয়ে। আর isinstance(x, object) যেকোনো x-এর জন্য True দেয় — কারণ Python-এ সব class শেষ পর্যন্ত object থেকেই আসে।

৭ · নাম আসলে লেবেল, বাক্স নয়

অনেক বইয়ে লেখা থাকে “ভ্যারিয়েবল হলো একটি বাক্স, যার ভেতরে মান রাখা হয়।” C-র জন্য ছবিটা মোটামুটি ঠিক। কিন্তু Python-এর জন্য এই ছবি আপনাকে ভুল পথে নিয়ে যাবে। Python-এ একটি নাম হলো একটি লেবেল বা স্টিকি নোট, যা কোনো object-এর গায়ে লাগানো থাকে। = চিহ্নের কাজ “বাক্সে ভরা” নয় — “এই লেবেলটি ওই object-এর গায়ে লাগাও”। একে বলে binding.

এবার এই ধারণা কোডে দেখুন। নিচের ধাপগুলোতে খেয়াল রাখুন — কয়টি list object তৈরি হচ্ছে, আর কয়টি নাম:

1a = [1, 2]2b = a3b.append(3)4print(a)5print(a is b)

এখন নিচের কোডটি চালান। এখানে নাম আর object-এর সম্পর্ক, “দেখতে এক” বনাম “আসলেই এক”, আর ফাংশনও যে object — তিনটিই একসাথে দেখবেন:

a = [1, 2]
b = a              # নতুন list নয় — একই object-এ দ্বিতীয় নাম
b.append(3)
print(a)
print(a is b)

c = [1, 2, 3]      # দেখতে এক, কিন্তু আলাদা object
print(a == c, a is c)

def greet(name):
    return f"সালাম, {name}!"

say = greet        # ফাংশনও object — তাকেও নতুন নাম দেওয়া যায়
print(say("রহিম"))
print(type(42), type("ঢাকা"), type(greet), type(int))
print(isinstance(greet, object), isinstance(int, object))

Dynamic typing-এর এক ঝলক

লেবেলের ছবি থেকে আরেকটি জিনিস স্বাভাবিকভাবেই আসে। Type থাকে object-এর গায়ে, নামের গায়ে নয়। তাই একই নাম এখন একটি int-এ, পরে একটি str-এ লাগানো যায়: score = 90, তারপর score = "A+". লেবেল সরে গেল, কিন্তু 90 নামের object নিজে কখনো string হয়নি। একে বলে dynamic typing. এর সুবিধা-অসুবিধা আর type hint দিয়ে কীভাবে নিয়ন্ত্রণ করা যায়, তা পরের পর্ব (পর্ব ০৬) আর পর্ব ৩৭-এ দেখবেন।

৮ · Object কখন মুছে যায় — reference counting আর garbage collector

C-তে malloc দিয়ে মেমরি নিলে free দিয়ে নিজেকেই ফেরত দিতে হয়। Python-এ আপনি কখনো object “মুছে” দেন না। তাহলে মেমরি ভরে যায় না কেন? কারণ CPython প্রতিটি object-এর সাথে একটি ছোট গণনা রাখে: এই object-কে এখন কতগুলো reference দেখাচ্ছে. একে বলে reference count. নাম, list-এর ঘর, ফাংশনের argument — সবাই একেকটি reference. গণনা শূন্য হলেই object সঙ্গে সঙ্গে মুছে যায়, মেমরি ফেরত যায়।

1book = ["গীতাঞ্জলি"]2shelf = book3reader = book4del book5shelf = None6reader = None

sys.getrefcount(x) নামে একটি ফাংশন সত্যিই আছে, যা এই গণনা দেখায়। কিন্তু এর সংখ্যা version অনুযায়ী বদলায় (ফাংশনে পাঠানোর সময়েই একটি বাড়তি reference তৈরি হয়, আর 3.14-এ কিছু জায়গায় reference না বাড়িয়েই “ধার” নেওয়া হয়), তাই সংখ্যাটি মুখস্থ করার বা তার ওপর নির্ভর করার কিছু নেই। ধারণাটিই আসল।

যেখানে গণনা কাজ করে না — reference cycle

ধরুন দুটি object একে অপরকে দেখাচ্ছে: x = [], y = [x], তারপর x.append(y). এখন del x, y করলে বাইরের কোনো নাম আর এদের দেখায় না, অথচ প্রত্যেকের count অন্তত 1 — একে অপরের কারণে। Reference counting একা এদের কখনো মুছবে না। একে বলে reference cycle.

এজন্য CPython-এ আছে একটি দ্বিতীয় ব্যবস্থা — garbage collector (gc module). এটি মাঝে মাঝে জেগে ওঠে, এমন object-দল খোঁজে যাদের বাইরে থেকে কেউ দেখায় না, শুধু নিজেরা নিজেদের দেখায় — আর তাদের মুছে দেয়। রোজকার কোডে আপনাকে gc নিয়ে কিছুই করতে হবে না। শুধু জেনে রাখুন: বেশিরভাগ object মুছে যায় reference counting-এ, সঙ্গে সঙ্গে; আর চক্রগুলো পরিষ্কার করে gc, পরে কোনো এক সময়।

৯ · Python কেন কখনো ধীর, কখনো দ্রুত — আর GIL

এতক্ষণ যা শিখলেন, তা দিয়েই এখন একটি বহুল আলোচিত প্রশ্নের উত্তর দিতে পারবেন: “Python কি ধীর?” উত্তর — কী করছেন তার ওপর নির্ভর করে।

ধরুন আপনি এক কোটি সংখ্যা যোগ করছেন একটি বিশুদ্ধ Python লুপে। প্রতিবার লুপ ঘোরার সময় VM-কে কয়েকটি bytecode নির্দেশ চালাতে হয়; প্রতিটি যোগে দেখতে হয় type কী; প্রতিটি নতুন ফলের জন্য একটি নতুন int object তৈরি করতে হয় (Python-এর int একটি পূর্ণ object, C-র মতো শুধু ৮ বাইটের সংখ্যা নয়); পুরোনোটির reference count কমিয়ে মুছতে হয়। একই কাজ C-তে কয়েকটি CPU নির্দেশেই হয়ে যায়। তাই এমন লুপে Python সাধারণত C-র চেয়ে কয়েক ডজন গুণ ধীর হতে পারে।

কিন্তু ডেটা সায়েন্স আর AI-এর জগৎ তো Python-এই চলে! রহস্য হলো — ভারী কাজটা Python করে না। NumPy-র মতো library-র ভেতরের অংশ C (আর কিছু Fortran)-এ লেখা, যাকে বলে C extension. আপনি Python-এ একটি লাইন লেখেন — “এই দুই কোটি সংখ্যার array যোগ করো” — আর VM একবারই সেই C ফাংশনকে ডাকে। বাকি পুরো লুপ চলে C-র গতিতে, bytecode-এর খরচ ছাড়া। Python এখানে ম্যানেজার: সিদ্ধান্ত নেয়, কাজ ভাগ করে দেয়; ভারী বোঝা বয় C. এই কৌশল আপনি পর্ব ৪৬-এ NumPy আর pandas-এ হাতে-কলমে দেখবেন, আর পর্ব ৪৩-এ শিখবেন কীভাবে মেপে দেখতে হয় আসলে কোথায় সময় যাচ্ছে।

GIL — এক পাতায়

CPython-এর একটি বিখ্যাত বৈশিষ্ট্যের নাম GIL (Global Interpreter Lock). সাধারণ CPython-এ একটি প্রক্রিয়ার ভেতরে যতগুলো thread-ই থাকুক, একসাথে শুধু একটি thread Python bytecode চালাতে পারে. কারণটি এই পর্বেই আছে: reference count. দুটি thread একই সময়ে একই object-এর গণনা বদলালে হিসাব গুলিয়ে যেতে পারত, আর ভুল সময়ে object মুছে যেত। প্রতিটি object-এ আলাদা তালা দেওয়ার বদলে পুরো interpreter-এ একটি বড় তালা — সরল ও দ্রুত সমাধান, কিন্তু multi-core CPU-র সব core বিশুদ্ধ Python কোডে কাজে লাগানো যায় না। তবে ফাইল পড়া বা নেটওয়ার্কের অপেক্ষার সময় GIL ছেড়ে দেওয়া হয়, আর NumPy-র মতো অনেক C library-ও ভারী হিসাবের সময় তালা ছাড়ে।

পরিস্থিতি বদলাচ্ছে। PEP 703 অনুযায়ী Python 3.13-এ এসেছে একটি আলাদা, পরীক্ষামূলক free-threaded build — GIL ছাড়া CPython. Python 3.14-এ এই build অফিসিয়ালি সমর্থিত হয়েছে, তবে এখনো ঐচ্ছিক: আলাদা করে ইনস্টল করতে হয় (অনেক সময় নাম python3.14t), ডিফল্ট Python-এ GIL এখনো আছে, আর সব C library এখনো এর জন্য তৈরি নয়। Thread, process আর GIL-এর পুরো আলোচনা পর্ব ৪১-এ।

১০ · AI-এর যুগে — internals নিয়ে AI-এর পুরোনো তথ্য যাচাই

“Python ভেতরে কীভাবে কাজ করে” — এই প্রশ্নে AI চ্যাটবট সাধারণত চমৎকার, আত্মবিশ্বাসী উত্তর দেয়। সমস্যা হলো, এই বিষয়ে ইন্টারনেটের বেশিরভাগ লেখা ২০২২-এর আগের, অর্থাৎ Python 3.11-এর বড় পরিবর্তনের আগের। AI সেই লেখা থেকেই শিখেছে। তাই internals নিয়ে AI-এর উত্তর প্রায়ই এক সময় ঠিক ছিল, এখন পুরোনো.

Python internals নিয়ে AI-এর উত্তর পেলে — যাচাইয়ের চেকলিস্ট

• উত্তরে কোন Python version-এর কথা বলা হচ্ছে, তা স্পষ্ট — নাকি version-ই উল্লেখ নেই
• Opcode বা bytecode-এর দাবি নিজের কম্পিউটারে dis চালিয়ে মিলিয়েছি
• “ভাষার নিয়ম” আর “CPython-এর ভেতরের সুবিধা” আলাদা করেছি (যেমন ছোট int-এর ক্যাশ, id() মানে ঠিকানা)
• GIL, JIT বা গতির দাবির জন্য docs.python.org-এর “What's New” বা সংশ্লিষ্ট PEP দেখেছি
• “X গুণ দ্রুত” ধরনের সংখ্যা পেলে প্রশ্ন করেছি — কোন কাজে, কোন version-এ, কে মেপেছে