Re: #11675:Pyblic+Memcache changes, Draft #1

What I"m doing now (returning None) is already fairly magical. The problem is that timeout=0 (or less) is what pylibmc sets as "never expire," so I can't think of a good way to--by only modifying what timeout is passed via _get_memcache_timeout--mimic the behavior of python-memcached -Jacob On

Re: RFC #9964 - fix "missing" db commits by forcing managed transactions to close

Hi all, This is just to let you know that, assuming interested parties have been notified, I'm taking the discussion back to the bug where it belongs (and patches can be added). Thanks, Shai. -- You received this message because you are subscribed to the Google Groups "Django

Re: #11675:Pyblic+Memcache changes, Draft #1

Hi Jacob, On Thu, Dec 2, 2010 at 8:05 AM, Jacob Burch wrote: > > The problem is I can't think of a good way to force instant-expiring > sets in pylibmc. The only way to fake the response is to alter the > actual return value. 0 and all negative numbers, in pylibmc, set for

CACHE_MIDDLEWARE_ANONYMOUS_ONLY should be removed

In the documentation, CACHE_MIDDLEWARE_ANONYMOUS_ONLY is promoted as "a simple and effective way of disabling caching for any user-specific pages." This may have been the case if user-specific requests didn't use to have the Vary: Cookie header added on automatically or the cache middleware didn't

Re: #11675:Pyblic+Memcache changes, Draft #1

>  * The timeout handling code should be abstracted behind > _get_memcache_timeout(). That utility already exists to ensure the > eccentricities of memcached timeout handling are supported, and I > can't see an obvious reason why we can't put this check in there too. > The problem is I can't

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 05:05 PM, Łukasz Rekucki wrote: from django.conf import settings def without_localization(view): @wraps(view): def decorated(*args, **kwargs): # NOTE: I'm assuming this will actually have any effect - settings caching is a different issue old_value,

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 1 December 2010 14:37, Ivan Sagalaev wrote: > On 12/01/2010 04:26 PM, Łukasz Rekucki wrote: >> >> What about view decorators? >> >> I don't want to invent use cases here, but if I right now have a view >> decorator that on it's way out changes something that could

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 04:26 PM, Łukasz Rekucki wrote: What about view decorators? I don't want to invent use cases here, but if I right now have a view decorator that on it's way out changes something that could alter how a template is rendered (like current language, some settings or the database

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 1 December 2010 13:51, Ivan Sagalaev wrote: > On 12/01/2010 02:52 PM, Łukasz Rekucki wrote: >> >> Lots of people find render_to_response so verbose, that they are using >> direct_to_template() view instead. Django 1.3 deprecates that one, so >> it would be fair to

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 02:52 PM, Łukasz Rekucki wrote: Lots of people find render_to_response so verbose, that they are using direct_to_template() view instead. Django 1.3 deprecates that one, so it would be fair to offer those people a replacement. Forcing them at the same time into the world of lazy

Re: #11675:Pyblic+Memcache changes, Draft #1

On Tue, Nov 30, 2010 at 10:31 AM, Jacob Burch wrote: > History: http://code.djangoproject.com/wiki/PylibmcSupport > Draft: https://gist.github.com/91de59e53f7f36f461ec > > Caveats/Notes: > > A) This is only the memcache.py file, changes to conf/global_settings > and

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 1 December 2010 11:41, burc...@gmail.com wrote: > Hi Russell, > > On Wed, Dec 1, 2010 at 4:03 PM, Russell Keith-Magee > wrote: >> On Wed, Dec 1, 2010 at 3:55 PM, Mikhail Korobov >> wrote: >>> Just for the record: I'm with

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 01:03 PM, Russell Keith-Magee wrote: I'd argue it doesn't simplify anything. It saves you a grand total of 10 characters (plus a couple more on import), but at the cost of the added complexity of having two ways of doing *exactly* the same thing. There is also a loss of

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

Hi Russell, On Wed, Dec 1, 2010 at 4:03 PM, Russell Keith-Magee wrote: > On Wed, Dec 1, 2010 at 3:55 PM, Mikhail Korobov > wrote: >> Just for the record: I'm with Ivan here and think that >> >> from django.template.response import

Re: Pluggable encryption for django auth (design proposal)

On Wed, Dec 1, 2010 at 2:30 AM, Christopher Petrilli wrote: > On Tue, Nov 30, 2010 at 4:22 AM, Tom Evans wrote: > >> First comment is that Django already has a pluggable authentication >> stack, which already allows for this - simply define a new

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On Wed, Dec 1, 2010 at 3:55 PM, Mikhail Korobov wrote: > Just for the record: I'm with Ivan here and think that > > from django.template.response import TemplateResponse > def my_view(request): >    return TemplateResponse(request, 'foo.html') > > is worse than > > from