[Python-ideas] Line continuations with comments
Ron Adam
ron3200 at gmail.com
Thu May 23 01:15:59 CEST 2013
On 05/22/2013 11:02 AM, Bruce Leban wrote:
>
> On Wed, May 22, 2013 at 6:41 AM, Mike Graham
> <mikegraham at gmail.com
> <mailto:mikegraham at gmail.com>> wrote:
>
> Backslash line continuations are mostly to be avoided and making a
> change like this would seem to
>
> a. make them slightly less obvious when they are used,
> b. increase their use in cases where there aren't even long lines of
> code involved, and
> c. seem to encourage their use in general.
>
> It seems to me that using parentheses is an already-existing,
> somewhat-better way to do what you're doing in your examples.
>
> Your last statement seems to be missing the point of the larger discussion.
> Yes, parenthesis can be used in most cases where someone might use \
> continuation. There seems to be strong sentiment to *not* remove \
> continuation. Given that, is allowing comments after a continuation a
> reasonable change? I think so.
>
> Notwithstanding that, these discussions are moving away from Guido's
> original comment about being bitten by implicit continuation of strings and
> not moving towards consensus. Let me throw in a few facts:
>
> 1) There are bugs caused by unintended implicit string concatenation.
There was one found in pythons own library recently where a missing comma
caused an unintentional implicit concatenation. It's fixed now, but it's
not clear how long it's been there.
> 2) Using + as it exists now is not a drop-in replacement for implicit
> string concatenation as it is a run-time operation and has a different
> precedence than the implicit concatenation.
> 3) There are programs that use implicit string concatenation that will need
> to be fixed if the feature is removed.
> 4) There are programs that use \ continuation that will need to be fixed if
> the feature is removed.
> 5) Explicit is better than implicit.
Agree on all counts.
> Personally, I would endorse deprecating and eventually removing implicit
> string concatenation and adding a syntax (not an operator) for explicit
> run-time string concatenation. The use of \ continuation as that syntax
> seems to me like a reasonable choice if we assume that this feature isn't
> going away. In particular, it works today so it's easy to start using it
> and linters can look for it.
I agree here too.
I'm still looking for the location in pythons source code where adjacent
strings are joined. The docs say this ...
-----------
Note that this feature is defined at the syntactical level, but implemented
at compile time. The ‘+’ operator must be used to concatenate string
expressions at run time. Also note that literal concatenation can use
different quoting styles for each component (even mixing raw strings and
triple quoted strings).
-----------
I haven't found either the syntactic definition, or the compile time
implementation yet. <shrug?>
>However, it's pointless to bikeshed the choice
> of syntax if there's no consensus that there should be an explicit syntax
> in the first place.
It seems the consensus may be dependent on what the syntax might be.
> On Tue, May 21, 2013 at 9:13 PM, Ron Adam
> <ron3200 at gmail.com
> <mailto:ron3200 at gmail.com>> wrote:
>
> I was able to make a small patch that removed the some of the
> restrictions on the '\' for testing some ideas which does the following.
>
> * Allow a line to continue on the same line.
>
>
> Aside from serving as a marker for explicit string concatenation, this
> means that I can freely sprinkle in backslashes anywhere I want, like this:
>
> foo \ = \ bar + \ \ 3
>
> That seems like a bad idea.
Yes, But just don't do that. ;-)
And don't do this either. (works now)
foo \
= \
bar + \
\
3
Or this. (also works now)
foo = (
(bar + (
(
3))
)
)
I'm not sure why some people dislike the back slash so much as a
continuation tool. Python is the language that avoids using {braces around
blocks}, so you'd think it would be the other way around.
I really don't think the '\' will be over used. New programmers do try a
lot of strange things at first for making their own programs easier to
read, (I did), but usually they come around to what the community practices
and recommends.
> <snip>
>
> The reason \# works, but not \ #, is when the comment comes directly
> after the back slash, it's removed and leaves a (backslash + new-line)
> pair.
>
>
> Whether we require there be no space between \ and # or, conversely,
> require there be at least one whitespace character should not be based on
> the relative ease of patching the current code. Personally, I would prefer
> the latter as I believe requiring a space after \ will increase readability.
My preference is to allow any number of spaces before and after the '\'.
and that any comments after the slash not change what it means.
A built in single space rule would probably frustrate people who don't want
to do it that way. Like how you get a character after a continuation
error, even if it's only a single space. Yeah, it's how it works, but it's
still annoying to get that error in that situation.
A comment of course, would still uses up the rest of the line. So a '\'
after '#' is just part of the comment.
Cheers,
Ron
More information about the Python-ideas
mailing list