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
*****************************************
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4