Black 23.1.0 is released which, as the first release of the year,
introduces the 2023 stable style. This incorporates most of last year's
preview style.
https://github.com/psf/black/releases/tag/23.1.0
In these cases Black produces unexpected results, e.g.
def make_random_password(
self,
length=10,
allowed_chars='abcdefghjkmnpqrstuvwxyz' 'ABCDEFGHJKLMNPQRSTUVWXYZ' '23456789',
):
or
cursor.execute("""
SELECT ...
""",
[table name],
)
Thanks Carlton Gibson, Chris Jerdonek, David Smith, Keryn Knight,
Mariusz Felisiak, and Nick Pope for reviews and mentoring this
Google Summer of Code 2021 project.
The validate_key() function should be called after make_key() to ensure
that the validation is performed on the key that will actually be
stored in the cache.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Many of the cache operations make use of the default argument to the
.get() operation to determine whether the key was found in the cache.
The default value of the default argument is None, so this results in
these operations assuming that None is not stored in the cache when it
actually is. Adding a sentinel object solves this issue.
Unfortunately the unmaintained python-memcached library does not support
a default argument to .get(), so the previous behavior is preserved for
the deprecated MemcachedCache backend.
There are 8 cache backends to test and each test of touch() takes
~7s → ~56s. This seems excessive and it feels like we should be able
to reduce this significantly. time.sleep() accepts floating point
values and is guaranteed to sleep for at least the number of seconds
specified as of Python 3.5.
We do run the risk that there may be spurious test failures from this,
but that already seemed to be the case anyway.
The servers property can be overridden to allow memcached backends to
alter the server configuration prior to it being passed to instantiate
the client. This allows avoidance of documentation for per-backend
differences, e.g. stripping the 'unix:' prefix for pylibmc.
DatabaseCache._cull implementation could fail if no key was found to
perform a deletion in the table. This prevented the new cache key/value
from being correctly added.
This is the new contract since middleware refactoring in Django 1.10.
Co-authored-by: Carlton Gibson <carlton.gibson@noumenal.es>
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>