[Raymond] > > To be considered as a possible itertool, an ideal candidate should: [Alex] > Very nice set of specs! Thanks! > Which reminds me: why don't we have take(n, it) > and drop(n, it) there? I find myself rewriting those quite often. Yeah, me too. When you write them, do they return lists or iterators? For me, take() has been most useful in list form, but my point of view is biased because I use it to experiment with itertool suggestions and need an easy way manifest a portion of a potentially infinite iterator. My misgivings about drop() and take() are, firstly, that they are expressible in-terms of islice() so they don't really add any new capability. Secondly, the number of tools needs to be kept to a minimum -- already, the number of tools is large enough to complicate the task of figuring out how to use them in combination -- the examples page in the docs is intended, in part, to record the best discoveries so they won't have to be continually re-invented. Raymond Hettinger P.S. Itertool tip for the day: to generate a stream of random numbers, write: stapmap(random.random, repeat(()))
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