4 ms·
yeah, can be annoying, but also encourages this, which is nice when the number of values grows: items = { "key": "value", "key": "value", } c
by guitarbill 7y ago
yeah, can be annoying, but also encourages this, which is nice when the number of values grows:
items = {
"key": "value",
"key": "value",
}
call(items)
it's a bit annoying with exception messages, but again, writing long args before works great, and i've become a fan of this (unintended?) nudge:
if error:
raise ValueError(
"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas vel ligula nec eros finibus metus."
)
if error:
msg = (
"Lorem ipsum dolor sit amet, consectetur adipiscing elit. "
"Maecenas vel ligula nec eros finibus metus."
)
raise ValueError(msg)
just to be clear, i don't think working around a formatter is good. in this case, i feel like the uncompromising rules were exposing a bit of an anti-pattern. obviously, your opinion on this may vary wildly.
- edflsafoiewq 7y agoThis puts the lie to the common claim that formatters end formatting decisions. Actually they only move the problem from "how shall I format my code" to "how shall I write my code so that I will like the way my autoformatter formats my code".
- weberc2 7y agoYou misunderstand the point of formatters. They aren’t meant to automate your personal preference; they automate a standard format so your team doesn’t have to waste time deciding on and enforcing a coding standard and so you don’t have to manually implement the standard. Implicit in using a code formatter is the decision to stop navel gazing and put the team first.
- deleted 7y ago[deleted]
- weberc2 7y agoI’m honestly fine with putting the dict in the function call in most cases. It’s not a big deal either way. As for your exceptions, you can just do raise ValueError( "Lorem ipsum dolor sit amet, consectetur adipiscing elit. " "Maecenas vel ligula nec eros finibus metus." ) No need for the extra variable.