Question: If the Python syntax were changed to allow comments
after line-ending backslashes, would it break any existing code?
I found myself building a complicated logical condition with many ands and ors
which I made more manageable by putting the various terms on individual lines
and breaking them with the "\" line continuation character. In this context it
would have been nice to be able to add comments to lines terms which of course
isn't possible because the backslash must be the last character on the line.
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an example.
x = 5
a = (x > 3 and
# x < 21 or
x > 100
)
I found myself building a complicated logical condition with many ands and ors
which I made more manageable by putting the various terms on individual lines and breaking them with the "\" line continuation character. In this context it
would have been nice to be able to add comments to lines terms which of course
isn't possible because the backslash must be the last character on the line.
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an example.
Il giorno mercoledì 22 febbraio 2023 alle 09:50:14 UTC+1 Robert
Latest ha scritto:
I found myself building a complicated logical condition with many
ands and ors
which I made more manageable by putting the various terms on
individual lines
and breaking them with the "\" line continuation character. In this
context it
would have been nice to be able to add comments to lines terms
which of course
isn't possible because the backslash must be the last character on
the line.
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an
example.
Well you can if you use parenthesis like in:
x = 5
a = (x > 3 and
#Â Â Â Â x < 21 or
    x > 100
    )
You don't need the "\" to continue a line in this case
That’s a neat tip. End of line comments work, too
x = (3 > 4 #never
and 7 == 7 # hopefully
or datetime.datetime.now().day > 15 # sometimes
)
print(x)
From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Edmondo Giovannozzi <edmondo.giovannozzi@gmail.com>listinfo/python-list__;!!Cn_UX_p3!kck9yP0ubC7L_tbIUoMY-nkZJlkXFAiZdnjPtekuYQXN6F8K2wFMW5lO1xZ6gYv6vDdsSo5jxy1QYU_T-EgHsOJ6x7TvXQ$>
Date: Wednesday, February 22, 2023 at 9:40 AM
To: python-list@python.org <python-list@python.org>
Subject: Re: Line continuation and comments
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***
Il giorno mercoledì 22 febbraio 2023 alle 09:50:14 UTC+1 Robert Latest ha scritto:
I found myself building a complicated logical condition with many ands and ors
which I made more manageable by putting the various terms on individual lines
and breaking them with the "\" line continuation character. In this context it
would have been nice to be able to add comments to lines terms which of course
isn't possible because the backslash must be the last character on the line. >>
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an example.
Well you can if you use parenthesis like in:
x = 5
a = (x > 3 and
# x < 21 or
x > 100
)
You don't need the "\" to continue a line in this case
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kck9yP0ubC7L_tbIUoMY-nkZJlkXFAiZdnjPtekuYQXN6F8K2wFMW5lO1xZ6gYv6vDdsSo5jxy1QYU_T-EgHsOJ6x7TvXQ$<https://urldefense.com/v3/__https:/mail.python.org/mailman/
On 2/22/2023 10:02 AM, Weatherby,Gerard wrote:
That’s a neat tip. End of line comments work, too
x = (3 > 4 #never
and 7 == 7 # hopefully
or datetime.datetime.now().day > 15 # sometimes
)
print(x)
I find myself doing this more and more often. It can also help to
make the code more readable and the intention more clear. Here's one
example:
return (getTerminalFromProcess()
or getTerminalFromDirectory('/usr/bin')
or getTerminalFromDirectory('/bin')
or getCommonTerminal(('konsole', 'xterm'))
)
Adding to this, there should be no reason now in recent versions of
Python to ever use line continuation. Black goes so far as to state "backslashes are bad and should never be used":
https://black.readthedocs.io/en/stable/the_black_code_style/future_style.html#using-backslashes-for-with-statements
Adding to this, there should be no reason now in recent versions of
Python to ever use line continuation. Black goes so far as to state "backslashes are bad and should never be used":
https://black.readthedocs.io/en/stable/the_black_code_style/future_sty le.html#using-backslashes-for-with-statements
I found myself building a complicated logical condition with many ands and ors
which I made more manageable by putting the various terms on individual lines and breaking them with the "\" line continuation character. In this context it
would have been nice to be able to add comments to lines terms which of course
isn't possible because the backslash must be the last character on the line.
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an example.
I found myself building a complicated logical condition with many ands and ors
which I made more manageable by putting the various terms on individual lines and breaking them with the "\" line continuation character. In this context it
would have been nice to be able to add comments to lines terms which of course
isn't possible because the backslash must be the last character on the line.
Question: If the Python syntax were changed to allow comments after line-ending
backslashes, would it break any existing code? I can't think of an example.
“
NB my PyCharm-settings grumble whenever I create an identifier which is
only used once (and perhaps, soon after it was established). I
understand the (space) optimisation, but prefer to trade that for 'readability'.
“
I haven’t seen that one. What I get is warnings about:
def is_adult( self )->bool:
   LEGAL_AGE_US = 21
   return LEGAL_AGE
It doesn’t like LEGAL_AGE_US being all caps if declared in a function.
NB my PyCharm-settings grumble whenever I create an identifier which is
only used once (and perhaps, soon after it was established). I
understand the (space) optimisation, but prefer to trade that for 'readability'.
“
NB my PyCharm-settings grumble whenever I create an identifier which
is only used once (and perhaps, soon after it was established). I
understand the (space) optimisation, but prefer to trade that for 'readability'.
“
I haven’t seen that one. What I get is warnings about:
def is_adult( self )->bool:
LEGAL_AGE_US = 21
return LEGAL_AGE
It doesn’t like LEGAL_AGE_US being all caps if declared in a function.
NB my PyCharm-settings grumble whenever I create an identifier which is
only used once (and perhaps, soon after it was established). I
understand the (space) optimisation, but prefer to trade that for 'readability'.
NB my PyCharm-settings grumble whenever I create an identifier which
is
only used once (and perhaps, soon after it was established). I
understand the (space) optimisation, but prefer to trade that for >>'readability'.
I haven’t seen that one. What I get is warnings about:
def is_adult( self )->bool:
   LEGAL_AGE_US = 21
   return LEGAL_AGE
It doesn’t like LEGAL_AGE_US being all caps if declared in a function.
Yes, I suffered this one too.
The rationale comes from PEP-008 (Constants):
Constants are usually defined on a module level and written in all
capital letters with underscores separating words.
Good example, Rob, of how some people make what I consider RELIGIOUS edicts that one can easily violate if one wishes and it makes lots of sense in your example.way of avoiding that.
Let me extend that. The goal was to store a character string consisting of multiple lines when printed that are all left-aligned. Had you written:
HelpText = """
Left click: Open spam
...
Shift + Right click: Fry egg
"""
Then it would begin with an extra carriage return you did not want. Your example also ends with a carriage return because you closed the quotes on another line, so a \ on the last line of text (or moving the quotes to the end of the line) would be a
Consider some alternatives I have seen that are in a sense ugly and may involve extra work for the interpreter unless it is byte compiled once.
def someFunc():
HelpText =
"Left click: Open spam" + "\n" +
"Shift + Left click: Cook spam" + "\n" +
...
Or the variant of:
HelpText = "Left click: Open spam\n"
HelpText += " Shift + Left click: Cook spam\n"
...
Or perhaps just dumping the multi-line text into a file beforehand and reading that into a string!
def someFunc():
The backslash is not looking like such a bad idea! LOL!
-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, February 22, 2023 2:08 PM
To: python-list@python.org
Subject: Re: Line continuation and comments
On 22/02/2023 15:23, Paul Bryan wrote:
Adding to this, there should be no reason now in recent versions of
Python to ever use line continuation. Black goes so far as to state
"backslashes are bad and should never be used":
https://black.readthedocs.io/en/stable/the_black_code_style/future_sty
le.html#using-backslashes-for-with-statements
def someFunc():
HelpText = """\
Left click: Open spam
Shift + Left click: Cook spam
Right click: Crack egg
Shift + Right click: Fry egg
"""
The initial backslash aligns the first line with the others (in a fixed font of course).
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
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)A way around this is using textwrap.dedent() (https://docs.python.org/3.10/library/textwrap.html?highlight=dedent#textwrap.dedent).
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.
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.
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".
Il giorno mercoledì 22 febbraio 2023 alle 09:50:14 UTC+1 Robert Latest ha scritto:
I found myself building a complicated logical condition with many ands and >> ors which I made more manageable by putting the various terms on individual >> lines and breaking them with the "\" line continuation character. In this
context it would have been nice to be able to add comments to lines terms
which of course isn't possible because the backslash must be the last
character on the line.
Question: If the Python syntax were changed to allow comments after
line-ending
backslashes, would it break any existing code? I can't think of an example.
Well you can if you use parenthesis like in:
x = 5
a = (x > 3 and
# x < 21 or
x > 100
)
You don't need the "\" to continue a line in this case
Adding to this, there should be no reason now in recent versions offuture_style.html#using-backslashes-for-with-statements
Python to ever use line continuation. Black goes so far as to state "backslashes are bad and should never be used":
https://black.readthedocs.io/en/stable/the_black_code_style/
Paul Bryan wrote:
Adding to this, there should be no reason now in recent versions offuture_style.html#using-backslashes-for-with-statements
Python to ever use line continuation. Black goes so far as to state
"backslashes are bad and should never be used":
https://black.readthedocs.io/en/stable/the_black_code_style/
Then I wonder how Mr. Black would go about these long "dot chaining" expressions that packages like pandas and sqlalchemy require.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:27:59 |
| Calls: | 6,716 |
| Files: | 12,247 |
| Messages: | 5,357,917 |