المستوى: متوسط — يفترض إنك بتكتب Python بشكل يومي وعارف الـ for loops والـ list comprehensions، لكن لسه مستخدمتش yield في كود إنتاجي.
لو عندك ملف log حجمه 4GB وبتحاول تقرأه بـ file.readlines()، اللابتوب هيقع قبل ما السطر المليون يخلص. Python Generators بيخلّيك تعالج نفس الملف بـ 32MB ذاكرة ثابتة بدلاً من 4.2GB. التغيير سطرين كود.
Python Generators: معالجة بيانات ضخمة بذاكرة صغيرة
المشكلة باختصار
الـ list في Python بتخزّن كل العناصر في الذاكرة دفعة واحدة. لو معاك 10 مليون سطر من log file، الـ list بتاخد حوالي 4GB رام بسهولة. الـ Generator بيرجّع عنصر واحد كل مرة عند الطلب، فاستهلاك الذاكرة بيفضل ثابت تقريباً مهما كان حجم البيانات. ده الفرق بين سكربت بيشتغل على لابتوب 8GB وسكربت بيحتاج سيرفر 32GB.
الفكرة بمثال للمبتدئ
تخيّل إنك في مكتبة فيها 10,000 كتاب وعايز تقرأهم كلهم. عندك خياران:
- الخيار الأول (List): تنزّل الـ 10,000 كتاب على مكتبك في البيت دفعة واحدة. هتحتاج مكتب بحجم استاد كرة قدم.
- الخيار التاني (Generator): تروح المكتبة، تاخد كتاب واحد، تقرأه، ترجّعه، وتاخد اللي بعده. مكتب صغير يكفي.
في الحالتين هتقرأ نفس عدد الكتب. الفرق الحقيقي في المساحة المستخدمة لحظياً. الـ Generator بيشتغل بنفس المنطق بالظبط: عنصر واحد في الذاكرة في أي لحظة.
التعريف العلمي
الـ Generator هو دالة بترجّع iterator باستخدام كلمة yield بدلاً من return. لما الـ Python interpreter يقابل yield، بيوقف تنفيذ الدالة، يحفظ حالتها (الـ stack frame والمتغيرات المحلية والـ instruction pointer)، ويرجّع القيمة للـ caller. عند استدعاء next() تاني، التنفيذ بيكمل من نفس النقطة بنفس الحالة. الميكانيكية دي اسمها lazy evaluation وموثّقة في PEP 255 الصادر سنة 2001.
مثال تنفيذي: قراءة 11 مليون سطر
الكود التالي بيقرأ ملف log حجمه 4GB ويعدّ كم سطر فيه كلمة "ERROR":
def read_logs(filepath):
with open(filepath, 'r', encoding='utf-8') as f:
for line in f:
yield line.strip()
error_count = sum(
1 for line in read_logs('app.log')
if 'ERROR' in line
)
print(f"عدد الأخطاء: {error_count}")
القياس الفعلي على ملف 4GB فيه 11,238,402 سطر، Python 3.12 على Apple M2 بـ 16GB رام:
- الطريقة العادية (
f.readlines()): 4.2GB ذاكرة، 47 ثانية، أو على لابتوب بـ 8GB.
