ترجمه‌ها: [انگلیسی English](https://github.com/satwikkansal/wtfpython) | [چینی 中文](https://github.com/leisurelicht/wtfpython-cn) | [ویتنامی Tiếng Việt](https://github.com/vuduclyunitn/wtfptyhon-vi) | [اسپانیایی Español](https://web.archive.org/web/20220511161045/https://github.com/JoseDeFreitas/wtfpython-es) | [کره‌ای 한국어](https://github.com/buttercrab/wtfpython-ko) | [روسی Русский](https://github.com/satwikkansal/wtfpython/tree/master/translations/ru-russian) | [آلمانی Deutsch](https://github.com/BenSt099/wtfpython) | [اضافه کردن ترجمه](https://github.com/satwikkansal/wtfpython/issues/new?title=Add%20translation%20for%20[LANGUAGE]&body=Expected%20time%20to%20finish:%20[X]%20weeks.%20I%27ll%20start%20working%20on%20it%20from%20[Y].)
حالت‌های دیگر: [وبسایت تعاملی](https://wtfpython-interactive.vercel.app) | [دفترچه تعاملی](https://colab.research.google.com/github/satwikkansal/wtfpython/blob/master/irrelevant/wtf.ipynb)
پایتون، یه زبان زیبا طراحی شده، سطح بالا و مبتنی بر مفسره که قابلیت‌های بسیاری برای راحتی ما برنامه‌نویس‌ها فراهم می‌کنه.
ولی گاهی اوقات قطعه‌کدهایی رو می‌بینیم که تو نگاه اول خروجی‌هاشون واضح نیست.
این یه پروژه باحاله که سعی داریم توش توضیح بدیم که پشت پرده یه سری قطعه‌کدهای غیرشهودی و فابلیت‌های کمتر شناخته شده پایتون
چه خبره.
درحالی که بعضی از مثال‌هایی که قراره تو این سند ببینید واقعا عجیب و غریب نیستند ولی بخش‌های جالبی از پایتون رو ظاهر می‌کنند که
ممکنه شما از وجودشون بی‌خبر باشید. به نظرم این شیوه جالبیه برای یادگیری جزئیات داخلی یه زبان برنامه نویسی و باور دارم که
برای شما هم جالب خواهد بود.
اگه شما یه پایتون کار سابقه‌دار هستید، می‌تونید از این فرصت به عنوان یه چالش برای خودتون استفاده کنید تا بیشتر مثالها رو
تو تلاش اول حدس بزنید. ممکنه شما بعضی از این مثالها رو قبلا تجربه کرده باشید و من خاطراتشون رو در این سند براتون زنده
کرده باشم! :sweat_smile:
پ.ن: اگه شما قبلا این سند رو خوندید، می‌تونید تغییرات جدید رو در بخش انتشار (فعلا در [اینجا](https://github.com/satwikkansal/wtfpython/)) مطالعه کنید
(مثال‌هایی که کنارشون علامت ستاره دارند، در آخرین ویرایش اضافه شده‌اند).
پس، بزن بریم...
# فهرست مطالب
- [فهرست مطالب](#فهرست-مطالب)
- [ساختار مثالها](#ساختار-مثالها)
- [استفاده](#استفاده)
- [👀 مثالها](#-مثالها)
- [بخش: ذهن خود را به چالش بکشید!](#بخش-ذهن-خود-را-به-چالش-بکشید)
- [▶ اول از همه! \*](#-اول-از-همه-)
- [💡 توضیحات](#-توضیحات)
- [▶ بعضی وقتها رشتهها میتوانند دردسرساز شوند](#-بعضی-وقتها-رشتهها-میتوانند-دردسرساز-شوند)
- [💡 Explanation:](#-explanation)
- [▶ Be careful with chained operations](#-be-careful-with-chained-operations)
- [💡 Explanation:](#-explanation-1)
- [▶ How not to use `is` operator](#-how-not-to-use-is-operator)
- [💡 Explanation:](#-explanation-2)
- [▶ Hash brownies](#-hash-brownies)
- [💡 Explanation](#-explanation-3)
- [▶ Deep down, we're all the same.](#-deep-down-were-all-the-same)
- [💡 Explanation:](#-explanation-4)
- [▶ Disorder within order \*](#-disorder-within-order-)
- [💡 Explanation:](#-explanation-5)
- [▶ Keep trying... \*](#-keep-trying-)
- [💡 Explanation:](#-explanation-6)
- [▶ For what?](#-for-what)
- [💡 Explanation:](#-explanation-7)
- [▶ Evaluation time discrepancy](#-evaluation-time-discrepancy)
- [💡 Explanation](#-explanation-8)
- [▶ `is not ...` is not `is (not ...)`](#-is-not--is-not-is-not-)
- [💡 Explanation](#-explanation-9)
- [▶ A tic-tac-toe where X wins in the first attempt!](#-a-tic-tac-toe-where-x-wins-in-the-first-attempt)
- [💡 Explanation:](#-explanation-10)
- [▶ Schrödinger's variable \*](#-schrödingers-variable-)
- [💡 Explanation:](#-explanation-11)
- [▶ The chicken-egg problem \*](#-the-chicken-egg-problem-)
- [💡 Explanation](#-explanation-12)
- [▶ Subclass relationships](#-subclass-relationships)
- [💡 Explanation:](#-explanation-13)
- [▶ Methods equality and identity](#-methods-equality-and-identity)
- [💡 Explanation](#-explanation-14)
- [▶ All-true-ation \*](#-all-true-ation-)
- [💡 Explanation:](#-explanation-15)
- [💡 Explanation:](#-explanation-16)
- [▶ Strings and the backslashes](#-strings-and-the-backslashes)
- [💡 Explanation](#-explanation-17)
- [▶ not knot!](#-not-knot)
- [💡 Explanation:](#-explanation-18)
- [▶ Half triple-quoted strings](#-half-triple-quoted-strings)
- [💡 Explanation:](#-explanation-19)
- [▶ What's wrong with booleans?](#-whats-wrong-with-booleans)
- [💡 Explanation:](#-explanation-20)
- [▶ Class attributes and instance attributes](#-class-attributes-and-instance-attributes)
- [💡 Explanation:](#-explanation-21)
- [▶ yielding None](#-yielding-none)
- [💡 Explanation:](#-explanation-22)
- [▶ Yielding from... return! \*](#-yielding-from-return-)
- [💡 Explanation:](#-explanation-23)
- [▶ Nan-reflexivity \*](#-nan-reflexivity-)
- [💡 Explanation:](#-explanation-24)
- [▶ Mutating the immutable!](#-mutating-the-immutable)
- [💡 Explanation:](#-explanation-25)
- [▶ The disappearing variable from outer scope](#-the-disappearing-variable-from-outer-scope)
- [💡 Explanation:](#-explanation-26)
- [▶ The mysterious key type conversion](#-the-mysterious-key-type-conversion)
- [💡 Explanation:](#-explanation-27)
- [▶ Let's see if you can guess this?](#-lets-see-if-you-can-guess-this)
- [💡 Explanation:](#-explanation-28)
- [▶ Exceeds the limit for integer string conversion](#-exceeds-the-limit-for-integer-string-conversion)
- [💡 Explanation:](#-explanation-29)
- [Section: Slippery Slopes](#section-slippery-slopes)
- [▶ Modifying a dictionary while iterating over it](#-modifying-a-dictionary-while-iterating-over-it)
- [💡 Explanation:](#-explanation-30)
- [▶ Stubborn `del` operation](#-stubborn-del-operation)
- [💡 Explanation:](#-explanation-31)
- [▶ The out of scope variable](#-the-out-of-scope-variable)
- [💡 Explanation:](#-explanation-32)
- [▶ Deleting a list item while iterating](#-deleting-a-list-item-while-iterating)
- [💡 Explanation:](#-explanation-33)
- [▶ Lossy zip of iterators \*](#-lossy-zip-of-iterators-)
- [💡 Explanation:](#-explanation-34)
- [▶ Loop variables leaking out!](#-loop-variables-leaking-out)
- [💡 Explanation:](#-explanation-35)
- [▶ Beware of default mutable arguments!](#-beware-of-default-mutable-arguments)
- [💡 Explanation:](#-explanation-36)
- [▶ Catching the Exceptions](#-catching-the-exceptions)
- [💡 Explanation](#-explanation-37)
- [▶ Same operands, different story!](#-same-operands-different-story)
- [💡 Explanation:](#-explanation-38)
- [▶ Name resolution ignoring class scope](#-name-resolution-ignoring-class-scope)
- [💡 Explanation](#-explanation-39)
- [▶ Rounding like a banker \*](#-rounding-like-a-banker-)
- [💡 Explanation:](#-explanation-40)
- [▶ Needles in a Haystack \*](#-needles-in-a-haystack-)
- [💡 Explanation:](#-explanation-41)
- [▶ Splitsies \*](#-splitsies-)
- [💡 Explanation:](#-explanation-42)
- [▶ Wild imports \*](#-wild-imports-)
- [💡 Explanation:](#-explanation-43)
- [▶ All sorted? \*](#-all-sorted-)
- [💡 Explanation:](#-explanation-44)
- [▶ Midnight time doesn't exist?](#-midnight-time-doesnt-exist)
- [💡 Explanation:](#-explanation-45)
- [ بخش: گنجینههای پنهان!](#-بخش-گنجینههای-پنهان)
- [▶ خب پایتون، میتوانی کاری کنی پرواز کنم؟](#--خب-پایتون-میتوانی-کاری-کنی-پرواز-کنم)
- [ 💡 توضیح:](#--توضیح)
- [▶ `goto`، ولی چرا؟](#--goto-ولی-چرا)
- [ 💡 توضیح:](#--توضیح-1)
- [▶ خودتان را آماده کنید!](#--خودتان-را-آماده-کنید)
- [ 💡 توضیح:](#--توضیح-2)
- [▶ بیایید با «عمو زبان مهربان برای همیشه» آشنا شویم](#--بیایید-با-عمو-زبان-مهربان-برای-همیشه-آشنا-شویم)
- [ 💡 توضیح:](#--توضیح-3)
- [▶ حتی پایتون هم میداند که عشق پیچیده است](#--حتی-پایتون-هم-میداند-که-عشق-پیچیده-است)
- [ 💡 توضیح:](#--توضیح-4)
- [▶ بله، این واقعاً وجود دارد!](#--بله-این-واقعاً-وجود-دارد)
- [ 💡 توضیح:](#--توضیح-5)
- [▶ Ellipsis \*](#-ellipsis-)
- [ 💡توضیح](#-توضیح)
- [▶ بینهایت (`Inpinity`)](#--بینهایت-inpinity)
- [ 💡 توضیح:](#--توضیح-6)
- [▶ بیایید خرابکاری کنیم](#--بیایید-خرابکاری-کنیم)
- [ 💡 توضیح:](#--توضیح-7)
- [ بخش: ظاهرها فریبندهاند!](#-بخش-ظاهرها-فریبندهاند)
- [▶ خطوط را رد میکند؟](#--خطوط-را-رد-میکند)
- [ 💡 توضیح](#--توضیح-8)
- [▶ تلهپورت کردن](#--تلهپورت-کردن)
- [ 💡 توضیح:](#--توضیح-9)
- [▶ خب، یک جای کار مشکوک است...](#--خب-یک-جای-کار-مشکوک-است)
- [ 💡 توضیح](#--توضیح-10)
- [بخش: متفرقه](#بخش-متفرقه)
- [ ▶ `+=` سریعتر است](#---سریعتر-است)
- [ 💡 توضیح:](#---توضیح)
- [ ▶ بیایید یک رشتهی بزرگ بسازیم!](#--بیایید-یک-رشتهی-بزرگ-بسازیم)
- [💡 توضیحات](#-توضیحات-1)
- [▶ کُند کردن جستجوها در `dict` \*](#---کُند-کردن-جستجوها-در-dict-)
- [ 💡 توضیح:](#---توضیح-1)
- [ ▶ حجیم کردن دیکشنری نمونهها (`instance dicts`) \*](#--حجیم-کردن-دیکشنری-نمونهها-instance-dicts-)
- [💡 توضیح:](#-توضیح-1)
- [ ▶ موارد جزئی \*](#---موارد-جزئی-)
- [ مشارکت](#-مشارکت)
- [ تقدیر و تشکر](#-تقدیر-و-تشکر)
- [ چند لینک جالب!](#-چند-لینک-جالب)
- [ 🎓 مجوز](#--مجوز)
- [ دوستانتان را هم شگفتزده کنید!](#-دوستانتان-را-هم-شگفتزده-کنید)
- [ آیا به یک نسخه pdf نیاز دارید؟](#-آیا-به-یک-نسخه-pdf-نیاز-دارید)
# ساختار مثالها
همه مثالها به صورت زیر ساخته می‌شوند:
> ### ▶ یه اسم خوشگل
>
> ```py
> # راه اندازی کد
> # آماده سازی برای جادو...
> ```
>
> **خروجی (نسخه(های) پایتون):**
>
> ```py
> >>> triggering_statement
> یه خروجی غیرمنتظره
> ```
> (دلخواه): توضیح یک‌خطی خروجی غیرمنتظره
>
>
> #### 💡 توضیح:
>
> * توضیح کوتاه درمورد اینکه چی داره اتفاق میافته و چرا.
> ```py
> # راه اندازی کد
> # مثال‌های بیشتر برای شفاف سازی (در صورت نیاز)
> ```
> **خروجی (نسخه(های) پایتون):**
>
> ```py
> >>> trigger # یک مثال که رونمایی از جادو رو راحت‌تر می‌کنه
> # یک خروجی توجیه شده و واضح
> ```
**توجه:** همه مثالها در برنامه مفسر تعاملی پایتون نسخه
۳.۵.۲ آزمایش شده‌اند و باید در همه نسخه‌های پایتون کار
کنند مگراینکه به صورت جداگانه و به طور واضح نسخه مخصوص
پایتون قبل از خروجی ذکر شده باشد.
# استفاده
یه راه خوب برای بیشتر بهره بردن، به نظرم، اینه که مثالها رو به ترتیب متوالی بخونید و برای هر مثال:
- کد ابتدایی برای راه اندازی مثال رو با دقت بخونید. اگه شما یه پایتون کار سابقه‌دار باشید، با موفقیت بیشتر اوقات اتفاق بعدی رو پیش‌بینی می‌کنید.
- قطعه خروجی رو بخونید و
+ بررسی کنید که آیا خروجی‌ها همونطور که انتظار دارید هستند.
+ مطمئین بشید که دقیقا دلیل اینکه خروجی اون طوری هست رو می‌دونید.
- اگه نمی‌دونید (که کاملا عادیه و اصلا بد نیست)، یک نفس عمیق بکشید و توضیحات رو بخونید (و اگه نفهمیدید، داد بزنید! و [اینجا](https://github.com/emargi/wtfpython/issues/new) درموردش حرف بزنید).
- اگه می‌دونید، به افتخار خودتون یه دست محکم بزنید و برید سراغ مثال بعدی.
---
# 👀 مثالها
## بخش: ذهن خود را به چالش بکشید!
### ▶ اول از همه! *
به دلایلی، عملگر "Walrus" (`:=`) که در نسخه ۳.۸ پایتون معرفی شد، خیلی محبوب شده. بیاید بررسیش کنیم.
1\.
```py
# Python version 3.8+
>>> a = "wtf_walrus"
>>> a
'wtf_walrus'
>>> a := "wtf_walrus"
File "", line 1
a := "wtf_walrus"
^
SyntaxError: invalid syntax
>>> (a := "wtf_walrus") # ولی این کار می‌کنه
'wtf_walrus'
>>> a
'wtf_walrus'
```
2 \.
```py
# Python version 3.8+
>>> a = 6, 9
>>> a
(6, 9)
>>> (a := 6, 9)
(6, 9)
>>> a
6
>>> a, b = 6, 9 # باز کردن معمولی
>>> a, b
(6, 9)
>>> (a, b = 16, 19) # آخ آخ
File "", line 1
(a, b = 16, 19)
^
SyntaxError: invalid syntax
>>> (a, b := 16, 19) # این یه تاپل ۳تایی چاپ می‌کنه رو صفحه
(6, 16, 19)
>>> a # هنوز تغییر نکرده؟
6
>>> b
16
```
#### 💡 توضیحات
**مرور سریع بر عملگر Walrus**
عملگر Walrus همونطور که اشاره شد، در نسخه ۳.۸ پایتون معرفی
شد. این عملگر می‌تونه تو مقعیت‌هایی کاربردی باشه که شما می‌خواید داخل یه عبارت، مقادیری رو به متغیرها اختصاص بدید
```py
def some_func():
# فرض کنید اینجا یک سری محاسبه سنگین انجام میشه
# time.sleep(1000)
return 5
# پس به جای اینکه این کارو بکنید:
if some_func():
print(some_func()) # که خیلی راه نادرستیه چون محاسبه دوبار انجام میشه
# یا حتی این کارو کنید (که کار بدی هم نیست)
a = some_func()
if a:
print(a)
# می‌تونید از این به بعد به طور مختصر بنویسید:
if a := some_func():
print(a)
```
**خروجی (+۳.۸):**
```py
5
5
5
```
این باعث میشه که یک خط کمتر کد بزنیم و از دوبار فراخوندن `some_func` جلوگیری کرد.
- "عبارت اختصاص‌دادن مقدار" بدون پرانتز (نحوه استفاده عملگر Walrus)، در سطح بالا محدود است، `SyntaxError` در عبارت `a := "wtf_walrus"` در قطعه‌کد اول به همین دلیل است. قرار دادن آن داخل پرانتز، همانطور که می‌خواستیم کار کرد و مقدار را به `a` اختصاص داد.
- به طور معمول، قرار دادن عبارتی که دارای `=` است داخل پرانتز مجاز نیست. به همین دلیل عبارت `(a, b = 6, 9)` به ما خطای سینتکس داد.
- قائده استفاده از عملگر Walrus به صورت `NAME:= expr` است، به طوری که `NAME` یک شناسه صحیح و `expr` یک عبارت صحیح است. به همین دلیل باز و بسته کردن با تکرار (iterable) پشتیبانی نمی‌شوند. پس،
- عبارت `(a := 6, 9)` معادل عبارت `((a := 6), 9)` و در نهایت `(a, 9)` است. (که مقدار `a` عدد 6 است)
```py
>>> (a := 6, 9) == ((a := 6), 9)
True
>>> x = (a := 696, 9)
>>> x
(696, 9)
>>> x[0] is a # هر دو به یک مکان در حافظه دستگاه اشاره می‌کنند
True
```
- به طور مشابه، عبارت `(a, b := 16, 19)` معادل عبارت `(a, (b := 16), 19)` است که چیزی جز یک تاپل ۳تایی نیست.
---
### ▶ بعضی وقتها رشتهها میتوانند دردسرساز شوند
1\.
```py
>>> a = "some_string"
>>> id(a)
140420665652016
>>> id("some" + "_" + "string") # دقت کنید که هردو ID یکی هستند.
140420665652016
```
2\.
```py
>>> a = "wtf"
>>> b = "wtf"
>>> a is b
True
>>> a = "wtf!"
>>> b = "wtf!"
>>> a is b
False
```
3\.
```py
>>> a, b = "wtf!", "wtf!"
>>> a is b # همه‌ی نسخه‌ها به جز 3.7.x
True
>>> a = "wtf!"; b = "wtf!"
>>> a is b # ممکن است True یا False باشد بسته به جایی که آن را اجرا می‌کنید (python shell / ipython / به‌صورت اسکریپت)
False
```
```py
# این بار در فایل some_file.py
a = "wtf!"
b = "wtf!"
print(a is b)
# موقع اجرای ماژول، True را چاپ میکند!
```
4\.
**خروجی (< Python3.7 )**
```py
>>> 'a' * 20 is 'aaaaaaaaaaaaaaaaaaaa'
True
>>> 'a' * 21 is 'aaaaaaaaaaaaaaaaaaaaa'
False
```
Makes sense, right?
#### 💡 Explanation:
+ The behavior in first and second snippets is due to a CPython optimization (called string interning) that tries to use existing immutable objects in some cases rather than creating a new object every time.
+ After being "interned," many variables may reference the same string object in memory (saving memory thereby).
+ In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation-dependent. There are some rules that can be used to guess if a string will be interned or not:
* All length 0 and length 1 strings are interned.
* Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f'])` will not be interned)
* Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`. CPython implementation of this rule can be found [here](https://github.com/python/cpython/blob/3.6/Objects/codeobject.c#L19)
+ When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `"wtf!"` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compile-time optimization. This optimization doesn't apply to 3.7.x versions of CPython (check this [issue](https://github.com/satwikkansal/wtfpython/issues/100) for more discussion).
+ A compile unit in an interactive environment like IPython consists of a single statement, whereas it consists of the entire module in case of modules. `a, b = "wtf!", "wtf!"` is single statement, whereas `a = "wtf!"; b = "wtf!"` are two statements in a single line. This explains why the identities are different in `a = "wtf!"; b = "wtf!"`, and also explain why they are same when invoked in `some_file.py`
+ The abrupt change in the output of the fourth snippet is due to a [peephole optimization](https://en.wikipedia.org/wiki/Peephole_optimization) technique known as Constant folding. This means the expression `'a'*20` is replaced by `'aaaaaaaaaaaaaaaaaaaa'` during compilation to save a few clock cycles during runtime. Constant folding only occurs for strings having a length of less than 21. (Why? Imagine the size of `.pyc` file generated as a result of the expression `'a'*10**10`). [Here's](https://github.com/python/cpython/blob/3.6/Python/peephole.c#L288) the implementation source for the same.
+ Note: In Python 3.7, Constant folding was moved out from peephole optimizer to the new AST optimizer with some change in logic as well, so the fourth snippet doesn't work for Python 3.7. You can read more about the change [here](https://bugs.python.org/issue11549).
---
### ▶ Be careful with chained operations
```py
>>> (False == False) in [False] # makes sense
False
>>> False == (False in [False]) # makes sense
False
>>> False == False in [False] # now what?
True
>>> True is False == False
False
>>> False is False is False
True
>>> 1 > 0 < 1
True
>>> (1 > 0) < 1
False
>>> 1 > (0 < 1)
False
```
#### 💡 Explanation:
As per https://docs.python.org/3/reference/expressions.html#comparisons
> Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN are comparison operators, then a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.
While such behavior might seem silly to you in the above examples, it's fantastic with stuff like `a == b == c` and `0 <= x <= 100`.
* `False is False is False` is equivalent to `(False is False) and (False is False)`
* `True is False == False` is equivalent to `(True is False) and (False == False)` and since the first part of the statement (`True is False`) evaluates to `False`, the overall expression evaluates to `False`.
* `1 > 0 < 1` is equivalent to `(1 > 0) and (0 < 1)` which evaluates to `True`.
* The expression `(1 > 0) < 1` is equivalent to `True < 1` and
```py
>>> int(True)
1
>>> True + 1 #not relevant for this example, but just for fun
2
```
So, `1 < 1` evaluates to `False`
---
### ▶ How not to use `is` operator
The following is a very famous example present all over the internet.
1\.
```py
>>> a = 256
>>> b = 256
>>> a is b
True
>>> a = 257
>>> b = 257
>>> a is b
False
```
2\.
```py
>>> a = []
>>> b = []
>>> a is b
False
>>> a = tuple()
>>> b = tuple()
>>> a is b
True
```
3\.
**Output**
```py
>>> a, b = 257, 257
>>> a is b
True
```
**Output (Python 3.7.x specifically)**
```py
>>> a, b = 257, 257
>>> a is b
False
```
#### 💡 Explanation:
**The difference between `is` and `==`**
* `is` operator checks if both the operands refer to the same object (i.e., it checks if the identity of the operands matches or not).
* `==` operator compares the values of both the operands and checks if they are the same.
* So `is` is for reference equality and `==` is for value equality. An example to clear things up,
```py
>>> class A: pass
>>> A() is A() # These are two empty objects at two different memory locations.
False
```
**`256` is an existing object but `257` isn't**
When you start up python the numbers from `-5` to `256` will be allocated. These numbers are used a lot, so it makes sense just to have them ready.
Quoting from https://docs.python.org/3/c-api/long.html
> The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you just get back a reference to the existing object. So it should be possible to change the value of 1. I suspect the behavior of Python, in this case, is undefined. :-)
```py
>>> id(256)
10922528
>>> a = 256
>>> b = 256
>>> id(a)
10922528
>>> id(b)
10922528
>>> id(257)
140084850247312
>>> x = 257
>>> y = 257
>>> id(x)
140084850247440
>>> id(y)
140084850247344
```
Here the interpreter isn't smart enough while executing `y = 257` to recognize that we've already created an integer of the value `257,` and so it goes on to create another object in the memory.
Similar optimization applies to other **immutable** objects like empty tuples as well. Since lists are mutable, that's why `[] is []` will return `False` and `() is ()` will return `True`. This explains our second snippet. Let's move on to the third one,
**Both `a` and `b` refer to the same object when initialized with same value in the same line.**
**Output**
```py
>>> a, b = 257, 257
>>> id(a)
140640774013296
>>> id(b)
140640774013296
>>> a = 257
>>> b = 257
>>> id(a)
140640774013392
>>> id(b)
140640774013488
```
* When a and b are set to `257` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `257` as an object.
* It's a compiler optimization and specifically applies to the interactive environment. When you enter two lines in a live interpreter, they're compiled separately, therefore optimized separately. If you were to try this example in a `.py` file, you would not see the same behavior, because the file is compiled all at once. This optimization is not limited to integers, it works for other immutable data types like strings (check the "Strings are tricky example") and floats as well,
```py
>>> a, b = 257.0, 257.0
>>> a is b
True
```
* Why didn't this work for Python 3.7? The abstract reason is because such compiler optimizations are implementation specific (i.e. may change with version, OS, etc). I'm still figuring out what exact implementation change cause the issue, you can check out this [issue](https://github.com/satwikkansal/wtfpython/issues/100) for updates.
---
### ▶ Hash brownies
1\.
```py
some_dict = {}
some_dict[5.5] = "JavaScript"
some_dict[5.0] = "Ruby"
some_dict[5] = "Python"
```
**Output:**
```py
>>> some_dict[5.5]
"JavaScript"
>>> some_dict[5.0] # "Python" destroyed the existence of "Ruby"?
"Python"
>>> some_dict[5]
"Python"
>>> complex_five = 5 + 0j
>>> type(complex_five)
complex
>>> some_dict[complex_five]
"Python"
```
So, why is Python all over the place?
#### 💡 Explanation
* Uniqueness of keys in a Python dictionary is by *equivalence*, not identity. So even though `5`, `5.0`, and `5 + 0j` are distinct objects of different types, since they're equal, they can't both be in the same `dict` (or `set`). As soon as you insert any one of them, attempting to look up any distinct but equivalent key will succeed with the original mapped value (rather than failing with a `KeyError`):
```py
>>> 5 == 5.0 == 5 + 0j
True
>>> 5 is not 5.0 is not 5 + 0j
True
>>> some_dict = {}
>>> some_dict[5.0] = "Ruby"
>>> 5.0 in some_dict
True
>>> (5 in some_dict) and (5 + 0j in some_dict)
True
```
* This applies when setting an item as well. So when you do `some_dict[5] = "Python"`, Python finds the existing item with equivalent key `5.0 -> "Ruby"`, overwrites its value in place, and leaves the original key alone.
```py
>>> some_dict
{5.0: 'Ruby'}
>>> some_dict[5] = "Python"
>>> some_dict
{5.0: 'Python'}
```
* So how can we update the key to `5` (instead of `5.0`)? We can't actually do this update in place, but what we can do is first delete the key (`del some_dict[5.0]`), and then set it (`some_dict[5]`) to get the integer `5` as the key instead of floating `5.0`, though this should be needed in rare cases.
* How did Python find `5` in a dictionary containing `5.0`? Python does this in constant time without having to scan through every item by using hash functions. When Python looks up a key `foo` in a dict, it first computes `hash(foo)` (which runs in constant-time). Since in Python it is required that objects that compare equal also have the same hash value ([docs](https://docs.python.org/3/reference/datamodel.html#object.__hash__) here), `5`, `5.0`, and `5 + 0j` have the same hash value.
```py
>>> 5 == 5.0 == 5 + 0j
True
>>> hash(5) == hash(5.0) == hash(5 + 0j)
True
```
**Note:** The inverse is not necessarily true: Objects with equal hash values may themselves be unequal. (This causes what's known as a [hash collision](https://en.wikipedia.org/wiki/Collision_(computer_science)), and degrades the constant-time performance that hashing usually provides.)
---
### ▶ Deep down, we're all the same.
```py
class WTF:
pass
```
**Output:**
```py
>>> WTF() == WTF() # two different instances can't be equal
False
>>> WTF() is WTF() # identities are also different
False
>>> hash(WTF()) == hash(WTF()) # hashes _should_ be different as well
True
>>> id(WTF()) == id(WTF())
True
```
#### 💡 Explanation:
* When `id` was called, Python created a `WTF` class object and passed it to the `id` function. The `id` function takes its `id` (its memory location), and throws away the object. The object is destroyed.
* When we do this twice in succession, Python allocates the same memory location to this second object as well. Since (in CPython) `id` uses the memory location as the object id, the id of the two objects is the same.
* So, the object's id is unique only for the lifetime of the object. After the object is destroyed, or before it is created, something else can have the same id.
* But why did the `is` operator evaluate to `False`? Let's see with this snippet.
```py
class WTF(object):
def __init__(self): print("I")
def __del__(self): print("D")
```
**Output:**
```py
>>> WTF() is WTF()
I
I
D
D
False
>>> id(WTF()) == id(WTF())
I
D
I
D
True
```
As you may observe, the order in which the objects are destroyed is what made all the difference here.
---
### ▶ Disorder within order *
```py
from collections import OrderedDict
dictionary = dict()
dictionary[1] = 'a'; dictionary[2] = 'b';
ordered_dict = OrderedDict()
ordered_dict[1] = 'a'; ordered_dict[2] = 'b';
another_ordered_dict = OrderedDict()
another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';
class DictWithHash(dict):
"""
A dict that also implements __hash__ magic.
"""
__hash__ = lambda self: 0
class OrderedDictWithHash(OrderedDict):
"""
An OrderedDict that also implements __hash__ magic.
"""
__hash__ = lambda self: 0
```
**Output**
```py
>>> dictionary == ordered_dict # If a == b
True
>>> dictionary == another_ordered_dict # and b == c
True
>>> ordered_dict == another_ordered_dict # then why isn't c == a ??
False
# We all know that a set consists of only unique elements,
# let's try making a set of these dictionaries and see what happens...
>>> len({dictionary, ordered_dict, another_ordered_dict})
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'dict'
# Makes sense since dict don't have __hash__ implemented, let's use
# our wrapper classes.
>>> dictionary = DictWithHash()
>>> dictionary[1] = 'a'; dictionary[2] = 'b';
>>> ordered_dict = OrderedDictWithHash()
>>> ordered_dict[1] = 'a'; ordered_dict[2] = 'b';
>>> another_ordered_dict = OrderedDictWithHash()
>>> another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';
>>> len({dictionary, ordered_dict, another_ordered_dict})
1
>>> len({ordered_dict, another_ordered_dict, dictionary}) # changing the order
2
```
What is going on here?
#### 💡 Explanation:
- The reason why intransitive equality didn't hold among `dictionary`, `ordered_dict` and `another_ordered_dict` is because of the way `__eq__` method is implemented in `OrderedDict` class. From the [docs](https://docs.python.org/3/library/collections.html#ordereddict-objects)
> Equality tests between OrderedDict objects are order-sensitive and are implemented as `list(od1.items())==list(od2.items())`. Equality tests between `OrderedDict` objects and other Mapping objects are order-insensitive like regular dictionaries.
- The reason for this equality in behavior is that it allows `OrderedDict` objects to be directly substituted anywhere a regular dictionary is used.
- Okay, so why did changing the order affect the length of the generated `set` object? The answer is the lack of intransitive equality only. Since sets are "unordered" collections of unique elements, the order in which elements are inserted shouldn't matter. But in this case, it does matter. Let's break it down a bit,
```py
>>> some_set = set()
>>> some_set.add(dictionary) # these are the mapping objects from the snippets above
>>> ordered_dict in some_set
True
>>> some_set.add(ordered_dict)
>>> len(some_set)
1
>>> another_ordered_dict in some_set
True
>>> some_set.add(another_ordered_dict)
>>> len(some_set)
1
>>> another_set = set()
>>> another_set.add(ordered_dict)
>>> another_ordered_dict in another_set
False
>>> another_set.add(another_ordered_dict)
>>> len(another_set)
2
>>> dictionary in another_set
True
>>> another_set.add(another_ordered_dict)
>>> len(another_set)
2
```
So the inconsistency is due to `another_ordered_dict in another_set` being `False` because `ordered_dict` was already present in `another_set` and as observed before, `ordered_dict == another_ordered_dict` is `False`.
---
### ▶ Keep trying... *
```py
def some_func():
try:
return 'from_try'
finally:
return 'from_finally'
def another_func():
for _ in range(3):
try:
continue
finally:
print("Finally!")
def one_more_func(): # A gotcha!
try:
for i in range(3):
try:
1 / i
except ZeroDivisionError:
# Let's throw it here and handle it outside for loop
raise ZeroDivisionError("A trivial divide by zero error")
finally:
print("Iteration", i)
break
except ZeroDivisionError as e:
print("Zero division error occurred", e)
```
**Output:**
```py
>>> some_func()
'from_finally'
>>> another_func()
Finally!
Finally!
Finally!
>>> 1 / 0
Traceback (most recent call last):
File "", line 1, in
ZeroDivisionError: division by zero
>>> one_more_func()
Iteration 0
```
#### 💡 Explanation:
- When a `return`, `break` or `continue` statement is executed in the `try` suite of a "try…finally" statement, the `finally` clause is also executed on the way out.
- The return value of a function is determined by the last `return` statement executed. Since the `finally` clause always executes, a `return` statement executed in the `finally` clause will always be the last one executed.
- The caveat here is, if the finally clause executes a `return` or `break` statement, the temporarily saved exception is discarded.
---
### ▶ For what?
```py
some_string = "wtf"
some_dict = {}
for i, some_dict[i] in enumerate(some_string):
i = 10
```
**Output:**
```py
>>> some_dict # An indexed dict appears.
{0: 'w', 1: 't', 2: 'f'}
```
#### 💡 Explanation:
* A `for` statement is defined in the [Python grammar](https://docs.python.org/3/reference/grammar.html) as:
```
for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]
```
Where `exprlist` is the assignment target. This means that the equivalent of `{exprlist} = {next_value}` is **executed for each item** in the iterable.
An interesting example that illustrates this:
```py
for i in range(4):
print(i)
i = 10
```
**Output:**
```
0
1
2
3
```
Did you expect the loop to run just once?
**💡 Explanation:**
- The assignment statement `i = 10` never affects the iterations of the loop because of the way for loops work in Python. Before the beginning of every iteration, the next item provided by the iterator (`range(4)` in this case) is unpacked and assigned the target list variables (`i` in this case).
* The `enumerate(some_string)` function yields a new value `i` (a counter going up) and a character from the `some_string` in each iteration. It then sets the (just assigned) `i` key of the dictionary `some_dict` to that character. The unrolling of the loop can be simplified as:
```py
>>> i, some_dict[i] = (0, 'w')
>>> i, some_dict[i] = (1, 't')
>>> i, some_dict[i] = (2, 'f')
>>> some_dict
```
---
### ▶ Evaluation time discrepancy
1\.
```py
array = [1, 8, 15]
# A typical generator expression
gen = (x for x in array if array.count(x) > 0)
array = [2, 8, 22]
```
**Output:**
```py
>>> print(list(gen)) # Where did the other values go?
[8]
```
2\.
```py
array_1 = [1,2,3,4]
gen_1 = (x for x in array_1)
array_1 = [1,2,3,4,5]
array_2 = [1,2,3,4]
gen_2 = (x for x in array_2)
array_2[:] = [1,2,3,4,5]
```
**Output:**
```py
>>> print(list(gen_1))
[1, 2, 3, 4]
>>> print(list(gen_2))
[1, 2, 3, 4, 5]
```
3\.
```py
array_3 = [1, 2, 3]
array_4 = [10, 20, 30]
gen = (i + j for i in array_3 for j in array_4)
array_3 = [4, 5, 6]
array_4 = [400, 500, 600]
```
**Output:**
```py
>>> print(list(gen))
[401, 501, 601, 402, 502, 602, 403, 503, 603]
```
#### 💡 Explanation
- In a [generator](https://wiki.python.org/moin/Generators) expression, the `in` clause is evaluated at declaration time, but the conditional clause is evaluated at runtime.
- So before runtime, `array` is re-assigned to the list `[2, 8, 22]`, and since out of `1`, `8` and `15`, only the count of `8` is greater than `0`, the generator only yields `8`.
- The differences in the output of `g1` and `g2` in the second part is due the way variables `array_1` and `array_2` are re-assigned values.
- In the first case, `array_1` is bound to the new object `[1,2,3,4,5]` and since the `in` clause is evaluated at the declaration time it still refers to the old object `[1,2,3,4]` (which is not destroyed).
- In the second case, the slice assignment to `array_2` updates the same old object `[1,2,3,4]` to `[1,2,3,4,5]`. Hence both the `g2` and `array_2` still have reference to the same object (which has now been updated to `[1,2,3,4,5]`).
- Okay, going by the logic discussed so far, shouldn't be the value of `list(gen)` in the third snippet be `[11, 21, 31, 12, 22, 32, 13, 23, 33]`? (because `array_3` and `array_4` are going to behave just like `array_1`). The reason why (only) `array_4` values got updated is explained in [PEP-289](https://www.python.org/dev/peps/pep-0289/#the-details)
> Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run.
---
### ▶ `is not ...` is not `is (not ...)`
```py
>>> 'something' is not None
True
>>> 'something' is (not None)
False
```
#### 💡 Explanation
- `is not` is a single binary operator, and has behavior different than using `is` and `not` separated.
- `is not` evaluates to `False` if the variables on either side of the operator point to the same object and `True` otherwise.
- In the example, `(not None)` evaluates to `True` since the value `None` is `False` in a boolean context, so the expression becomes `'something' is True`.
---
### ▶ A tic-tac-toe where X wins in the first attempt!
```py
# Let's initialize a row
row = [""] * 3 #row i['', '', '']
# Let's make a board
board = [row] * 3
```
**Output:**
```py
>>> board
[['', '', ''], ['', '', ''], ['', '', '']]
>>> board[0]
['', '', '']
>>> board[0][0]
''
>>> board[0][0] = "X"
>>> board
[['X', '', ''], ['X', '', ''], ['X', '', '']]
```
We didn't assign three `"X"`s, did we?
#### 💡 Explanation:
When we initialize `row` variable, this visualization explains what happens in the memory
And when the `board` is initialized by multiplying the `row`, this is what happens inside the memory (each of the elements `board[0]`, `board[1]` and `board[2]` is a reference to the same list referred by `row`)
