Решение на Пет функции от Стефан Маринов
Резултати
- 10 точки от тестове
- 0 бонус точки
- 10 точки общо
- 16 успешни тест(а)
- 0 неуспешни тест(а)
Код
Лог от изпълнението
................ ---------------------------------------------------------------------- Ran 16 tests in 0.008s OK
История (9 версии и 10 коментара)
Стефан обнови решението на 13.03.2014 15:53 (преди над 10 години)
Това с азбуката в самото начало нямаше много голям смисъл да му правя специално set comprehension вместо да извикам просто set(str)
. :)
Стефан обнови решението на 13.03.2014 16:46 (преди над 10 години)
Добавка на collections.defaultdict()
. :)
Стефан обнови решението на 15.03.2014 14:40 (преди над 10 години)
-
is_pangram(sentence)
вече поддръжа правилно и изречения, съдържащи и букви, които не са в нашата кирилица -
anagrams(words)
вече не е case sensitive
Анаграма е дума или фраза образувана от буквите на друга дума или фраза, чрез пермутация.
- Твоето решение не прави разлика между буква и символ
- Операторът
in
е добър начин да разбереш дали нещо е в друго нещо. Изключенията са лош
Стефан обнови решението на 16.03.2014 00:42 (преди над 10 години)
Да, прав си. Тъкмо видях и дискусията във форума точно по този въпрос. Добавката в новата версия би трябвало да го е оправила. :)
Стефан обнови решението на 16.03.2014 00:56 (преди над 10 години)
Опа, сега вече нямам изключения и анаграмите отчитат само букви за пермутациите.
Поправка: Въпросът за изключенията го преместих във форумите, за да е по-лесно достъпен и за останалите.
Стефан обнови решението на 18.03.2014 16:44 (преди над 10 години)
По същество азбуката е константа и я обозначих по съответния начин – WHOLE_ALPHABET
.
Поправка: въпросът го преместих най-отдолу, за да не се губи нишката (тук не мога да оставям нови коментари).
Стефан обнови решението на 18.03.2014 17:38 (преди над 10 години)
Разкарах онази ужасия с filter
-а в anagrams(words)
за сметка на много по-четимия list comprehension. Доколкото разбрах от доста четене по темата, това е и предпочитаният начин на работа в Python.
Все пак горният ми въпрос остава: добър стил ли е константи като моята WHOLE_ALPHABET
да се изкарват извън всички функции в рамките на един модул, дори да са нужни само в една от тях? Тоест, избраното от мен решение, да я декларирам най-отгоре в съответната функция е по-скоро (а) за отбягване; (б) приемливо/добро; (в) за предпочитане?
- Какъв е смисъла да кажеш това ми е константата, не я пипай като никой не може да я ползва или види? Държат се извън функциите на места, където да са достъпни до други евентуално заинтересовани страни. В случая глобалното поле е това място.
- вместо
update
с новопостроен единичен речник спокойно можеш да ползвашmy_dict[key] = value
-
char
е съкращение. Не ползваме съкращения в имената си
Стефан обнови решението на 19.03.2014 02:02 (преди над 10 години)
@Орлин, благодаря за пълния коментар. Ще карам точките в същия ред:
- Да, наистина няма смисъл. Преместих я непосредствено след
import
-ите и преди първата функция, като ѝ сложих един коментар и по-подходящо име. - Съгласен съм и точно това правя при хистограмата, но в случая с групирането според типа не е удачно. Все пак там се търси речник с типовете за ключове и речници от самите елементи. Всеки от последните е новосъздаден речник точно веднъж (при първото срещане на типа). Ако ползвам твоето предложение там, постоянно ще презаписвам съответния елемент и ще ми остане запазена само последната стойност, което би давало верен отговор само ако има по точно един елемент от всеки тип на ключа в първоначалния речник. Малко объркано, но се надявам, че се разбра все пак. :)
- Съгласен съм. Оправих си всички съкратени имена на променливи, които намерих.
- Бонус: добавих docstrings (с малко reStructuredText) според съответните PEP-ове. :)
И още един въпрос: забележката ти за съкращенията значи ли, че името на char_histogram
е (сравнително) неподходящо избрано или това важи предимно/само за променливите?