【问题标题】:Single quotes vs. double quotes in Python [closed]Python中的单引号与双引号[关闭]
【发布时间】:2010-09-08 12:47:44
【问题描述】:

根据文档,它们几乎可以互换。是否有风格上的理由使用一个而不是另一个?

【问题讨论】:

    标签: python coding-style


    【解决方案1】:

    我喜欢在用于插值或自然语言消息的字符串周围使用双引号,对类似符号的小字符串使用单引号,但如果字符串包含引号或我忘记了,则会违反规则。我对文档字符串使用三重双引号,对正则表达式使用原始字符串文字,即使它们不是必需的。

    例如:

    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
    

    【讨论】:

    • 有趣,我使用它们的方式完全相同。我不记得曾经读过任何东西来推动我朝那个方向前进。我还对不适合人类使用的长字符串使用三重单引号,例如原始 html。可能跟英文报价规则有关。
    • 大多数 python 编码器都是这样编码的。没有明确的规则,但是因为我们经常这样阅读代码,所以它成为了一种习惯。
    • 我想知道类似符号的单引号是否实际上来自 Lisp/Scheme 中的引号表达式快捷方式。无论如何,它是直观的。另外,我的伙伴们,如果我们遵循 PEP 8 风格指南,函数真的应该命名为 light_message() 和 is_pirate()。
    • 我认为 Perl 区分了单引号字符串(无插值)和双引号字符串(有插值),python 编码人员可能继承了这个习惯,或者永远不会放弃。
    • 我使用相同的约定,而且我滥用它,让 vim 将三重单引号内的所有内容突出显示为 SQL。
    【解决方案2】:

    引用https://docs.python.org/2.0/ref/strings.html的官方文档:

    简而言之:字符串文字可以用匹配的单引号 (') 或双引号 (") 括起来。

    所以没有区别。相反,人们会告诉您选择与上下文匹配的任何样式,并保持一致。我同意 - 补充说,尝试为这类事情制定“约定”是没有意义的,因为你最终只会让任何新人感到困惑。

    【讨论】:

    • 是的,对我来说,一致性是关键,所以我到处都使用单曲。更少的按键,明确且一致。
    【解决方案3】:

    我以前更喜欢',尤其是'''docstrings''',因为我发现"""this creates some fluff"""。此外,' 可以在没有瑞士德语键盘上的 Shift 键的情况下输入。

    我后来改为使用三引号 """docstrings""",以符合 PEP 257

    【讨论】:

    • 我更喜欢单引号,因为我每天都在写 SQL 代码,而单引号用于 T-SQL 中的字符串文字。但我确实使用了三重双引号,因为文档字符串有时会在其中使用一些绒毛。
    • 在任何地方都使用简单的字符串引号允许我使用三个双引号禁用部分源代码 - 类型为 '#if 0' 和 '#endif'。
    • " 仅在 PC QWERTY 键盘上需要 shift 键。在我的键盘上," 实际上更容易输入。
    • on my keybord " 和 ' 都需要 shift 键。
    • 这个答案违反了python约定;请参阅 PEP 257,其中说:为了保持一致性,请始终在文档字符串周围使用 """三双引号"""。 python.org/dev/peps/pep-0257
    【解决方案4】:

    我和威尔在一起:

    • 文本的双引号
    • 单引号表示任何行为类似于标识符的内容
    • 正则表达式的双引号原始字符串文字
    • 文档字符串的三重双引号

    即使这意味着很多逃避,我也会坚持下去。

    由于引号,我从单引号标识符中获得最大价值。其余的做法只是为了给那些单引号标识符一些站立空间。

    【讨论】:

      【解决方案5】:

      如果您拥有的字符串包含一个,那么您应该使用另一个。例如,"You're able to do this"'He said "Hi!"'。除此之外,您应该尽可能保持一致(在模块内、包内、项目内、组织内)。

      如果您的代码将被使用 C/C++ 的人阅读(或者如果您在这些语言和 Python 之间切换),那么将 '' 用于单字符串,"" 用于更长的字符串可能帮助缓解过渡。 (同样适用于其他不可互换的语言)。

      我在野外看到的 Python 代码倾向于支持 " 而不是 ',但只是略微偏爱。一个例外是"""these"""'''these''' 更常见,据我所知。

      【讨论】:

        【解决方案6】:

        三重引用的 cmets 是这个问题的一个有趣的子主题。 PEP 257 specifies triple quotes for doc strings。我使用 Google 代码搜索进行了快速检查,发现 triple double quotes in Python 的流行程度大约是 triple single quotes 的 10 倍——在 Google 索引代码中出现了 130 万次和 131K 次。因此,在多行情况下,如果您的代码使用三重双引号,人们可能会更熟悉它。

        【讨论】:

          【解决方案7】:
          "If you're going to use apostrophes, 
                 ^
          
          you'll definitely want to use double quotes".
             ^
          

          出于这个简单的原因,我总是在外面使用双引号。 总是

          说到绒毛,如果您将不得不使用转义字符来表示撇号,那么用 ' 简化您的字符串文字有什么好处?读小说会冒犯程序员吗?我无法想象高中英语课对你来说是多么痛苦!

          【讨论】:

          • '如果你要“引用”某些东西,你肯定会想要使用单引号'
          • 自从我写这篇文章后,我的看法发生了很大的变化。现在只是一种情况,我会争辩说我会使用双引号。在使用单引号的情况下,另一个将是您的。请参阅the accepted answer,了解我目前对此事的更详细立场。我认为这是一个很好的例子,说明它应该如何呈现给广大观众。
          【解决方案8】:

          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'
          

          【讨论】:

          • 但是"""This is a string with "quotes"""" 引发了一个语法错误。这种情况怎么解决? (与'''This is a string with 'quotes'''' 相同)
          • 在“引号”和“”之间插入换行符
          • @dolma33 Nicolas 的建议会更改字符串的内容。更好的解决方案已经在答案中:如果您的字符串以某种引号结尾,请使用 other 类型的三引号。例如,'''This is a string with "quotes"'''.
          【解决方案9】:

          我通常使用双引号,但不是出于任何特定原因 - 可能只是出于 Java 的习惯。

          我猜你也更可能想要在内联文字字符串中使用撇号而不是想要双引号。

          【讨论】:

            【解决方案10】:

            我个人坚持其中一种。没关系。并且为任何一个引用提供你自己的意思只是在你合作时混淆其他人。

            【讨论】:

              【解决方案11】:

              这可能是一种风格偏好。我刚刚检查了 PEP 8,没有看到任何提及单引号和双引号的内容。

              我更喜欢单引号,因为它只有一次击键而不是两次。也就是说,我不必混搭 shift 键来制作单引号。

              【讨论】:

              • PEP 8 在“文档字符串”下的第一句中链接到 PEP 257。在 PEP 257 中,它声明:为了保持一致性,请始终在文档字符串周围使用 """三双引号"""。如果您在文档字符串中使用任何反斜杠,请使用 r"""raw 三双引号"""。对于 Unicode 文档字符串,使用 u"""Unicode 三引号字符串"""。尽管如此,我还是喜欢单引号的简洁外观和您给出的一个按键原因。
              【解决方案12】:

              在 Perl 中,当您有一个不需要插入变量或转义字符(如 \n、\t、\r 等)的字符串时,您希望使用单引号。

              PHP 与 Perl 有相同的区别:单引号中的内容不会被解释(甚至 \n 都不会被转换),而双引号可以包含变量以打印出它们的值。

              恐怕Python没有。从技术上看,Python 中没有 $ 标记(或类似符号)将名称/文本与变量分开。毕竟,这两个特性都使 Python 更具可读性,更少混乱。单引号和双引号在 Python 中可以互换使用。

              【讨论】:

              • 为了强化你所说的 \n 在 PHP 和 Perl 中将仅在双引号中解释,而在 Python 中将同时使用双引号和单引号
              • @stivlo:除非你要从中创建一个原始字符串,否则在字符串文字前添加r。所以print 'a\nb' 会打印出两行,而print r'a\nb' 会打印出一行。
              【解决方案13】:

              我选择使用双引号是因为它们更容易看到。

              【讨论】:

                【解决方案14】:

                我只是使用当时我喜欢的任何东西;可以随心所欲地在两者之间切换很方便!

                当然,在引用引号字符时,两者之间的切换毕竟可能不是那么异想天开……

                【讨论】:

                  【解决方案15】:

                  您团队的品味或项目的编码指南。

                  如果您处于多语言环境中,您可能希望鼓励对其他语言使用的字符串使用相同类型的引号。否则,我个人最喜欢'

                  【讨论】:

                    【解决方案16】:

                    据我所知没有。虽然如果你看一些代码,“”通常用于文本字符串(我猜'在文本中比“更常见),并且''出现在哈希键之类的东西中。

                    【讨论】:

                      【解决方案17】:

                      我的目标是尽量减少像素和惊喜。我通常更喜欢' 以最小化像素,但" 如果字符串有撇号,则再次最小化像素。但是,对于文档字符串,我更喜欢 """ 而不是 ''',因为后者是非标准的、不常见的,因此令人惊讶。如果现在我有一堆字符串,我按照上述逻辑使用了",但还有一个可以使用',我可能仍然在其中使用" 以保持一致性,只是为了尽量减少意外。

                      也许通过以下方式思考像素最小化理念会有所帮助。您是否希望英文字符看起来像 A B CAA BB CC?后一种选择浪费了 50% 的非空像素。

                      【讨论】:

                        【解决方案18】:

                        我使用双引号是因为多年来我在除 Bash 之外的大多数语言(C++、Java、VB……)中都使用双引号,因为我也在普通文本中使用双引号,并且因为我使用的是(修改后的)非两个字符都需要 shift 键的英文键盘。

                        【讨论】:

                          【解决方案19】:

                          ' = "

                          / = \ = \\

                          例子:

                          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 中的路径而言,正斜杠的解释方式相同。显然,字符串本身是不同的。不过,我不能保证它们会在外部设备上以这种方式处理。

                          【讨论】:

                          • 天哪,这是旧的,但我还是想评论指出,使用正斜杠可能适用于 Windows,但仍然依赖于系统。为确保您清除操作系统依赖项,请使用os.path.join()
                          猜你喜欢
                          • 2011-09-17
                          • 2012-12-13
                          • 2012-12-30
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 2018-01-30
                          • 2013-02-07
                          • 1970-01-01
                          相关资源
                          最近更新 更多