Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add missing asynchronous utility functions #30

Open
h2non opened this issue Dec 29, 2016 · 3 comments
Open

Add missing asynchronous utility functions #30

h2non opened this issue Dec 29, 2016 · 3 comments
Assignees
Milestone

Comments

@h2non
Copy link
Owner

h2non commented Dec 29, 2016

Ideally, porting the following functions to the asynchronous world:

  • itertools.chain
  • itertools.chain.from_iterable
  • functools.partial_method
  • itertools.takewhile
  • itertools.compress
  • itertools.startmap
  • take
  • itertools.tee
@h2non h2non added this to the 0.2.0 milestone Dec 29, 2016
@h2non h2non self-assigned this Dec 29, 2016
@h2non
Copy link
Owner Author

h2non commented Dec 29, 2016

See: http://fitzgen.github.io/wu.js/

@JamesMcGuigan
Copy link

JamesMcGuigan commented Dec 29, 2017

I'd like to suggest functions similar to bluebird.js::props(), and pydash::map_values() for working with dictionaries rather than lists.

This allows computing a series of async functions whilst retaining the original mapping between input and output values, and is also a convenient way to load multiple named async variables before the main synchronous code block.

output = await paco.map_dict({
   "A.txt": async_read_file("A.txt"),
   "B.txt": async_read_file("B.txt")
})
assert output == { "A.txt": "contents A.txt", "A.txt": "contents B.txt" }
output = await paco.map_dict({
   "A.txt": "A.txt",
   "B.txt": "B.txt"
}, async_read_file)
assert output == { "A.txt": "contents A.txt", "B.txt": "contents B.txt" }
output = await paco.map_dict(["A.txt", "B.txt"], async_read_file)
assert output == { "A.txt": "contents A.txt", "B.txt": "contents B.txt" }

@h2non
Copy link
Owner Author

h2non commented Dec 29, 2017

Oh, yeah, that's relatively common if you came from a JS background, but not sure if Python devs are going to appreciate this. At the end I feel it's pretty much logic sugar for convenience and laziness.

If any, I would only bet supporting interface and behavior of example 1 and 2, but no more. I prefer a concrete, predictable interface instead of a too overloaded interface with too many vectors.

This can be easily implemented in multiple ways, such as using the async reducer.
PR are welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants