| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Add integration tests to reproduce the issue and add an argument to
_fetch_cmd to skip the key prefix logic as needed.
Closes #430
|
| | |
|
| |
|
|
| |
See https://github.com/pinterest/pymemcache/issues/396 for more details
|
| |
|
|
| |
https://black.readthedocs.io/en/stable/index.html
|
| |
|
|
|
| |
* future was needed for some python 2 specific tests
* use mock from unittest.mock instead of the 3rd party mock library
|
| |
|
|
|
|
|
| |
Now that we don't require Python 2 support no need for six.
Code upgraded with pyupgrade and manual fixes to remove remaining six
usage.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For consideration for v3.0.0
'cas' is documented as needing to be an int or bytestring of the digits
0-9. However, this is not actually enforced and it is possible to pass a
value to pymemcache which doesn't conform to these rules. In fact, you
can do weird things like `cas=b'noreply'` and potentially trigger
"unexpected" behavior.
To go along with validating int inputs, validate cas inputs. However,
these are not necessarily integers. Instead, if an int or string is
given, it will be encoded as a bytestring. But in order to validate the
value given, it is checked against isdigit() .
(NB: You could also use `int(cas)` for very similar checking.)
Rationale for allowing non-integer inputs to cas is not obvious.
Presumably it allows callers using `gets()` to pass the `cas` value they
get back into a `cas` command without issue. But it may be debatable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Change serialization interface to be an object
Rather than passing separate serialization and deserialization methods
to a pymemcache client, pass an object implementing a very simple
two-method interface.
This is a rather significant breaking change and should be part of an
x.0.0 major release.
Resolves #56
As suggested in that issue, this is a cleaner interface, as there's no
sensible context in which you would provide only one of these two
methods and it should therefore be thought of as a
serialization/deserialization protocol.
Also adds a note to the documentation's Best Practices list that you
should use the built-in serializer object unless you have a reason to do
otherwise.
* Support "de/serializer" in addition to "serde"
In order to support older client usage in addition to the new
serialization object (protocol), restore the "serializer" and
"deserializer" arguments to the Client classes.
These are marked as deprecated and will be automatically wrapped into a
small "serde" object.
In order to make the various object names more distinguishable and more
informative, the built-in default serializer is now called
"python_memcache_pickle_serde"
Additionally, default client.serde to a "no-op serializer".
This object does no transforms on the data. By putting this in place, we
can skip some conditionals in the code around presence or absence of a
serializer and therefore simplify internally (at the cost of an extra,
unnecessary, functional call in some cases).
It also simplifies logic around the handling of flags because we are now
*guaranteed* the presence of a serializer object which returns some
flags. i.e. "default flags" are no longer the responsibility of the
various serializer usage sites.
This is done carefully to ensure that passing a `serializer` without a
`deserializer` is respected.
|
| |
|
|
|
|
|
|
| |
It's unsafe to use the max pickle version when you are switching between
versions of python with different max versions.
Add a new function get_python_memcache_serializer that
returns a python_memcache_serializer with any pickle version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously python2 code using python-future to backport the py3 bytes
behavior would trigger the following exception:
code:
from builtins import bytes as newbytes
from pymemcache.client.base import Client
client = Client(('localhost', 11211))
client.set(newbytes('key'), 'value')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 297, in set
return self._store_cmd(b'set', key, expire, noreply, value)
File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 770, in _store_cmd
key = self.check_key(key)
File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 251, in check_key
key_prefix=self.key_prefix)
File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 91, in _check_key
key = key.encode('ascii')
File "/usr/local/lib/python2.7/site-packages/future/types/newbytes.py", line 381, in __getattribute__
raise AttributeError("encode method has been disabled in newbytes")
AttributeError: encode method has been disabled in newbytes
Add a test case for this and fix.
|
| | |
|
| |
|
|
|
|
|
| |
- A string (will vary on Python version)
- Another unicode string
- A list (pickled)
- A defaultdict (pickled)
|
| |
|
|
| |
Currently this will fail with unicode strings on Python 3, as the pymemcache client will return a byte string - but the deserializer doesn't change it back to a unicode string.
|
| | |
|
| |
|
|
|
|
| |
memcached's ASCII protocol supports unicode keys, so lets support them
as well. Since using unicode keys for memcache is uncommon and to
preserve the previous behavior disable support by default.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
