More Itertools

I've implemented the "chunked" iterator a million times. Glad to see I can just import this next time.

If you like this sort of things, why not check out “boltons” - things that should be built-in in Python?<p><a href="https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;boltons&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;boltons&#x2F;</a>

My favorite function here is more_itertools.one. Especially in something like a unit test, where ValueErrors from unexpected conditions are desirable, we can use it to turn code like<p><pre><code> results = list(get_some_stuff(...)) assert len(results) = 1 result = results[0] </code></pre> into<p><pre><code> result = one(get_some_stuff(...)) </code></pre> I guess you could also use tuple-unpacking:<p><pre><code> result, = get_some_stuff(...) </code></pre> But the syntax is awkward to unpack a single item. Doesn&#x27;t that trailing comma just look implausible? (Also I&#x27;ve worked with type-checkers that will complain when a tuple-unpacking could potentially fail, while one has a clear type signatures Iterable[T] -&gt; T.)

Shout out to JavaScript massively delaying <a href="https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-async-iterator-helpers">https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-async-iterator-helpers</a> in the 23rd hour.<p>The proposal seemed very close to getting shipped alongside <a href="https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-iterator-helpers">https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-iterator-helpers</a> while basically accepting many of the constraints of current async iteration (one at a time consumption). But the folks really accepted that concurrency needs had evolved, decided to hold back &amp; keep iterating &amp; churning for better.<p>I feel like a lot of the easy visible mood on the web (against the web) is that there&#x27;s too much, that stuff is just piled in. But I see a lot of caring &amp; deliberation &amp; trying to get shit right &amp; good. Sometimes that too can be maddening, but ultimately with the web there aren&#x27;t really re-do-es &amp; the deliberation is good.

This library is my python productivity secret weapon. So many things I&#x27;ve needed to impliment in the past is now just chaining functions in itertools, functions, and this

Nice! These can make code a <i>ton</i> simpler. Also no python dependencies, which is a requirement for me adopting. Would love to see this brought into the standard lib at some point.

What&#x27;s the process for adding these to the Python&#x27;s stdlib? Is it even possible to adopt a whole library such as this one?

it has always annoyed me that flatten isn&#x27;t already part of itertools

I was frustrated by the itertools design, because the chain of operations are going from the inside out. Iterative design in Scala is much friendly to me<p><a href="https:&#x2F;&#x2F;pybites.circle.so&#x2F;c&#x2F;python-discussion&#x2F;functional-composition-in-python" rel="nofollow">https:&#x2F;&#x2F;pybites.circle.so&#x2F;c&#x2F;python-discussion&#x2F;functional-com...</a>

itertools is a gem and has been since the 2.7 days. Glad to see people waking up to its powerful abstractions.

This looks great.<p>Usally, I&#x27;d cast my arrays into a pandas DF and then use the equivalent dataframe operations. To me, pandas and numpy might as well be part of the python stdlib.<p>How should I reason about the tradeoff of using something like this vs pandas&#x2F;numpy ? Esp. with Numpy 2.0 supporting the string dtype.

This is really helpful. Thank you.<p>I would like to see some kind of query AST for this stuff in a query engine for semantics that its ops can be fused together for efficiency. For example, like a Clojure transducer.