-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should delimiters of different priorities be extra-indented? #147
Comments
Workaround until I figure out what to do here: wrap the string in parentheses. Then you don't even have to explicitly concatenate it with |
We will put optional parentheses in this situation. |
I thought about this some more and I'm not sure that parentheses are the right answer here. At the same time, Black currently doesn't have any rule that performs additional indentation based on delimiter priority. |
+1 for indenting as in #345 |
Just using implicit string concatenation the example becomes: params = {
"prompt": "consent",
"response_type": "code",
"access_type": "offline",
"client_id": google_client_id,
"scope": "profile "
"email https://www.googleapis.com/auth/contacts.readonly "
"https://www.googleapis.com/auth/drive.readonly",
"redirect_uri": google_callback_uri,
"state": state,
} I find that is undesirable. Adding more brackets does seem OK: params = {
"prompt": "consent",
"response_type": "code",
"access_type": "offline",
"client_id": google_client_id,
"scope": (
"profile "
"email https://www.googleapis.com/auth/contacts.readonly "
"https://www.googleapis.com/auth/drive.readonly"
),
"redirect_uri": google_callback_uri,
"state": state,
} It isn't explicit, but is the suggestion here (and in #345 which was marked as a duplicate) the following extra indentation?: params = {
"prompt": "consent",
"response_type": "code",
"access_type": "offline",
"client_id": google_client_id,
"scope":
"profile "
"email https://www.googleapis.com/auth/contacts.readonly "
"https://www.googleapis.com/auth/drive.readonly",
"redirect_uri": google_callback_uri,
"state": state,
} |
What we will do is this:
|
I would like to point out an edge case: when the value in and of itself would fit on a single line, but key and value together go over. The following code looks fine in my own eyes:
No line over 88 characters, clear distinction between keys and values. But black reformats this to this, which is longer than 88 characters:
Because apparently putting keys and values on the same line is a lot more important than sticking to the line length... But if we're adding parentheses anyway in related cases, why not prefer consistence with this new rule and have this as output instead?
I mean... I would personally still prefer the original and I don't quite understand why black insists on making a change to begin with, but at least this change stays within the line length. |
I'm going to put in a vote for different types of splitting get different indents
which currently gets reformatted to
I would prefer
which black (22.8.0 with preview) will persist if it's manually done, but not do automatically |
there's a similar issue with inline conditionals where
gets reformatted as
|
This was implemented in #3440. On current main:
|
Black takes an interesting decision regarding how to treat strings as dictionary values.
Following dict has a very long string:
As Black won't split the string, I manually edited it to this:
But Black than changes to this:
I think the indentation here is important for readability, as one might mistake the broken line as dict pairs.
======================================
Operating system: macOS
Python version: 3.6.4
Black version: 18.4a2
Does also happen on master: yes
The text was updated successfully, but these errors were encountered: