Według dokumentacji są one prawie wymienne. Czy istnieje stylistyczny powód, aby używać jednego nad drugim?
Według dokumentacji są one prawie wymienne. Czy istnieje stylistyczny powód, aby używać jednego nad drugim?
Odpowiedzi:
Lubię używać podwójnych cudzysłowów wokół ciągów używanych do interpolacji lub komunikatów w języku naturalnym oraz pojedynczych cudzysłowów dla małych ciągów podobnych do symboli, ale złamie zasady, jeśli ciągi zawierają cudzysłowy lub jeśli zapomnę. Używam potrójnych podwójnych cudzysłowów dla dokumentów i surowych literałów łańcuchowych dla wyrażeń regularnych, nawet jeśli nie są one potrzebne.
Na przykład:
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
Cytując oficjalne dokumenty na https://docs.python.org/2.0/ref/strings.html :
W prostym języku angielskim: literały łańcuchowe mogą być ujęte w pasujące pojedyncze cudzysłowy (') lub podwójne cudzysłowy (").
Więc nie ma różnicy. Zamiast tego ludzie powiedzą ci, aby wybrać styl pasujący do kontekstu i zachować spójność . I zgodziłbym się - dodając, że nie ma sensu wymyślać „konwencji” dla tego rodzaju rzeczy, ponieważ tylko wprowadzisz zamieszanie w nowych przybyszach.
Wolałem '
, szczególnie '''docstrings'''
, jak się przekonałem """this creates some fluff"""
. Ponadto '
można pisać bez Shiftklawisza na mojej szwajcarskiej niemieckiej klawiaturze.
Od tego czasu zmieniłem się na stosowanie potrójnych cudzysłowów dla """docstrings"""
, aby dostosować się do PEP 257 .
"
wymaga klawisza Shift tylko na klawiaturze komputera QWERTY. Na mojej klawiaturze "
łatwiej jest pisać.
Jestem z Willem:
Pozostanę przy tym, nawet jeśli to oznacza dużo ucieczki.
Największą wartość czerpię z identyfikatorów pojedynczych cytatów wyróżniających się ze względu na cytaty. Reszta praktyk ma na celu zapewnienie tym stojącym pojedynczym identyfikatorom trochę miejsca na stojąco.
Jeśli ciąg, który masz zawiera jeden, powinieneś użyć drugiego. Na przykład "You're able to do this"
, lub 'He said "Hi!"'
. Poza tym powinieneś być tak spójny, jak tylko możesz (w module, w pakiecie, w projekcie, w organizacji).
Jeśli twój kod będzie czytany przez osoby pracujące z C / C ++ (lub jeśli przełączysz się między tymi językami a Pythonem), to użycie ''
ciągów jednoznakowych i ""
dłuższych może ułatwić przejście. (Podobnie w przypadku innych języków, w których nie są one wymienne).
Kod Python widziałem w naturze ma tendencję do faworyzowania "
nad '
, ale tylko nieznacznie. Jedynym wyjątkiem jest to, że """these"""
są znacznie częstsze niż '''these'''
z tego, co widziałem.
Ciekawe podtemat tego pytania stanowią trzy cytowane komentarze. PEP 257 określa potrójne cudzysłowy dla ciągów dokumentów . Zrobiłem szybkie sprawdzenie za pomocą Google Code Search i odkryłem, że potrójne podwójne cudzysłowy są w Pythonie około 10 razy bardziej popularne niż potrójne pojedyncze cudzysłowy - 1,3 mln w porównaniu z 131 000 wystąpień w indeksach Google kodu. Więc w przypadku wielu linii twój kod prawdopodobnie będzie bardziej znany ludziom, jeśli użyje potrójnych podwójnych cudzysłowów.
"If you're going to use apostrophes,
^
you'll definitely want to use double quotes".
^
Z tego prostego powodu zawsze używam podwójnych cudzysłowów na zewnątrz. Zawsze
Skoro mowa o puchu, co dobrego jest w usprawnianiu literałów łańcuchowych słowem „jeśli będziesz musiał użyć znaków specjalnych do reprezentowania apostrofów? Czy obraża programistów czytających powieści? Nie wyobrażam sobie, jak bolesna była dla ciebie klasa angielskiego w liceum!
Python używa cudzysłowów mniej więcej tak:
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
Co daje następujące dane wyjściowe:
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""""
podnosi błąd SyntaxError. Jak można rozwiązać tę sytuację? (tak samo jak z '''This is a string with 'quotes''''
)
'''This is a string with "quotes"'''
.
Używam podwójnych cudzysłowów, ale nie z żadnego konkretnego powodu - prawdopodobnie po prostu z przyzwyczajenia z Javy.
Wydaje mi się, że bardziej prawdopodobne jest, że będziesz chciał apostrofów w dosłownym ciągu literalnym niż podwójnych cudzysłowów.
To chyba stylistyczna preferencja bardziej niż cokolwiek innego. Właśnie sprawdziłem PEP 8 i nie widziałem żadnej wzmianki o pojedynczych i podwójnych cudzysłowach.
Wolę pojedyncze cudzysłowy, ponieważ jest to tylko jedno naciśnięcie klawisza zamiast dwóch. Oznacza to, że nie muszę zaciskać klawisza Shift, aby utworzyć pojedynczy cytat.
W Perlu chcesz używać pojedynczych cudzysłowów, gdy masz ciąg znaków, który nie musi interpolować zmiennych lub znaków specjalnych, takich jak \ n, \ t, \ r itp.
PHP robi to samo rozróżnienie, co Perl: treść w pojedynczych cudzysłowach nie będzie interpretowana (nawet \ n nie zostanie przekonwertowana), w przeciwieństwie do podwójnych cudzysłowów, które mogą zawierać zmienne w celu wydrukowania ich wartości.
Obawiam się, że Python nie. Technicznie rzecz biorąc, nie ma $ token (lub podobnego), aby oddzielić nazwę / tekst od zmiennej w Pythonie. Obie funkcje sprawiają, że Python jest bardziej czytelny, w końcu mniej mylący. Pojedyncze i podwójne cudzysłowy mogą być używane zamiennie w Pythonie.
r
przed literałem łańcucha. Więc print 'a\nb'
wypisze ci dwie linie, ale print r'a\nb'
pozwoli Ci wydrukować jeden.
Wybrałem podwójne cudzysłowy, ponieważ są łatwiejsze do zobaczenia.
Po prostu używam tego, co mi się wtedy podoba; wygodnie jest móc przełączać się między nimi jednym kaprysem!
Oczywiście, cytując bohaterów cytatów, przełączanie się między nimi może nie być wcale takie kapryśne ...
Smak twojego zespołu lub wytyczne kodowania twojego projektu.
Jeśli pracujesz w środowisku wielojęzycznym, możesz zachęcić do korzystania z tego samego rodzaju cudzysłowów dla ciągów znaków, na przykład w innym języku. W przeciwnym razie osobiście najbardziej lubię wygląd „
Staram się zminimalizować oba piksele i zaskoczyć. Zazwyczaj wolę '
, aby zminimalizować piksele, ale "
zamiast tego, jeśli ciąg ma apostrof, ponownie, aby zminimalizować piksele. Dla docstring jednak wolą """
na '''
ponieważ ten ostatni nie jest standardem, rzadkie i dlatego zaskakujące. Jeśli teraz mam kilka ciągów znaków, których użyłem "
zgodnie z powyższą logiką, ale także taki, który może uciec od '
, mogę nadal używać "
go w celu zachowania spójności, tylko w celu zminimalizowania zaskoczenia.
Być może pomaga to myśleć o filozofii minimalizacji pikseli w następujący sposób. Czy wolałbyś, żeby angielskie znaki wyglądały A B C
lub AA BB CC
? Ten drugi wybór marnuje 50% niepustych pikseli.
'
= "
/
= \
=\\
przykład:
f = open('c:\word.txt', 'r')
f = open("c:\word.txt", "r")
f = open("c:/word.txt", "r")
f = open("c:\\\word.txt", "r")
Wyniki są takie same
= >> nie, nie są takie same. Pojedynczy ukośnik odwróci znaki. Po prostu stało się szczęście w tym przykładzie, bo \k
i \w
nie jest ważne, jak ucieka \t
lub \n
lub \\
lub\"
Jeśli chcesz używać pojedynczych ukośników odwrotnych (i należy je interpretować jako takie), musisz użyć łańcucha „raw”. Możesz to zrobić, umieszczając znak „ r
” przed ciągiem
im_raw = r'c:\temp.txt'
non_raw = 'c:\\temp.txt'
another_way = 'c:/temp.txt'
Jeśli chodzi o ścieżki w systemie Windows, ukośniki są interpretowane w ten sam sposób. Oczywiście sam łańcuch jest inny. Nie gwarantowałbym jednak, że są obsługiwane w ten sposób na urządzeniu zewnętrznym.
os.path.join()