>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
pro
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" "t
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 a
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) err
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.
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
P
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 RETUR
Tres Seaver 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 there i
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
-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",
> "
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,
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 h
13 matches
Mail list logo
