The Hashable object was moved in python 3.3 and support for the old
location is dropped in python 3.10 the new location is available in
python 3.8 so we can just update this and it should work with both
python 3.8 and 3.11
https://docs.python.org/3.8/library/collections.html
Given code like the following
```
class Foo:
@process_cached
def bar(self):
pass
```
In Python 3.8 referencing `bar` would not call its `__get__` method.
```
x = Foo().bar
```
However in Python 3.11, making the same call would call the `__get__`
method, permanently replacing the underlying `process_cached` object
with the partial function that references it.
This meant that code to clear the cache would work in Python 3.8 but
would break in 3.11
```
Foo().bar.cache.clear() # Works in 3.8 but not in 3.11
```
In 3.11 this results in the following error:
```
E AttributeError: 'functools.partial' object has no attribute 'cache'
```
To make this compatible in both version, we just add the cache as an
accessible attribute on the partial we generate for our wrapped
function.
* Deprecates ModuleSystem can_execute_unsafe_code, get_python_lib_zip and cache properties
* Adds a new CacheService and SandboxService to provide the deprecated property
* Adds tests for the added CacheService and SandboxService
* Updates the ModuleSystemShim tests in Lms and Studio
- Updating Python Requirements
- Fix cache key generation to use class name and module
This was stringifying the class object directly, resulting in cache keys
like `:1:<class 'xblock_django.models.XBlockConfiguration'>.xblock_django.api.deprecated_xblocks`
which then cause breakage when Django 2.2.13 validates the keys.
Co-authored-by: edX requirements bot <testeng+edx-requirements-bot@edx.org>
Updating to the current highest number instead of making it the default
which is highest know by the language. This is beacuse when we update
between python versions if there is a new proctocol version, we don't
want that to cause cache thrashing as we try to load things from the
various caches. We can get into a situation where new machines pickle
things with a newer versions of the procotocl, put them in the cache and
then break older machines that don't know about the new protocol
version.
HIGHEST_PROTOCOL will cause it to change when we move from python 2 to 3
and this may cause issues as older machines try to read objects pickeld
with a version of the protocol they don't know.
During deploys, and if we have to roll back are two examples.
