Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Antoine Pitrou
Le 09/08/2014 01:08, Steven D'Aprano a écrit : On Fri, Aug 08, 2014 at 10:20:37PM -0400, Alexander Belopolsky wrote: On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman wrote: I don't use sum at all, or at least very rarely, and it still irritates me. You are not alone. When I see sum([a, b, c]),

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Greg Ewing
Steven D'Aprano wrote: I've long believed that + is the wrong operator for concatenating strings, and that & makes a much better operator. Do you have a reason for preferring '&' in particular, or do you just want something different from '+'? Personally I can't see why "bitwise and" on string

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Steven D'Aprano
On Fri, Aug 08, 2014 at 10:20:37PM -0400, Alexander Belopolsky wrote: > On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman wrote: > > > I don't use sum at all, or at least very rarely, and it still irritates me. > > > You are not alone. When I see sum([a, b, c]), I think it is a + b + c, but > in Py

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Alexander Belopolsky
On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman wrote: > I don't use sum at all, or at least very rarely, and it still irritates me. You are not alone. When I see sum([a, b, c]), I think it is a + b + c, but in Python it is 0 + a + b + c. If we had a "join" operator for strings that is different

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Ethan Furman
On 08/08/2014 05:34 PM, Raymond Hettinger wrote: On Aug 8, 2014, at 11:09 AM, Ethan Furman mailto:et...@stoneleaf.us>> wrote: So why not apply a similar optimization to sum() for strings? That I cannot answer -- I find the current situation with sum highly irritating. It is only irritatin

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Raymond Hettinger
On Aug 8, 2014, at 11:09 AM, Ethan Furman wrote: >> So why not apply a similar optimization to sum() for strings? > > That I cannot answer -- I find the current situation with sum highly > irritating. > It is only irritating if you are misusing sum(). The str.__add__ optimization was put in

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Ethan Furman
On 08/08/2014 08:23 AM, Chris Barker wrote: So my final question is this: repeated string concatenation is not the "recommended" way to do this -- but nevertheless, cPython has an optimization that makes it fast and efficient, to the point that there is no practical performance reason to pref

Re: [Python-Dev] sum(...) limitation

2014-08-08 Thread Chris Barker
On Thu, Aug 7, 2014 at 4:01 PM, Ethan Furman wrote: > I don't remember where, but I believe that cPython has an optimization > built in for repeated string concatenation, which is probably why you > aren't seeing big differences between the + and the sum(). > Indeed -- clearly so. A little test

[Python-Dev] Summary of Python tracker Issues

2014-08-08 Thread Python tracker
ACTIVITY SUMMARY (2014-08-01 - 2014-08-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4602 (+10) closed 29340 (+43) total 33942 (+53) Open issues wit

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

2014-08-08 Thread Alexander Belopolsky
On Fri, Aug 8, 2014 at 8:27 AM, Paul Moore wrote: > I had a use case where I wanted to allow a config file to contain > "path: foo" to create a file called foo, and "path: foo/" to create a > directory. It was a shortcut for specifying an explicit "directory: > true" parameter as well. > Here is

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

2014-08-08 Thread Paul Moore
On 7 August 2014 02:55, Antoine Pitrou wrote: > pathlib is generally concerned with filesystem operations written in Python, > not arbitrary third-party tools. Also it is probably easy to append the > trailing slash in your command-line invocation, if so desired. I had a use case where I wanted t