Какие самые неприятные хаки Python для раскрутки, переписывания и т. Д.?

Question

Мое впечатление от Python за то короткое время, которое я разрабатывал с ним, заключается в том, что он невероятно мощный и гибкий, но я не могу не чувствовать, что «с большой силой приходит большая ответственность». Поэтому, хотя я прочитал множество постов в блоге о простых и элегантных фрагментах Python, которые решают проблему, мне интересно, существуют ли шаблоны проектирования или злоупотребления функциями языка Python, которые, будучи встроенными в приложение или библиотеку, делают код невероятно хрупким и почти невозможно провести рефакторинг.

Таким образом, вопрос заключается в том, каковы наиболее разочаровывающие, но в некоторой степени распространенные «хаки» Python или злоупотребления языковыми функциями, которые кто-то может ввести, что вызовет кошмары для будущих разработчиков этого кода?

Answer 1

Чрезмерное использование from module import *.

Имея много таких импортов в модуле, вы не знаете, откуда взялась каждая переменная, и вам нужно искать все импортированные модули. Поиск не очень помогает в этом случае.

Answer 2

Использование eval или exec при вводе пользователем может быть самым распространенным нарушением функций Python.

Answer 3

Магия, которая работает, но не всегда. Например, когда метаклассы используются для создания DSL. Такой DSL может быть подходящим для большинства задач, но ужасно ломается на сложную (неожиданную для автора) задачу.

Answer 4

.. какие самые разочаровывающие, но в некоторой степени распространенные «хаки» Python или злоупотребления языковыми функциями, которые кто-то может ввести, могут стать кошмарами для будущих разработчиков этого кода?

Трудно рефакторинг:

понимание вложенного списка (как в: несколько уровней глубины).

Большинство людей (при изучении Python) очарованы мощью и полезностью понимания списков. Это может вызвать тенденцию к чрезмерному их использованию и созданию глубоко вложенных, сложных. Большую часть времени один и тот же код должен был быть написан с простыми циклами для удобства чтения и поддержки. Я считаю, что три уровня уже слишком глубоко вложены.

-

А также (не так сложно перестроить, но в основном раздражает):

пытается использовать Python, как если бы он был другим языком (без собственных специфических конструкций); e.g.:

for i in range(len(mylist)):
    item = mylist[i]
    # do stuff with item

вместо

for i, item in enumerate(mylist):
    # do stuff with item

или даже (зачем вам индекс в любом случае):

for item in mylist:
    # do stuff with item

Это включает в себя: заново изобретать колесо (плохо), когда функциональность уже (точно названа) в богатой стандартной библиотеке.

И проверка типов, делающая вещи невозможными для подкласса и т. Д. *

Answer 5

Это не хак, но с ключевым словом print в Python 2.X была довольно большая проблема.

Люди будут полагаться на print, который будет вызываться для вывода в течение всего проекта, а затем, когда наконец наступит время, скажем, изменить вывод в файл и на стандартный вывод, они получат чтобы перейти и выполнить рефакторинг всех этих выводов ключевых слов в другую пользовательскую функцию вывода.

Python 3 решил эту проблему, сделав print фактической функцией, а не ключевым словом (поэтому автоматически выводит слабо связанную с остальной частью системы), поэтому при необходимости вы можете заменить исходную print с новым print, который делает больше, чем просто пишет в стандартный вывод.

См. PEP3105 для конкретных рассуждений Гвидо и более подробной информации.

Answer 6

Самая большая проблема, с которой я столкнулся, - это использование атрибутов с двойным подчеркиванием. Исполнители практически всегда являются новыми программистами Python или программистами, которые предпочитают другой язык (в частности, Java, по какой-то причине). Двойное подчеркивание приводит к искажению имен атрибутов (с использованием текущего имени класса), избегая столкновений в подклассах. Это слишком часто рассматривается как «личное», хотя это не так. (См. этот ответ, который я однажды написал .) Те же самые классы обычно завалены средствами доступа - не свойствами, а обычными методами, вызываемыми напрямую - для получения этих атрибутов с именами. Конечным результатом всегда является ужасно запутанный класс, который невозможно разделить на подклассы, чтобы специализироваться, исправлять ошибки, ставить обезьяны или тестировать.