Trey Long
Trey Long
It's great there is a workaround, but why do this? It should at *LEAST* be a no-op, and at most it should re-implement the timeout.
I saw this using chi router's logging middleware. Here is a pretty minimal example. ``` go package main import ( "http" "github.com/pressly/chi" "github.com/pressly/chi/middleware" ) func main() { r := chi.NewRouter()...
This would be tremendous. Is there work planned for this? If you were able to give some pointers on what needs doing perhaps we could open a PR for this...
Same same, completely non-functional as far as I can tell and no debug output of any kind.
~~Switching pylibmc to `binary=True` also seems to avoid this issue. I assume since the key content no longer matters.~~
The exception is: ``` _pylibmc.SocketCreateError _pylibmc.SocketCreateError: error 11 from memcached_set_multi: SUCCESS ``` If you switch to `python-memcached` you get a more reasonable error. Something along the lines of "`Cannot use...
That one is easy. `_memoize_make_cache_key` calls `_memoize_version` and that function interacts with the cache directly.
I've got a unit test for you... Just working on PR. It will only work if you use `memcached` as the `CACHE_TYPE`
The issue is that some objects have a `__repr__` that have spaces for debug/readability and also to make sure that `memoize()` is unique enough. These spaces cause the cache to...