 |
Выражения-генераторы. Тестирование. (не) Погружение
|
|
|
|
Выражения-генераторы
Выражения-генераторы, как генератор функций, но без функции.
> > > unique_characters = {'E', 'D', 'M', 'O', 'N', 'S', 'R', 'Y'}
> > > gen = (ord(c) for c in unique_characters) ①
> > > gen ②
< generator object < genexpr> at 0x00BADC10>
> > > next(gen) ③
69
> > > next(gen)
68
> > > tuple(ord(c) for c in unique_characters) ④
(69, 68, 77, 79, 78, 83, 82, 89)
① Выражение-генератор, это как анонимная функция которая выдает значения. Само выражение выглядит как список, но он обернут не в квадратные, а в фигурные скобки.
② Выражение-генератор возвращает итератор.
③ Вызов next(gen) возвращает следующее значение итератора.
④ Если вам нравится, вы можете повторить через все возможные значения и возвратить кортеж, список или множество, направив выражение-генератор в tuple(), list(), или set(). В этих случаях вам не нужно дополнительных скобок - просто передайте " голые" выражение ord(c) for c in unique_characters в tuple() функцию, и Python понимает, что это выражение-генератор.
| Использование выражений-генераторов вместо списка помогает сохранить cpu и ram. Если вы используете список, чтобы потом выбросить его (например передать в tuple() или set()), используйте генератор вместо него! |
Вот еще один способ сделать то же самое, используя генератор функции:
def ord_map(a_string):
for c in a_string:
yield ord(c)
gen = ord_map(unique_characters)
Выражения-генераторы более компактны, но функционально равны.
Тестирование
(не) Погружение
(Данная страница находится на стадии перевода)
Современная молодежь. Избалованы быстрыми компьютерами и модными «динамическими» языками. Писать, потом предоставлять свой код, потом отлаживать (в лучшем случае). В наши дни была дисциплина. Я сказал, дисциплина! Нам приходилось писать программы вручную, на бумаге, и вводить их в компьютер на перфокартах. И нам это нравилось!
|
|
|
В этом разделе вы напишете и отладите набор вспомогательных функций для конвертирования в римскую систему и обратно. Вы видели, как конструируются и валидируются числа в римской системе в разделе «Учебный пример: Римские цифры». Вернемся немного назад и представим, как бы выглядила реализация в виде функции, производящей преобразование в обоих направлениях.
Правила формирования римских чисел приводят нас к нескольким интересным наблюдениям:
1. Существует только один правильный способ записать число римскими цифрами.
2. Обратное также верно: если строка символов является последовательностью римских символов, она представляет только одно число, то есть может быть интерпретирована единственным способом.
3. Диапазон чисел, которые могут быть записаны римскими цифрами, — от 1 до 3999. У римлян было несколько способов записывать более крупные числа, в частности, с помощью черты над числом, которая означала 6ы, что значение нужно умножить на 1000. Для целей этой главы нам достаточно ограничиться диапазоном 1 — 3999.
4. Нет способа представить 0 в римской системе.
5. Нет способа представить отрицательные числа в римской системе.
6. Нет способа представить дробные или нецелые числа в римской системе.
Попробуем отразить, что должен делать модуль roman. py. Он будет содержать две основные функции, to_roman() и from_roman(). Функция to_roman() должна принимать целое число в диапазоне от 1 до 3999 и возвращать строку, содержащую римское представление этого числа…
Остановимся здесь. Давайте теперь сделаем кое-что неожиданное: опишем небольшой тестовый случай, который проверяет, работает ли функция to_roman() так, как мы этого ожидаем. Вы правильно поняли: мы собираемся написать код, который тестирует код, который еще не написан.
Это так называемая разработка через тестирование (test-driven-development, TDD). Набор из двух функций конвертации — to_roman(), from_roman() — может быть написан и протестирован как юнит, в отдельности от любой крупной программы, которая импортирует их. В Python’е есть фреймворк для юнит-тестирования, модуль с соответствующим называнием unittest.
|
|
|
Юнит тестирование — важная часть всей стратегии разработки, основанной на тестировании. Если вы пишете юнит-тесты, необходимо писать их на ранних этапах и обновлять их по мере изменений кода и требований. Многие люди пропагандируеют написание тестов до написания тестируемого кода, и именно этот подход я собираюсь продемонстрировать в этом разделе. Однако юнит-тесты выгодны вне зависимости от того, когда вы их пишете.
- До написания кода написание юнит тестов заставляет детализировать требования в удобном для их реализации виде
- Во время написания кода юнит тесты предохраняют вас от лишнего кодирования. Когда все тесты проходят, тестируемый юнит готов.
- Во время рефакторинга они помогают доказать, что новая версия ведет себя так же, как и старая.
- Во время поддержки кода существование юнит тестов прикроет вашу задницу, когда кто-то начнет кричать, что ваше последнее изменение сломало их код. («Но сэр, все тесты проходили успешно, когда я делал commit. »)
- Когда код пишется в команде, наличие всестороннего набора тестов значительно снижает риск того что ваш код сломает код другого разработчика, поскольку вы можете исполнить его юнит тесты. (Я видел как это работает на практике в code sprints (кодинг на скорость? : )??? ). Команда разбивает задание, участники разбирают спецификации своих задач, пишут для них юнит тесты, затем обмениваются юнит тестами со всей командой. Так никто не зайдет слишком далеко в разработке кода который плохо пригоден для команды. )
|
|
|
