ak.choose MUST be renamed, maybe ak.cross, too

NumPy has an np.choose function and it’s something that could conceivably be NEP18-overloaded someday. Awkward can’t have an ak.choose function that does something different, or we’d never be able to overload NumPy’s (and it would be confusing to users, anyway).

Perhaps the right name is “combinations”, since itertools.combinations is exactly what our function does. Moreover, the diagonal=True option should probably be “replacement” because itertools.combinations_with_replacement (too long of a name, in my opinion) is exactly what that option does.

On a similar note, perhaps ak.cross should become “product” because then we’d be consistently getting our names from itertools: itertools.product. I’m a little afraid that “product” would be confused with multiplication—in particular, ak.prod (so named because of np.prod).

Thoughts? I’m asking everyone who’s had opinions on Awkward naming before: @HDembinski, @henryiii, @nsmith-, @masonproffitt, @eduardo-rodrigues, @chrisburr, @lgray, @ianna, @lukasheinrich…

I need to pick a final name before I do a tutorial on April 8, which will definitely include combinatorics. At that point, the names would be “out in the wild” and much harder to change again.

[jpivarski]

How does everyone else feel if I make it ak.cartesian first with the option of possibly later adding ak.product? With ak.cartesian being first, this also means that all the documentation and tutorials will say ak.cartesian, leading users in that direction. There would also be some resistance against adding a synonym for the reason Lindsey described, and just because synonyms are hard to get rid of.

I personally preferred agreement with itertools, but I’m willing to go with majority opinion (as I was with the underscores between words and the 80-character width if the community is clear).

If I don’t hear a complaint, I’ll change ak.product to ak.cartesian. If there isn’t consensus, I will leave it as ak.product (because I get the deciding vote if the community’s opinion isn’t strongly one way).

[lgray]

I think ak.product is too close to ak.prod, in letter space and that makes them want to be close in concept space. If some one just types ‘product’ programming away they’re probably gonna expect multiplication first, if they’re coming from numpythonic background. It will make sense to itertools users, but that might not be the largest cross section of people this package encounters.

ak.cartesian at least has that first level of “what exactly do they mean by cartesian??”, and it’ll show up quickly when searching in the repository for functions.