Improvement to imports, what is a better way ?

[Thomas Passin]

On 1/19/2023 11:55 AM, Roel Schroeven wrote:
> Op 19/01/2023 om 11:32 schreef Stefan Ram:
>> dn <PythonList at DancesWithMice.info> writes:
>> >The longer an identifier, the more it 'pushes' code over to the right 
>> or >to expand over multiple screen-lines. Some thoughts on this are 
>> behind >PEP-008 philosophies, eg line-limit.
>>
>>    Raymond Hettinger (transcribed, shortened and partially
>>    paraphrased by me [Stefan Ram]):
>>
>> |The line-width part of PEP 8 bugs me.
>> |
>> |You have to wrap your commits in seventy-two characters. You have
>> |to end your lines at seventy-nine characters.
>> |
>> |One time it bugs me is when I'm writing unit tests.
>> |
>> |When I write unit tests, I have to start with a class, and then
>> |inside the class there's a "def" for tests, and then the test
>> |starts with a "self.assertEqual", and by then most of my line
>> |is gone. So by the time I get to any business logic in my test,
>> |I'm near the end of the line.
>> |
>> |If I go over seventy-nine characters, somebody will come and
>> |PEP 8 me.
  [snip]

Well, it's an art, not a science.  Very long lines are hard to read. 
Multi-line "lines" can be hard because we are all used to taking in a 
line of code at a time.  And some things you can't shorten, like a long URL.

Personally I prefer shorter lines, even shorter than 72 characters.  But 
splitting a long line of code while still making it easy to grasp is an 
art in itself.  Some constructions do lend themselves nicely to 
splitting into several lines (I hope they don't get wrapped by your 
email reader!):

# Create a plot
g2 = (
       ggplot(df2,
       aes('Days Since Jan 22',  # Comments can clarify these params
       + geom_point(size=.1, color='blue') # size, color params optional
       + theme_bw() # Optional theme (background, grid color, ...)
      )

# Compose a long string:
msg = ('A very long line .....\n'
	+ 'Another long bit of text ....'
	+ 'plus another ....'
       )

For the second example, I will sometimes tokenize it:

M1A = 'A very long line .....\n'
M1B = 'Another long bit of text ....'
M1C = 'plus another ....'
msg = M1A + M1B + M1C

But I usually find the first form easier to grasp, so I tend to use it 
more - and I don't have to invent throwaway variable names.

The PEP-8 rules are good, but they can't cover all cases perfectly.