Expand cycler() signature.

[WeatherGod]

Closes #12 . If you don't like the idea of breaking the API, we can easily add in support for a single pair of positional args, and keep just about everything else.

Btw, I didn't have time to look up how to display and reference multiple call signatures in numpydoc format, so it is probably "wrong".

[efiring]

"inner product" might not mean much to many docstring readers here. Maybe add something like, "All iterables are cycled simultaneously."

[WeatherGod]

On my way home, I realize a situation where we would want to keep the two argument form. Technically speaking, Cyclers can use any hashable as keys, but only certain kinds of strings can be keyword arguments. The two-argument form enables situations where the key can't be a keyword argument. We might also want to change the repr back to the two-argument form so that it will always be valid syntax.

[efiring]

True--but is there a significant cycler use case for keys that are not valid keywords?

[WeatherGod]

Maybe, maybe not (I haven't delved into my work project enough to determine
this). But if we want to exclude that, then we should perform checking on
the keys to make sure they are valid identifiers.

On Thu, Aug 20, 2015 at 7:37 PM, Eric Firing notifications@github.com
wrote:

True--but is there a significant cycler use case for keys that are not
valid keywords?

—
Reply to this email directly or view it on GitHub
#14 (comment).

[tacaswell]

Probably want to do a keep copy, I can in to some really weird bugs earlier due to underlying dict objects getting shared. I think this will play badly with the re-labeling functionality.

[WeatherGod]

Do you want me to use copy.deepcopy() everywhere, or just here?

[tacaswell]

Can we keep the 2 positional args as valid input as well? I see the advantage to this (and going **kwargs is way better than expecting an even number of args), but for reasons I can't articulate I like

cycler('c', 'rgb')

better than

cycler(c='rgb')

even though the first is is more typing.

One use-case for non-string keys is if someone is using Enums as keys. Another, possible too-cute, use-case is using functions as keys.

I am so-so to 👎 with breaking API. It has only been out for a month or two, but we have some external users (@danielballan is using this in our day job) and there is at least one plausible use case for non-string keys.

👍 on adding the implicit + for many kwargs.

👍 on changing the repr back to the cycler(a, b) version.

[danielballan]

Maybe I'm just used to the current API, but I also like two args, and I am
using cycles with nonstring objects as keys.
On Thu, Aug 20, 2015 at 10:51 PM Thomas A Caswell notifications@github.com
wrote:

Can we keep the 2 positional args as valid input as well? I see the
advantage to this (and going **kwargs is way better than expecting an
even number of args), but for reasons I can't articulate I like

cycler('c', 'rgb')

better than

cycler(c='rgb')

even though the first is is more typing.

One use-case for non-string keys is if someone is using Enums as keys.
Another, possible too-cute, use-case is using functions as keys.

I am so-so to [image: 👎] with breaking API. It has only been out for a
month or two, but we have some external users (@danielballan
https://github.com/danielballan is using this in our day job) and there
is at least one plausible use case for non-string keys.

[image: 👍] on adding the implicit + for many kwargs.

[image: 👍] on changing the repr back to the cycler(a, b) version.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[WeatherGod]

Ok, I brought back the 2-arg form of the call signature, and even modified some unit tests to use labels that can't be used as a keyword argument (which caught a couple things). Also updated the docs a bit per comments.

[tacaswell]

should have both of these tests 🐑

[tacaswell]

never mind

[tacaswell]

thanks @WeatherGod