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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

Я с Уиллом:

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

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

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

Вероятно, это скорее стилистическое предпочтение, чем что-либо еще. Я только что проверил PEP 8 и не увидел упоминания о двойных кавычках и одинарных.

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

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

In plain English: String literals can be enclosed in matching single quotes (') or double quotes (").

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

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

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

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

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

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

' = "

/ = \ = \

пример :

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 не являются допустимыми escape-последовательностями, такими как \t, \n, \ или \".

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

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

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

In Perl you want to use single quotes when you have a string which doesn't need to interpolate variables or escaped characters like \n, \t, \r, etc.

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

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

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

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 2quotes2'
mystringliteral6='this is a string with 7quotes7'

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'

"If you're going to use apostrophes, 
       ^

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

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

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

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

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