Python 2, nonlocal and immutable variables
Нудний вступ я опущу, і перейду зразу до розваги:
def case(func): # декоратор прикладу
print func.__name__ # печатаємо назву
try:
func() # виконуємо функцію
except Exception, e: # Якщо є помилки
print 'Error:', e # помічаємо і продовжуємо
print
@case
def test_a():
x = 1
def inner():
x = 2 # x в цій області імен посилається на новий об’єкт - 2
print 'inner:', x # x == 2
inner()
print 'outer:', x # x == 1. Цю область імен ми не чіпали
@case
def test_b():
x = [1]
def inner():
x[0] = 2 # при обчисленні x[0], ми шукаємо x у всіх просторах тут і вище
print 'inner:', x # x == [2], x посилається на все той же об’єкт, але він змінився
inner()
print 'outer:', x # x == [2], сказано ж, об’єкт змінився.
@case
def test_c():
x = 1
def inner():
x +=1 # генерує UnboundLocalError
# бо x - в лівій частині присвоєння, що робить його локальним.
# а в правій частині - x + 1, значення якого ще не визначено
# бо ж x щойно з’явився в просторі імен
# детальніше про те чому так: http://eli.thegreenplace.net/2011/05/15/understanding-unboundlocalerror-in-python/
print 'inner:', x
inner()
print 'outer:', x # сюди ми не доходимо
# Як реалізувати нелокальну змінну, якщо ви працюємо не з третім Python?
@case
def test_d():
# використати mutable об’єкт
nonlocal = lambda:7 # функція підходить
nonlocal.x = 1
def inner():
nonlocal.x += 1
print 'inner:', nonlocal.x # == 2
inner()
print 'outer:', nonlocal.x # == 2
Мораль теж опущу, все таки потрібно працювати.
Назад в термінал
Я переключився з Gvim назад на Vim, при чому вже давно, та все ніяк не збирався написати. Приводом до цього стало те що Gvim ніяк не вміє перейти в повноекранний режим. Проте, в консольного Vim є ще купа переваг:
- Нормальна підтримка терміналу. З curses, що дає можливість використовувати кольори, пейджери, і взагалі bpython.
- Можливість починати роботу командою
vim -p `hg st -n`(відрити у вкладках всі файли які були змінені в поточній ревізії). - Можливість змінювати розмір шрифту на ходу – можна дивитись на код з висоти пташиного польоту по 90 рядків на екран, і до 40 рядків при яких можна відкинутись назад на крісло і медитувати на якусь цікаву функцію.
Новий кваліфікаційний рівень і пізнання AOP
Ах, я його отримав позавчора. Але часу побритись не знаходжу, не те що про це написати.
Ну але зараз я маю хвильку часу:

тому знову похвалюсь.
Хоча взагалі те що я закінчив вчитись це не так вже й важливо, бо загалом на спеціаліста мене вчили не набагато більше ніж на бакалавра. Взагалі не вчили можна сказати. І я радий що не дав їм витягнути мені оцінку диплому, і змусив поставити її об’єктивно. Так, завжди є люди які ще гірші за мене, які займаються не тільки самоплагіатом, а взагалі плагіатом і я вмію притворятись розумним хлопчиком, але я просто щаслиіший коли люди оцінюють мене об’єктивно.
На захисті запам’ятався елемент виступу мого одногрупника, забув як його звати, але пам’ятаю що він senior Java developer в EPAM.
Він сказав: AOP – це парадигма яка дозволяє замість, перед чи після методу виконати ще якийсь код. І я прозрів! Аспектно орієнтоване програмування – це декоратори. І маємо ще простіше визначення ніж “екзистенціалізм це гуманізм”, бо AOP це таки точно, за визначенням декоратори.
Ну може хіба вони застосовуються лише в обмежених точках з’єднання, але в мене є сумніви що в інших мовах advice можна чіпляти до чогось окрім методів та класів.
Я правильно розумію парадигму?
Весна
Зараз спробую зекономити час на багаторазові відповіді на запитання “як справи?” і куди я подівся.
Прочитати решту цієї замітки »
Легенда про самодокументований код
Якось був код:
if self.get_package_ids() == [None]: # only free package
Він був дещо незрозумілим, тому прокоментованим. Але потім в когось з’явилась ідея додати
def only_free_package(self):
return self.get_package_ids() == [None]
І коментар в нашому рядочку став зайвим:
if self.only_free_package():
Ось і все. Це коротка легенда з простим сюжетом. Її мораль – методи призначені не тільки для повторного використання. Їх також варто використовувати для ізоляції рівнів абстракції.
Макконел також розповідає що можна писати спочатку псевдокод, потім його поступово закоментовувати (якщо він хороший він може бути документацією), і під ним писати решту коду.
Але дуже часто я бачив псевдокод нижчого рівня ніж Python. Я читав погані псевдокоди?


