On Wed, Mar 14, 2018 at 05:06:02PM +1100, Chris Angelico wrote:
> On Wed, Mar 14, 2018 at 4:58 PM, Steven D'Aprano wrote:
> > On Wed, Mar 14, 2018 at 04:20:20PM +1100, Chris Billington wrote:
> >
> >> Instead, maybe a user should just get a big fat error if they try to import
> >> the same file tw
The (perhaps minor) problem with simply having the same module object have
two entries in sys.modules is that at least one of them will have a
different __name__ attribute than the corresponding key in sys.modules.
It's not the end of the world (os.path.__name__ is 'posixpath' on linux,
not 'os.pat
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 = (
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
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 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 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
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 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
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 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: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
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 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
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 <
> [email protected]> wrote:
> > On Wed, Mar 14, 2018 at 09:18:30AM -030
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
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
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
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
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
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
+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 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
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
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
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
10.05.13 21:48, Guido van Rossum пише:
I just spent a few minutes staring at a bug caused by a missing comma
-- I got a mysterious argument count error because instead of foo('a',
'b') I had written foo('a' 'b').
This is a fairly common mistake, and IIRC at Google we even had a lint
rule against
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
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
In module filecmp, the normal functions cmp and cmpfiles do have a
shallow attribute. But the dircmp class doesn't provide one, could we
add it in the constructor ?
In the implementation, it would only change the call to cmpfiles in def phase3 ?
It could be useful for performance (same reason, th
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
On 14 March 2018 at 15:34, Serhiy Storchaka wrote:
> 10.05.13 21:48, Guido van Rossum пише:
>>
>> I just spent a few minutes staring at a bug caused by a missing comma
>> -- I got a mysterious argument count error because instead of foo('a',
>> 'b') I had written foo('a' 'b').
>>
>> This is a fair
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
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
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,
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.
>
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
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
On Tue, 13 Mar 2018 15:35:56 +
Rhodri James wrote:
> On 12/03/18 20:57, George Fischhof wrote:
> > Good day all,
> >
> > as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
> > contain file operations.
> >
> > Here is the draft. What do you think about this?
>
> I am mil
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
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
path.py conveniently defines very many (most?) file operations as methods:
https://github.com/jaraco/path.py/blob/master/path.py
https://pathpy.readthedocs.io/en/latest/api.html
The division operator is mapped to os.path.join:
Path('a') / '/root' == Path('/root')
On Monday, March 12, 2018, Geor
On 2018-03-14 04:18, Steven D'Aprano wrote:
Apart from intentionally manipulating sys.modules or the import system,
or playing file system tricks like hard-linking your files, under what
circumstances can this occur by accident?
It can occur if a given directory winds up appearing twice on the
On Thu, Mar 15, 2018 at 5:25 AM, Brendan Barnwell wrote:
> On 2018-03-14 04:18, Steven D'Aprano wrote:
>>
>> Apart from intentionally manipulating sys.modules or the import system,
>> or playing file system tricks like hard-linking your files, under what
>> circumstances can this occur by accident
+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 Wed, Mar 14, 2018 at 8:43 PM Robert Vanden Eynde <
[email protected]> 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
On Mar 12, 2018 1:57 PM, "George Fischhof" wrote:
This PEP proposes pathlib module to be a centralized place for all
file-system related operations.
I'd find this useful for another reason that hasn't been mentioned yet:
having a single class collecting all the common/basic file operations make
Yeah, one should never add a module to sys.path that has a __init__.py file.
On Wed, Mar 14, 2018 at 11:25 AM, Brendan Barnwell
wrote:
> On 2018-03-14 04:18, Steven D'Aprano wrote:
>
>> Apart from intentionally manipulating sys.modules or the import system,
>> or playing file system tricks like
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 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 12 Mar 2018, at 21:56, George Fischhof wrote:
>
>
>
> 2018-03-12 22:16 GMT+01:00 Paul Moore :
>> On 12 March 2018 at 20:57, George Fischhof wrote:
>> > Good day all,
>> >
>> > as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
>> > contain file operations.
>> >
>> > H
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 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
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
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 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
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
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
_
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
Once there was a discussion about alternative list and arrays
creation and assignment syntaxes. I think this is one of things with room for
ideas and has frequent usage.
I've had some ideas for syntax long ago, and now I remembered it because of
the recent topic "Descouraging the implicit string co
On 3/14/2018 8:32 PM, Mikhail V wrote:
Once there was a discussion about alternative list and arrays
creation and assignment syntaxes. I think this is one of things with room for
ideas and has frequent usage.
I've had some ideas for syntax long ago, and now I remembered it because of
the recent t
On Thu, Mar 15, 2018 at 2:10 AM, Terry Reedy wrote:
> On 3/14/2018 8:32 PM, Mikhail V wrote:
>>
>> ...
>>
>> Also in 1d case one might omit the line continuation \:
>>
>> L ===*
>> "msg1"
>> "msg2"
>> "error"
>>
>> returns:
>> ["msg1", "msg2", "error"]
>
>
> No, this would return "m
On Thu, Mar 15, 2018 at 01:32:35AM +0100, Mikhail V wrote:
> Idea is a concept for 2D arrays/lists syntax, which should simplify
> some editing boilerplate while working with arrays and improve
> readability for bigger arrays.
I don't understand; we already have perfectly good syntax for working
63 matches
Mail list logo
