kw support in function_key_generator

Issue #43 resolved
Andrey Petrov
created an issue

Any interest in adding kw support to function_key_generator using something like this?

Can send a PR if interested.

Comments (8)

  1. Michael Bayer repo owner

    i think i might have left this out after seeing how many bug reports there were in beaker regarding this. my hope was to leave it open ended so that it's not my problem. if you can figure out a way to add it to the API, e.g. in the docs "use key_gen = dogpile.foobar for this version", maybe that's OK.

  2. Andrey Petrov reporter

    So far I've been using this:

    I'll mess around with it some more, but the code is almost identical to function_key_generator. Maybe once I get some better internet in a few days, I'll search for the aforementioned beaker bugs.

    Looks like kw and varargs are going to be fun edgecases.

    (Edited this comment about a million times. Sorries.)

  3. Michael Bayer repo owner

    I do think that I want to do this. Not for for **kw or varargs yet; but for kw arguments that are named, i think definitely. They're not any different than positional args with default values. Send me a pullreq. Overall I find the whole cached function fn still a little troubling, when I actually had to use it the other day. There needs to be some way to process individual arguments into strings without having to write a "to_str" for the whole thing.

  4. Andrey Petrov reporter

    Ugh just found this notification email in my 8th page of my Gmail spam label. What was I doing reading my 8th page of spam emails? Good question.

    Anyways, you want the PR as-is in the gist? Might be a while before I can get around to writing tests and such. (Feel free to just grab it from the gist, if it's easier.)

  5. Morgan Fainberg

    @Andrey Petrov I took a stab at this with

    The key is that without the py3 semantic of using * and forcing arguments to be kwargs via the method/function def (or in py2, the positional package), there is a need to handle populating defaults and deconflicting the defaults when the arguments are passed positionally.

    I wasn't able to make it work in the short window I had with the multi_key_generator, but all of my tests (both synthetic in unit tests and direct use) seem to indicate this works. Ideally, this would make using the memoization decorators a little easier.

    The downside is that it [by very nature] has to mangle the cache keys since kwargs can happen in any order so this could break current cache-keys if someone was relying on them being stable even over DC upgrades.

  6. Michael Bayer repo owner

    Add a key-word-arg aware cache-key generator

    Add in a key-word-arg cache key generator that may be optionally used. This generator will generate a key that mirrors closely to the original key generator. The key difference is that it will flatten all arguments down to just the values ordered alphabetically based on the argument name. This order will be used to ensure that regardless of the order that the keys are passed (positional, key-word, or out-of-order key-word) the cache key ends up being the same.

    This was not made the default keygenerator to avoid reverse incompatibilities with developers that are relying on stable cache-key generation (e.g. storing data via the memcache-like interface to a non-volitile backend).

    Fixes: #43 Co-authored-by: Mike Bayer Change-Id: I86c9d5e9c611090d5a84d8a746486a0b6c80039a Pull-request:

    → <<cset 656df0ba9df3>>

  7. Log in to comment