Одинарные кавычки против двойных кавычек в Python [закрыто]

Согласно документации, они в значительной степени взаимозаменяемы. Есть ли стилистическая причина использовать один над другим?

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

Например:

LIGHT_MESSAGES = {
    'English': "There are %(number_of_lights)s lights.",
    'Pirate':  "Arr! Thar be %(number_of_lights)s lights."
}

def lights_message(language, number_of_lights):
    """Return a language-appropriate string reporting the light count."""
    return LIGHT_MESSAGES[language] % locals()

def is_pirate(message):
    """Return True if the given message sounds piratical."""
    return re.search(r"(?i)(arr|avast|yohoho)!", message) is not None

Цитирование официальных документов по адресу https://docs.python.org/2.0/ref/strings.html :

На простом английском языке: строковые литералы могут быть заключены в одинарные кавычки (') или двойные кавычки (").

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

Раньше я предпочитал ', особенно для '''docstrings''', как я нахожу """this creates some fluff""". Кроме того, 'можно печатать без Shiftключа на моей швейцарской немецкой клавиатуре.

С тех пор я изменил использование тройных кавычек для """docstrings"""соответствия PEP 257 .

Я с Уиллом:

• Двойные кавычки для текста
• Одинарные кавычки для всего, что ведет себя как идентификатор
• Необработанные строковые литералы в двойных кавычках для регулярных выражений
• Утроенные двойные кавычки для строк документации

Я буду придерживаться этого, даже если это будет означать побег.

Я получаю наибольшее значение из одинарных кавычек, выделяющихся из-за кавычек. Остальные практики предназначены только для того, чтобы дать этим идентификаторам, заключенным в одинарные кавычки, некоторое место для стояния.

Если у вас есть одна строка, то вы должны использовать другую. Например "You're able to do this", или 'He said "Hi!"'. Кроме этого, вы должны быть настолько последовательными, насколько это возможно (внутри модуля, внутри пакета, внутри проекта, внутри организации).

Если ваш код будут читать люди, работающие с C / C ++ (или если вы переключаетесь между этими языками и Python), то использование ''односимвольных и ""более длинных строк может помочь облегчить переход. (Аналогично для следующих других языков, где они не являются взаимозаменяемыми).

Код Python , я видел в дикой природе , как правило , в пользу "более ', но только немного. Единственным исключением является то, что они """these"""встречаются гораздо чаще '''these''', чем я видел.

Тройной цитаты комментарии являются интересной подтемой этого вопроса. PEP 257 определяет тройные кавычки для строк документа . Я быстро проверил, используя Google Code Search, и обнаружил, что тройные двойные кавычки в Python примерно в 10 раз популярнее, чем тройные одинарные кавычки - 1,3 млн против 131 КБ в коде индексов Google. Так что в случае с несколькими строками ваш код, вероятно, станет более привычным для людей, если он использует тройные двойные кавычки.

"If you're going to use apostrophes, 
       ^

you'll definitely want to use double quotes".
   ^

По этой простой причине я всегда использую двойные кавычки снаружи. Всегда

Говоря о пуху, что хорошего в том, чтобы упорядочить ваши строковые литералы с помощью «если вам придется использовать escape-символы для представления апострофов? Обижает ли кодеров читать романы? Я не могу представить, насколько болезненным для вас был урок английского языка в старшей школе!

Python использует кавычки примерно так:

mystringliteral1="this is a string with 'quotes'"
mystringliteral2='this is a string with "quotes"'
mystringliteral3="""this is a string with "quotes" and more 'quotes'"""
mystringliteral4='''this is a string with 'quotes' and more "quotes"'''
mystringliteral5='this is a string with \"quotes\"'
mystringliteral6='this is a string with \042quotes\042'
mystringliteral6='this is a string with \047quotes\047'

print mystringliteral1
print mystringliteral2
print mystringliteral3
print mystringliteral4
print mystringliteral5
print mystringliteral6

Что дает следующий вывод:

this is a string with 'quotes'
this is a string with "quotes"
this is a string with "quotes" and more 'quotes'
this is a string with 'quotes' and more "quotes"
this is a string with "quotes"
this is a string with 'quotes'

Я вообще использую двойные кавычки, но не по какой-то конкретной причине - вероятно, просто по привычке из Java.

Я предполагаю, что вы также скорее всего захотите апострофы в строковой литеральной строке, чем двойные кавычки.

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

Это, вероятно, стилистическое предпочтение больше всего на свете. Я только что проверил PEP 8 и не увидел упоминаний об одинарных и двойных кавычках.

Я предпочитаю одинарные кавычки, потому что это только одно нажатие клавиши вместо двух. То есть мне не нужно нажимать клавишу Shift, чтобы сделать одинарную кавычку.

В Perl вы хотите использовать одинарные кавычки, когда у вас есть строка, которая не нуждается в интерполяции переменных или экранированных символов, таких как \ n, \ t, \ r и т. Д.

PHP делает то же различие, что и Perl: содержимое в одинарных кавычках не будет интерпретироваться (даже \ n не будет преобразовано), в отличие от двойных кавычек, которые могут содержать переменные, для которых выводится их значение.

Боюсь, Python нет. С технической точки зрения, в Python нет $ токена (или тому подобного) для отделения имени / текста от переменной. Обе функции делают Python более читабельным, в конце концов, менее запутанным. Одинарные и двойные кавычки могут использоваться взаимозаменяемо в Python.

Я решил использовать двойные кавычки, потому что их легче увидеть.

Я просто использую то, что поражает мое воображение в то время; удобно переключаться между двумя прихотями!

Конечно, при цитировании цитат characetrs переключение между ними может быть не таким уж и причудливым в конце концов ...

Вкус вашей команды или правила кодирования вашего проекта.

Если вы находитесь в мультиязычной среде, вы можете поощрять использование кавычек того же типа для строк, которые использует другой язык, например. Иначе мне лично больше всего нравится внешний вид

Нет, насколько я знаю. Хотя, если вы посмотрите на некоторый код, «» обычно используется для текстовых строк (я полагаю, «чаще встречается внутри текста, чем»), и «» появляется в хэш-ключах и тому подобном.

Я стремлюсь минимизировать как пиксели, так и удивление. Я обычно предпочитаю 'минимизировать пиксели, но "вместо этого, если строка имеет апостроф, снова минимизировать пиксели. Для строки документации, однако, я предпочитаю """более , '''потому что последний является нестандартным, необычным, и поэтому удивительно. Если сейчас у меня есть несколько строк, которые я использовал в "соответствии с приведенной выше логикой, но также и та, которая может сойти с рук ', я все равно могу использовать "ее для сохранения согласованности, только чтобы минимизировать неожиданность.

Возможно, это помогает думать о философии минимизации пикселей следующим образом. Вы бы предпочли, чтобы английские символы выглядели A B Cили AA BB CC? Последний выбор тратит 50% непустых пикселей.

Я использую двойные кавычки, потому что я делал это годами на большинстве языков (C ++, Java, VB ...), кроме Bash, потому что я также использую двойные кавычки в обычном тексте и потому что я использую (измененную) неанглийскую клавиатуру, где оба символа требуют клавиши Shift.

' знак равно "

/= \=\\

пример :

f = open('c:\word.txt', 'r')
f = open("c:\word.txt", "r")
f = open("c:/word.txt", "r")
f = open("c:\\\word.txt", "r")

Результаты одинаковы

= >> нет, они не одинаковы. Единственная обратная косая черта будет экранировать символы. Вы просто случайно повезло в этом примере , потому что \kи \wне являются действительными , как ускользает \tили \nили \\или\"

Если вы хотите использовать одиночные обратные слеши (и интерпретировать их как таковые), вам нужно использовать «необработанную» строку. Вы можете сделать это, поставив ' r' перед строкой

im_raw = r'c:\temp.txt'
non_raw = 'c:\\temp.txt'
another_way = 'c:/temp.txt'

Что касается путей в Windows, косые черты интерпретируются одинаково. Очевидно, что сама строка отличается. Я не гарантирую, что они обрабатываются таким образом на внешнем устройстве.