[Python-Dev] Adding any() and all()
John Williams
jrw at pobox.com
Fri Mar 11 21:42:46 CET 2005
Jim Jewett wrote:
> Guido van Rossum:
>>[Why any() and all() shouldn't need to be imported.]
>
> Is that so bad?
>
> If you plan to use them often, then
>
> from itertools import any, every
>
> is reasonable. If you only use them once and weren't expecting it
> (and want your imports at the top) ... well how awful is it to have
> an extra line or two in your code?
The problem with this approach is that any() and all() are so
fundamental* that you should just use them without thinking about it,
just as when you use "+" to conctenate strings, you don't have to stop
and think to yourself, "Ah, this program needs to be able to manipulate
strings. I'd better make sure string operations as available in this
module." Thinking such thoughts takes you away from thinking about the
problem you're trying to solve by manipulating strings.
Likewise, programmers solve a lot of problems with boolean expressions,
and it seems silly to require a special declaration just to make the
full complement of boolean operations available. I can think of three
ways of coping with any() and all() being in a module:
First, I could just not use them. In that case all the effort here is
wasted, and my code becomes less readable than it would have been
otherwise. This is the approach I usually take with modules like
"operator", where I can just as easily write a lambda expression (for
now at least).
Second, I could break my concentration to think about import statements
every time I have a use for these particular functions.
Third, I could import them at the top of every module. Since one of the
distinguishing features of Python in a lack of gratuitous boilerplate
code everywhere, I would find it very sad to add even a little bit.
So while putting any() and all() into a module isn't that bad in itself,
it seems like the start of a slippery slope that has Python at the top
and C++ at the bottom.
-- jw
*I appreciate the irony of calling something "fundamental" when we've
all gotten by just fine without it for many years--I'm trying to think
from the perspective of someone used to dealing with a later (and
hopefully better) version of Python.
More information about the Python-Dev
mailing list