Future of `string_processing`

[JelleZijlstra]

We merged string processing in May 2020 (#1132), almost four years ago. A few months later, I put the feature behind a flag because there were too many related bugs (#1609). Four years later, we're still in basically the same state: most of the open issues in https://github.com/psf/black/labels/C%3A%20preview%20style are about string processing.

I'm also increasingly convinced that string_processing's core feature, splitting up long strings, would be exceedingly controversial if we ever did turn it on by default. It is just too hard for a tool to figure out how to split a string in a way that makes sense to readers of the code. However, there are other things that string_processing does, and some of those are valuable and could perhaps be split off.

So my proposal is:

• Give up on splitting strings automatically; Black will simply not do that
• Split out any other useful features from string-processing into separate preview features that we can reasonably hope to enable in next year's stable style.

If you're interested in getting any part of string_processing into stable Black, please contribute a PR moving it to a separate preview feature.

I ran string_processing on my work codebase and noticed a few specific changes that could be split out. I'll list them in a separate comment.

[JelleZijlstra]

Here are some examples of changes that string-processing makes in my codebase that I'd consider accepting in a standalone preview feature:

• Add parentheses around a string so it fits in the line limit

  
       xxxxxx = xx.xxxxxxx.XXXXXxxxxXxxXxfxxxxxx(

• xxxxx_xxxxxxx_x3_xxxx_xxxxxxxx=f"x3://{XXX_X3_XXXXXX}/{XXXX_XXXXXXX_X3_XXXX_XXXXXXXX}",
• xxxxx_xxxxxxx_x3_xxxx_xxxxxxxx=(
• f"x3://{XXX_X3_XXXXXX}/{XXXX_XXXXXXX_X3_XXXX_XXXXXXXX}"
• ), xxxxx_xxx=[

• Merge implicitly concatenated strings if the result fits in the line limit

  
   xxx_xxxxxxx_xxxxxxxx = (

• "XXX(XX(xx XXXXXXX '{xxxxx_xx}' XXX '{xxx_xx}', {xxx}, 0)) "
• "XX {xxx}_x{xxxxxx}"
• "XXX(XX(xx XXXXXXX '{xxxxx_xx}' XXX '{xxx_xx}', {xxx}, 0)) XX {xxx}_x{xxxxxx}" )

• Combination of both, looks much nicer

  
   name_to_base_expression = {

• "view": f"CASE WHEN (playtime >= {VIEW_THRESHOLD} "
• "or has_unmute) THEN 1 ELSE 0 END",
• "view": (
• f"CASE WHEN (playtime >= {VIEW_THRESHOLD} or has_unmute) THEN 1 ELSE 0 END"
• ), }

• Remove f from parts of an implicitly concatenated f-string that don't have placeholders

  
           [

• f"xxxxxx /xxxx/xxxxxxx/xxxx_xxxxxxx_xxxxx_xx.xx "
• "xxxxxx /xxxx/xxxxxxx/xxxx_xxxxxxx_xxxxx_xx.xx " f"--xxxxxxxx_xxxx {xxxxx_xxxxxxx_xxxxx} " f"--xxxxxx_xxx {xxxxx_xxxxxx_xxxx} "
• f"--xx_xxxx "
• "--xx_xxxx " f" {xxxxxx_xxxxxxx_xxxxx_xxx} " f" {xx_xxx_fxxxx} " ]

[zanieb]

My 2-cents: I switched to Black's preview mode just for this feature. Otherwise, string processing is the vast majority of the time I spend manually formatting code. I would love to see this reach a place where it can be stabilized. I never had any problems with it, although I do understand there are many edge cases. I think splitting it into individual features makes a lot of sense so you can make incremental progress. I find splitting long strings really valuable, but understand it's a tough problem — we've been hesitant to tackle it in Ruff as well.

[carschandler]

Agreed with @zanieb this feature is the main reason I use Black over Ruff. Thinking about splitting all of my strings manually gives me Java-scented nightmares.