Комментарии 13
НЛО прилетело и опубликовало эту надпись здесь
Интересная штучка. Вообще, Twisted — это та еще цаца.
Может, покажете еще и реализацию Entry?
Может, покажете еще и реализацию Entry?
Мне не совмем понятно, зачем вы сделали
Очень режет глаз не указывание четких зависимостей в классах. Сейчас поясню. У вас
Преимущество на лицо — когда надо заменить только вид кэша, просто создаем новый сабкласс или передаем другой кэш. К сожалению, даже в стандартной библиотеке такой подход редко встречается.
Жизненный пример: в модуле
Чем-то этот принцип напоминает inversion of control, только здесь я делаю упор просто на указание всех явных зависимостей класса, а не на их инициализацию.
Cache синглтоном? Можно же было просто создавать его инстанс и передавать его MemcacheProtocol. В реальности это упрощает связи в программе. Да и потом, представьте, что вам потребуется заменить Cache на обычный dict. Сейчас это очень сложно, а с инстансом можно обойтись сабклассом: class DictCache(dict): ...Очень режет глаз не указывание четких зависимостей в классах. Сейчас поясню. У вас
Cache hard-coded в MemcacheProtocol. А хотелось бы видеть нечто подобное:
class MemcacheProtocol(LineOnlyReceiver):
cache = Cache
# либо
class MemcacheProtocol(LineOnlyReceiver):
def __init__(self, cache, ...):
pass
Преимущество на лицо — когда надо заменить только вид кэша, просто создаем новый сабкласс или передаем другой кэш. К сожалению, даже в стандартной библиотеке такой подход редко встречается.
Жизненный пример: в модуле
weakref есть WeakKeyDictionary. Когда потребовалось использовать свой конструктор для создания слабых связей, пришлось переписать полностью весь класс. А хотелось бы так:
class MyWeakDict(WeakKeyDictionary):
weakref_factory = MyWeakref
Чем-то этот принцип напоминает inversion of control, только здесь я делаю упор просто на указание всех явных зависимостей класса, а не на их инициализацию.
Большое спасибо! Я это обязательно кстати поменяю.
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
Закоммитил на github изменения, еще раз спасибо за очень дельное замечание. Действительно очень часто встречается ситуация, когда хочется что-то слегка подменить в поведении используемой библиотеки, а потом приходится тащить за собой ее исправленный код, из-за того, что встроенной возможности не было, и пришлось библиотеку править.
А не поясните еще раз, зачем это? Академический интерес или что-то еще? Да, и у memcached фишка в распределенности, с этим тут как?
Извините, я видимо не в теме, но про распределённость у memcached ничего не слышал. Из wikipedia:
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
Клиентская библиотека используя ключ данных вычисляет хэш и использует его для выбора соответствующего сервера. Ситуация сбоя сервера трактуется как промах кэша, что позволяет повышать отказоустойчивость комплекса за счет наращивания количества memcached серверов и возможности производить их горячую замену.
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
Распределенность реализуется не memcached, а его библиотеками — клиентами. Такими как libmemcached.
Зачем это, если у twisted уже есть реализация протокола memcached python.net/crew/mwh/apidocs/twisted.protocols.memcache.MemCacheProtocol.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Twisted в действии — memcache на python