Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black: An uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

231–240 of 262 posts

Re: Black: An uncompromising Python code formatter

#231

Post by greyman »

rndgermandude wrote: post #212
weberc2 wrote: post #193

Earlier quoted context omitted.

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. ;)

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

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.

Re: Black: An uncompromising Python code formatter

#232

Post by [deleted] »

rndgermandude wrote: post #212
weberc2 wrote: post #193

Earlier quoted context omitted.

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. ;)

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

[deleted]

Re: Black: An uncompromising Python code formatter

#233

Post by kuroguro »

heavenlyblue wrote: post #226
weberc2 wrote: post #193

Earlier quoted context omitted.

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. ;)

I’ve always thought that double quotes are for degenerates who don’t pay attention to what a standard repr output is for strings.

And I’ve always thought that triple quotes are for degenerates who... no, wait, nvm.

Re: Black: An uncompromising Python code formatter

#234

Post by heavenlyblue »

kuroguro wrote: post #233
heavenlyblue wrote: post #226

Earlier quoted context omitted.

I’ve always thought that double quotes are for degenerates who don’t pay attention to what a standard repr output is for strings.

And I’ve always thought that triple quotes are for degenerates who... no, wait, nvm.

... who can’t write self-explanatory code.

Re: Black: An uncompromising Python code formatter

#235

Post by jhall1468 »

prawl wrote: post #200
epr wrote: post #85

--single-quoted-strings would be a really nice option for the vast majority of python programmers that use single quotes by default.

This isn't a vast majority by any stretch of the imagination.

The overwhelming response here saying use single quotes begs to differ.

Re: Black: An uncompromising Python code formatter

#236

Post by makapuf »

fishywang wrote: post #171
makapuf wrote: post #159

Earlier quoted context omitted.

Sure you can prefer this but it is not the point. The point is that having ONE average way to do it > several best ways for several people.

I'm saying this is a weird/below-average way to do it. If this cannot fit in one line: foo(arg1, arg2) My first choice would be: foo( arg1, arg2, ) Second choice would be: foo( arg1, arg2, ) While Black chooses: foo( arg1, arg2 ) And made some unconvincing argument about it: > Unnecessary trailing commas are removed if an expression fits in one line. This makes it 1% more likely that your line won't exceed the allott…

I know and I completely agree. Maybe a kind of vote could be made on this kind of choices. But what would be really nice would be git "style lenses" : having different styles to edit or share.

Re: Black: An uncompromising Python code formatter

#237

Post by zachsnow »

Too wrote: post #216
danpalmer wrote: post #91

I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need to be human readable, single quotes otherwise. This makes it so obvious when something is going to be sent to the user, we find it really useful. That said, I think Black’s appeal is it’s uncompromising nature, so I wouldn’t ask it to change. Adding the option t…

Why would you have strings that are not supposed to be human readable? Machine to machine should ideally use bytearray (b""-strings) or integer enums for that purpose. Then you also have the ambiguity of what is considered human readable, is an xml document human readable? Http headers? File paths? Urls? Is a programmer considered human?

I believe the point is whether the string is intended to be displayed to a human, not whether a human might read it in the code. Still some wiggle room around logging, etc. I guess.

Re: Black: An uncompromising Python code formatter

#238

Post by masklinn »

stevesimmons wrote: post #175
kstrauser wrote: post #80

Earlier quoted context omitted.

That's the #1 complaint I have (and hear) about Black. Everything else, I can live with. And honestly, I can live with using double quotes everywhere, especially when I can type single quotes and then let it re-write them. It's just that they currently look really, really odd to me because that's not how Python is traditionally written.

I prefer a quoting convention of single quotes for text identifiers (as they rarely contain quotes) and double quotes for English text (because contractions are common). Thus: key['first_name'] print("Isn't this clearer?")

Same, though I'd word the first one as programmatic identifiers.

Adopted that from Erlang, where atoms are single-quoted and text strings are double-quoted.

Re: Black: An uncompromising Python code formatter

#239

Post by jrs95 »

yycom wrote: post #182
ambivalence wrote: post #95

Earlier quoted context omitted.

Do you find your team enforcing the string quote rule consistently? It seems to me like it's easy to miss at times as automatic enforcement is impossible. Are there no cases where a string that wasn't originally planned to be user-visible ends up being so? I've heard this idea at times but when I looked at actual codebases it turns out it's more of an aspiration than an actual rule. And if you can't depend on it, why…

> And if you can't depend on it, why have it? That's a bit rich. There are other conventions in programming that you can't depend on technically but serve a real purpose. Identifier naming and comments are the first that come to mind. If a language gives you a choice of token that has no semantic distinction then different people will adopt different semantics by convention. As an aside, calling a tool "opinionated"…

Comments are often a side of poorly written code though. Ideallly the name and structure of the program should make the intent and purpose obvious, which eliminates the need for a lot of the comments people leave. Of course this isn’t always true, but if you’re using comments to compensate for bad/confusing code, you shouldn’t think you’re doing “the right thing”.

Re: Black: An uncompromising Python code formatter

#240

Post by nerdwaller »

heavenlyblue wrote: post #234
kuroguro wrote: post #233

Earlier quoted context omitted.

And I’ve always thought that triple quotes are for degenerates who... no, wait, nvm.

... who can’t write self-explanatory code.

Code only captures the what and the how, comments for any complex routines can capture the why. Obviously overuse is probably a red-flag, but in my experience code alone doesn’t always capture enough context in any sufficiently complex system.

I get your specific comment may be a bit sarcastic, given the ancestry - but I make this one more for younger developers I see that don’t always filter that ;)

Post reply on HN