Black: An uncompromising Python code formatter

Post by jhall1468 » Mon, May 28, 2018, 4:17 PM UTC

ambivalence wrote: post #244

jhall1468 wrote: post #235

Earlier quoted context omitted.

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

That's not how this works. All the people who are just happy or indifferent about double quotes don't comment about it. And some of the ones that aren't happy about it commented here multiple times. Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

> Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

Accuse me of selection bias. Immediately use even more biased selection bias.

Post by Too » Mon, May 28, 2018, 5:21 PM UTC

aldanor wrote: post #258

Too wrote: post #256

Earlier quoted context omitted.

Sorry if i wasn't clear, what i meant was actually why would you have strings that are not intended to be displayed to end user? Smells like non binary serialization format or something alike, which is usually a code smell. It's convenient the first 2 weeks but once the project grows you need a more strict schema and once you have that you might as well use a serialization library which might as well have a binary se…

> why would you have strings that are not intended to be displayed to end user Why would you not? E.g., you use pandas and columns all have names. Colors are typically also strings, etc. Thus you would often do things like grouped = df.groupby(['foo', 'bar'])['baz'].mean() However, the parent's point, IIUC, is that he'd do grouped.plot(color='red', title="User-facing title.")

Colors as strings is a perfect example of what i'm trying to question here. How do i know which colors that are valid? Run time error? No thanks. Reading online documentation[0]? No thanks. I'd rather have my auto-complete[0] tell me right away the available options and my compiler tell me if i misspelled 'turquoiuse'. A better solution for this is a color-class with a long list of predefined colors as constants, and since they are just constants they could have any underlying format, not necessarily a string. Even in a dynamic language such as python this should be preferred over random strings.

Then yes, there are valid uses, especially in ad-hoc scripts. Column names and dictionary keys are one of the gray zones, though again, in my experience once your project grows these are also usually better to code generate from your db schema or serialization protocol; either complete data structures, api-functions, or just a list of constants. Anyway, my point is not to ban strings entirely, it's to question what we use it for. If you use strings as data/identifiers so frequently that you need a special convention for them something smells quite fishy.

[0] Auto complete = More accessible form of documentation. Before someone starts screaming that i'm stupid for "ignoring documentation".

Re: Black: An uncompromising Python code formatter

Re: Black: An uncompromising Python code formatter