Line continuation and comments

[dn]

On 25/02/2023 10.04, Mark Bourne wrote:
> Personally, I don't particularly like the way you have to put multiline 
> strings on the far left (rather than aligned with the rest of the scope) 
> to avoid getting spaces at the beginning of each line.  I find it makes 
> it more difficult to see where the scope of the class/method/etc. 
> actually ends, especially if there are multiple such strings.  It's not 
> too bad for strings defined at the module level (outer scope) though, 
> and of course for docstrings the extra spaces at the beginning of each 
> line don't matter.
> 
> However, rather than using "+" to join strings as in your examples 
> (which, as you suggest, is probably less efficient), I tend to use 
> string literal concatenation which I gather is more efficient (treated 
> as a single string at compile-time rather than joining separate strings 
> at run-time).  See 
> <https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation>.
> 
> For example:
>        HelpText = ("Left click:             Open spam\n"
>                    "Shift + Left click:     Cook spam\n"
>                    "Right click:            Crack egg\n"
>                    "Shift + Right click:    Fry egg\n")
> 
> The downside is having to put an explicit "\n" at the end of each line, 
> but to me that's not as bad as having to align the content to the far left.

S\Possible solution to that:

HelpText = "\n".join( ["Left click:             Open spam",
...                   "Shift + Left click:     Cook spam",
...                   "Right click:            Crack egg",
...                   "Shift + Right click:    Fry egg"
...                   ]
...                   )

To PEP-008 Police:
Apologies for formatting - was working from original example

In this manner, the sub-strings may be placed wherever you see fit, and 
those pesky line-endings no-longer contribute to visual clutter (but 
maybe the brackets do...)

Another philosophy is to move awkward strings, such as the examples in 
this thread, 'out' of the mainline code and into a config-file (of sorts).

The PEP-008 Police are more likely to ignore transgressions in a 
'data-file' during code-review. So, you can format the code in whatever 
fashion you like...


Text for GUIs, report print-outs, etc, tends to be at the (tender) mercy 
of (opinionated) users. By putting such into a separate file, such 
changes can be made without (as much) risk of 'breaking' the code 
itself. Ultimately, if you ever have to expand the application to 
multi-tenancy, such will become necessary.

Using a separate file, you can consider if should write such as Python 
(import module) or use something else like JSON, YAML, ...
(and may God bless all who sail in her...).

YMMV!


> Getting a bit more on topic, use of backslashes in strings is a bit 
> different to backslashes for line continuation anyway.  You could almost 
> think of "\
> (newline)" in a multiline string as being like an escape sequence 
> meaning "don't actually put a newline character in the string here", in 
> a similar way to "\n" meaning "put a newline character here" and "\t" 
> meaning "put a tab character here".

Book title: "Don't Make Me Think"
(thoroughly recommended. Author: Steve Krug)

-- 
Regards,
=dn