Python Nation🐍🇺🇦

🔍 Інтроспекція в Python: як програмі бачити себе зсередини Інтроспекція — це здатність програми досліджувати свою структуру під час виконання. У Python це зручно реалізовано через вбудовані функції. Ось декілька корисних прикладів: type(obj) — визначає тип об’єкта. dir(obj) — показує доступні атрибути та методи. getattr(obj, attr) — отримує значення атрибута. isinstance(obj, class) — перевіряє, чи об'єкт є екземпляром класу. help(obj) — виводить документацію об'єкта. Це корисно для: 🔹дебагінгу та аналізу об'єктів 🔹динамічного створення функцій чи класів 🔹розробки IDE, автозаповнення або генерації документації Пам’ятайте, що надмірне використання інтроспекції може ускладнити код. Використовуйте її з розумом! 🐍✨

Python 3.15 додає lazy імпорти і це реально корисно Якщо ти хоч раз запускав CLI-утиліту або скрипт і думав "чому воно так довго стартує" - ця фіча для тебе. Проблема проста. Python при запуску завантажує всі модулі одразу, навіть якщо половина з них потрібна тільки в одному з десяти сценаріїв. Великий проєкт з pandas, numpy і ще купою залежностей - і ти вже чекаєш секунди просто щоб побачити --help. Раніше це вирішували переносом імпортів всередину функцій. Працює, але код стає брудним і незрозумілим. Тепер у Python 3.15 є нормальне рішення - ключове слово lazy: lazy import pandas lazy from json import dumps Модуль не завантажується поки ти його не використаєш. Перший раз звернувся - тоді й завантажується. lazy import pandas if user_wants_report: df = pandas.DataFrame(data) # тільки тут pandas реально завантажиться Якщо користувач не запитав звіт - pandas взагалі не торкнувся пам'яті. Пара моментів які варто знати: — lazy працює тільки на рівні модуля, не всередині функцій — from module import * не підтримується — помилку в імпорті побачиш не одразу, а коли вперше використаєш модуль За даними з PEP - CLI-утиліти стартують на 50-70% швидше, великі застосунки споживають на 30-40% менше пам'яті. Python 3.15 ще не вийшов фінально, але PEP вже прийнятий. Якщо цікаво розібратись детальніше то ось першоджерело: https://peps.python.org/pep-0810

True - це насправді 1 Багато хто не знає, але bool у пайтоні це підклас int. Тобто True дорівнює 1, а False дорівнює 0. Ними навіть можна рахувати: True + True # 2 False * 10 # 0 True == 1 # True isinstance(True, int) # True З цього виходить зручна штука. Треба порахувати, скільки елементів підходять під умову? Лічильник не потрібен: orders = [120, 0, 45, 0, 300] paid = sum(x > 0 for x in orders) # 3 Кожен x > 0 це True або False, а sum складає їх як 1 і 0. Швидко і без зайвого коду. Але є нюанс. Раз True == 1, то в словнику вони стають одним ключем: d = {1: "one", True: "boolean"} print(d) # {1: 'boolean'} Ключ лишився 1, а значення перезаписалось. Такий баг знайти непросто. Коротко: сумувати булеві це нормально, а мішати їх з числами як ключі не варто.

__slots__ - коли обʼєктів багато За замовчуванням кожен обʼєкт у пайтоні тримає свій __dict__, тобто словник з атрибутами. Це зручно бо можна додати будь-який атрибут на льоту, але словник займає памʼять. Коли обʼєктів кілька то це не є проблемою, а от коли їх багато, то вже стає помітно по пам'яті. __slots__ каже класу: атрибути тільки ці, словник не потрібен. class Receipt: __slots__ = ("id", "total", "paid") def __init__(self, id, total, paid): self.id = id self.total = total self.paid = paid Що це дає: - менше памʼяті на кожен обʼєкт (немає __dict__) - трохи швидший доступ до атрибутів Ціна - гнучкість. Новий атрибут вже не додаси: r = Receipt(1, 100, True) r.discount = 10 # AttributeError І ще пара нюансів: наслідування працює, але кожен клас у ланцюгу має свої __slots__, інакше __dict__ повернеться. З @dataclass теж дружить - просто @dataclass(slots=True). Коротко: якщо клас створюється багато разів і набір полів фіксований - __slots__ економить реальну памʼять. Для звичайних класів це зайве.

Чому 256 is 256 - True, а 257 is 257 - не завжди У пайтоні є оператор is, який перевіряє не рівність значень, а те, чи це один і той самий обʼєкт у памʼяті. І тут ховається несподіванка: a = 256 b = 256 a is b # True a = 257 b = 257 a is b # False Значення однакові, а результат різний. Причина в тому, що CPython при старті створює й тримає в кеші всі малі цілі від -5 до 256. Вони використовуються постійно, тож інтерпретатор не робить нові обʼєкти щоразу - віддає ті самі. Число 257 у кеш не потрапляє, тому кожне таке присвоєння - новий обʼєкт. Звідси False. І ще нюанс: якщо написати 257 is 257 в одному рядку чи в одній функції, компілятор може сам згорнути константи, і вийде True. Тобто поведінка залежить від того, де саме стоїть код. Висновок простий: is для чисел використовувати не треба взагалі. Він про ідентичність обʼєкта, а не про значення. Для порівняння чисел завжди ==.

Чому None перевіряють через is, а не == У пайтоні прийнято писати if x is None, а не if x == None. І це не просто стиль. None - це єдиний обʼєкт на всю програму. Скільки б разів ти не написав None, це завжди той самий обʼєкт у памʼяті. Тому is тут найточніша й найшвидша перевірка: порівняння за ідентичністю, без зайвих викликів. == працює інакше - він викликає метод __eq__. А його можна перевизначити. І тоді == None починає працювати неочікувано: class Weird: def __eq__(self, other): return True w = Weird() w == None # True w is None # False Обʼєкт очевидно не None, але == каже, що None. З is такого не станеться ніколи бо його не можна перевизначити. Коротко: для None (як і для True/False) завжди is. Це швидше, надійніше і не залежить від того, що хтось накрутив в __eq__.

finally мовчки затирає твій return Погляньмо на функцію: def f(): try: return "from try" finally: return "from finally" f() # "from finally" Здавалося б, return "from try" мав спрацювати. Але finally виконується завжди - навіть після return. І якщо в ньому є свій return, він перекриває той, що був у try. Те саме з винятками: return у finally проковтне навіть виняток, який мав вилетіти назовні. def g(): try: raise ValueError("boom") finally: return "all good" g() # "all good", виняток зник Помилка сталася, але про неї ніхто не дізнається. Такий баг ловиться довго, бо код виглядає цілком робочим. Висновок: finally тримай тільки для очищення (закрити файл, зʼєднання, відпустити лок). Ніяких return чи raise всередині - інакше він тихо перепише всю логіку вище.