Hello, is concatenation of adjacent strings a useful feature? So far the only use case I've seen is causing me endless hours of debugging when I forget the comma in a tuple of strings, like so: ("first", "second" "third") Which then becomes a tuple of two items, instead of three. It would have been much better if it produced an error. Is there any good reason that this feature exists, or would it be better if it were removed? Regards, Stavros Korokithakis
Stavros Korokithakis wrote:
It can be a very useful feature. See the rejected PEP 3126 for a discussion: http://www.python.org/dev/peps/pep-3126/ Michael Foord
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/
Hmm, thanks, although I don't see why it was rejected, since it seems to me that by using the addition operator or triple-quoting all the use cases would become clearer and not significantly harder to write, while the (often silent) errors would not happen any more. The PEP only mentions that "the feature to be removed isn't all that harmful, and there are some use cases that would become harder", but I'm not sure that the "harder use cases" (which ones?) justify the error potential. Stavros Korokithakis Michael Foord wrote:
Stavros Korokithakis wrote:
As I recall, removing implicit string concatenation simply resulted in too much code breakage for not enough benefit. There is also the minor(!) issue of breaking il8n tools that understand implicit string concatenation but not string addition. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Aug 3, 2008, at 19:12, Stavros Korokithakis wrote:
I use this feature all the time in preference to triple quote strings to allow the indenting structure to be preserved. def I_like_this(): s = ("a multi line\n" "that keeps the indent of the function") return def I_do_not_like_this(): s = '''a multi line that break the indent of the function" return Barry
Is the only issue with this feature that you might accidentally miss a comma after a string in a sequence of strings? That seems like a significantly obscure scenario compared to the usefulness of the current syntax, for exactly the purpose Barry points out (which most people use all the time). I think the runtime concatenation costs are less important than the handiness of being able to break strings across lines without having to figure out where to put that '+' operator.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stavros Korokithakis wrote:
- -1. The feature exists to allow adherence to PEP-8, "Limit all lines to a maximum of 79 characters.", without requiring runtime concatenation costs. I use it frequently when assembling and testing message strings, for instance. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlfMR+gerLs4ltQ4RAjc/AJ9QiO4EWMfamHwyRLaZ+cowu8bT9gCbB+/Y 979rSOIrbRs8lYW3T8Kv6WE= =NSdL -----END PGP SIGNATURE-----
Tres Seaver wrote:
removing it is a bad idea for the reasons already given, but requiring parentheses could help. that is, the following would result in a warning or an error: L = ["first", "second" "third"] but the following wouldn't: L = ["first", ("second" "third")] T = ("This is a line of text.\n" "This is another line of text.\n") etc. </F>
On Sat, 23 Aug 2008, Fredrik Lundh wrote:
This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem. And it's still a change in the language which would probably affect lots of existing code. I doubt if there is any problem-free way of trying to address this issue by changing the language. One suggestion to help minimize problems when writing code would be always to put the optional trailing comma: [ 'a', 'b', 'c', ] which is also a revision-control-friendly practice, and in the tuple constuction context avoids the possibility of removing an item from a two-tuple and ending up with not a one-tuple but instead just the item itself. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist
Isaac Morland wrote:
This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem.
Tuple construction already has a "no comma, no tuple" problem. That problem remains, but as soon as you add a comma, you'll get the same protection as you get for lists.
And it's still a change in the language which would probably affect lots of existing code.
Having read and written tons of existing code, I'm not so sure about that. A tool that wraps backslash-escaped blocks in parentheses would take care of most cases. What's left after that is probably ambiguous to a human reader anyway. <F>
Stavros Korokithakis wrote:
It can be a very useful feature. See the rejected PEP 3126 for a discussion: http://www.python.org/dev/peps/pep-3126/ Michael Foord
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/
Hmm, thanks, although I don't see why it was rejected, since it seems to me that by using the addition operator or triple-quoting all the use cases would become clearer and not significantly harder to write, while the (often silent) errors would not happen any more. The PEP only mentions that "the feature to be removed isn't all that harmful, and there are some use cases that would become harder", but I'm not sure that the "harder use cases" (which ones?) justify the error potential. Stavros Korokithakis Michael Foord wrote:
Stavros Korokithakis wrote:
As I recall, removing implicit string concatenation simply resulted in too much code breakage for not enough benefit. There is also the minor(!) issue of breaking il8n tools that understand implicit string concatenation but not string addition. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Aug 3, 2008, at 19:12, Stavros Korokithakis wrote:
I use this feature all the time in preference to triple quote strings to allow the indenting structure to be preserved. def I_like_this(): s = ("a multi line\n" "that keeps the indent of the function") return def I_do_not_like_this(): s = '''a multi line that break the indent of the function" return Barry
Is the only issue with this feature that you might accidentally miss a comma after a string in a sequence of strings? That seems like a significantly obscure scenario compared to the usefulness of the current syntax, for exactly the purpose Barry points out (which most people use all the time). I think the runtime concatenation costs are less important than the handiness of being able to break strings across lines without having to figure out where to put that '+' operator.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stavros Korokithakis wrote:
- -1. The feature exists to allow adherence to PEP-8, "Limit all lines to a maximum of 79 characters.", without requiring runtime concatenation costs. I use it frequently when assembling and testing message strings, for instance. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlfMR+gerLs4ltQ4RAjc/AJ9QiO4EWMfamHwyRLaZ+cowu8bT9gCbB+/Y 979rSOIrbRs8lYW3T8Kv6WE= =NSdL -----END PGP SIGNATURE-----
Tres Seaver wrote:
removing it is a bad idea for the reasons already given, but requiring parentheses could help. that is, the following would result in a warning or an error: L = ["first", "second" "third"] but the following wouldn't: L = ["first", ("second" "third")] T = ("This is a line of text.\n" "This is another line of text.\n") etc. </F>
On Sat, 23 Aug 2008, Fredrik Lundh wrote:
This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem. And it's still a change in the language which would probably affect lots of existing code. I doubt if there is any problem-free way of trying to address this issue by changing the language. One suggestion to help minimize problems when writing code would be always to put the optional trailing comma: [ 'a', 'b', 'c', ] which is also a revision-control-friendly practice, and in the tuple constuction context avoids the possibility of removing an item from a two-tuple and ending up with not a one-tuple but instead just the item itself. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist
Isaac Morland wrote:
This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem.
Tuple construction already has a "no comma, no tuple" problem. That problem remains, but as soon as you add a comma, you'll get the same protection as you get for lists.
And it's still a change in the language which would probably affect lots of existing code.
Having read and written tons of existing code, I'm not so sure about that. A tool that wraps backslash-escaped blocks in parentheses would take care of most cases. What's left after that is probably ambiguous to a human reader anyway. <F>
participants (10)
-
Antoine Pitrou -
Barry Scott -
Fredrik Lundh -
Isaac Morland -
Matt Giuca -
Michael Foord -
Nick Coghlan -
Simon Cross -
Stavros Korokithakis -
Tres Seaver