Коли ви кодуєте іншими мовами, ви іноді створюєте область блоку, наприклад:
statement
...
statement
{
statement
...
statement
}
statement
...
statement
Однією з цілей (з багатьох) є покращення читабельності коду: показати, що певні оператори утворюють логічну одиницю або що певні локальні змінні використовуються лише в цьому блоці.
Чи існує ідіоматичний спосіб робити те саме в Python?
__exit__і висловитись with, змінивши, globals()але мені не вдалося.
Відповіді:
Ідіоматичним способом у Python є короткість ваших функцій. Якщо ви вважаєте, що вам це потрібно, переробіть свій код! :)
Python створює нову область для кожного модуля, класу, функції, виразу генератора, розуміння дикту, розуміння набору, а в Python 3.x також для кожного розуміння списку. Крім них, всередині функцій немає вкладених областей.
Ви можете зробити щось подібне до області блоку C ++ у Python, оголосивши функцію всередині вашої функції, а потім негайно викликавши її. Наприклад:
def my_func():
shared_variable = calculate_thing()
def do_first_thing():
... = shared_variable
do_first_thing()
def do_second_thing():
foo(shared_variable)
...
do_second_thing()
Якщо ви не впевнені, чому ви можете зробити це, це відео може вас переконати.
Основний принцип полягає в тому, щоб розгорнути все якомога щільніше, не вводячи будь-яке «сміття» (додаткові типи / функції) в більш широкий обсяг, ніж це абсолютно потрібно - Ніщо інше не хоче використовувати do_first_thing()метод, наприклад, тому його не слід масштабувати поза функція виклику.
Я погоджуюсь, що не існує блоку. Але одне місце в python 3 робить його ЗДАЙТИСЯ так, ніби він має область блоку.
що сталося, що надало цьому погляду? Це працювало належним чином у python 2. але, щоб зупинити змінні витоки в python 3, вони зробили цей трюк, і ця зміна робить його схожим на те, ніби тут є область блоку.
Дозволь пояснити.
Відповідно до ідеї сфери дії, коли ми вводимо змінні з однаковими іменами всередині однієї області дії, її значення слід модифікувати.
це те, що відбувається в python 2
>>> x = 'OLD'
>>> sample = [x for x in 'NEW']
>>> x
'W'
Але в python 3, хоча змінна з тим самим іменем введена, вона не перевизначає, розуміння списку чомусь діє як пісочниця і, здається, створює в ній нову область.
>>> x = 'OLD'
>>> sample = [x for x in 'NEW']
>>> x
'OLD'
і ця відповідь суперечить твердженню відповідача @ Thomas . Єдиним засобом для створення області є функції, класи або модулі, оскільки це виглядає як одне інше місце створення нової області.
Модулі (та пакети) - чудовий пітонічний спосіб розділити вашу програму на окремі простори імен, що, мабуть, є неявною метою цього питання. Дійсно, коли я вивчав основи Python, я відчував розчарування через відсутність функції сфери блоку. Однак, як тільки я зрозумів модулі Python, я міг більш елегантно реалізувати свої попередні цілі без необхідності в області блоків.
Як мотивацію та спрямування людей на правильний напрямок, я вважаю, що корисно навести чіткі приклади деяких конструкцій обсягу Python. Спочатку я пояснюю свою невдалу спробу використання класів Python для реалізації області блоків. Далі я поясню, як я досяг чогось більш корисного, використовуючи модулі Python. Наприкінці я описую практичне застосування пакетів для завантаження та фільтрації даних.
Декілька хвилин я думав, що досяг межі блоку, вставивши код всередину оголошення класу:
x = 5
class BlockScopeAttempt:
x = 10
print(x) # Output: 10
print(x) # Output: 5
На жаль, це руйнується, коли визначається функція:
x = 5
class BlockScopeAttempt:
x = 10
print(x) # Output: 10
def printx2():
print(x)
printx2() # Output: 5!!!
Це тому, що функції, визначені в класі, використовують глобальну область. Найпростіший (хоча і не єдиний) спосіб виправити це явним вказівкою класу:
x = 5
class BlockScopeAttempt:
x = 10
print(x) # Output: 10
def printx2():
print(BlockScopeAttempt.x) # Added class name
printx2() # Output: 10
Це не настільки елегантно, тому що потрібно писати функції по-різному, залежно від того, чи містяться вони в класі.
Модулі дуже схожі на статичні класи, але на мій досвід модулі набагато чистіші. Щоб зробити те саме з модулями, я створюю файл, що викликається my_module.pyу поточному робочому каталозі, із таким вмістом:
x = 10
print(x) # (A)
def printx():
global x
print(x) # (B)
Тоді у своєму основному файлі чи інтерактивному (наприклад, Юпітер) сеансі я це роблю
x = 5
import my_module # Output: 10 from (A)
my_module.printx() # Output: 10 from (B)
print(x) # Output: 5
Як пояснення, кожен файл Python визначає модуль, який має власний глобальний простір імен. Імпорт модуля дозволяє отримати доступ до змінних у цьому просторі імен із .синтаксисом.
Якщо ви працюєте з модулями в інтерактивному сеансі, ви можете виконати ці два рядки на початку
%load_ext autoreload
%autoreload 2
і модулі будуть автоматично перезавантажені, коли їх відповідні файли будуть змінені.
Ідея пакетів - це невелике розширення концепції модулів. Пакет - це каталог, що містить (можливо порожній) __init__.pyфайл, який виконується при імпорті. До модулів / пакетів у цьому каталозі можна отримати доступ із .синтаксисом.
Для аналізу даних мені часто потрібно прочитати великий файл даних, а потім інтерактивно застосувати різні фільтри. Читання файлу займає кілька хвилин, тому я хочу зробити це лише один раз. Виходячи з того, що я дізнався в школі про об’єктно-орієнтоване програмування, я звик вважати, що потрібно писати код для фільтрації та завантаження як методи в класі. Основним недоліком цього підходу є те, що якщо я потім перевизначу свої фільтри, визначення мого класу змінюється, тому мені доводиться перезавантажувати весь клас, включаючи дані.
Сьогодні за допомогою Python я визначаю пакет, my_dataякий називається, який містить підмодулі з іменем loadта filter. Усередині filter.pyя можу зробити відносний імпорт:
from .load import raw_data
Якщо я модифікую filter.py, тоді autoreloadвиявлять зміни. Він не перезавантажується load.py, тому мені не потрібно перезавантажувати свої дані. Таким чином я можу прототипувати свій код фільтрації в блокноті Jupyter, обернути його як функцію, а потім вирізати-вставити зі свого блокнота безпосередньо в filter.py. З’ясування цього справило революцію в моєму робочому процесі та перетворило мене із скептика на віруючого в “дзен Пітона”.
One purpose (of many) is to improve code readability- Код Python, написаний правильно (тобто, слідуючи дзену python ), не потребував би такого гарніру для читання. Насправді це одна з (багатьох) речей, які мені подобаються в Python.