On Thu, Mar 15, 2018 at 8:58 PM, Rob Cliffe via Python-ideas
wrote:
>
>
> On 14/03/2018 17:57, Chris Angelico wrote:
>
> On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård
> wrote:
>
> Of course you can always make error, even in a single letter.
> But I think there is a big difference between mixin
On 14/03/2018 17:57, Chris Angelico wrote:
On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård wrote:
Of course you can always make error, even in a single letter.
But I think there is a big difference between mixing up +-/* and **
where the operator is in "focus" and the implicit concatenation w
I'm with Steven D`Aprano here. Implicit string concat, in my experience, is
something clear, concise and convenient.
I've had a bug because of it only once or twice during my whole career, and
not only that "occasional" bug would have occurred either way because of a
missing comma or plus sign, bu
Carl Meyer wrote:
With this rule the only missing-comma that can slip through is when
you've forgotten _all_ the intervening commas in your sequence of
strings. That's much less likely.
Not so unlikely when the argument list is of length 2.
--
Greg
_
Facundo Batista wrote:
That we say "hey, this works but please don't use it, because it tends
to a error prone way of writing some code, instead do this".
The trouble is that there is nowhere near widespread
agreement that it is error prone enough to be worth
such a drastic measure as deprecati
On Thu, Mar 15, 2018 at 9:06 AM, Kyle Lahnakoski
wrote:
> I did use implicit concatenation for a long SQL statement, and a few
> long error messages, but the byte savings is not worth the increased bug
> density.
>
>>self.db.execute(
>>"CREATE TABLE files (" +
>>" bucket TEXT
Oleg Broytman wrote:
The most painful was that the bug destroyed important information
that was hard to fix later (enterprise code in production, the code is
certificated and hard to replace).
Seems to me there are a number of problems right there:
* Important information that is not backed
On Wed, Mar 14, 2018 at 01:47:53PM -0300, Facundo Batista wrote:
> 2018-03-14 11:30 GMT-03:00 Stephan Houben :
>
> > Op 14 mrt. 2018 15:23 schreef "Facundo Batista" :
> >
> > I propose the discouragement of the idiom.
> >
> >
> >
> > What does that mean?
>
> That we say "hey, this works but pleas
On 2018-03-14 08:18, Facundo Batista wrote:
> Hello!
>
> What would you think about formally descouraging the following idiom?
>
> long_string = (
> "some part of the string "
> "with more words, actually is the same "
> "string that the compiler puts together")
>
Tha
Facundo Batista wrote:
What was proposed and reject was the *removal* of the feature/syntax.
I propose the discouragement of the idiom.
Providing a linter option to catch it would be fine.
Officially discouraging it would be going too far, I think.
It's one thing to promote style guidelines c
On 3/14/2018 11:03 AM, Guido van Rossum wrote:
I use the feature regularly for long error messages, and when combined
with .format() or % it's not so easy to replace it with a + (it would
require adding parentheses).
I like using f-strings for this now, and adding '+' stops compile-time
conca
On 3/14/2018 8:18 AM, Facundo Batista wrote:
Hello!
What would you think about formally descouraging the following idiom?
long_string = (
"some part of the string "
"with more words, actually is the same "
"string that the compiler puts together")
-1
We shoul
On Wed, Mar 14, 2018 at 8:43 PM Robert Vanden Eynde <
robertvandeney...@hotmail.com> wrote:
> > We should write the following, instead:
> >
> > long_string = (
> > "some part of the string " +
> > "with more words, actually is the same " +
> > "string that the compiler
+1 on general idea of discouraging it.
> [...] mistakes like:
>
> fruits = {
> "apple",
> "orange"
> "banana",
> "melon",
> }
+1
> (and even making the static analysers, like pyflakes or pylint, to
> show that as a warning)
+1
> I agree that implicit concatenation is a bad feat
On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård wrote:
> Of course you can always make error, even in a single letter.
> But I think there is a big difference between mixing up +-/* and **
> where the operator is in "focus" and the implicit concatenation where
> there is no operator.
> A common pr
On Wed, 14 Mar 2018 15:03:02 +
Guido van Rossum
wrote:
> I use the feature regularly for long error messages, and when combined with
> .format() or % it's not so easy to replace it with a + (it would require
> adding parentheses).
Same here. Implicit string concatenation together with string
Le mer. 14 mars 2018 à 18:04, Carl Meyer a écrit :
> On 3/14/18 8:03 AM, Guido van Rossum wrote:
> > I use the feature regularly for long error messages, and when combined
> > with .format() or % it's not so easy to replace it with a + (it would
> > require adding parentheses).
> >
> > So I am ag
Le mer. 14 mars 2018 à 17:29, Paul Moore a écrit :
> Ironically, many of the places I see implicit concatenation used are
> where people need to work around linters complaining about line
> lengths. I understand the benefits of projects that mandate code
> passing lint checks, but I foresee seque
On 3/14/18 8:03 AM, Guido van Rossum wrote:
> I use the feature regularly for long error messages, and when combined
> with .format() or % it's not so easy to replace it with a + (it would
> require adding parentheses).
>
> So I am against formally discouraging it or adding something to PEP 8.
>
Hi Facundo,
On 14.03.2018 17:47, Facundo Batista wrote:
> 2018-03-14 11:30 GMT-03:00 Stephan Houben :
>
>> Op 14 mrt. 2018 15:23 schreef "Facundo Batista" :
>>
>> I propose the discouragement of the idiom.
>>
>>
>>
>> What does that mean?
>
> That we say "hey, this works but please don't use it,
2018-03-14 11:30 GMT-03:00 Stephan Houben :
> Op 14 mrt. 2018 15:23 schreef "Facundo Batista" :
>
> I propose the discouragement of the idiom.
>
>
>
> What does that mean?
That we say "hey, this works but please don't use it, because it tends
to a error prone way of writing some code, instead do
On 14 March 2018 at 15:10, Robert Vanden Eynde
wrote:
> Indeed, linters are the place to go, but I think there is no
> "official" linter (am I wrong ?), are pyflakes and pylint independant
> projects ?
Ironically, many of the places I see implicit concatenation used are
where people need to work
On 14/03/18 12:18, Facundo Batista wrote:
What would you think about formally descouraging the following idiom?
long_string = (
"some part of the string "
"with more words, actually is the same "
"string that the compiler puts together")
-1. I use it a fair bit
14.03.18 17:33, Steven D'Aprano пише:
Um, yeah, okay, I get lots of mysterious errors caused by carelessness.
Some of them are easy to fix. Some are much harder to track down and fix
than a missing comma. Do they all need official warnings in the docs?
"Don't misspell None as 'none' in thre
14.03.18 14:18, Facundo Batista пише:
What would you think about formally descouraging the following idiom?
long_string = (
"some part of the string "
"with more words, actually is the same "
"string that the compiler puts together")
We should write the following
On Wed, Mar 14, 2018 at 03:01:07PM +0100, Oleg Broytman wrote:
> > People can make all sorts of mistakes through carlessness. I wrote
>
> > {y, x*3}
> >
> > the other day instead of {y: x**3}. (That's *two* errors in one simple
> > expression. I wish I could say it was a record for me.) Shou
Indeed, linters are the place to go, but I think there is no
"official" linter (am I wrong ?), are pyflakes and pylint independant
projects ?
2018-03-14 16:03 GMT+01:00 Guido van Rossum :
> I use the feature regularly for long error messages, and when combined with
> .format() or % it's not so eas
I use the feature regularly for long error messages, and when combined with
.format() or % it's not so easy to replace it with a + (it would require
adding parentheses).
So I am against formally discouraging it or adding something to PEP 8.
However linters could warn about lists of comma-separate
On Thu, Mar 15, 2018 at 01:18:06AM +1100, Steven D'Aprano
wrote:
> On Wed, Mar 14, 2018 at 02:31:58PM +0100, Oleg Broytman wrote:
> >Once I stumbled over a bug caused by this in legacy code in
> > production. Fixing it was quite painful!
>
> Did you mean that *finding* the bug was painful? F
+1 on general idea of discouraging it.
> [...] mistakes like:
>
> fruits = {
> "apple",
> "orange"
> "banana",
> "melon",
> }
+1
> (and even making the static analysers, like pyflakes or pylint, to
> show that as a warning)
+1
> I agree that implicit concatenation is a bad feat
On 14 March 2018 at 14:22, Facundo Batista wrote:
> 2018-03-14 10:54 GMT-03:00 Paul Moore :
>
>> Also, we need to consider the significant body of code that would
>> break if this construct were prohibited. Even if we were to agree that
>> the harm caused by implicit concatenation outweighed the b
Op 14 mrt. 2018 15:23 schreef "Facundo Batista" :
I propose the discouragement of the idiom.
What does that mean?
Stephan
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
2018-03-14 11:09 GMT-03:00 Stephan Houben :
> Note that this has already been proposed and rejected before:
>
> https://www.python.org/dev/peps/pep-3126/
What was proposed and reject was the *removal* of the feature/syntax.
I propose the discouragement of the idiom.
Regards,
--
.Facundo
B
2018-03-14 10:54 GMT-03:00 Paul Moore :
> Also, we need to consider the significant body of code that would
> break if this construct were prohibited. Even if we were to agree that
> the harm caused by implicit concatenation outweighed the benefits,
> that would *still* not justify making it illeg
On Wed, Mar 14, 2018 at 02:31:58PM +0100, Oleg Broytman wrote:
[...]
> > fruits = {
> > "apple",
> > "orange"
> > "banana",
> > "melon",
> > }
>
>I am all for that, with both hands! +100, dammit!
>
>Once I stumbled over a bug caused by this in legacy code in
> product
On Wed, Mar 14, 2018 at 03:09:28PM +0100, Stephan Houben
wrote:
> Note that this has already been proposed and rejected before:
>
> https://www.python.org/dev/peps/pep-3126/
Not the same. The current proposal is to discourage, not remove the
misfeature.
> Stephan
Oleg.
--
Oleg Broytm
Note that this has already been proposed and rejected before:
https://www.python.org/dev/peps/pep-3126/
Stephan
Op 14 mrt. 2018 15:01 schreef "Oleg Broytman" :
> On Thu, Mar 15, 2018 at 12:15:52AM +1100, Steven D'Aprano <
> st...@pearwood.info> wrote:
> > On Wed, Mar 14, 2018 at 09:18:30AM -030
On Thu, Mar 15, 2018 at 12:15:52AM +1100, Steven D'Aprano
wrote:
> On Wed, Mar 14, 2018 at 09:18:30AM -0300, Facundo Batista wrote:
> > We should write the following, instead:
> >
> > long_string = (
> > "some part of the string " +
> > "with more words, actually is the same
Hi!
On Wed, Mar 14, 2018 at 09:18:30AM -0300, Facundo Batista
wrote:
> Hello!
>
> What would you think about formally descouraging the following idiom?
>
> long_string = (
> "some part of the string "
> "with more words, actually is the same "
> "string that the com
On Wed, Mar 14, 2018 at 2:54 PM, Paul Moore wrote:
> On 14 March 2018 at 13:40, Søren Pilgård wrote:
>> We can't remove all potential pitfalls, but I do think there is value
>> in evaluating whether something has bigger potential to cause harm
>> than the benefits it brings, especially if there a
On 14 March 2018 at 13:40, Søren Pilgård wrote:
> We can't remove all potential pitfalls, but I do think there is value
> in evaluating whether something has bigger potential to cause harm
> than the benefits it brings, especially if there are other ways to do
> the same.
Certainly. However, in t
On Wed, Mar 14, 2018 at 2:26 PM, Steven D'Aprano wrote:
> On Wed, Mar 14, 2018 at 01:43:53PM +0100, Søren Pilgård wrote:
>
> [...]
>> I have also experienced beginners asking why you can do `x = "abc"
>> "def"` but not `a = "abc"; b = "def"; x = a b` and then you have to
>> either explain them the
On Wed, Mar 14, 2018 at 2:15 PM, Steven D'Aprano wrote:
> On Wed, Mar 14, 2018 at 09:18:30AM -0300, Facundo Batista wrote:
>> Hello!
>>
>> What would you think about formally descouraging the following idiom?
>>
>> long_string = (
>> "some part of the string "
>> "with more wor
While I personally dislike implicit string concatenation,
I've worked in projects that use it, and I, more often than
I'd like, use them myself.
The problem is that there is no "less typing" way of entering
a correct multi-line string - due to multiline string literals
preserving the indentation c
On Wed, Mar 14, 2018 at 01:43:53PM +0100, Søren Pilgård wrote:
[...]
> I have also experienced beginners asking why you can do `x = "abc"
> "def"` but not `a = "abc"; b = "def"; x = a b` and then you have to
> either explain them the differences between strings and string
> literals or just tell t
On Wed, Mar 14, 2018 at 09:18:30AM -0300, Facundo Batista wrote:
> Hello!
>
> What would you think about formally descouraging the following idiom?
>
> long_string = (
> "some part of the string "
> "with more words, actually is the same "
> "string that the compiler p
On Wed, Mar 14, 2018 at 12:18 PM, Facundo Batista
wrote:
>
> Note that there's no penalty in adding the '+' between the strings,
> those are resolved at compilation time.
The above statement is not true for versions prior to 3.7. Previously
the addition of string literals was optimized by the pee
On Wed, Mar 14, 2018 at 1:18 PM, Facundo Batista
wrote:
> Hello!
>
> What would you think about formally descouraging the following idiom?
>
> long_string = (
> "some part of the string "
> "with more words, actually is the same "
> "string that the compiler puts togeth
Hello!
What would you think about formally descouraging the following idiom?
long_string = (
"some part of the string "
"with more words, actually is the same "
"string that the compiler puts together")
We should write the following, instead:
long_string = (
49 matches
Mail list logo
