Guido van Rossum:
Whether to segregate these into a separate module: they are really a very small amount of syntactic sugat, and I expect that in most cases, instead of importing that module (which totally makes me lose my context while editing) I would probably just write the extra line that it takes to get the same effect with an explicit for loop and if statement.
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? These aren't *really* replacing map/filter/reduce because you're adding the new functions now, but the old-function removal is waiting until (forever?) A compromise (which may not be worth doing) would be to put them in another module, and then import them into __builtins__ if desired. map/filter/reduce could be moved out (but reimported for at least 2.5) in the same way, which would make their inclusion look more like "standard policy" than "part of the language". [And yes, I know that itertools might be the "wrong" module; I just don't remember the name of the module for iteration-related tools that happen to return something other than an iterator.] -jJ
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.
Jim Jewett wrote:
Guido van Rossum:
Whether to segregate these into a separate module: they are really a very small amount of syntactic sugat, and I expect that in most cases, instead of importing that module (which totally makes me lose my context while editing) I would probably just write the extra line that it takes to get the same effect with an explicit for loop and if statement.
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?
Basically the question (at least in my mind) when it comes to built-ins is whether the usage is so basic and fundamental that sticking them in a module is done more for rigid organization than for convenience. Personally, I think any() and all() meet this requirement. With their ties to basic boolean testing they should be built into the language and not just a part of the stdlib. If I am banging something out at a interpreter prompt I will want these functions easily accessible and I won't think of them as something to import. This probably comes off as wishy-washy, but it is just what my mind is spitting out at the moment. They also have the feeling as something that could be useful as a syntax (although I am just suggesting syntactic support!). Which could be an even better way to measure whether something should be a built-in. Would the function be useful as a syntactic addition to the language, but just can't quite reach the need of a new keyword? Once again any() and all() feel like that to me.
These aren't *really* replacing map/filter/reduce because you're adding the new functions now, but the old-function removal is waiting until (forever?)
Even if Python 3000 comes out a while from now, why wait? Two more is not that much. Besides, it isn't like we are adding functions as some crazy rate. And Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) comes out. So at worst you only have to worry about 5 more releases to worry. =) -Brett
participants (4)
-
Barry Warsaw -
Brett C. -
Jim Jewett -
John Williams