41–50 of 51 posts
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 results = list(get_some_stuff(...)) assert len(results) = 1 result = results[0] into result = one(get_some_stuff(...)) I guess you could also use tuple-unpacking: result, = get_some_stuff(...) But the syntax is awkward to unpack a single…
result, _* = iterable()
Earlier quoted context omitted.
It must be possible, because the 'dataclasses' library used to be third-party.
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.
Earlier quoted context omitted.
Also, my grief with DF is they aren't typed (typing module) by column. Maybe that's changed though? It's been a while. The only way to understand what's going on with DF code is to step it in a debugger. I know they can be much faster, but man you pay a maintainability price!
This is incorrect: each column in a pandas DFs can have a separate type (what you're asking for is compatibility with Python's type-hinting on a per-column basis, though, which is different), and you can debug the code without needing a debugger: I use pandas regularly and I've never needed to use a debugger on pandas. (Sure, it's easy to write obfuscated pandas, and it sometimes has version-specific bugs or deprecat…
I don't have anything I can show because the stuff I was working on was commercial and I don't code Pandas for fun at home ;)
The code I was maintaining / updating had long pipelines, had lots of folding, and would drift in and out of numpy quite a bit.
Part of the issue was my unfamiliarity with Pandas, for sure. But if I just picked a random function in the code, I would have no idea as to the shape of the data flowing in and out, without reading up and down the callstack to see what columns are in play.
Breakpoint and then look at the data, every time!
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 results = list(get_some_stuff(...)) assert len(results) = 1 result = results[0] into result = one(get_some_stuff(...)) I guess you could also use tuple-unpacking: result, = get_some_stuff(...) But the syntax is awkward to unpack a single…
Do tuple unpacking like this result, _* = iterable()
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…
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.
Here is an update that should be much easier to convert to JS:
def tee(iterable, n=2):
iterator = iter(iterable)
shared_link = [None, None]
return tuple(_tee(iterator, shared_link) for _ in range(n))
def _tee(iterator, link):
try:
while True:
if link[1] is None:
link[0] = next(iterator)
link[1] = [None, None]
value, link = link
yield value
except StopIteration:
returnEarlier quoted context omitted.
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.
Your nice work on the JS itertools port has a todo for a "better tee". This was my fault because the old "rough equivalent" code in the Python docs was too obscure and didn't provide a good emulation. Here is an update that should be much easier to convert to JS: def tee(iterable, n=2): iterator = iter(iterable) shared_link = [None, None] return tuple(_tee(iterator, shared_link) for _ in range(n)) def _tee(iterator,…
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?
Earlier quoted context omitted.
Is np.flatten not a workable option in some cases?
Is np part of the itertools?