De acordo com a documentação, eles são praticamente intercambiáveis. Existe uma razão estilística para usar um sobre o outro?
De acordo com a documentação, eles são praticamente intercambiáveis. Existe uma razão estilística para usar um sobre o outro?
Respostas:
Eu gosto de usar aspas duplas em torno de strings que são usadas para interpolação ou que são mensagens de linguagem natural e aspas simples para strings pequenas como símbolos, mas quebrarei as regras se as strings contiverem aspas, ou se eu esquecer. Uso aspas duplas triplas para docstrings e literais de strings brutos para expressões regulares, mesmo que não sejam necessárias.
Por exemplo:
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
Citando os documentos oficiais em https://docs.python.org/2.0/ref/strings.html :
Em inglês simples: os literais de string podem ser colocados entre aspas simples (') ou aspas duplas (").
Portanto, não há diferença. Em vez disso, as pessoas dirão para você escolher o estilo que corresponder ao contexto e ser consistente . E eu concordaria - acrescentando que não faz sentido tentar criar "convenções" para esse tipo de coisa, porque você só acabará confundindo os recém-chegados.
Eu costumava preferir '
, especialmente para '''docstrings'''
, como acho """this creates some fluff"""
. Além disso, '
pode ser digitado sem a Shifttecla no meu teclado suíço-alemão.
Desde então, mudei para o uso de aspas triplas para """docstrings"""
, em conformidade com o PEP 257 .
"
requer uma tecla shift apenas no teclado QWERTY do PC. No meu teclado, "
é realmente mais fácil digitar.
Estou com Will:
Eu vou continuar com isso, mesmo que isso signifique muito escape.
Eu obtenho o máximo valor dos identificadores citados únicos que se destacam por causa das aspas. O restante das práticas existe apenas para dar espaço a esses identificadores citados.
Se a string que você possui contém uma, você deve usar a outra. Por exemplo,, "You're able to do this"
ou 'He said "Hi!"'
. Fora isso, você deve ser o mais consistente possível (dentro de um módulo, dentro de um pacote, dentro de um projeto, dentro de uma organização).
Se o seu código for lido por pessoas que trabalham com C / C ++ (ou se você alternar entre essas linguagens e Python), usar ''
para cadeias de caracteres únicos e cadeias ""
mais longas pode ajudar a facilitar a transição. (Da mesma forma para seguir outros idiomas onde eles não são intercambiáveis).
O código Python que eu vi na natureza tende a favorecer "
mais '
, mas apenas ligeiramente. A única exceção é que """these"""
são muito mais comuns do que '''these'''
, pelo que vi.
Os comentários triplos são um subtópico interessante dessa questão. O PEP 257 especifica aspas triplas para sequências de documentos . Fiz uma verificação rápida usando a Pesquisa de código do Google e constatei que as aspas duplas triplas no Python são cerca de 10x tão populares quanto as aspas simples triplas - ocorrências de 1,3 milhão de vezes 131 mil nos índices de código do Google. Portanto, no caso de várias linhas, seu código provavelmente será mais familiar para as pessoas se ele usar aspas duplas triplas.
"If you're going to use apostrophes,
^
you'll definitely want to use double quotes".
^
Por esse motivo simples, eu sempre uso aspas duplas do lado de fora. Sempre
Falando em cotão, de que adianta simplificar seus literais de cordas com 'se você precisar usar caracteres de escape para representar apóstrofos? Ofende os codificadores a ler romances? Não consigo imaginar como a aula de inglês do ensino médio foi dolorosa para você!
Python usa aspas algo como isto:
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
O que fornece a seguinte saída:
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'
"""This is a string with "quotes""""
gera um SyntaxError. Como essa situação poderia ser resolvida? (mesmo que com '''This is a string with 'quotes''''
) #
'''This is a string with "quotes"'''
,.
Uso aspas duplas em geral, mas não por qualquer motivo específico - provavelmente apenas por hábito do Java.
Eu acho que é mais provável que você apóstrofe em uma string literal in-line do que aspas duplas.
Provavelmente é uma preferência estilística mais do que tudo. Acabei de verificar o PEP 8 e não vi menção de aspas simples versus aspas duplas.
Prefiro aspas simples, porque é apenas uma combinação de teclas em vez de duas. Ou seja, não tenho que pressionar a tecla Shift para fazer aspas simples.
No Perl, você deseja usar aspas simples quando tiver uma string que não precise interpolar variáveis ou caracteres de escape como \ n, \ t, \ r etc.
O PHP faz a mesma distinção que Perl: o conteúdo entre aspas simples não será interpretado (nem mesmo \ n será convertido), em oposição às aspas duplas que podem conter variáveis para que seu valor seja impresso.
Python não, receio. Tecnicamente visto, não há token $ (ou algo semelhante) para separar um nome / texto de uma variável no Python. Ambos os recursos tornam o Python mais legível, menos confuso, afinal. As aspas simples e duplas podem ser usadas de forma intercambiável no Python.
r
na frente da string literal. Assim print 'a\nb'
, você imprimirá duas linhas, mas print r'a\nb'
uma.
Eu escolhi usar aspas duplas porque elas são mais fáceis de ver.
Eu apenas uso o que me agrada na época; é conveniente poder alternar entre os dois por um capricho!
Claro, ao citar caracteres de cotação, alternar entre os dois pode não ser tão caprichoso, afinal ...
O gosto da sua equipe ou as diretrizes de codificação do seu projeto.
Se você estiver em um ambiente multilíngüe, convém incentivar o uso do mesmo tipo de aspas para strings que o outro idioma usa, por exemplo. Senão, eu pessoalmente gosto mais da aparência de '
Eu pretendo minimizar os pixels e a surpresa. Normalmente, prefiro '
minimizar os pixels, mas, "
se a string tiver um apóstrofo, novamente para minimizar os pixels. No entanto, para uma doutrina, prefiro a """
outra, '''
porque esta não é padrão, incomum e, portanto, surpreendente. Se agora eu tenho um monte de strings onde usei de "
acordo com a lógica acima, mas também uma que possa se safar de um '
, ainda posso usá "
-lo para preservar a consistência, apenas para minimizar a surpresa.
Talvez ajude a pensar na filosofia de minimização de pixels da seguinte maneira. Você prefere que os caracteres em inglês sejam parecidos A B C
ou AA BB CC
? A última opção desperdiça 50% dos pixels não vazios.
'
= "
/
= \
=\\
exemplo:
f = open('c:\word.txt', 'r')
f = open("c:\word.txt", "r")
f = open("c:/word.txt", "r")
f = open("c:\\\word.txt", "r")
Os resultados são os mesmos
= >> não, eles não são os mesmos. Uma única barra invertida escapará dos caracteres. Você só acontecerá a sorte no mesmo exemplo, porque \k
e \w
não são escapes válidos como \t
ou \n
ou \\
ou\"
Se você quiser usar barras invertidas únicas (e tê-las interpretadas como tal), precisará usar uma string "bruta". Você pode fazer isso colocando um ' r
' na frente da string
im_raw = r'c:\temp.txt'
non_raw = 'c:\\temp.txt'
another_way = 'c:/temp.txt'
No que diz respeito aos caminhos no Windows, as barras são interpretadas da mesma maneira. Claramente, a string em si é diferente. Eu não garantiria que eles sejam tratados dessa maneira em um dispositivo externo.
os.path.join()