6 ms·

Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no space

• komali2 8y ago
  I'm new to python, I didn't realize there's a difference, can you help me understand the benefits?
  • ambivalence 8y ago
    I put it in the README. Let me know if anything is unclear.
• deleted 8y ago
  [deleted]
• mixmastamyk 8y ago
  Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.
  • ambivalence 8y ago
    You can still type single quotes. You have a tool to convert that for you. The visual noise complaint is interesting. Do you also consider the letter W to be more noisy than the letter V? Should we discourage the use of noisy letters in the alphabet?
    • mixmastamyk 8y ago
      Yes, why www. was dropped, and quotes are used everywhere in most Python code. The triple doubles for doc strings are the worst example, though I have no illusions pep8 will be changed any time soon.
    • davnn 8y ago
      > The visual noise complaint is interesting. I thought the same. I guess you could just modify your programming font to make the double quotes really tiny :)
    • zestyping 8y ago
      A double-quote is more noisy than a single-quote, and W is more noisy than V. The difference is that " and ' are equally usable options in the context we're talking about. Quotes are very common, so the visual noise adds up when your screen is full of quote marks. Given that they mean the same thing, and one is both harder to type and harder to read, it makes sense to prefer the other.
      • mixmastamyk 8y ago
        > Given that they mean the same thing, and one is both harder to type and harder to read, it makes sense to prefer the other. Nailed it.
      • prawl 8y ago
        A double quote is in no way harder to read. Only on Hacker News.
        • abiox 8y ago
          this seems a bit reductive.
  • woolvalley 8y ago
    Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.
    • ciupicri 8y ago
      Also Pascal and SQL.
    • samatman 8y ago
      Lua, and there are others. I favor double quotes for this same reason even when single quotes are allowed. I'd like «guillemets» but that's going to have to be self-serve...
      • spc476 8y ago
        I use single quotes when the string in question is used like an enumeration: set_color('black','white') And double quotes for strings meant to be read by a human: print("Hello there. How are you?") And an example with both forms: syslog('warning',"unit %s spin rate %f too low",u,rate) For me, it's an indication of how I expect the string to be used.
    • Inityx 8y ago
      And even then, Perl and Ruby (heck, even Bash) have a semantic difference between double- and single-quoted strings. The only other popular general-purpose languages where they're synonymous are PHP, JavaScript, and Lua.
      • ComputerGuru 8y ago
        >The only other popular general-purpose languages where they're synonymous are PHP, JavaScript, and Lua. PHP does treat single and double quotes differently. Contents of single quotes strings are not parsed for variable substitution.
    • ComputerGuru 8y ago
  • ben509 8y ago
    I agree about the noise, but, it's much easier to work with. raise FooException("Can't load bar") works, as does f"The flange is elevated by {flange['spronge']} degrees of spronge."
    • mixmastamyk 8y ago
      Goes both ways, sometimes there's text to quote: raise KeyError('"%s" not found.' % name) f'The flange is elevated by {flange["spronge"]} degrees of spronge.' I don't normally use many contractions or possessives in my code, but am willing to admit it happens occasionally.
      • zestyping 8y ago
        Yep, that's why I like how repr() does it. Guido solved this nicely a long time ago :)
  • rapind 8y ago
    The "visual noise" makes it clearer the me that it surrounds a block of text, so I don't buy this. Double quotes are also the convention in english to delineate a literal, so I would argue it's more obvious. I'll grant you keyboard presses though. There's an obvious advantage to single quotes here, but consider why this is the case. To make the use of "apostrophe" more efficient since it appears far more often than a double quote in english. I suppose it's pragmatic to leverage this advantage in code where string quoting is extremely common... Perhaps double quoting is a bias I've developed writing code, but I suspect it's actually a bias I carried over from reading and writing english and what simply seemed more obvious. Language design than supports both makes me crazy. Pick one and enforce it!
• lambda 8y ago
  Hmm. My reading of PEP 8 on slices is that the spaces surrounding : in slices are optional, and used to implement the later rule "If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator." This leads to the following difference between the PEP 8 recommendation and Black: PEP 8 accepts both of these: ham[lower+offset : upper+offset] ham[lower + offset : upper + offset] While Black just uses: ham[lower + offset : upper + offset] Also, this is one that PEP 8 doesn't have a example on, but I think this would be one of the cases in which the space wasn't necessary: slice[a.b : c.d] The "." operator binds so tightly in my mind that it doesn't need the spaces around the ":" to disambiguate. It's at the same precedence level as subscription and function call, and higher precedence than unary + and -. After typing this all out, I think that it might be the case that the bigger difference is actually in how binary operators are treated. It looks like Black always puts whitespace around binary operators, which contradicts PEP 8's recommendation that you are allowed to vary spacing around binary operators to make precedence clear. Since Black does allow for leaving in extraneous parentheses to make precedence clear, I wonder why it doesn't allow varying the space around binary operators as well? Of course, it should enforce that the spacing actually does match the precedence, and that the spacing is consistent within an expression. That would allow the following examples which PEP 8 lists as "Yes": x = x*2 - 1 hypot2 = x*x + y*y c = (a+b) * (a-b) While right now Black rewrites them as follows, which PEP 8 lists as "No" (though my reading is that varying the spacing like this is optional, so the following could be accepted as well): x = x * 2 - 1 hypot2 = x * x + y * y c = (a + b) * (a - b)
  • ambivalence 8y ago
    Black does not take existing formatting into account. Doing so would cause non-deterministic formatting (Black would sometimes change its mind about its own formatting and a second pass would cause a different formatting than the first). With this in mind, it has to enforce a rule around operators. Since any operand might be complex, it's more robust to default to spaces around operands always. Otherwise we would inevitably end up hugging operands with an operator that humans consider too tight. And since that's subjective, there is actually no rule that we can hard-code about that.
• zestyping 8y ago
  Slices: My reading of README.md is that Black inserts spaces around the colon, is that right? Almost none of the Python I've seen in 20+ years is written that way. The tutorial and documentation on python.org don't use spaces around the colon, and it is extremely rare in the standard library (out of over 1100 slice expressions that have operands on both sides of a colon, I count 10 that use the extra spaces). Quotes: We have a difference of opinion over what constitutes an established convention. If the language's own way of displaying strings has been stable for its entire history, I consider that established. A reasonable choice would have been to do what repr() does (single-quotes unless the string contains a literal single-quote) or a simplified version of it (single-quotes always), not the opposite of what the language itself does. (I wouldn't care so much about this except that I've really wanted a tool like Black for a while and greatly appreciate the philosophy!)
  • Shish2k 8y ago
    > My reading of README.md is that Black inserts spaces around the colon, is that right? I can't speak for the readme, but: $ cat test.py x = [1,2,3] print(x[1: 3]) $ black test.py reformatted test.py $ cat test.py x = [1, 2, 3] print(x[1:3])
    • zestyping 8y ago
      Oh, I must have misunderstood. Sorry! I take back my issue with the slices, then.
  • geofft 8y ago
    The README confused me, but I think it's saying that it inserts spaces if needed to make it clear that it's a lower-precedence operator. But unlike operators like +, it's not one that inherently requires spaces. I tried out black and it does the following (the file originally had no spaces): x = a + b x = m[a:b] x = m[a + 1 : b] x = m[a:-b] x = m[a : 1 - b] I would personally still write m[a + 1:b], I think, but black's approach is totally defensible. (I guess I would really write m[a+1:b], and black would rightly correct me.)
• zestyping 8y ago
  I thought of another way to express this that might resonate better. What I like about the Black philosophy is that it wants to make code style _uninteresting_. People should think about other things, not formatting. That's a great goal. So it seems to me that the best style choice is the most _boring_ choice. The least creative, least novel way. It should try to avoid inventing new formatting algorithms. What's the most boring way to format a string literal? The way the language already does it. The way every Python programmer has already seen string literals formatted from the very first day they started typing things into a Python interpreter. Even if half of us liked single-quotes and half of us liked double-quotes, you can guarantee that every Python programmer on the planet has seen and lived with strings that are formatted the repr() way, including the double-quote fans. You can't guarantee the opposite. No one could fault you for doing it the repr() way. Blame Guido :) he made that choice decades ago, and everyone has already had to make their peace with it. It's a solved problem. For anyone writing a program that emits Python code, it's the default way to format a string. It's the least assailable option, and that's a good thing. How does that sit with you?
  • weberc2 8y ago
    I’m a Python programmer and I never had the perception that single quotes are more canonical in any capacity. I always felt that single quotes were for degenerates who didn’t realize that single quotes are most commonly used for chars by the broader programming community. ;)
    • rndgermandude 8y ago
      I despise people using single quotes even more than people using tabs instead of space, emacs instead of vim or GNU-style indentation instead of... anything sane :D
      • greyman 8y ago
        I used to use single quotes for dictionary keys and other constants, and double quotes for strings intended to be read by human. I read some article about it a considered it a good convention. Now I see it actually isn't a convention. :-) I switched to black just yesterday and overall I like it, still I miss a bit this distinction between single and double quotes.