5 ms·

The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/ https://www.python.org/d

The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/ https://www.python.org/dev/peps/pep-3126/

wodenokoto 5y ago
The rejection notice seems completely counter intuitive to me. How is adding a plus "harder" compared to removing a foot gun? > This PEP is rejected. There wasn't enough support in favor, the feature to be removed isn't all that harmful, and there are some use cases that would become harder.
- oa2022 5y ago
  This change would break a lot of legacy code for no good reason The most common way to split a string in lines is using this concatenation formula.
  - benesch 5y ago
    > This change would break a lot of legacy code for no good reason Preventing a bug that occurs in 5% of observed codebases (and anecdotally, happens to me during development all the time) seems like about as good as reasons get. Swapping a perfectly fine print statement for a function, on the other hand… that’s the breaking change in Py3k that’s never seemed worth it to me.
    - aflag 5y ago
      I've never heard from Guido on this, but I've always felt that he created the print keyword in the very early days, just because it was easy and he always thought the language would be a niche small language. But, as the popularity of the language increased, the print keyword just stand out as a sore thumb and he just had to fix that.
  - wodenokoto 5y ago
    But wasn't this proposal part of the move to python 3? strings where broken left and right anyway.
    - gsnedders 5y ago
      Right, there was lots of deliberate breakage, _and_ this is purely syntaxual hence the sort of thing 2to3 could trivially deal with.
      - ehsankia 5y ago
        > the sort of thing 2to3 could trivially deal with 2to3 could also trivially add +, and if anything, that would actually help surface these kind of bugs, because if you randomly see a + in the middle of your list of strings, it's much easier to spot the bug than if there was a missing comma.
  - deleted 5y ago
    [deleted]
  - nojs 5y ago
    > The most common way to split a string in lines is using this concatenation formula. Is it really? I tend to avoid it in favour of ””” or ‘\n’.join(<list of lines>), because it looks like a mistake. Triple quotes are kind of annoying if the string is indented, but you can just not indent the string to avoid the whitespace.
    - housecarpenter 5y ago
      I use it, personally. The other two options I find too aesthetically displeasing: not indenting the string looks bad when it's within an indented block of code, and using join and putting the strings in a list is just too much boilerplate. I will use """ if I don't care about the extra space put at the start of each line by the indentation.
      - Spivak 5y ago
        I think you want textwrap.dedent https://docs.python.org/3/library/textwrap.html#textwrap.dedent https://docs.python.org/3/library/textwrap.html#textwrap.ded... or inspect.cleandoc. https://docs.python.org/3.8/library/inspect.html#inspect.cleandoc https://docs.python.org/3.8/library/inspect.html#inspect.cle...
        deleted 5y ago
        [deleted]
    - nostoc 5y ago
      Both of your solutions are great but don't fully cover the use case. They are useful for multiline strings, but implicit concatenation is also often used to break long strings that may not have newlines.
      - boublepop 5y ago
        In y opinion that would be better served with ‘’.join( ‘hello’, ‘world’) No footgun potential, and as others have mentioned the “good usage” would often be bad simply because it ends up looking like a mistake even if it’s intentional.
Wowfunhappy 5y ago
Does Python support the concept of allowing code to opt in to new safety features? I can understand rejecting something like this for the sake of legacy compatibility (something Python has abandoned too readily in the past), but it seems like an option—or maybe even a default—might be nice. I suppose this is also something you could catch with a linter?
- cpeterso 5y ago
  Yes: import from __future__ https://docs.python.org/3/library/__future__.html https://docs.python.org/3/library/__future__.html
  - Wowfunhappy 5y ago
    I'd say that's a "kind of", since it implies the feature will eventually become mandatory. I was thinking more along the lines of Javascript's 'use strict';
    - oblvious-earth 5y ago
      No, there's a general aversion to "use flag" features among the Python core dev due to not wanting to support multiple versions of Python behavior and how they may interact over the long term. "from __future__" is meant to only ever be used temporarily with a specific Python version slated for it becoming the default behavior. This discussion about flags has come up recently as part of the debate of accepting PEP 649 or PEP 563 or something else continues. If the Steering Council does not accept PEP 563 it will need to be figured out how to deprecate "from __future__ import annotations" without making it the default and how to implement it's replacement.

The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/ https://www.python.org/dev/peps/pep-3126/

wodenokoto 5y ago

The rejection notice seems completely counter intuitive to me. How is adding a plus "harder" compared to removing a foot gun? > This PEP is rejected. There wasn't enough support in favor, the feature to be removed isn't all that harmful, and there are some use cases that would become harder.

oa2022 5y ago
This change would break a lot of legacy code for no good reason The most common way to split a string in lines is using this concatenation formula.
- benesch 5y ago
  > This change would break a lot of legacy code for no good reason Preventing a bug that occurs in 5% of observed codebases (and anecdotally, happens to me during development all the time) seems like about as good as reasons get. Swapping a perfectly fine print statement for a function, on the other hand… that’s the breaking change in Py3k that’s never seemed worth it to me.
  - aflag 5y ago
    I've never heard from Guido on this, but I've always felt that he created the print keyword in the very early days, just because it was easy and he always thought the language would be a niche small language. But, as the popularity of the language increased, the print keyword just stand out as a sore thumb and he just had to fix that.
- wodenokoto 5y ago
  But wasn't this proposal part of the move to python 3? strings where broken left and right anyway.
  - gsnedders 5y ago
    Right, there was lots of deliberate breakage, _and_ this is purely syntaxual hence the sort of thing 2to3 could trivially deal with.
    - ehsankia 5y ago
      > the sort of thing 2to3 could trivially deal with 2to3 could also trivially add +, and if anything, that would actually help surface these kind of bugs, because if you randomly see a + in the middle of your list of strings, it's much easier to spot the bug than if there was a missing comma.
- deleted 5y ago
  [deleted]
- nojs 5y ago
  > The most common way to split a string in lines is using this concatenation formula. Is it really? I tend to avoid it in favour of ””” or ‘\n’.join(<list of lines>), because it looks like a mistake. Triple quotes are kind of annoying if the string is indented, but you can just not indent the string to avoid the whitespace.
  - housecarpenter 5y ago
    I use it, personally. The other two options I find too aesthetically displeasing: not indenting the string looks bad when it's within an indented block of code, and using join and putting the strings in a list is just too much boilerplate. I will use """ if I don't care about the extra space put at the start of each line by the indentation.
    - Spivak 5y ago
      I think you want textwrap.dedent https://docs.python.org/3/library/textwrap.html#textwrap.dedent https://docs.python.org/3/library/textwrap.html#textwrap.ded... or inspect.cleandoc. https://docs.python.org/3.8/library/inspect.html#inspect.cleandoc https://docs.python.org/3.8/library/inspect.html#inspect.cle...
      - deleted 5y ago
        [deleted]
  - nostoc 5y ago
    Both of your solutions are great but don't fully cover the use case. They are useful for multiline strings, but implicit concatenation is also often used to break long strings that may not have newlines.
    - boublepop 5y ago
      In y opinion that would be better served with ‘’.join( ‘hello’, ‘world’) No footgun potential, and as others have mentioned the “good usage” would often be bad simply because it ends up looking like a mistake even if it’s intentional.

Wowfunhappy 5y ago

Does Python support the concept of allowing code to opt in to new safety features? I can understand rejecting something like this for the sake of legacy compatibility (something Python has abandoned too readily in the past), but it seems like an option—or maybe even a default—might be nice. I suppose this is also something you could catch with a linter?

cpeterso 5y ago
Yes: import from __future__ https://docs.python.org/3/library/__future__.html https://docs.python.org/3/library/__future__.html
- Wowfunhappy 5y ago
  I'd say that's a "kind of", since it implies the feature will eventually become mandatory. I was thinking more along the lines of Javascript's 'use strict';
  - oblvious-earth 5y ago
    No, there's a general aversion to "use flag" features among the Python core dev due to not wanting to support multiple versions of Python behavior and how they may interact over the long term. "from __future__" is meant to only ever be used temporarily with a specific Python version slated for it becoming the default behavior. This discussion about flags has come up recently as part of the debate of accepting PEP 649 or PEP 563 or something else continues. If the Steering Council does not accept PEP 563 it will need to be figured out how to deprecate "from __future__ import annotations" without making it the default and how to implement it's replacement.