Георги обнови решението на 26.04.2013 10:53 (преди над 11 години)
+REPOSITORY = 'https://github.com/stormbreakerbg/python-retrospective'
+
+##############################################################################
+# По-малко от двадесет неща, които научих
+##############################################################################
+#
+# 1. range е по-ясно как и защо се използва отколкото просто някакви числа в
+# тюпъли.
+#
+#####
+#
+# 2. Светът не е идеален. В задачата за хороскопа SIGNS щеше да е по-добре да
+# е dict (става още по-ясно кое защо е), но се налага 'Козирог' да го има
+# два пъти.
+# Със сигурност има някой странен трик да се направи да работи с една поява
+# на 'Козирог', но няма да е толкова изчистено и разбираемо от други хора.
+#
+#####
+#
+# 3. Използването на list/dict comprehensions не е толкова готино.
+# В groupby е много по-изчистен варианта с цикъла, пък и върши по-малко
+# работа като извиква func много по-малко пъти и проверява по-малко
+# елементи. Варианта с comprehensionите въобще не изглежда разбираем.
+#
+#####
+#
+# 4. Използването на list/dict comprehensions е готино.
+# ... когато са къси нещата и се налага прост map/filter/проверка
+# на итеруеми.
+#
+#####
+#
+# 5. Използването на вградени функции е готино и пести код (стига да знаеш за
+# тези функции).
+# В комбинация с точка 4 се получават много по-кратки неща.
+# Пример: кода на zip_with се смали до
+# return [func(*line) for line in zip(*iterables)]
+#
+#####
+#
+# 6. Имплементирането на повече функционалност, отколкото е в условието на
+# задача/домашно е безсмислено, освен ако не научиш нещо в процеса
+# на писане.
+# Съкратих 61 реда от Person като махнах нещата, които не се изискват от
+# условието. Е, беше добро упражнение за гетъри и сетъри.
+#
+#####
+#
+# 7. Python не е C++, Java, C# или който и да е силно-типизиран ОО език.
+# Няма как със 100% сигурност да се поддържа йерархията от Person-и в добър
+# стейт. Ако някой иска може да я прецака все някак. Безсмислено е да
+# пробвам да я правя "по-умна" в този случай.
+# Имам чувството, че някаква йерархия от обекти Person във всеки един
+# момент ще се срине. Странно ми е да няма никакви гаранции за
+# енкапсулация.
+#
+#####
+#
+# 8. Използването на set вместо list не винаги е по-добрата идея. Понякога
+# ти трябва наредбата, дори и да не го осъзнаваш на момента.
+#
+#####
+#
+# 9. set е готин начин за премахване на дубликати на елементи от итеруеми,
+# но само ако си 100% сигурен, че не ти трябва наредбата. Искам OrderedSet!
+#
+#####
+#
+# 10.По-ясното решение почти винаги е по-доброто решение. В тази връзка
+# пренаписах начина за търсене на решения в TicTacToeBoard.
+# Първо списъка с печелещите линии (_WIN_LINES) е най-ясен като всяка е
+# просто координатите на три полета. Защо го бях писал координати на едно
+# поле + стъпка нямам идея.
+#
+#####
+#
+# 11.Усложняването на кода за сметка на малко съкращаване на една константа е
+# самоубийство.
+# Когато е подбран добре формата на константите много неща могат
+# да се направят на 1 ред в кода. Или ако не на 1 ред, то поне много
+# по-просто.
+#
+#####
+#
+# 12.Вътрешното представяне на информацията трябва да е възможно най-близко до
+# външното. Да записвам ключовете в _game_board като (row, column), вместо
+# просто като стринга, който се използва за достъп, е глупаво и ми създава
+# много повече работа.
+#
+#####
+#
+# 13.Още не мога да разгранича ясно къде да използвам една долна черта и къде
+# две. Мисля, че е хубаво колкото се може повече неща (от тези, които са
+# детайли на имплементацията) да са с една.
+#
+#
+#####
+#
+# 14.Котките са много готини
+#
+# _
+# \`*-.
+# ) _`-.
+# . : `. .
+# : _ ' \
+# ; *` _. `*-._
+# `-.-' `-.
+# ; ` `.
+# :. . \
+# . \ . : .-' .
+# ' `+.; ; ' :
+# : ' | ; ;-.
+# ; ' : :`-: _.`* ;
+# [bug] .*' / .*' ; .*`- +' `*'
+# `*-* `*-* `*-*'
С точка 3 съм тотално несъгласен, но съм склонен да приема, че е въпрос на лично мнение.
Относно точка 13: Може би не сме го обяснили добре. Ще се пробвам тук и пак на някоя от следващите лекции.
-
_my_sweet_method- е метод, който не е за използване извън текущия клас/модул. Някакъв не особено магически метод, който е там вероятно за избегване на повторения или нещо в този дух. Знаеш, че приfrom my_sweet_module import *това име няма да се импортне -
__my_sweet_methodот друга страна е с критична важност за функционирането на твоя клас/модул. Той става достъпен през_MySweetClass__my_sweet_methodи ясно казваш, че ако някой го пипне заслужава камъни да летят по главата му. Ако правиш някакви безумни магии, ползваш тази идея. -
my_sweet_method_е най-нормално име, което просто overwrite-ва вградено нещо в езика. Знаеш, чеclassе запазена дума и не може да се използва като първи аргумент за класметод. В този случай,class_е един страхотен избор. -
__my_sweet_method__е начин, по който никога не именоваш свои неща. Само вградени в езика неща се именоват така и знаеш, че можеш да ги предефинираш.
Колкото и да съм съгласен с точка 14, не мога да я приема. Но може да я предадеш като точка 21 :P
Благодаря за обяснението. Явно наистина повечето неща, които са по някакъв начин вътрешни, най-често се налага да са с една долна черта.
Точка 14 да се чете като 21 тогава :D Не се сещам какво друго да допълня, тъй че ще ги оставя така. :)