Калоян обнови решението на 28.04.2013 22:32 (преди над 11 години)
+REPOSITORY = 'https://github.com/KaloyanKaludov/python-retrospective'
+
+# Двадесет неща, които научих.
+#
+# 1. Именованите променливи правят кода по-четим.
+# 2. "is not" е по-четимо от "!=", но не винаги е вярно заради различното им
+# значение, въпреки че за immutable низове върши работа.
+# 3. Колкото и да е красиво използването на List Comprehension понякога за да
+# угодим на PEP8 трябва да го счупим на няколко реда, което води до грозен
+# код, който е най-добре в крайна сметка да бъде заменен с цикъл for.
+# 4. Ако итерираш през няколко списъка едновременно без да знаеш размера им
+# можеш да проверяваш за StopIteration изключението за да разбереш кога
+# някой от тях е свършил.
+# 5. За разлика от навсякъде другаде според PEP8 равното при именованите
+# променливи се пише без интервали.
+# 6. Вместо "not A in B" може да се запише "A not in B" и ще върши същата
+# работа само, че ще се чете по-лесно.
+# 7. Функциите генератори са по-лесни за използване от наши собствени итератори.
+# 8. Когато се прави композиция на функции е добра идея тя да е в отделна
+# функция, защото ако е директно в lambda предизвиква Stack Overflow.
+# 9. Понякога е по-лесно да се реализира клас със дъндър __call__ отколкото
+# да се направи функция - основно заради възможността да се запази някакво
+# особено състояние на функцията.
+# 10.За dict, в който обаче искаме да има наредба, си има готов клас наречен
+# OrderedDict. В него има приятни методи, които помагат да се изхвърли
+# например най-стария елемент.
+# 11.Един безкраен "while True" цикъл върши чудесна работа във функции
+# генератори, когато не знаем кога трябва да спрем. (Въпреки, че изглежда
+# малко грозно някакси)
+# 12.List Comprehension е по-четимо от map или/и filter освен в случаите, когато
+# символите на ред не станат твърде много и не ни се наложи да го чупим на
+# няколко реда.
+# 13.В PEP8 има много смислени неща, но правилото за 80 символа на ред
+# не е едно от тях. (Освен ако на пишем на 20 годишна пишеща машина)
+# 14.Ако функция се използва само на едно място и при това вътре друга функция,
+# то е добра идея тя да се дефинира вътре в използващата я функция.
+# 15.Когато не знаем някакви аргументи ползваме *args и **kwargs за да сме
+# сигурни, че ще хванем всички.
+# 16.Ако искаме да разберем какви са аргументите на някаква функция можем да
+# използваме модула inspect.
+# 17.Ако използваме модула inspect значи по всяка вероятност не сме се сетили
+# за някое по-лесно решение, което със сигурност съществува.
+# 18.За да реализираме достъп чрез оператора [] използваме дъндър __getitem__.
+# 19.След като сме тръгнали да пишем __getitem__ няма да е лоша идея да сложим
+# и дъндър __setitem__ за пълнота. Лоша идея е да има само едното.
+# 20.Не със всичко, което може да се итерира, може да се извика len().
+# Проблем са безкрайните функции генератори.
Много добре, харесват ми. Имам коментари само по една точка.
Точка 13: Това правило не е някакво legacy, а чисто и просто е там за да подтиква хората да си оправят кода. Ако получиш ред 200 символа и не пишеш на Java, значи правиш нещо грешно. Много редактори поддържат сплитове и ако целия ти проект минава PEP 8, е в реда на нещата да докараш и три колони.
Все пак осъзнавам, че на моменти е дразнещо. Примерно в Django изрично го пренебрегват това правило, тъй като е наистина досадно да докараш реда на 84 символа и да се чудиш как да го оправиш. Поради тази причина приемам тази точка :)
точка 2: ... освен ако не са от по-дългите :)