چرا پیتون ؟
کاردینال بیگلز، اریک بی ایمان را بیش از چهار ساعت روی صندلی راحتی نشاند تا سرانجام این اعترافات را از او گرفت ...
اولین نگاه من به پیتون یک تصادف بود، و علاقه چندانی به چیزی که در آن زمان دیدم پیدا نکردم. اوایل سال 1997 بود و کتاب "برنامه نویسی پیتون" نوشته مارک لوتز از انتشارات O'reilly به تازگی بیرون آمده بود. کتابهای O'reilly به ندرت به در خانه من می‌رسند، که در آن مورد هم توسط یک فرد ذینفع درون سازمان طی یک فرآیند تصادفی که من تصمیم گرفته‌ام دیگر سعی در فهمیدن آن نکنم، از بین تازه‌های چاپ برای من فرستاده می‌شوند.
یکی از این کتابها "برنامه نویسی پیتون" بود. از آنجا که من زبانهای رایانه‌ای را جمع آوری می‌کنم، این موضوع برایم جالب بود. من بیش از دوجین زبان همه منظوره بلدم، برای تفریح مفسر و مترجم‌های زیادی نوشته‌ام و شخصا تعدادی زبانهای یک منظوره و فرمهای نشانه گذاری (Markup) مختلف طراحی کرده‌ام. تازه‌ترین پروژه‌ای که من در زمان نوشتن این مقاله به پایان رسانده‌ام، یک زبان یک منظوره به نام SNG برای کار کردن روی تصاویر PNG یا Portable Network Graphics است. خوانندگان علاقمند می‌توانند صفحات خانگی SNG را در آدرس
http://www.catb.org/~esr/sng مشاهده کنند
. من همچنین چند نسخه پیاده سازی شده از چند زبان همه منظوره عجیب را در صفحه
Retrocomputing Museum خود به آدرس
The Retrocomputing Museum قرار داده‌ام
.من قبلا آنقدر درباره پیتون شنیده بودم که بدانم از آن چیزهایی است که امروزه به آنها زبانهای اسکریپت می‌گویند، یک زبان تفسیری با مدیریت داخلی (built-in) حافظه و تسهیلاتی خوب برای فراخوانی و همکاری با دیگر برنامه‌ها. بنابراین در هنگام شروع پیتون یک سوال بالاتر از همه مسائل برای من مطرح بود: این زبان چه چیزی دارد که پرل ندارد؟
البته، پرل گوریل ۸۰۰ کیلویی زبانهای اسکریپت امروزی است. این زبان تا حدی به لطف کتابخانه‌های یونیکس و اعلان‌های جامع خود و تا حدی به دلیل مجموعه بزرگ ماژول‌های به وجود آمده توسط جامعه برنامه نویسان پرل ، به نسبت زیادی جایگزین زبانهای اسکریپت انتخابی مدیران و ناظران سیستم‌ها شده است. این زبان، زبان CGI پنهان در پشت حدود ۸۵% محتوای "زنده" بر روی شبکه به شمار می‌رود. سازنده آن، Larry Wall، به درستی یکی از مهمترین رهبران جامعه متن باز به شمار می‌رود و اغلب پس از Linus Torvalds و Richard Stallaman در مکان سوم جایگاه خدایان قرار می‌گیرد.
در آن زمان من پرل را برای تعدادی از پروژه‌های کوچک استفاده کرده بودم. من این زبان را بسیار قدرتمند یافتم گرچه به نظر من می‌رسید سینتکس و بعضی جنبه‌های دیگر این زبان می‌توانند تا حدی برای شخصی که به آن عادت نداشته باشد، خطرناک باشند. به نظر من می‌رسید که پیتون به عنوان یک زبان اسکریپت باید گام مهم دیگری بردارد، بنابراین درحال خواندن به دنبال چیزی می‌گشتم که به نظر برسد آن را از زبان پرل مجزا می‌کند.
من به سرعت مطالب غیرعادی اصلی‌ای که ممکن است در پیتون به نظر هر کسی برسد را مرور کردم: این واقعیت که فضای خالی (indentation) در سینتکس این زبان بامعنی است؛ این زبان هیچ سنخیتی با ساختار آکولادی C و پرل ندارد، در عوض تغییرات در توگذاری (indentation) محدودیت گروه‌های عبارات را از بین می‌برند؛ و مثل اکثر هکرها پس از فهمیدن این مطلب با بی‌علاقگی عقب کشیدم.
آنقدر از عمر من گذشته است که برای چند ماهی در دهه ۷۰ با FORTRAN برنامه نویسی کرده باشم. اکثر هکرهای این دوره چنین نیستند ولی به نظر می‌رسد فرهنگ ما به گونه‌ای ، خاطره ای دقیق وسنتی از اینکه آن زبانهای قدیمی با محدوده ثابت چقدر عذاب آور بودند حفظ کرده باشد. "فرمت آزاد"، که درآن زمان برای توصیف حالت جدیدتر سینتکس token-oriented زبانهای C و پاسکال استفاده می‌شد، تقریبا فراموش شده است؛ چندین دهه است تمامی زبانها اینگونه طراحی شده اند، یا تقریبا تمام زبانها. بسیار سخت است کسی را، پس از دیدن این ویژگی پیتون، به خاطر عکس العمل اولیه ای مانند اینکه به صورت غیرمنتظره در انبوهی از بی‌ادبی! دایناسور قدم گذاشته است سرزنش کرد.
این احساس من در آن زمان بود. من بدون علاقه چندانی از کنار بقیه توضیحات این زبان گذاشتم. من دلیل چندان دیگری برای توصیه پیتون پیدا نکردم به جز اینکه احتمالا سینتکس آن تا حدی شسته و رفته تر از پرل بود و امکانات موجود برای اجرای CGI های ابتدایی مانند دکمه ها و منوها بسیار خوب به نظر می‌رسید.
من کتاب را با این یادآوری ذهنی که باید زمانی یک پروژه کوچک با محوریت GUI انجام دهم، تا مطمئن شوم که واقعا این زبان را می‌فهمم، در قفسه گذاشتم. ولی باور نداشتم چیزی که دیده‌ام هرگز بتواند به طور موثر با پرل رقابت کند.
اتفاقات زیادی باعث شدند این یادآوری ذهنی ماه‌ها در فهرست اولویت‌های من در مکان آخر قرار بگیرد. بقیه سال ۱۹۹۷ برای من پر از اتفاقات بود، در کنار بقیه اتفاقات، این سالی بود که من نسخه اصلی
"کلیسای اعظم و بازار
" را نوشته و منتشر کردم
. در عین حال من فرصت یافتم تا چندین برنامه پرل بنویسم، از جمله دو برنامه با حجم و پیچیدگی قابل توجه
. یکی از آنها،
keeper، برنامه دستیاری است که همچنان برای بایگانی پرونده‌های ارسالی وارده در شرکت نرم افزاری
Metalab به کار می‌رود
. این برنامه تولیدکننده صفحات وبی است که شما در
http://metalab.unc.edu/pub/Linux/!INDEX.html مشاهده می‌کنید
. برنامه دیگر،
anthologize، با هدف تولید خودکار
PostScript برای ششمین ویرایش لینوکس از آرشیو
"چگونه‌ها
" ی پروژه مستندسازی لینوکس استفاده شد
. هر دوی این برنامه ها در
Metalab موجود هستند
. نوشتن هر دوی این پروژه‌ها مرا بیشتر و بیشتر از پرل ناراضی کرد. به نظر می‌رسید پروژه‌های با اندازه بزرگتر یک نارضایتی ساده از پرل را تبدیل به مشکلات جدی و مداوم می‌نمایند. سینتکسی که در صد خط ابتدایی بسیار راضی کننده به نظر می‌رسید، با گذشت زمان تبدیل به توده‌ای از خارهای غیرقابل نفوذ می‌شد. "بیش از یک راه برای انجام کار" که حال و هوا و تاثیرگذاری خاصی به آن می‌بخشید، نگهداری یک استیل خاص در یک محدوده کد وسیعتر را به مقدار قابل توجهی مشکل می‌ساخت. و بسیاری قابلیت‌هایی که بعدا به منظور جوابگویی به نیاز برای کنترل پیچیدگی در برنامه های بزرگتر (اشیاء، lexical scoping ،use strict و ...) به پرل اضافه شده بودند حالتی شکننده و نه چندان دلچسب داشتند.
تمامی این مشکلات دست به دست یکدیگر داده بودند تا خواندن و درک حجم زیادی از کدهای پرل به عنوان یک کلیت را تنها پس از چند روز به صورت غیرمنطقی ای مشکل کنند. علاوه بر این، من دریافتم که روز به روز زمان بیشتری را به جای ور رفتن با برنامه خود، صرف ور رفتن با قابلیت‌های این زبان می‌کنم و بدتر از همه اینکه کد من زشت شده بود ، ... این مساله واقعی بود. برنامه های زشت مثل پل‌هایِ معلقِ زشت هستند، واژگون شدن آنها بسیار محتمل تر از انواع زیبای آنها است، زیرا نحوه ادراک انسانها (به خصوص مهندس- انسانها) از زیبایی رابطه بسیار نزدیکی با قابلیت ما برای پردازش و فهم پیچیدگی دارد. زبانی که کار نوشتن کد باوقار و باشکوه را سخت کند در حقیقت نوشتن کد خوب را مشکل کرده است.
با وجود یک دو جین زبان که به آنها تسلط داشتم، من می‌توانستم به تمامی علامات مشهود یک طراحی زبان که به منتهای قابلیت خود رسیده است و چیز بیشتری برای عرضه ندارد پی‌ببرم. من فکر کردم "باید راه بهتری وجود داشته باشد" و شروع به گشتن به دنبال یک زبان اسکریپت باشکوه تر کردم.
موردی که من حتی به آن فکر نکردم بازگشت به C به عنوان یک زبان پیش فرض بود. دوره ای که انجام مدیریت حافظه در یک برنامه به صورت شخصی معنا داشت، به جز در بعضی زمینه ها مانند طراحی هسته سیستم عامل (kernel hacking) ، برنامه نویسی علمی و گرافیک ۳ بعدی که در آنها شما نیاز دارید بیشترین سرعت و کنترل کامل بر روی استفاده از حافظه به منظور حداکثر استفاده از سخت افزار را داشته باشید، مدتهاست که گذشته است.
در اکثر موارد دیگر پذیرفتن بار اضافه debug کردن [ چندین اصطلاح را در این قسمت حذف کردم م.] و دیگر مشکلات از این دست در ماشین‌های امروزی دیوانگی است. بسیار عاقلانه تر است که چندین چرخه و چندین کیلوبایت حافظه برای نیازهای مدیر حافظه یک زبان اسکریپت فدا کنیم و در وقت گرانبهای انسان صرفه جویی کنیم. در حقیقت استفاده از این راهبرد (استراتژی) دقیقا همان چیزی است که باعث رشد انفجاری پرل از اوایل دهه ۹۰ شده است.
مدتی با Tcl ور رفتم تا متوجه شدم که در مقیاس‌های بالا حتی از پرل هم ضعیفتر عمل می‌کند. به عنوان یک برنامه نویس قدیمی LISP، همچنین نگاهی به اشکال ( dialects) مختلف رایج LISP و Scheme انداختم ولی همانگونه که از نظر تاریخی در مورد LISP معمول است، طراحی‌های هوشمندانه متعدد آن به دلیل عدم وجود یا ناقص بودن مستندات، دسترسی ناقص به امکانات POSIX/UNIX و یک جامعه کوچک و در عین حال بسیار پراکنده کاربران، بی استفاده شده بودند. پرطرفدار بودن پرل به هیچ عنوان یک تصادف نیست؛ اکثر رقبای آن یا برای پروژه‌های بزرگ بدتر از پرل هستند یا اصلا و ابدا به آن مفیدی که ساختار نظری برتر آنها انتظارش را ایجاد می‌کند نیستند.
نگاه دومی من به پیتون تقریبا همانقدر تصادفی بود که نگاه اول. در اکتبر ۱۹۹۷، یک سری سوالات در فهرست نامه های الکترونیک افراد استفاده کننده از fetchmail این موضوع را کاملا مشخص کرد که افراد برای ایجاد فایلهای تنظیمات برنامه fetchmail دچار مشکلات فزاینده‌ای می‌شوند. این فایل دارای ساختاری ساده و کلاس به سبک فرمت آزاد یونیکس است ولی می‌تواند هنگامی که کاربر دارای چندین حساب از نوع POP3 و IMAP باشد، به شدت پیچیده شود. به عنوان نمونه، برای دیدن یک مثال ساده شده از برنامه من به لیست ۱ نگاه کنید.
Listing 1. fetchmail Configuration File
set postmaster ``esr''
set daemon 300
poll imap.ccil.org with proto IMAP and options no dns
aka snark.thyrsus.com locke.ccil.org ccil.org
user esr there is esr here options fetchall dropstatus warnings 3600
poll imap.netaxs.com with proto IMAP
user "esr" there is esr here options dropstatus warnings 3600
skip imap.21cn.com with proto IMAP
user esr here is tranxww there options fetchall
skip pop.tems.com with proto POP3:
user esr here is ed there options fetchall
skip mail.frequentis.com with proto IMAP:
user esr here is imaptest there with options fetchall
من تصمیم گرفتم برای حل مشکل از یک ویرایشگر تنظیمات با حالتی کاربر پسند ( End-User-Friendly ) به نام fetchmailconf استفاده کنم. هدف از طراحی fetchmail مشخص بود؛ پنهان کردن کامل سینتکس فایل کنترل در پشت ظاهر شیک و صحیح از نظر ارگونومی یک رابط گرافیکی کاربر ( GUI ) با کلیدهای انتخاب، منوهای کشویی و فرمهای مختلف.
فکر پیاده کردن این برنامه با پرل چندان مرا ذوق زده نکرد. من کدهای GUI را در پرل دیده بودم که ترکیبی ناهمگون بود از پرل و Tcl که حتی از کد پرل خود برنامه هم زشت تر بود. در این لحظه بود که قولی را که ۶ ماه قبل داده بودم یادم آمد. این می‌توانست فرصتی برای کسب یک تجربه عملی با پیتون باشد.
البته این موضوع مجددا من را با بامعنی بودن فضای خالی در پیتون روبرو کرد. البته این بار تخته گاز پیش رفتم و مقداری کد برای انبوهی از عناصر GUI نوشتم. جدا ّ حیرت آور بود که تنها پس از ۲۰ دقیقه، استفاده پیتون از فضای سفید دیگر امر عجیبی به نظر نمی‌آمد. من همانقدر از فرورفتگی متن در پیتون استفاده می‌کردم که امکان داشت در C از آن استفاده کنم و این روش جواب هم می‌داد.
این اولین حیرت من بود. حیرت دومی ، حدود ۲ ساعت بعد (با احتساب زمان‌های توقفی که برای نگاه کردن به قابلیت‌های پیتون در کتاب Learning Python صرف شد) ، وقتی پیش آمد که متوجه شدم با همان سرعتی مشغول نوشتن برنامه‌های به دردبخور هستم که می‌توانم تایپ کنم. وقتی متوجه این موضوع شدم تقریبا مبهوت شدم. یکی از معیارهای مهم عملکرد در برنامه نویسی تعداد دفعاتی است که شما چیزی می نویسید که واقعا با درک شما از مساله همخوانی ندارد و ناچارید پس از فهمیدن این موضوع که چیزی که تایپ کرده‌اید، به زبان آنچه را شما فکر می کنید نمی‌گوید به عقب برگردید. یکی از معیارهای مهم طراحی مناسب زبان اینست که درصد چنین اشتباهاتی با تجربه پیدا کردن شخص در آن زبان با چه سرعتی کاهش می‌یابند.
هنگامی که شما با بیشترین سرعتی که قادرید تایپ کنید، برنامه به دردبخور می‌نویسید و اشتباهات شما در انتخاب مسیر تقریبا صفر است، این به آن معناست که شما در آن زبان به استادی رسیده‌اید. ولی این بی معنی بود، چون به زحمت یک روز از این موضوع گذشته بود و من هنوز مجبور بودم امکانات مربوط به زبان و کتابخانه‌ها را از روی کتاب نگاه کنم.
این اولین چیزی بود که به من فهماند من در پیتون با یک طراحی عالی سروکار دارم. اکثر زبانها آنقدر دارای تداخل و ضعف در طراحی خود هستند که شما قبل از اینکه ضریب اشتباهاتتان در آنها حتی نزدیک به صفر شود بسیاری از امکانات آنها را فرا گرفته اید. پیتون تنها زبان همه منظوره‌ای بود که من تا آن روز استفاده کرده بودم و این فرآیند را معکوس می‌کرد.
البته یادگیری مجموعه امکانات آن نیز چندان وقت گیر نبود. من یک برنامه fetchmailconf کارآ و قابل استفاده، به همراه GUI ، را در ۶ روز کاری نوشتم که از این ۶ روز احتمالا ۲ روز آن تماما صرف یادگیری خود پیتون شد. این موضوع نشان دهنده یک خاصیت مفید دیگر این زبان است: این زبان حالت اختصاری دارد، شما می‌توانید تمامی مجموعه امکانات آن (حداقل یک ایده فهرست وار از کتابخانه های آن) را در ذهن نگه دارید. C زبانی است که به اختصار معروف است. پرل در این زمینه شهرت خوبی ندارد. یکی از چیزهایی که عبارت معروف "بیش از یک راه برای انجام آن وجود دارد!" قربانی می کند توانایی مختصر بودن پرل است.
ولی هنوز رویایی ترین کشف من باقی مانده بود. طراحی من یک مشکل داشت: من قادر بودم به راحتی فایلهای تنظیم را با استفاده از عملهای GUI کاربر تولید کنم ولی ویرایش آنها مشکل بزرگتری بود. یا بهتر است بگویم خواندن آنها به یک شکل قابل ویرایش کار مشکلی بود.
Parser به کار رفته برای سینتکس فایل تنظیماتfetchmail بسیار کاربر بود. این برنامه در حقیقت با استفاده از YACC و Lex، دو ابزار کلاسیک یونیکس برای تولید کد parsing زبان در C، نوشته شده بود. تصور من این بود که برای اینکه قادر به ویرایش فایلهای تنظیمات در fetchmail باشم ناچار به تکرار همان parser وقت گیر در پیتون خواهم بود. من برای انجام این کار بسیار دودل بودم، تا حدودی به دلیل حجم کار و تا حدودی هم به دلیل اینکه نمیدانستم از کجا باید مطمئن باشم که دو parser در دو زبان مختلف مثل یکدیگر عمل خواهند کرد. کار فوق العاده زیاد همخوان نگاه داشتن دو parse آخرین چیزی بود که ممکن بود من با تحول زبانها به آن نیاز داشته باشم.
این مشکل برای مدتی مرا متوقف کرد. بعد از این فکری به ذهنم رسید: من به fetchmailconf اجازه می‌دادم از parser خود استفاده کند. من یک گزینه –configdump به fetchmail اضافه کردم و نتیجه را در یک خروجی استاندارد با فرمت یک initializer پیتون تخلیه کردم. برای فایل بالایی، نتیجه تقریبا شبیه به لیست ۲ بود (برای صرفه جویی در فضا بعضی داده های غیرمرتبط با مثال حذف شده اند).
Listing 2. fetchmailrc
fetchmailrc = {
'poll_interval':300,
"logfile":None,
"postmaster":"esr",
'bouncemail':TRUE,
"properties":None,
'invisible':FALSE,
'syslog':FALSE,
# List of server entries begins here
'servers': [
# Entry for site `imap.ccil.org' begins:
{
"pollname":"imap.ccil.org",
'active':TRUE,
"via":None,
"protocol":"IMAP",
'port':0,
'timeout':300,
'dns':FALSE,
"aka":["snark.thyrsus.com", "locke.ccil.org", "ccil.org"],
'users': [
{
"remote":"esr",
"password":"Malvern",
'localnames':["esr"],
'fetchall':TRUE,
'keep':FALSE,
'flush':FALSE,
"mda":None,
'limit':0,
'warnings':3600,
}
, ]
}
,
# Entry for site `imap.netaxs.com' begins:
{
"pollname":"imap.netaxs.com",
'active':TRUE,
"via":None,
"protocol":"IMAP",
'port':0,
'timeout':300,
'dns':TRUE,
"aka":None,
'users': [
{
"remote":"esr",
"password":"d0wnthere",
'localnames':["esr"],
'fetchall':FALSE,
'keep':FALSE,
'flush':FALSE,
"mda":None,
'limit':0,
'warnings':3600,
}
, ]
}
,
# Entry for site `imap.21cn.com' begins:
{
"pollname":"imap.21cn.com",
'active':FALSE,
"via":None,
"protocol":"IMAP",
'port':0,
'timeout':300,
'dns':TRUE,
"aka":None,
'users': [
{
"remote":"tranxww",
"password":None,
'localnames':["esr"],
'fetchall':TRUE,
'keep':FALSE,
'flush':FALSE,
"mda":None,
'limit':0,
'warnings':3600,
}
, ]
}
,
# Entry for site `pop.tems.com' begins:
{
"pollname":"pop.tems.com",
'active':FALSE,
"via":None,
"protocol":"POP3",
'port':0,
'timeout':300,
'dns':TRUE,
'uidl':FALSE,
"aka":None,
'users': [
{
"remote":"ed",
"password":None,
'localnames':["esr"],
'fetchall':TRUE,
'keep':FALSE,
'flush':FALSE,
"mda":None,
'limit':0,
'warnings':3600,
}
, ]
}
,
# Entry for site `mail.frequentis.com' begins:
{
"pollname":"mail.frequentis.com",
'active':FALSE,
"via":None,
"protocol":"IMAP",
'port':0,
'timeout':300,
'dns':TRUE,
"aka":None,
'users': [
{
"remote":"imaptest",
"password":None,
'localnames':["esr"],
'fetchall':TRUE,
'keep':FALSE,
'flush':FALSE,
"mda":None,
'limit':0,
'warnings':3600,
}
, ]
}
]
}
پیتون سپس قادربود خروجی fetchmail--configdump را ارزیابی کند و سپس تنظیمات را به صورت مقدار متغیر "fetchmail" ارائه کند.
حتی این هم آخرین حرکت رقص من نبود. چیزی که من می‌خواستم صرفا این نبود که fetchmail تنظیمات فعلی خود را داشته باشد بلکه می خواستم آن را تبدیل به یک ساختار درختی از اشیا زنده (live objects) کنم. احتمالا در این درخت سه نوع شی وجود داشت: تنظیمات ( که شیء واقع در بالاترین مرتبه و نشان دهنده کل تنظیمات بود)؛ سایت (نشان دهنده یکی از سایتهایی که باید به رای گذاشته می‌شد.) و کاربر ( نشان دهنده داده‌های کاربران که به سایت متصل می‌شود). فایلهای مثال پنج شیء از نوع سایت که به هر کدام یک شیء از نوع کاربر متصل شده است را نشان می‌دهد.
تا اینجا من سه شیء کلاس را طراحی کرده و نوشته بودم (این همان چیزی بود که چهار روز از وقت من را گرفت که اکثر آن هم صرف چیدن درست و مناسب کنترلهای صفحه شد). هر یک از این کلاسها یک متد داشت که باعث می شد برای ویرایش داده های آن instance خاص یک صفحه GUI باز شود. تنها مشکل باقیمانده من یافتن روشی برای تبدیل اشیاء مرده این برنامه initializer پیتون به اشیاء زنده بود.
چیزی که به نظر من رسید نوشتن کدی بود که به وضوح راجع به ساختار هر سه کلاس بداند و از این دانش برای پلکیدن در initializer و ایجاد اشیایی که پاسخگوی نیازها باشند استفاده کند ولی این ایده را رد کردم زیرا اعضای این کلاس جدید احتمالا با اضافه شدن امکانات جدید به تنظیمات زیاد می شدند. اگر من کد ایجاد اشیا را با این روش مشهود می نوشتم، احتمال زیادی وجود داشت که کد حالت شکننده پیدا کند و با تغییر تعریفهای کلاس یا ساختار initializer از حالت به روز خارج شود.
چیزی که من واقعا به دنبالش بودم کدی بود که شکل و اعضای initializer را تجزیه و تحلیل کند، از تعریفهای کلاس برای پرس و جو درباره اعضای آن کلاس استفاده کند و سپس خودش را با این دو مجموعه هماهنگ کند.
به این گونه چیزها در اصطلاح هک کردن metaclass گفته می شود و در حالت عمومی چیزی به ترسناکی جادوی سیاه به شمار می‌روند. اکثر زبانهای برنامه نویسی شیءگرا مطلقا از این قابلیت پشتیبانی نمی‌کنند و در آنهایی که این کار را می کنند (که پرل هم یکی از آنهاست)، این موضوع امری پیچیده و ظریف و شکننده است. تا همان زمان من از ضریب بسیار پایین اشکال سازی پیتون متعجب شده بودم ولی این یک آزمایش واقعی بود. برای اینکه این زبان را مجبور به انجام چنین کاری کنم چقدر باید با آن کشتی می‌گرفتم؟ با استفاده از تجربیات قبلی می‌دانستم که ، حتی با این فرض که من ببرم، این می تواند تجربه دردناکی باشد ولی روی کتاب شیرجه رفتم و شروع به مطالعه امکانات metaclass پیتون کردم. تابع به دست آمده در لیست ۳ نشان داده شده است و کدی که فراخوانی می کند در لیست ۴ آمده است.
Listing 3. Metaclass Function
def copy_instance(toclass, fromdict):
# Initialize a class object of given type from a conformant dictionary.
class_sig = toclass.__dict__.keys(); class_sig.sort()
dict_keys = fromdict.keys(); dict_keys.sort()
common = intersect(class_sig, dict_keys)
if 'typemap' in class_sig:
class_sig.remove('typemap')
if tuple(class_sig) != tuple(dict_keys):
print "Conformability error"
# print "Class signature: " + `class_sig`
# print "Dictionary keys: " + `dict_keys`
print "Not matched in class signature: " + `setdiff(class_sig, common)`
print "Not matched in dictionary keys: " + `setdiff(dict_keys, common)`
sys.exit(1)
else:
for x in dict_keys:
setattr(toclass, x, fromdict[x])
Listing 4. Code that Calls Metaclass Function
# The tricky part--initializing objects from the
# configuration global
# `Configuration' is the top level of the object
# tree we're going to mung
Configuration = Controls()
copy_instance(Configuration, configuration)
Configuration.servers = [];
for server in configuration[`servers']:
Newsite = Server()
copy_instance(Newsite, server)
Configuration.servers.append(Newsite)
Newsite.users = [];
for user in server['users']:
Newuser = User()
copy_instance(Newuser, user)
Newsite.users.append(Newuser)
برای جادوی سیاه چندان بد به نظر نمی‌رسد، اینطور نیست ؟ سی و دو خط با احتساب توضیحات. فقط با توجه به چیزهایی که من درباره ساختار کلاسها گفتم، حتی کد فراخوان نیز قابل خواندن است. ولی اندازه این کد موضوع شوکه کننده نیست. خودتان را کنترل کنید: نوشتن این کد تنها ۹۰ دقیقه وقت گرفت و در اولین باری که من آن را اجرا کردم به خوبی کار کرد.
تنها گفتن این که من حیرت زده شده بودم می‌تواند کم لطفی باشد. درست و به خوبی کار کردن پیاده سازی حتی ساده ترین تکنیکها در اولین بار همانگونه که انتظار می‌رفته می‌تواند امری قابل توجه باشد؛ ولی اولین هک کردن metaclass من تنها پس از ۶ روز از یک شروع بی مقدمه؟ حتی اگر به اغراق بگوییم که من یک هکر با استعداد هستم این یک موفقیت بزرگ برای پیتون در زمینه شفافیت و شکوه و عظمت طراحی است.
تقریبا هیچ راهی وجود نداشت که من بتوانم با وجود تجربه بسیار زیادترم در پرل عمل مشابهی را با استفاده از آن انجام دهم. در این زمان بود که احساس کردم که احتمالا پرل را ترک خواهم کرد.
این رویایی ترین لحظه من در پیتون بود. ولی حالا که همه اینها تمام شده باید بگویم تمام اینها یک هک هوشمندانه بود. مفید بودن یک زبان برنامه نویسی در بلند مدت بستگی به پشتیبانی آنها از هک های هوشمندانه ندارد بلکه به چند و چون پشتیبانی آن از امور روزمره برنامه نویسی مرتبط است. کار روزمره برنامه نویسی اکثرا به جای نوشتن برنامه های جدید، از خواندن و تغییر دادن برنامه های موجود تشکیل می شود.
مساله تکان دهنده اینجاست: هفته‌ها و ماه‌ها پس از نوشتن fetchmailconf، من هنوز قادر بودم کد آن را بخوانم و بدون هیچ تلاش فکری جدی ای متوجه بشوم که چکار می‌کند و دلیل واقعی این موضوع که من دیگر برای هیچ چیزی جز پروژه‌های کوچک از پرل استفاده نمی‌کنم این است که این موضوع هرگز در مورد پرل صادق نبود. من حتی از تصور این موضوع که زمانی ناچار شوم keeper یا anthologize را تغییر دهم به وحشت می‌افتم در حالیکه برای انجام چنین کاری در مورد fetchmailconf ککم هم نمی‌گزد.
پرل همچنان کاربردهای خود را دارد. برای پروژه‌های کوچک (۱۰۰ خط یا کمتر) که شامل مقدار زیادی جور کردن الگوی متن است، من احتمالا بیشتر از یک راه حل با استفاده از پرل استقبال می‌کنم تا پیتون. برای دیدن چندین مثال خوب، برنامه های timeseries و growplot را در فهرست توزیع fetchmail مشاهده کنید. در حقیقت، اینها تا حد زیادی شبیه کاری هستند که پرل در نقش اصلی خود، قبل از اینکه دارای توابع و دسترسی مستقیم به API سیستم عامل باشد، به عنوان نوعی ترکیب awk/sed/grep/sh انجام می‌داد. برای هر چیز بزرگتر یا پیچیده تر، من عادت کرده‌ام که ارزشهای لطیف پیتون را ترجیح بدهم و فکر کنم شما نیز همین کار را انجام بدهید.
چرا زبان پیتون؟
نمي كنيد
پاسخ با نقل قول
