Базовая библиотека Python и PEP8 - PullRequest
Новая
       5

Базовая библиотека Python и PEP8

5 голосов
/ 01 марта 2011

Я пытался понять, почему Python называется прекрасным языком.Я был направлен на красоту ПКП 8 ... и это было странно.На самом деле это говорит о том, что вы можете использовать любое соглашение, которое хотите, просто быть последовательным ... и вдруг я обнаружил некоторые странные вещи в базовой библиотеке: 

request()
getresponse()
set_debuglevel()
endheaders()
http://docs.python.org/py3k/library/http.client.html

Следующие функции появились в Python 3.1.Какая часть соглашения PEP 8 используется здесь? 

popitem()
move_to_end()
http://docs.python.org/py3k/library/collections.html

Итак, мой вопрос: используется ли PEP 8 в базовой библиотеке или нет?Почему это так?
Есть ли такая же ситуация, как в PHP, когда я не могу просто запомнить имя функции, потому что возможны все способы написания имени?

Почему PEP 8 не используетсяв основной библиотеке даже для новых функций?

Ответы [ 3 ]

10 голосов
/ 01 марта 2011

PEP 8 рекомендует использовать подчеркивания в качестве выбора по умолчанию, но обычно их опускают по одной из двух причин:

  • согласованность с некоторым другим API (например, текущим модулем или стандартным интерфейсом)
  • , потому что их игнорирование не ухудшает читаемость (или даже улучшает ее)

Чтобы привести конкретные примеры, которые вы цитируете:

  • popitem - это давний метод для dict объектов. Другие API, которые принимают его, сохраняют это написание (то есть не подчеркивание).

  • move_to_end совершенно новый. Несмотря на то, что в объекте пропущены подчеркивания, не использующие подчеркивания, он следует рекомендованному соглашению PEP 8 об использовании подчеркиваний, поскольку movetoend трудно читать (в основном из-за того, что toe - это слово, поэтому большинству людей придется выполнять резервное копирование и повторный анализ один раз. они замечают nd)

  • set_debuglevel (и более новый set_tunnel), вероятно, должны были оставить подчеркивание для согласованности с остальной частью HTTPConnection API. Однако первоначальный автор мог просто предпочесть от set_debuglevel до setdebuglevel (обратите внимание, что debuglevel также является аргументом для конструктора HTTPConnection, объясняющего отсутствие второго подчеркивания), а затем просто автор set_tunnel последовал этому примеру.

  • set_tunnel на самом деле еще один случай, когда падение подчеркивания, возможно, ухудшает читабельность. Сопоставление двух «t» в settunnel не способствует легкому анализу.

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

4 голосов
/ 01 марта 2011

Из PEP8:

Но самое главное: знать, когда нужно быть непоследовательным - иногда руководство по стилю просто не применяется.В случае сомнений используйте свое лучшее суждение.Посмотрите на другие примеры и решите, что выглядит лучше.И не стесняйтесь спрашивать!

То, что вы упомянули здесь, в некоторой степени соответствует рекомендациям PEP8;на самом деле, основные несоответствия есть в других частях, обычно с CamelCase.

2 голосов
/ 01 марта 2011

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

Конечно, я считаю, что другие факторы перевешивают этот негатив, нотем не менее, это негатив.

...