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.