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

kw support in function_key_generator #43

Closed
sqlalchemy-bot opened this issue Oct 4, 2013 · 9 comments
Closed

kw support in function_key_generator #43

sqlalchemy-bot opened this issue Oct 4, 2013 · 9 comments
Labels

Comments

@sqlalchemy-bot
Copy link

Migrated issue, originally created by Andrey Petrov (shazow)

Any interest in adding kw support to function_key_generator using something like this? http://stackoverflow.com/questions/10920180/is-there-a-pythonic-way-to-support-keyword-arguments-for-a-memoize-decorator-in/10921408#10921408

Can send a PR if interested.

@sqlalchemy-bot
Copy link
Author

Michael Bayer (zzzeek) wrote:

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.

@sqlalchemy-bot
Copy link
Author

Andrey Petrov (shazow) wrote:

So far I've been using this: https://gist.github.com/shazow/6838337

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.)

@sqlalchemy-bot
Copy link
Author

Michael Bayer (zzzeek) wrote:

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.

@sqlalchemy-bot
Copy link
Author

Andrey Petrov (shazow) wrote:

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.)

@sqlalchemy-bot
Copy link
Author

Michael Bayer (zzzeek) wrote:

not doing too much on DC right now, writing the tests is the hard part, ill let you know if i start doing them myself.

@sqlalchemy-bot
Copy link
Author

Morgan Fainberg () wrote:

@shazow I took a stab at this with https://bitbucket.org/zzzeek/dogpile.cache/pull-requests/46/add-a-key-word-arg-aware-cache-key/diff

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.

@sqlalchemy-bot
Copy link
Author

Andrey Petrov (shazow) wrote:

@morgan_fainberg Excellent, thanks for taking over this! :)

@sqlalchemy-bot
Copy link
Author

Michael Bayer (zzzeek) wrote:

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 mike_mp@zzzcomputing.com
Change-Id: I86c9d5e9c611090d5a84d8a746486a0b6c80039a
Pull-request: https://bitbucket.org/zzzeek/dogpile.cache/pull-requests/46

656df0b

@sqlalchemy-bot
Copy link
Author

Changes by Michael Bayer (zzzeek):

  • changed status to closed

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

No branches or pull requests

1 participant