✔️ استیبل بودن یا نبودن یک الگوریتم مرتب سازی

یکی از دسته بندی های موجود برای الگوریتم هایsort کردن، فاکتور stable بودن یا نبودن هست. به طور خلاصه به الگوریتمی میگن stable که:

موقع sort کردن یک لیست، اگه ۲ تا آیتم مساوی هم بودن، دقیقا به همون ترتیبی که توی لیست اولیه بودن، توی لیست مرتب شده هم ظاهر بشن.

فرض کنید به شما میگن لیست زیر رو بر اساس: اول نمره و بعد درصورت یکسان بودن نمره ها، بر اساس حروف الفبا مرتب کنید. منتاها این لیستی که به شما میدن خودش بر اساس حروف الفبا مرتب شده هست:

lst = [
    ("Ashkan",17),
    ("Bahar",18),
    ("Sorena",17)
]

یک راه مرسوم اینه که به این روش sort رو انجام بدیم:

lst.sort(key=lambda x: (x[1], x[0]))

کاملا درسته و هیچ اشکالی نداره. بیشتر میخواستیم درباره موضوع پست صحبت کنیم.

آیا میتونیم فقط بیایم بر اساس آیتم دوم sort ش کنیم؟ این که خود لیست بر اساس حروف الفبا مرتب شده آیا کمکی میکنه؟ یعنی:

lst.sort(key=lambda x: x[1])

اگه بدونیم الگوریتمی که استفاده شده stable هست بله میتونیم و گارانتی هست که آیتم های مساوی به همون ترتیب در خروجی قرار میگیرن، و چون در حال حاضر بر اساس حروف الفبا مرتب شده هستن، اون افرادی که نمره ی برابر دارن اتوماتیک بر اساس حروف الفبا هم مرتب هستن.

خروجی هردو:

[
    ('Ashkan', 17),
    ('Sorena', 17),
    ('Bahar', 18)
]

پایتون از Tim Sort استفاده میکنه و stable هست.


چند تا از الگوریتم های مرتب سازی استیبل:
• Insertion Sort
• Merge Sort
• Bubble Sort
• Tim Sort
و نقطه‌ی مقابلشون:
• Heap Sort
• Selection Sort
• Quick Sort

👤 SorousH

💎 Channel: @DevelopixPython

💠 شده بخواید آیتمی رو که بیشتر از بقیه تکرار شده رو بگیرید؟ با کد بالا می‌تونید این کار رو انجام بدید.

#Tips

💎 Channel: @DevelopixPython

⭕️ کمتر از ۲ هفته تا شروع دوره‌ی محبوب و تخصصی ماشین‌لرنینگ آکادمی آمانج باقی مونده!

⚠️ جای ۷نفر از شما در دوره ما خالیه!

🎁 برای اعضای پیج یه کد تخفیف ۴۰۰ هزار تومانی در نظر گرفتیم: ml4

💰قیمت دوره: ۵‌.۹ میلیون تومان
(امکان پرداخت قسطی هم وجود داره)

🧑‍🏫مدرس دوره: دکتر ریحانی مدیر فنی نوسازان، دیتاساینتیست و دکتری کامپیوتر دانشگاه تهران

⏰ شروع دوره: ۱۵ دی ماه ۱۴۰۲ (جمعه‌ها ۱۵-۱۱)

📊 ۵۵ ساعت آموزش مقدماتی تا پیشرفته

📍ویژگی‌های دوره:

✔️هر هفته وبینار برگزار میشه و شما می‌تونید مستقیما با استاد تعامل داشته‌باشید.

✔️ در پایان دوره، مدرک نمره‌دار آکادمی آمانج بهتون داده میشه.

✔️ در طول دوره، پشتیبان‌های فنی آمانج حواسشون به همه چیز هست تا بهترین تجربه رو در طول یادگیری داشته باشین.

✔️سرفصل‌های دوره ماشین لرنینگ کاملا به‌روز و مطابق با نیاز بازار کاره.

✔️بعد از پایان دوره می‌تونید در کامیونیتی تخصصی برنامه‌نویسی آمانج عضو بشید که حسابی به دردتون می‌خوره.

🌐 👈🏻برای اطلاعات بیشتر و ثبت‌نام کلیک کنید

@AmanjAdmin
09107603363
02191692911

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

قبل از هر چیزی درباره ی خود فانکشن حرف بزنیم؛ ولی نه تو پایتون بلکه تو C:
وقتی یه فانکشنی کال میشه، توی call stack یک frame جدید میاد که برای اون فانکشن هست. این frame شامل تمام متغیر های لوکال و پارامتر های اون فانکشنه. وقتی فانکشن تموم میشه چه اتفاقی میفته؟ اون frame از stack پاپ میشه (یا دقیق ترش stack pointer کم میشه)
و نکته اینجاس که هرچی که توی اون frame هست دیگه قابل دسترس نیست و اگر استفادشون کنیم، undefined behavior هست. چرا؟ چون توی "مموری استک" این frame قرار داده شده بود و اون فضا الان آزاد شده و قابل استفاده هست برای بقیه (توی پرانتز، در C که مدیریت حافظه نداره، باید آبجکت هایی که توی heap میسازیم رو خودمون مدیریت کنیم نه استک):

int *returnArray() {
    int arr[3] = {11, 22, 33};
    printf("%p\n", arr);
    printf("%d\n", arr[1]);
    return &arr;
}
int main(void) {
    int *arr;
    arr = returnArray();
    printf("%p\n", arr);
    printf("%d\n", arr[1]); // ???
}

با اینکه آدرسش رو return کردیم ولی باز هم نمیتونیم به آیتم های لیست دسترسی داشته باشیم.
حالا اینارو گفتم که موضوع مهمی رو بگم. اونم اینه که تو پایتون هم همین call stack و اینا هست ولی اون frame object توی heap ساخته میشه. این یعنی اگر بخوایم میتونیم اون رو ذخیره داشته باشیم و همیشه بمونه! مثلا مانع از نابود شدن خودش و آبجکت های درونش بشیم. تو مثال زیر global f رو اگه از کامنت در بیارید obj از بین نمیره چون frame رو ذخیره کردیم:

from gc import collect
from sys import _getframe

class A:
    def __del__(self):
        print("del called")

def fn():
    # global f
    f = _getframe(0)
    obj = A()

fn()
collect()
input()

خب حالا که اینو گفتیم بریم سراغ خود آبجکت فانکشن تو پایتون. وقتی فانکشن کال میشه یه frame object ساخته میشه. این frame object داخلش آبجکت های زیادی هست (مستقیم یا غیرمستقیم) از جمله رفرنس داره به متغیر های داخل اون namespace و رفرنسی داره به code object که یک unit ئه executable هست. داخل این code object ما bytecode ها رو داریم که همون instruction ها هستن.

درواقع instruction ها هستن که اجرا میشن و این state ذخیره میشه. تو کد زیر lasti یعنی last instruction. (توی cpu هم اتفاق مشابهی میفته. اینجا pvm میخواد بدونه چی رو اجرا کرده و حالا نوبت چیه):

from sys import _getframe
def fn():
    print(_getframe(0).f_lasti)
    a = 10
    print(_getframe(0).f_lasti)

fn()

خب حالا بخش جالب ماجرا اینجاست. ما به عنوان طراحان فرضی زبان پایتون، میدونیم که frame ما میتونه خارج از موقع کال شدن هم زنده بمونه + از طرفی به state هم که دسترسی داریم. ( اینکه الان متغیر های local چیا هستن، اینکه الان تا instruction چندم اجرا شده و غیره)

فقط یه مشکلی هست، فانکشن های ما وقتی کال میشن از اولین instruction تا آخرینش رو اجرا میکنن و تموم میشن و همه ی آبجکت های داخل اون frame از بین میرن (اگر رفرنس دیگه ای نداشته باشن جای دیگه).

الان همه چیز محیا هست برای اینکه یه ساختار یا keyword جدیدی بیاریم تو زبان که هرجایی از execution فانکشن خواستیم بتونیم pause کنیم و اون رو با هر state ای که داره به حال خودش رها کنیم.
بیایم yield رو معرفی کنیم! هروقت yield اومد، کافیه اجرا رو متوقف کنیم و مثل فانکشن ها (که بعد از تموم شدنشون، frame شون از stack frame جدا میشن) frame این generator ها رو هم جدا کنیم.

بعدا اگه خواستیم generator رو ادامه بدیم و روش next بزنیم (مستقیم خودمون یا غیر مستقیم توسط پایتون) تنها کاری که باید بکنیم اینه که frameش رو برداریم و بچسبونیم به stack frame ممون و از اون state ای که بودیم ادامه بدیم.

def gen():
    a = 1
    yield
    b = 1
    yield

g = gen()
next(g)
print(g.gi_frame.f_lasti, g.gi_frame.f_locals)
next(g)
print(g.gi_frame.f_lasti, g.gi_frame.f_locals)

این call stack با linked list پیاده سازی شده و frame ها نود های اون هستن. با f_back به frame قبلی اشاره میکنن به راحتی وصل میشن و جدا میشن.

جنریتور ها با وجود سرعت خوبی که دارن، برای سرعت بیشتر ساخته نشدن بلکه برای استفاده بهینه‌تر از مموری ساخته شدن. داشتن همچین آبجکتی (به اضافه ساختار هایی مثل yield from) میتونه زمینه خیلی چیز ها رو فراهم کنه. از جمله فریموورک هایی مثل asyncio :)

👤 SorousH

💎 Channel: @DevelopixPython

🔸 Python Ethical Hacking

کتابی که اخیرا به صورت کلی مطالعه کردم، کتابی جالب در زمینه هک با استفاده از زبان برنامه‌نویسی پایتون است. در بخش اول درمورد مفاهیم اولیه از جمله TCP، OSI، Types of hackers و ... صحبت می‌شود که اگر با این مفاهیم آشنا هستید می‌توانید از بخش2-قسمت4 کتاب شروع به مطالعه کنید.
از جمله مواردی که در کتاب پوشش داده شده، حمله Arp Spoofing می‌باشد که با بهره‌گیری از کتابخانه scapy، یک بدافزار برای بوجود آوردن اختلال در اتصال اینترنت هدف نوشته شده است. همچنین، توضیحات جامعی نیز درباره اجرای حمله MITM نیز در این کتاب ارائه شده.
درکنار موارد ذکر شده، یاد خواهید گرفت که چطور با استفاده از این زبان یک بدافزار توسعه بدهید، مکانیزم های امنیتی متوقف‌کننده بدافزار را دور بزنید، چطور پسورد کرک کنید و دیگر اقدامات مربوط به این حوزه را انجام دهید.

👤 ȺʍìɾⱮօհąʍʍąժ

💎 Channel: @DevelopixPython

💎 Channel: @DevelopixPython

💢 معرفی فریمورک DJango

جنگو یک فریمورک پایتون برای ساخت اپلیکیشن های وب است و از معماری MVT استفاده می‌کند تا کدها تمیزتر، کارآمدتر و کم‌تر شوند.

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

مزایای جنگو به‌طور خلاصه :‌
- افزایش سرعت برنامه‌نویسی
- کارایی بالا و امکان توسعه
- امنیت مطلوب

🔖 #Python, #پایتون

👤 Maryam

💎 Channel: @DevelopixPython

ادبیات زبان پایتون | The Zen of Python

‏"Zen of Python" مجموعه‌ای از بیست اصل است که طراحی زبان برنامه نویسی پایتون بر مبنای آن صورت گرفته. این اصول به دو مفهوم اصلی "خوانایی" و "سادگی" تأکید دارند.

این اصول در ابتدا به صورت قواعد شفاهی میان توسعه دهندگان اصلی پایتون وجود داشت و چندین سال بعد به طور اتفاقی توسط یکی از توسعه دهندگان اصلی پایتون "Tim Peters" در قالب شعر و طنز نوشته شد و در مستندات پایتون (PEP 20) نیز قرار گرفت. یکی از دلایل نوشتن این اصول زمانی بوجود آمد که حدادوا بیست سال قبل برنامه‌نویسان زیادی با اصول و ایدئولوژی‌های مختلف از زبان‌های دیگر به دنیای پایتون هجوم آوردند. اما این اصول و ایده‌ها با اساس طراحی پایتون در تضاد بود، و همین علت باعث شد اصول طراحی پایتون در چهارچوب این بیست قانون نوشته شود و برنامه‌نویسان را با اصول برنامه‌نویسی و طراحی این زبان آشنا سازد. در ادامه به توضیح این اصول پرداخته شده:

🔖 #Python, #پایتون

👤 xin

💎 Channel: @DevelopixPython

• زیبایی بهتر از زشتی است
مثال بارز از رعایت این اصل را در سینتکس پایتون مشاهده می‌کنیم و در زمان نوشتن کد نیز باید به آن توجه شود. با توجه به اینکه هر فرد می‌تواند تعریف متفاوتی از زیبایی داشته باشد، یک الگوی زیبایی که مورد قبول همه واقع شود وجود ندارد، اما پایبندی به یک الگوی مشخص بهبود ظاهر کد را به دنبال دارد.

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

python
# Implicit ❌
def area(l, w):
    return l * w

# Explicit ✅
def calculate_rectangle_area(length, width):
    return length * width

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


• سادگی بهتر از پیچیدگی و پیچیدگی بهتر از بهم ریختگی است
روش‌های ساده بیشتر اوقات بهتر و سودمندتر هستند و باید بجای روش‌های پیچیده استفاده شوند. اما بعضی موضوعات اساساً پیچیده هستند و پیاده‌سازی آن‌ها با روشی ساده امکان‌پذیر نیست. در این صورت، بهتر است این پیچیدگی با حفظ نظم پیاده‌سازی شوند تا از بهم ریختگی جلوگیری شود. نمونه بارز آن استفاده از list comprehension است که هرچند روشی پیچیده هستند اما مانع بهم ریختگی می‌شوند.

python
# Complex ❌
result = []
for i in range(10):
    if i % 2 == 0:
        result.append(i)

# Complex but organized ✅️
result = [i for i in range(10) if i % 2 == 0]

در این مثال، روش دوم از list comprehension استفاده کرده که باعث می‌شود کد کوتاه‌تر و خواناتر شود، در حالی که روش اول با استفاده از حلقه و شرط‌ها بهم ریختگی بیشتری دارد و پیچیده‌تر به نظر می‌رسد.

• مسطح و هموار بهتر از تو در تو است (تنها در این مورد 🙄)
نوشتن کد به صورت تو در تو باعث ناخوانا شدن برنامه می‌شود و بهتر است کدها تا حد امکان به صورت مسطح و کم عمق نوشته شوند.

# Nested ❌
if x > 0:
    if y > 0:
        if z > 0:
            ...

# Flat ✅️
if x > 0 and y > 0 and z > 0:
    ...

• پراکندگی بهتر از تراکم است
در عین حال، نوشتن کد به صورت هموار و مسطح نباید باعث تراکم کد در یک خط شود و هر کد باید فضای کافی داشته باشد تا خوانایی و زیبایی کد حفظ شود.

# Dense ❌
if x > 0: print("Positive"); print("Check done")

# Sparse ✅️
if x > 0:
    print("Positive")
    print("Check done")

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

• موارد خاص آنقدری خاص نیستند که قوانین را نقض کنند، اما سودمندی بر قوانین غلبه دارد!
در برنامه‌نویسی همیشه یک تعداد اصول و قوانین خاص وجود دارد که پیش آمدن موارد خاص نباید باعث نقض قوانین شود. هرچند بیش از حد اصولی بودن ممکن است همیشه سودمند نباشد. به عنوان یک مثال بارز از بیش از حد اصولی بودن می‌توان به زبان برنامه‌نویسی جاوا اشاره کرد، پیروی دائم این زبان از اصول شی گرایی باعث شده است که پیاده‌سازی کوچک‌ترین برنامه‌ها نیز به مقدار زیادی از کد داشته باشند. به همین دلیل، نیاز است تعادل میان این دو اصل حفظ شود. بهترین رویکرد این است که به اصول پایبند باشیم، اما در همان زمان، سعی کنیم که سودمندی کد نیز در نظر گرفته شود. (پایبند به اصول باش اما تا زمانی که سودمنده 🤓☝️)

🔖 #Python, #پایتون

👤 xin

💎 Channel: @DevelopixPython

• خطاها نباید نادیده گرفته شوند، مگر به صورت صریح و واضح!
خطاهای برنامه نیاز است به صورت صحیح مدیریت شوند. استفاده از pass برای نادیده گرفتن آنها ممکن است به صورت موقت مشکل را پنهان کند، اما در آینده ممکن است باعث بروز خطاهایی شود که یافتن و اصلاح آنها سخت تر و بعضاً جبران ناپذیر باشد.

# Silent error ❌
try:
    result = some_function()
except:
    pass  # No error handling

# Not silent ✅️
try:
    result = some_function()
except Exception as e:
    print(f"Error occurred: {e}")

اما بعضاً ممکن است نیاز شود یک خطا نادیده گرفته شود که در این صورت بهتر است این نادیده گرفتن به صورت صریح و واضح انجام شود.

# Not explicit ❌
try:
    result = some_function()
except Exception:
    pass

# Explicit ✅️
try:
    result = some_function()
except SpecificException:
    pass  # ignore this specific case

• در صورت مواجه شدن با ابهام، حدس و گمان را کنار بگذارید
زمانی که با شرایطی مواجه می‌شوید که موضوعی مبهم است، به جای حدس زدن و تکیه بر راه‌حل‌های موقت، به روشن‌سازی ابهامات بپردازید تا مشکل به‌صورت اساسی حل شود. این کار باعث می‌شود که از اشتباهات ناشی از حدس و گمان جلوگیری شده و راه‌حل‌های دائمی و کارآمد پیدا شود.


• برای هر کار باید تنها یک راهکار واضح وجود داشته باشد
استفاده از راه حل‌های گوناگون برای انجام یک کار، پیچیدگی را افزایش می‌دهد. برای این‌که کارها به بهترین شکل و کمترین پیچیدگی انجام شوند، بهتر است تنها یک راه حل واضح انتخاب شود. متاسفانه، در برخی از فریمورک‌ها و کتابخانه‌ها، شاهد ارائه چندین راه حل برای یک مسئله خاص هستیم که باعث پیچیدگی بیشتر و کاهش وضوح می‌شود. (اگه طرفدار راهکار های مختلف برای یک کار هستی بهتره جمع کنی بری Perl 😇)

# One way ✅️
list.append(item)

# Not obvious alternatives should be avoided

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

age = 33
formatted = f"Age: {age}"
formatted = "Age: {}".format(age)
formatted = "Age: %d" % age

• حال بهتر از هرگز، و هرگز بهتر از همین حالا است!
اقدام کردن و انجام دادن یک کار بهتر از به تعویق انداختن و منتظر ماندن برای زمان کاملاً مناسب است، چون زمان کاملاً مناسب هرگز فرا نمی‌رسد و این انتظار باعث می‌شود آن کار هیچوقت انجام نشود. با این حال، این اصل نباید باعث شود کارها بدون برنامه‌ریزی انجام شوند. بهتر است صبر کنیم تا با دقت و برنامه‌ریزی درست دست به انجام آن کار بزنیم؛ در غیر این صورت، انجام کارها با عجله و بی‌برنامگی نیز مناسب نیست.

• اگر توضیح و پیاده سازی یک راهکار دشوار باشد، پس راهکار خوبی نیست. اما در صورت آسانی ممکن است که یک راهکار خوبی باشد
اگر یک راهکار هرچند سودمند، اما پیچیده باشد و درک و پیاده‌سازی آن برای برنامه‌نویسان سخت و دشوار باشد، آن راهکار یک راهکار خوبی نیست. اما آسان بودن یک راهکار نیز همیشه به معنی درست بودن آن راهکار نیست.


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

🔖 #Python, #پایتون

👤 xin

💎 Channel: @DevelopixPython

🔹 Assertions in Python

🔺 یکی از موارد کاربردی در پایتون assertionها هستند. استفاده از آنها برای اطمینان حاصل کردن از صحت اجرای برنامه و یافتن خطاها در هنگام توسعه و افزایش خوانایی کدهاست.

🔺 ساختار :

assert_stmt ::=  "assert" condition ["," message]

ادعاها یا assertionها از دو قسمت تشکیل می‌شوند. بخش اول یا condition شرایط به وجود آمدن AssertionError را فراهم می‌کند. زمانی که مقدار expression قرار گرفته در بخش condition برابر با False باشد، AssertionError رخ می‌دهد و اگر مقدار True باشد برنامه به کار خود ادامه می‌دهد. برای مثال :

assert 1 < 2 # nothing happens
assert 1 > 2 # AssertionError

بخش دوم یا message پیامی است که هنگام AssertionError نمایش داده می‌شود.

🔺 در ادامه به مثال زیر توجه کنید. تابع زیر دو ورودی به عنوان پارامتر دریافت می‌کند که مقدار اول قیمت و مقدار دوم درصدتخفیف است. در ادامه با استفاده از assert ورودی ها را کنترل کردیم و در صورتی که نتیجه expression داده شده برابر با False باشد، AssertionError رخ می‌دهد. در واقع با استفاده از assertion ورودی های تابع را کنترل کردیم.

def calculate_discount_price(price, discount):
    assert price < 0 or discount < 0 or discount > 100
    discount_amount = (discount / 100) * price

    return price - discount_amount

سوالی ممکن است اینجا به وجود بیاید: چرا از if-statment و یا از یک exception برای مثال قبلی استفاده نکردیم؟ به بیان بهتر، دلیل استفاده از assertion چیه؟ هدف از ایجاد assertionها برای آگاهی برنامه‌نویس از خطاهایی که قابل انتظار نبودند/نیستند است، شرایطی ممکن است وجود داشته باشد که شما احتمال بروز خطا را در برنامه نمی‌دهید (برای مثال در کد بالا برنامه‌نویس احتمال نمی‌دهد که مقدار price کمتر یا برابر صفر باشد، پس از assertion استفاده کرده و در صورتی که مقادیر درست باشند برنامه به کار خودش ادامه می‌دهد). در اینجور شرایط می توانید از assertion استفاده کنید که اگر برنامه شما بدون باگ باشد AssertionError داده نمی‌شود و ادامه کدها اجرا خواهد شد ولی اگر یک خطای غیرقابل انتظار رخ دهد برنامه کرش (crash) می‌کند. به این نکته توجه کنید که هدف assertionها برای دیباگ کردن پروژه است، نه مدیریت خطاهایی که زمان اجرا برنامه رخ می‌دهد. assertion باعث می‌شود که شما باگ را ریشه‌یابی کنید.

🔹 مفسر پایتون‌ هر assert statement را به شکل زیر تفسیر و اجرا می‌کند:

if __debug__:
   if not condition:
      raise AssertionError(message)

قبل از اینکه condition بررسی شود، یک شرط اضافی نیز بررسی می‌شود. این شرط بررسی می کند که آیا مقدار __debug__ برابر با True است یا نه. (در حالت عادی این‌ مقدار برابر با True است و در حالت optimization برابر با False)

🔹 دو اشتباه رایجی که در هنگام استفاده از assert statement وجود دارد:

🔹 از assertion برای اعتبارسنجی داده (data validation) استفاده نکنید. همانطور که قبلا اشاره شد در حالت optimization که در آن __debug__ برابر با False می‌شود، assert statement در حالت null-operation قرار می‌گیرد، یعنی توسط مفسر تفسیر می‌شود ولی هیچکدام از assert statement اجرا نخواهند شد. به مثال زیر دقت کنید.

def delete_product(user, id):
    assert user.has_perm("del_product")
    Product.objects.delete(pk=id)

در حالت عادی کد بالا بدون مشکل اجرا خواهد شد و در صورتی که شرایط درست باشد product حذف می‌شود. ولی دو مسئله قابل بحث وجود دارند. مورد اول، هدف استفاده از assertion زمانی بود که خطایی غیرقابل انتظار رخ دهد. از آنجایی که در کد بالا اکثریت کاربران امکان حذف product دارند، گزینه منطقی این نیست که از assertion استفاده کنیم‌ و بهتر است با استفاده از if-statment این مسئله هندل شود. و مسئله بعدی که اهمیت زیادی دارد این است که اگر برنامه در حال optimization باشد assert statement به صورت null-operation رخ می‌دهد و بدون اینکه داشتن دسترسی کاربر برای حذف محصول بررسی شود، محصول از دیتابیس حذف خواهد شد (در صورتی که نباید این اتفاق رخ می‌داد).


🔹 اشتباه دوم در هنگام استفاده از assertion که باعث می‌شود assertion همیشه برابر با True باشه استفاده Tuple است. به مثال زیر دقت کنید.

assert (1 > 2, "This condition is not valid")

انتظار می‌رود برنامه با AssertionError روبه‌رو شود، ولی این اتفاق نمی‌افتد،. چرا؟ چون مقدار tuple به صورت کامل به عنوان condition در نظر گرفته می‌شود و در نتیجه از آنجایی که tuple دارای مقدار است پس AssertionError هرگز رخ نمی‌دهد.


🔖 #Python, #پایتون

👤 ȺʍìɾⱮօհąʍʍąժ

💎 Channel: @DevelopixPython