سرزمين دانلود

یاهو- پردازنده دو هسته‌ای مک بوک ۲۰۱۰ از ۲۶/۲ گیگاهرتز به ۴/۲ گیگاهرتز ارتقا یافته است. همچنین تراشه گرافیکی GeForce 320M جایگزین تراشه قدیمی GeForce 9400M شده است که به گفته اپل، قدرت پردازش گرافیکی مک بوک را تا ۸۰ درصد ارتقا می‌دهد. آخرین به روز  رسانی مک بوک پرو در ماه اکتبر ۲۰۰۹ صورت گرفته بود.

مک بوک جدید همچنین برای انجام کارهای روزانه مانند چک کردن ایمیل‌ها و گشت و گذار در وب مناسب‌تر است. اپل ادعا می‌کند طول عمر باتری مک بوک ۲۰۱۰ به ۱۰ ساعت تمام افزایش یافته که این رقم سه ساعت بیشتر از طول عمر باتری مدل قبلی مک بوک است. با وجود این نمی‌توان به ادعای اپل تکیه کرد و باید دید باتری مک بوک در کاربری‌های گوناگون تا چند ساعت دوام خواهد آورد.

این نوت بوک ۱۳ اینچی که هم‌اکنون در فروشگاه آنلاین اپل قابل سفارش و خریداری است، دارای رنگ بدنه سفید مدل قبلی این سری نوت بوک است. رم ۲ گیگابایتی و هارد درایو ۲۵۰ گیگابایتی از دیگر ویژگی های مک بوک ۲۰۱۰ است که نسبت به مدل قبلی دست نخورده باقی مانده است.

رم این مدل از مک بوک تا ۴ گیگابایت و هارد درایو آن هم تا ۳۲۰ یا ۵۰۰ گیگابایت قابل ارتقاست.

با ارتقای مک بوک ۹۹۹ دلاری، تنها محصول خانواده نوت‌بوک‌های اپل که هنوز ارتقا پیدا نکرده، “مک بوک ایر” است. ابتدایی‌ترین مدل مک بوک ایر هزار و ۴۹۹ دلار قیمت دارد و به پردازنده ۸۶/۱ گیگاهرتزی اینتل و هارد درایو ۱۲۰ گیگابایتی مجهز است.

تصمیم دبیان (م: یک توزیع معروف گنو/لینوکس) مبنی بر شامل سازی مونو (م: یک پیاده سازی آزاد از دات نت که در گنو/لینوکس قابل استفاده است) در روش اصلی نصب گنوم (GNOME)، بخاطر Tomboy که یک اپلیکیشن نوشته شده با سی شارپ است، اجتماع (م: اجتماع نرم افزار آزاد) را به یک جهت خطر پذیر سوق میدهد.
وابسته بودن به سی شارپ خطرناک است، پس ما نیاز داریم تا استفاده از آنرا نهی کنیم.

مشکل صرفا مختص مونو نیست؛ هر پیاده سازی آزاد از سی شارپ مسئلهء یکسانی را برمی انگیزد. خطر اینست که احتمالا مایکروسافت بطور پنهان در حال طرح ریزی مجبور کردن قانونی تمام پیاده سازی های آزاد سی شارپ در وقت نامعینی است (en.swpat.org و League for Programming Freedom (LPF) را ببینید). این یک خطر جدی است، و تنها احمق ها آنرا تا وقتیکه آن عملا اتفاق بیفتند نادیده خواهند گرفت. ما احتیاج داریم احتیاط هایی را اکنون برای حفاظت از خودمان از این خطر آینده درپیش بگیریم.

این بدین معنا نیست که پیاده سازی سی شارپ یک چیز بد است. پیاده سازی های آزاد سی شارپ به کاربران اجازه میدهند تا برنامه های سی شارپ خود را روی پلتفرمهای آزاد اجرا کنند، که خوب است (پروژهء گنو همچنین یک پیاده سازی از سی شارپ دارد که Portable.NET نامیده میشود – DotGNU Portable.NET). بطور ایدئال ما میخواهیم پیاده سازی آزاد برای تمامی زبانهایی که برنامه نویسها استفاده کرده اند فراهم کنیم.

مشکل در پیاده سازی های سی شارپ نیست، بلکه بیشتر در Tomboy و دیگر اپلیکیشن های نوشته شده در سی شارپ است. اگر ما امکان استفاده از سی شارپ را از دست بدهیم، ما همچنین تمامی آنها را هم از دست خواهیم داد. این آنها را غیراخلاقی نمی سازد، اما بدین معناست که نوشتن و استفاده کردن از آنها یک ریسک بدون مزیت است.

ما باید بطور سیستماتیک چنان سازماندهی کنیم تا هرچه کمتر که ممکن است به پیاده سازیهای آزاد سی شارپ وابسته باشیم. به بیان دیگر، ما باید مردم را از نوشتن برنامه ها در سی شارپ نهی کنیم. بنابراین ما نباید پیاده سازیهای سی شارپ را در نصب پیشفرض توزیعهای گنو/لینوکس یا راههای اصلی نصب گنوم شامل کنیم، و ما باید هروقت که ممکن است، اپلیکیشن های غیر سی شارپ را بجای اپلیکیشن های معادل سی شارپ توزیع و توصیه کنیم.

——————————————————

یک نسخهء پیشتر از این مقاله به غلط اظهار کرده بود که مونو اکنون بصورت پیشفرض در دبیان نصب خواهد شد. ما این متن را تصحیح کردیم، و بخاطر اشتباه معذرت میخواهیم.

Last modified 2009-10-08 05:02 PM

مولف: A.M. Kuchling

-= چکیده =-

معمولا دشوار است که مدیریت خود را راضی کنید نرم افزار باز متن را بپذیرد، و پایتون استثنایی بر این قاعده نیست. این مقاله دربارهء دلایل استفاده از پایتون بحث میکند، استراتژی هایی برای مقبولیت یافتن، واقعیت ها و استدلال هایی که شما میتوانید استفاده کنید، و مواردی که شما نباید تلاش کنید از پایتون استفاده کنید.

-= دلایل استفاده از پایتون =-

چندین دلیل برای سهیم کردن یک زبان اسکریپتی در فرایند توسعهء شما وجود دارند، و این بخش دربارهء آنها بحث خواهد کرد، و اینکه چرا پایتون بعضی ویژگیهایی دارد که آنرا یک انتخاب مخصوصا مناسب میسازند.

-= قابلیت برنامه پذیری =-

برنامه ها اغلب در یک روش ماجول وار سازماندهی میشوند. عملیات سطح پایینتر با هم گروه بندی شده اند، و توسط توابع سطح بالاتر فراخوانی میشوند، که به نوبه خود توسط سطوح بالاتر بعنوان عملیات پایه استفاده میشوند.
برای مثال، پایین ترین سطح ممکن است یک مجموعه خیلی سطح پایین از توابع برای دسترس به یک نگاشت (hash table) را تعریف کند. سطح بعدی ممکن است نگاشت ها را برای ذخیره هدرهای یک پیام ایمیل استفاده کند که بطور مثال یک نام هدر (سرآیند – header) مثل تاریخ (Date) را به یک مقدار مانند Tue, 13 May 1997 20:00:54 -0400 نگاشت میکند. یک سطح بالاتر ممکن است روی اشیاء پیام کار کند، بدون دانستن یا اهمیت دادن به اینکه هدرهای پیام در یک جدول نگاشت ذخیره شده اند، و الی آخر به همین صورت.
اغلب، پایین ترین سطوح کارهای خیلی ساده ای انجام میدهند؛ آنها یک ساختار داده همچون یک درخت باینری یا یک جدول نگاشت را پیاده سازی میکنند، یا آنها یک محاسبهء ساده انجام میدهند، مثل تبدیل یک تاریخ بصورت متن به یک عدد. سطوح بالاتر سپس محتوی منطقی هستند که این عملیات پایه ای را به یکدیگر متصل میکند. با استفاده از این روش، اجزای پایه ای میتوانند بعنوان قطعات سازنده ای که سپس برای تولید یک محصول کامل بهم متصل میشوند تصور شوند.
چرا این روش طراحی به پایتون مربوط است؟ چون پایتون خوب مناسب عمل کردن بعنوان چنان زبان متصل کننده ای است. یک روش متداول نوشتن یک ماجول پایتون است که عملیات سطح پایین را پیاده سازی میکند؛ بخاطر سرعت، پیاده سازی ممکن است با سی، جاوا یا حتی فورترن باشد. به محض اینکه پایه ای ها در دسترس پایتون قرار گرفتند، منطق زیربنایی عملیات سطح بالاتر بصورت کد پایتون نوشته میشود. منطق سطح بالا سپس قابل فهم تر و آسانتر برای تغییر دادن است.
John Ousterhout یک مقاله با عنوان «اسکریپت نویسی: برنامه نویسی سطح بالاتر برای قرن ۲۱» نوشت که این ایده را با طول بیشتر شرح میدهد. من توصیه میکنم که شما این مقاله را بخوانید؛ رفرنس ها را برای آدرس نگاه کنید. Ousterhout مخترع زبان Tcl است و بنابراین استدلال میکند که Tcl باید برای این منظور استفاده شود؛ اون تنها مختصرا به زبانهای دیگر همچون پایتون، پرل، و Lisp/Scheme اشاره میکند، اما در واقع استدلال های Ousterhout در کل درمورد زبانهای اسکریپتی مصداق دارد، چون شما میتوانستید بطور یکسانی extension را برای هریک از زبانهای مذکور بنویسید.

-= نمونه اولیه =-

در مرد شب پره ای افسانه ای (م: کتابی درمورد مهندسی نرم افزار و مدیریت پروژه)، Fredrick Brook قاعدهء زیر را در هنگام طراحی پروژه های نرم افزاری پیشنهاد میکند: «درنظر داشته باشید تا یکی را دور بریزید؛ شما بهرحال اینکار را خواهید کرد». Brooks میگوید که اقدام نخست در طراحی یک نرم افزار اغلب اشتباه از آب درمی آید؛ مگر اینکه مسئله خیلی ساده باشد یا شما یک طراح بینهایت خوب باشید، شما درخواهید یافت که نیازها و ویژگیهای جدید وقتیکه توسعه عملا شروع شد نمایان میشوند. اگر این نیازهای جدید نتوانند بصورت تمیزی در ساختار برنامه یکپارچه شوند، شما با دو انتخاب ناخوشایند رودرور هستید: هر طور که هست ویژگیهای جدید را در برنامه زور چپان کنید، یا همه چیز را اوراق کرده و یک نسخهء جدید از برنامه را با درنظر داشتن ویژگیهای جدید از ابتدا، بنویسید.
پایتون یک محیط خوب برای شما برای توسعهء سریع یک نمونه اولیه نخستین فراهم میکند. که به شما اجازه میدهد ساختار و منطق کلی برنامه را درست کنید، و شما میتوانید جزییات کوچک را در چرخهء توسعهء سریعی که پایتون فراهم میکند بخوبی تنظیم کنید. وقتیکه شما از رابط گرافیکی یا خروجی برنامه راضی شدید، میتوانید کد پایتون را به سی++، فورترن، جاوا، یا زبان کامپایل شوندهء دیگری ترجمه کنید.
تهیه نمونه اولیه به معنای آنست که شما باید محتاط باشید تا از ویژگیهای زیادی از زبان پایتون که پیاده سازی آنها در زبانهای دیگر دشوار است بیش از حد استفاده نکنید. استفاده از تابع eval، یا عبارت منظم (regular expressions)، یا ماجول pickle، به معنای آنست که بطور مثال شما به کتابخانه های سی یا جاوا برای ارزیابی فرمول، عبارات منظم، و serialization نیاز خواهید داشت. اما اجتناب از چنان کد گمراه کننده ای دشوار نیست، و در پایان ترجمه معمولا خیلی دشوار نیست. کد حاصل شده میتواند با سرعت عیب یابی شود، زیرا هر خطای جدی منطقی از نمونهء اولیه زدوده شده خواهد بود، که تنها خطاهای کوچک را در ترجمه باقی میگذارد.
این استراتژی بر بحث قبلتر دربارهء برنامه پذیری استوار است. استفاده از پایتون بعنوان یک متصل کننده برای اتصال اجزای سطح پایینتر ارتباط واضحی برای ساخت سیستم های نمونه اولیه دارد. به این روش پایتون میتواند در توسعه به شما کمک کند، حتی اگر کاربران نهایی هرگز به هیچ صورتی در تماس با کد پایتون نباشند. اگر کارایی (performance) نسخهء پایتون کافی باشد و سیاست های شرکتی آنرا اجازه دهند، شما ممکن است نیازی به انجام یک ترجمه به سی یا جاوا نداشته باشید، اما توسعهء یک نمونه اولیه و سپس ترجمه کردن آن میتواند هنوز سریعتر باشد، بجای تلاش کردن برای تولید فوری نسخهء نهایی.
یک مثال از این استراتژی توسعه Microsoft Merchant Server است. نسخهء ۱٫۰ در پایتون خالص نوشته شده بود، بوسیلهء یک شرکت که متعاقبا توسط میکروسافت خریداری شد. نسخهء ۲ شروع به ترجمهء کد به سی++ کرد و همراه با مقداری کد سی++ و مقداری کد پایتون ارائه شد. نسخهء ۳٫۰ هیچ کد پایتونی نداشت؛ و کد به سی++ ترجمه شده بود. گرچه محصول حتی محتوی یک مفسر پایتون نیست، اما زبان پایتون هنوز بوسیلهء بالا بردن سرعت توسعه در خدمت یک هدف مفید بوده است.
این یک استفادهء خیلی متداول از پایتون است. مقالات کنفرانس گذشته همچنین این روش را برای توسعهء الگوریتم های سطح بالای عددی شرح داده اند؛ مقالهء avid M. Beazley و Peter S. Lomdahl با عنوان «خوراندن یک کاربرد فیزیکی مقیاس وسیع به پایتون» را در رفرنسها برای یک مثال خوب ببینید. اگر عملیات های پایهء یک الگوریتم چیزهایی مثل «معکوس این ماتریس ۴۰۰۰ در ۴۰۰۰ را بگیر» باشند و در یک زبان سطح پایینتری پیاده سازی شده باشند، آنوقت پایتون تقریبا هزینهء اضافه ای ندارد؛ زمان اضافی مورد نیاز پایتون برای ارزیابی یک عبارت مثل m.invert() تحت الشعاع هزینهء عملیات واقعی قرار میگیرد. آن بویژه برای کاربردهایی که تغییرات جزیی ظاهرا بی پایان برای درست کردن چیزها مورد نیاز است خوب است. رابطهای گرافیکی کاربر و سایت های وب نمونه های نخست هستند.
کد پایتون همچنین کوتاهتر و سریعتر برای نوشتن است (وقتیکه شما با پایتون آشنا شدید)، بنابراین دور انداختن آن درصورتیکه شما تصمیم گرفتید که روش شما اشتباه بوده است آسانتر است؛ اگر شما بجای تنها دو ساعت دو هفته روی آن کار کرده بودید، ممکن بود زمان را در تلاش برای وصله و پینه کردن آن از روی یک بی میلی طبیعی برای پذیرفتن آنکه آن دو هفته هدر رفته بودند، هدر دهید. حقیقتا آن دو هفته هدر نرفته بودند، چون شما چیزی دربارهء مسئله و فناوری ای که شما برای حل آن استفاده میکنید آموخته اید، اما طبیعت بشر است که این را بعنوان یک نوع شکست ببیند.

-= سادگی و آسانی فهم =-

پایتون قطعا یک زبان اسباب بازی نیست از آنرو که آن برای کارهای کوچک قابل استفاده است. ویژگیهای زبان بقدر کافی عام و قدرتمند هستند تا آنرا قادر کنند تا برای خیلی مقاصد مختلف استفاده شود. آن در کارهای کوچک مفید است، برای اسکریپتهای ۱۰ یا ۲۰ خطی، اما همچنین تا سیستم های بزرگتری که هزاران خط کد را شامل میشوند تطبیق می یابد.
اما این گویایی به هزینهء یک دستور زبان مبهم یا گمراه کننده نیست. درحالیکه پایتون بعضی جوانب تاریکی دارد که میتوانند به کد مبهم منجر شوند، چنان جوانبی نسبتا معدود هستند، و طراحی مناسب میتواند استفادهء آنها را به تنها به معدودی از کلاسها یا ماجول ها ایزوله کند. قطعا نوشتن کد گیج کننده بوسیلهء استفاده از تعداد بیش از حد ویژگیها با توجه و روشنی کم ممکن است، اما بیشتر کد پایتون میتواند خیلی شبیه یک نسخهء اندکی رسمی شده از شبه کد (pseudocode) قابل فهم برای بشر بنظر برسد.

در فرهنگ لغت جدید هکر، Eric S. Raymond تعریف زیر را برای «فشرده» ارائه میکند:
صفت فشرده از یک طراحی، دارایی ارزشمندی را توصیف میکند که میتواند یکباره در مغز کسی دریافت شود. این عموما به معنای آنست که چیزی که از طرح ایجاد شده است میتواند با سهولت بیشتر و خطاهای کمتری نسبت به یک ابزار معادل که فشرده نیست استفاده شود. فشرده بودن مفهوم جزیی بودن یا کمبود قدرت را نمیرساند؛ برای مثال، سی فشرده است و فورترن نیست، اما سی از فورترن قدرتمندتر است. طراحی ها بوسیلهء افزوده شدن تدریجی ویژگیها و قطعاتی که بصورت تمیزی در طراحی کلی ادغام نمیشوند غیر فشرده میشوند (از اینرو، بعضی طرفداران سی کلاسیک معتقد هستند که ANSI C دیگر فشرده نیست).
منبع: compact

در این معنای کلمه، پایتون کاملا فشرده است، زیر زبان تنها ایده های معدودی دارد، که در جاهای خیلی زیادی استفاده شده اند. برای مثال namespace ها را فرض کنید. یک ماجول را با import math وارد (Import) کنید، و شما یک namespace بنام math ایجاد میکنید. کلاسها همچنین فضاهای نامی (namespace) ای هستند که خیلی از ویژگیهای ماجول ها را به اشتراک دارند، و معدودی هم مال خودشان؛ برای مثال، شما نمونه هایی (instances) از یک کلاس ایجاد میکنید. نمونه ها؟ آنها فضاهای نامی دیگری هستند. فضاهای نامی درحال حاضر بصورت جدول های نگاشت پایتون (dictionaries) پیاده سازی شده اند، بنابراین آنها متدهای یکسانی با نوع دادهء دیکشنری دارند: keys() همهء کلیدها را برمیگرداند، و غیره.
این سادگی از تاریخچهء توسعهء پایتون برمی آید. دستور زبان از منابع متفاوتی مشتق میشود؛ ABC، یک زبان نسبتا مبهم آموزشی، یک منبع تاثیرپذیری اولیه است، و Modula-3 دیگری است (برای اطلاع بیشتر درمورد ABC و Modula-3 به سایتهای آنها در A Short Introduction to the ABC Language و http://www.m3.org مراجعه کنید). بقیهء ویژگیها از سی، Icon، Algol-68 و حتی پرل آمده اند. پایتون واقعا چیز زیادی اختراع نکرده است، اما درعوض تلاش کرده است تا زبان را کوچک و آسان برای یادگیری نگه دارد، با بنا کردن بر روی ایده هایی که در زبانهای دیگر آزموده شده و مفید یافته شده اند.
سادگی یک خصیصه است که نباید دست کم گرفته شود. آن به شما اجازه میدهد زبان را سریعتر یاد بگیرید، و سپس سریع کد بنویسید – کدی که اغلب برای اولین باری که شما آنرا اجرا میکنید کار میکند.

-= یکپارچگی با جاوا =-

اگر شما با جاوا کار میکنید، Jython قطعا ارزش توجه شما را دارد. Jython یک پیاده سازی مجدد پایتون در جاوا است که کد پایتون را به بایت کد جاوا کامپایل میکند. محیط حاصل شده یکپارچگی نفوذ ناپذیر تقریبا بدون درزی با جاوا دارد. دسترسی به کلاسهای جاوا از پایتون کاری بسیار کوچک است، و شما میتوانید کلاسهای پایتونی بنویسید که کلاسهای جاوا را مشتق میکنند. Jython میتواند برای نمونه سازی اولیهء اپلیکیشن های جاوا خیلی یکسان با روشی که CPython استفاده میشود استفاده شود، و همچنین میتواند برای مجموعه تست ها برای کد جاوا استفاده شود، یا در داخل یک اپلیکیشن جاوا برای اضافه کردن قابلیت های اسکریپت نویسی تعبیه شود.

-= ادعاهای مخالف و تکذیب ها =-

بگذارید بگوییم شما تصمیم گرفته اید پایتون را بعنوان بهترین انتخاب برای اپلیکیشن خودتان استفاده کنید. چطور شما میتوانید مدیریت خود یا توسعه دهندگان همکار را به استفاده از پایتون قانع کنید؟ این بخش استدلال های مخالف متداول درمقابل استفاده از پایتون را لیست میکنید، و تکذیب های ممکنی را فراهم میکند.

– پایتون نرم افزار مجانی ای است که هیچ چیزی نمی ارزد. آن میتواند چقدر خوب باشد؟
درواقع خیلی خوب. این روزها لینوکس و آپاچی دو قطعه از نرم افزار باز متن هستند که بعنوان جایگزینی برای نرم افزار تجاری درحال پذیرش بیشتری هستند، اما پایتون آنقدر عمومیت نداشته است.
پایتون سالهاست وجود داشته است، با تعداد زیادی کاربر و توسعه دهنده. متناسبا، مفسر بوسیلهء تعداد زیادی از افراد استفاده شده است، و بیشتر باگها از آن تکانده شده اند. درحالیکه باگها هنوز در فواصلی کشف میشوند، آنها معمولا کاملا مبهم هستند (آنها باید میبودند چراکه هیچکس قبلا با آنها مواجه نشده بود) یا آنها با رابطهایی به کتابخانه های خارجی درگیر هستند. اجزای داخلی زبان خودشان کاملا پایدار هستند.
داشتن کد منبع باید بعنوان فراهم کردن نرم افزار برای بازنگری همردیفان تلقی شود؛ افراد میتوانند کد را امتحان کنند، بهبودهایی را پیشنهاد (و پیاده سازی) کنند، و باگها را ردیابی کنند. برای فهمیدن بیشتر درمورد ایدهء کد متن باز، همراه استدلال ها و موارد تحقیق پشتیبانی کنندهء آن به Home | Open Source Initiative مراجعه کنید.

– چه کسی میخواهد آنرا پشتیبانی کند؟
پایتون یک اجتماع قابل ملاحظه از توسعه دهندگان دارد، و تعداد هنوز درحال رشد است. اجتماع اینترنتی احاطه کنندهء زبان یکی از فعال هاست، و میتواند بعنوان یکی دیگر از مزایای پایتون تلقی شود. بیشتر پرسشهای پست شده به گروه خبری comp.lang.python بسرعت بوسیلهء کسی پاسخ داده میشوند.
اگر شما باید در عمق کد منبع فرو بروید، آنرا روشن و خوب سازماندهی شده خواهید یافت، پس نوشتن توسعه ها (extensions) و ردیابی باگها خیلی دشوار نیست. اگر شما ترجیح میدهید برای پشتیبانی پول بپردازید، شرکتها و اشخاصی وجود دارند که پشتیبانی تجاری برای پایتون ارائه میکنند.

– چه کسی پایتون را برای کار جدی ای استفاده میکند؟
خیلی از افراد؛ یک چیز جالب درمورد پایتون تنوع غافلگیرکنندهء اپلیکیشن هایی است که برای آنها استفاده شده است. مردم پایتون را برای اجرای وب سایت ها، نوشتن رابطهای گرافیکی کاربر، کنترل کدهای پردازش اعداد روی ابررایانه ها، اضافه کردن قابلیت اسکریپت نویسی به یک اپلیکیشن تجاری با تعبیه کردن مفسر پایتون در آن، پردازش مجموعه داده های بزرگ XML، ساخت مجموعه تست ها برای سی یا جاوا استفاده میکنند.
حیطهء اپلیکیشن شما هرچیزی که هست، احتمالا کسی وجود دارد که پایتون را برای چیز مشابهی استفاده کرده است. اما علیرغم قابل استفاده بودن برای چنان اپلیکیشن های سطح بالایی، پایتون هنوز بقدر کافی ساده هست تا برای کارهای کوچک استفاده شود.
آدرس OrganizationsUsingPython – PythonInfo Wiki را برای یک لیست از سازمانهایی که از پایتون استفاده میکنند ببینید.

– محدودیت ها بر روی استفاده از پایتون چه هستند؟
آنها عملا وجود ندارند. به فایل Misc/COPYRIGHT در توزیع کد منبع مراجعه کنید یا بخش History and License رفرنس برای کل زبان، اما آن به سه شرط خلاصه میشود:
- شما باید اعلان کپی رایت را بر روی نرم افزار باقی بگذارید (م: بنظرم درمورد خود پایتون)؛ اگر شما کد منبع را در یک محصول شامل نمیکنید، باید اعلان کپی رایت را در مستندات پشتیبانی کننده قرار دهید.
- ادعا نکنید که موسسه هایی که پایتون را توسعه داده اند محصول شما را به هیچ شکلی توصیه میکنند.
- اگر چیزی درست از آب درنیاید، شما نمیتوانید برای خسارت پیگرد قانونی کنید. بطور خاص تمام مجوزهای نرم افزاری محتوی این شرط هستند.
توجه کنید که شما مجبور نیستید کد منبع را برای هرچیزی که شامل پایتون است یا با آن ساخته شده است فراهم کنید. همچنین مفسر پایتون و مستندات همراه میتوانند به هر شکلی که شما دوست دارید تغییر پیدا کرده و توزیع شوند، و شما به هیچ وجه مجبور نیستید هیچ هزینهء مجوزی را به هیچکس پرداخت کنید.

– چرا ما باید یک زبان گمنام همچون پایتون را بجای زبان ایکس مشهور استفاده کنیم؟
من امیدوارم این راهنما، و مستندات لیست شده در بخش نهایی، کمک خواهند کرد که شما قانع شوید که پایتون گمنام نیست، و یک پایهء کاربری سلامت درحال رشد دارد. یک کلمه نصیحت: همیشه مزایای مثبت پایتون را ارائه کنید بجای اینکه روی ناتوانایی های زبان ایکس متمرکز شوید. مردم میخواهند بدانند چرا یک راه حل خوب است، بجای اینکه چرا همهء راه حل های دیگر بد هستند. بنابراین بجای حمله به یک راه حل رقیب بر زمینه های مختلف، بسادگی نشان دهید چطور خصیصه های پایتون میتوانند کمک کنند.

-= منابع مفید =-

Pythonology Python Success Stories
داستان های موفقیت یک مجموعه از روایت ها از کاربران موفق پایتون هستند که روی کاربران تجاری و شرکتی تاکید دارند.

Scripting
مقالهء رسمی John Ousterhout درمورد اسکریپت نویسی یک استدلال خوب برای قابلیت استفاده از زبانهای اسکریپتی است، هرچند بقدر کافی بطور طبیعی، او روی Tcl، زبانی که او توسعه داد، تاکید میکند. بیشتر استدلال ها به هر زبان اسکریپتی ای قابل اعمال هستند.

Feeding a Large-scale Physics Application to Python
مولفان، David M. Beazley و Peter S. Lomdahl، استفادهء خود از پایتون در آزمایشگاه ملی Los Alamos را شرح میدهند. آن یک مثال خوب دیگر از اینکه چطور پایتون میتواند کار واقعی را انجام دهد است. این نقل قول از مقاله بوسیلهء بسیاری دیگر از مردم تکرار شده است:

ابتدا طراحی شده بعنوان یک اپلیکیشن یکپارچه برای سیستم های پردازش موازی انبوه، ما پایتون را برای تبدیل اپلیکیشن مان به یک سیستم منعطف، خیلی ماجولار، و درنهایت قدرتمند برای انجام شبیه سازی، تحلیل داده ها، و بصری سازی استفاده کردیم. بعلاوه، ما توضیح میدهیم چطور پایتون تعدادی از مسائل مهم مربوط به توسعه ، رفع عیب، برقراری، و نگهداری نرم افزار علمی را حل کرد.

Cognizor.com – cogn iz or Resources and Information.This website is for sale!
این مصاحبه با Andy Feit، که دربارهء استفادهء Infoseek از پایتون بحث میکند، میتواند برای نشان دادن آنکه انتخاب پایتون هیچ دشواری ای را به فرایند توسعهء یک شرکت اضافه نمیکند و فواید قابل توجهی را فراهم میکند، استفاده شود.

http://www.python.org/workshops/1997…dings/stein.ps
مدیریت میتواند دربارهء قابلیت اعتماد و سودمندی نرم افزاری که بصورت تجاری نوشته نشده است در تردید باشد. این سایت استدلال هایی را ارائه میکند که نشان میدهند چطور نرم افزار بازمتن میتواند مزایایی قابل توجهی نسبت به نرم افزار غیربازمتن داشته باشد.

Linux Advocacy mini-HOWTO
مقالهء چگونگی دفاع از لینوکس الهام بخش این مقاله بود، و همچنین برای موفقیت پیشنهاد پذیرش یک فناوری جدید همچون لینوکس یا پایتون بخوبی ارزش خواندن را دارد. درکل، شما با حمله کردن بر سیستم های موجود و شکایت کردن درمورد ناکارایی های آنها پیشرفت چندانی نخواهید کرد؛ این اغلب همچون موفقیت متمرکز نشده بنظر خواهد رسید. بسیار بهتر است که چند حیطه از حیطه های بسیاری را که پایتون در آنها یک بهبود نسبت به سیستم های دیگر است نشان دهید.

================================

منبع: مقالهء Python Advocacy HOWTO از بخش Python HOWTOs در رفرنس رسمی پایتون نسخهء سری ۳