[Python-Dev] RE: Python-Dev Digest, Vol 3, Issue 10

[Schneider, Michael]

Tana,

I have a conflict for the 10:30 meeting.

Can we get together at 2:00 this afternoon.  I'm sorry for the clash,
Mike

 
----------------------------------------------------------------
Michael Schneider
Senior Software Engineering Consultant
EDS PLM Solutions
 
"The Greatest Performance Improvement Is the transitioning from a non-working state to the working state"


-----Original Message-----
From: python-dev-request at python.org
[mailto:python-dev-request at python.org]
Sent: Sunday, October 05, 2003 12:02 PM
To: python-dev at python.org
Subject: Python-Dev Digest, Vol 3, Issue 10


Send Python-Dev mailing list submissions to
	python-dev at python.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
	python-dev-request at python.org

You can reach the person managing the list at
	python-dev-owner at python.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."


Today's Topics:

   1. RE: Efficient predicates for the standard library
      (Raymond Hettinger)
   2. Efficient predicates for the standard library (Raymond Hettinger)


----------------------------------------------------------------------

Message: 1
Date: Sun, 5 Oct 2003 11:46:29 -0400
From: "Raymond Hettinger" <python at rcn.com>
Subject: RE: [Python-Dev] Efficient predicates for the standard
	library
To: "'Christian Stork'" <cstork at ics.uci.edu>
Cc: python-dev at python.org
Message-ID: <000001c38b57$d7e91c20$e841fea9 at oemcomputer>
Content-Type: text/plain;	charset="us-ascii"


> Honestly, I assumed that 
>
>    x in iterable
>
> has a short-circuit implementation.  Why doesn't it?

It does.

The ifilter() version is faster only because it doesn't have to
continually return values to the 'in' iterator.  The speedup is a small
constant factor.




> Let me just give you the reasons (in no particular order) for my
> suggestion to include the `all' and `some/any' predicates:
> 
> 1. Efficiency
> Maybe I'm a bit naive here, but it seems to me that since these
> predicates involve tight inner loops they offer good potential for
> speedup, especially when used often and over many iterations.

You're guessing incorrectly.  The pure python versions use underlying
itertools which run at full C speed.  You cannot beat the ifilter()
version..

> 2. Readabilty
> If we offer universally-used predicates with succinct names which are
> available as part of the "batteries included" then that increases 
> readabilty of code a lot.

I put the code in the docs in a form so that people can cut and paste
the function definitions it as needed.  Then, they can use all(), any(),
or no() to their heart's content.  


> 4. It's *not* trivial!
> Contrary to what you imply it's not trivial for everybody to just
write
> efficient and well designed predicates with well-chosen names.  This
> discussion is the proof. :-)

Cut and paste is easy. 

 

Raymond




------------------------------

Message: 2
Date: Sun, 5 Oct 2003 11:49:28 -0400
From: "Raymond Hettinger" <python at rcn.com>
Subject: [Python-Dev] Efficient predicates for the standard library
To: <python-dev at python.org>
Message-ID: <000101c38b58$42d5da00$e841fea9 at oemcomputer>
Content-Type: text/plain;	charset="us-ascii"

> Honestly, I assumed that 
>
>    x in iterable
>
> has a short-circuit implementation.  Why doesn't it?

It does.

The ifilter() version is faster only because it doesn't have to
continually return values to the 'in' iterator.  The speedup is a small
constant factor.




> Let me just give you the reasons (in no particular order) for my
> suggestion to include the `all' and `some/any' predicates:
> 
> 1. Efficiency
> Maybe I'm a bit naive here, but it seems to me that since these
> predicates involve tight inner loops they offer good potential for
> speedup, especially when used often and over many iterations.

You're guessing incorrectly.  The pure python versions use underlying
itertools which loop at full C speed.  You cannot beat the ifilter()
version.


> 2. Readabilty
> If we offer universally-used predicates with succinct names which are
> available as part of the "batteries included" then that increases 
> readabilty of code a lot.

I put the code in the docs in a form so that people can cut and paste
the function definitions it as needed.  Then, they can use all(), any(),
or no() to their heart's content.  


> 4. It's *not* trivial!
> Contrary to what you imply it's not trivial for everybody to just
write
> efficient and well designed predicates with well-chosen names.  This
> discussion is the proof. :-)

Cut and paste is your friend. 

 

Raymond




------------------------------

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev


End of Python-Dev Digest, Vol 3, Issue 10
*****************************************