[HN Gopher] More Itertools
___________________________________________________________________
More Itertools
Author : stereoabuse
Score : 106 points
Date : 2024-05-27 18:03 UTC (4 hours ago)
(HTM) web link (more-itertools.readthedocs.io)
(TXT) w3m dump (more-itertools.readthedocs.io)
| hiAndrewQuinn wrote:
| itertools is a gem and has been since the 2.7 days. Glad to see
| people waking up to its powerful abstractions.
| zokier wrote:
| itertools and more-itertools are two different libs
| wenc wrote:
| itertools (iterators) and collections (data structures) are
| both underrated modules in stdlib.
| drexlspivey wrote:
| And are both written by Raymond Hettinger
| jauntywundrkind wrote:
| Shout out to JavaScript massively delaying
| https://github.com/tc39/proposal-async-iterator-helpers in the
| 23rd hour.
|
| The proposal seemed very close to getting shipped alongside
| https://github.com/tc39/proposal-iterator-helpers 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 & keep
| iterating & churning for better.
|
| I feel like a lot of the easy visible mood on the web (against
| the web) is that there's too much, that stuff is just piled in.
| But I see a lot of caring & deliberation & trying to get shit
| right & good. Sometimes that too can be maddening, but ultimately
| with the web there aren't really re-do-es & the deliberation is
| good.
| jacobolus wrote:
| You can implement quite a lot of Python's itertools in
| Javascript without too much trouble. For instance,
| https://observablehq.com/@jrus/itertools
|
| Disclaimer: this code was written several years ago with few
| downstream users, not all of these are super high performing,
| and they have not been super extensively tested.
| elijahbenizzy wrote:
| Nice! These can make code a _ton_ 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.
| jdeaton wrote:
| it has always annoyed me that flatten isn't already part of
| itertools
| isoprophlex wrote:
| Amen. For a language that gloats on about "flat is better than
| nested" you have to jump to too many hoops to get your stuff
| flattened.
| jdeaton wrote:
| ok itertools has chain.from_iterable but that name is hard to
| remember
| Myrmornis wrote:
| Yes, I think it might have been a slight design mistake to
| make the variadic version the default. I've only very rarely
| used it, whereas I use chain.from_iterable a lot.
| samsquire wrote:
| This is really helpful. Thank you.
|
| 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.
| jszymborski wrote:
| I've implemented the "chunked" iterator a million times. Glad to
| see I can just import this next time.
| fastily wrote:
| Since python 3.12, builtin itertools now includes a batched
| method
| https://docs.python.org/3/library/itertools.html#itertools.b...
| jszymborski wrote:
| Even better! Thanks :)
| slig wrote:
| What's the process for adding these to the Python's stdlib? Is it
| even possible to adopt a whole library such as this one?
| loloquwowndueo wrote:
| Yes. Unittest.mock used to be a third-party library.
|
| For an idea of the process followed, look up PEP417 (Python
| Enhancement Proposal.
| cosmic_quanta wrote:
| It must be possible, because the 'dataclasses' library used to
| be third-party.
| ericvsmith wrote:
| That's not actually true. While dataclasses to most of its
| inspiration from attrs, there are many features of attrs that
| were deliberately not implemented in dataclasses, just so it
| could "fit" in the stdlib.
|
| Or maybe you mean the backport of dataclasses to 3.6 that is
| available on PyPI? That actually came after dataclasses was
| added to 3.7.
|
| Source: I wrote dataclasses.
| PLenz wrote:
| This library is my python productivity secret weapon. So many
| things I've needed to impliment in the past is now just chaining
| functions in itertools, functions, and this
| screye wrote:
| This looks great.
|
| Usally, I'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.
|
| How should I reason about the tradeoff of using something like
| this vs pandas/numpy ? Esp. with Numpy 2.0 supporting the string
| dtype.
| almostgotcaught wrote:
| > Usally, I'd cast my arrays into a pandas DF
|
| I promise I mean no offense by this but this is so comically
| absurd. Like you know it's not a cast right? Ie That you're
| _constructing_ pandas dataframes.
|
| > How should I reason about the tradeoff of using something
| like this vs pandas/numpy ?
|
| For small sizes, operations on native types will be faster than
| the construction of complex objects.
___________________________________________________________________
(page generated 2024-05-27 23:00 UTC)