Re: [Python-Dev] os.walk() is going to be *fast* with scandir

2014-08-10 Thread Robert Collins
A small tip from my bzr days - cd into the directory before scanning it - especially if you'll end up statting more than a fraction of the files, or are recursing - otherwise the VFS does a traversal for each path you directly stat / recurse into. This can become a dominating factor in some

Re: [Python-Dev] os.walk() is going to be *fast* with scandir

2014-08-10 Thread Larry Hastings
On 08/09/2014 10:40 PM, Robert Collins wrote: A small tip from my bzr days - cd into the directory before scanning it I doubt that's permissible for a library function like os.scandir(). //arry/ ___ Python-Dev mailing list Python-Dev@python.org

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

2014-08-10 Thread Stephen J. Turnbull
Alexander Belopolsky writes: On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull step...@xemacs.org wrote: All the suggestions I've seen so far are (IMHO, YMMV) just as ugly as the present situation. What is ugly about allowing strings? CPython certainly has a way to to

Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

2014-08-10 Thread Stephen J. Turnbull
Chris Angelico writes: The justification is illogical. However, I personally believe boilerplate should be omitted where possible; But it mostly can't be omitted. I wrote 22 classes (all trivial) yesterday for a Python 3 program. Not one derived directly from object. That's a bit unusual,

Re: [Python-Dev] os.walk() is going to be *fast* with scandir

2014-08-10 Thread Armin Rigo
Hi Larry, On 10 August 2014 08:11, Larry Hastings la...@hastings.org wrote: A small tip from my bzr days - cd into the directory before scanning it I doubt that's permissible for a library function like os.scandir(). Indeed, chdir() is notably not compatible with multithreading. There would

Re: [Python-Dev] os.walk() is going to be *fast* with scandir

2014-08-10 Thread R. David Murray
On Sun, 10 Aug 2014 13:57:36 +1000, Nick Coghlan ncogh...@gmail.com wrote: On 10 August 2014 13:20, Antoine Pitrou anto...@python.org wrote: Le 09/08/2014 12:43, Ben Hoyt a écrit : Just thought I'd share some of my excitement about how fast the all-C version [1] of os.scandir() is

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

2014-08-10 Thread Barry Warsaw
On Aug 10, 2014, at 05:24 PM, Stephen J. Turnbull wrote: Actually ... if I were a fan of the .join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate .join(string_iterable) in favor of .sum(string_iterable) (with the same efficient semantics).

Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

2014-08-10 Thread Alexander Belopolsky
On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano st...@pearwood.info wrote: It is certainly required when writing code that will behave the same in version 2 and 3 This is not true. An alternative is to put __metaclass__ = type at the top of your module to make all classes in your module

Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

2014-08-10 Thread Barry Warsaw
On Aug 10, 2014, at 11:51 AM, Alexander Belopolsky wrote: This is not true. An alternative is to put __metaclass__ = type at the top of your module to make all classes in your module new-style in python2. I like this much better, and it's what I do in my own bilingual code. It makes it much

Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

2014-08-10 Thread Steven D'Aprano
On Sun, Aug 10, 2014 at 11:51:51AM -0400, Alexander Belopolsky wrote: On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano st...@pearwood.info wrote: It is certainly required when writing code that will behave the same in version 2 and 3 This is not true. An alternative is to put

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

2014-08-10 Thread Glenn Linderman
On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote: Actually ... if I were a fan of the .join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate .join(string_iterable) in favor of .sum(string_iterable) (with the same efficient semantics).

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

2014-08-10 Thread R. David Murray
On Sun, 10 Aug 2014 13:12:26 -0700, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote: Actually ... if I were a fan of the .join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate

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

2014-08-10 Thread R. David Murray
On Sun, 10 Aug 2014 13:12:26 -0700, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote: Actually ... if I were a fan of the .join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate

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

2014-08-10 Thread Stephen J. Turnbull
Glenn Linderman writes: On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote: Actually ... if I were a fan of the .join() idiom, I'd seriously propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could deprecate .join(string_iterable) in favor of .sum(string_iterable) (with