Tres Seaver 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.
removing it is a bad idea for the reasons
On Sat, 23 Aug 2008, Fredrik Lundh 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)]
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
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
On Aug 3, 2008, at 19:12, Stavros Korokithakis wrote:
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)
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
Stavros Korokithakis wrote:
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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stavros Korokithakis wrote:
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
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
Tres Seaver tseaver at palladion.com writes:
-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.
In many cases
On Sun, Aug 3, 2008 at 8:29 PM, Antoine Pitrou [EMAIL PROTECTED] wrote:
In many cases there is no runtime concatenation cost.
def f():
... return first + second
...
import dis
dis.dis(f)
2 0 LOAD_CONST 3 ('firstsecond')
3 RETURN_VALUE
The many cases
Le dimanche 03 août 2008 à 20:38 +0200, Simon Cross a écrit :
The many cases only extends to strings whose combined length is less
than 20 characters:
Oops. I didn't know that. Is there any rationale (I suppose so)?
___
Python-Dev mailing list
Stavros Korokithakis wrote:
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.
13 matches
Mail list logo
