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 django.shortcuts import render > def my_view(request): > return render(request, 'foo.html') > > I think that the cases where user should prefer 'render' returning > HttpResponse over 'render' returning TemplateResponse are rare so the > API by itself should suggest TemplateResponse. TemplateResponse is > more flexible and can provide a performance benefit (the template > rendering can be prevented in some cases). > > I don't see much value in adding 'render' shortcut that just use > RequestContext after TemplateResponse is introduced - one can still > use render_to_response if TemplateResponse is undesired and one > shouldn't use such 'render' in other cases. > > 'render' as alias for TemplateResponse seems fine for me: it is a > shortcut and it adds value by simplifying the API. 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 explicitness -- there's no doubting what TemplateResponse will return. On the other hand, there *is* value in adding a render() shortcut -- because there will be a subset of cases where a TemplateResponse isn't needed, but a HttpResponse with a RequestContext is. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 auth
>> backend that tests the password in the manner you wish.
>
> My understanding of the pluggable authentication system is that it's
> for situations where you need a totally different authentication
> mechanism, such as LDAP. Simply replacing the crypto mechanism for the
> default authentication system should not require developing a lot of
> pieces. It is something that needs to be upgraded on an ongoing basis
> for everyone. It's simply best practices.
It doesn't 'require developing a lot of pieces'. Have you even tried
implementing this in the current stack?
At the moment, a typical setup has AUTHENTICATION_BACKENDS set to
('django.contrib.auth.backends.ModelBackend',). Changing how passwords
are tested simply requires a different backend, typically derived from
ModelBackend, that overrides the authenticate method.
Is that a lot of pieces, or one small one?
>
> The federal government already forbids use of SHA-1 after 2010.
>
>> It doesn't allow for this with the default authenticator, but it is
>> doable. I have a django project with >100k users, and none of them
>> have a sha1 hash as their password.
>
> I won't comment on the wisdom of this, but I'd not use it as an
> example of why we don't need to provide flexibility to improve
> security.
>
> Chris
Wow, that's a thing to say. Your federal government forbids SHA-1, I
don't use SHA-1, but you "won't comment on the wisdom of this"? Let's
try to keep it civil without casting FUD and aspersions around, eh.
We already have flexibility to implement security in any manner that
you can think of. I'm looking for the argument that says 'This current
flexibility is not enough, and we need to re-architecture', and I
don't think that has been made.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
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 TemplateResponse >> def my_view(request): >> return TemplateResponse(request, 'foo.html') >> >> is worse than >> >> from django.shortcuts import render >> def my_view(request): >> return render(request, 'foo.html') >> >> I think that the cases where user should prefer 'render' returning >> HttpResponse over 'render' returning TemplateResponse are rare so the >> API by itself should suggest TemplateResponse. TemplateResponse is >> more flexible and can provide a performance benefit (the template >> rendering can be prevented in some cases). >> >> I don't see much value in adding 'render' shortcut that just use >> RequestContext after TemplateResponse is introduced - one can still >> use render_to_response if TemplateResponse is undesired and one >> shouldn't use such 'render' in other cases. >> >> 'render' as alias for TemplateResponse seems fine for me: it is a >> shortcut and it adds value by simplifying the API. > > 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 explicitness -- there's no doubting what > TemplateResponse will return. > > On the other hand, there *is* value in adding a render() shortcut -- > because there will be a subset of cases where a TemplateResponse isn't > needed, but a HttpResponse with a RequestContext is. > > Yours, > Russ Magee %-) If I got it right, you want to make default shortcut render() that would not use TemplateResponse. But then how one will alter 3rd-party rendered responses in middleware? I suggest people use TemplateResponse by default, and making render = TemplateResponse just to be sure of this, and render_to_response is "just 10 more characters" or a line to make your own render that uses RequestContext. I think, talking about "saving few characters" is not constructive. So I'm talking about good architecture and code beauty. I think your will to make render=render_to_response with RequestContext means you want people to use render_to_response by default. But I'd like if we have a way to make template creators to use TemplateResponse by default. That would encourage better view reusing in django. And that means we would have render=TemplateResponse. However, render_to_response has another feature -- ability to use custom context, and the one real use case is using Context for Http500 when you can't rely on anything. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 explicitness -- there's no doubting what TemplateResponse will return. On the other hand, there *is* value in adding a render() shortcut -- because there will be a subset of cases where a TemplateResponse isn't needed, but a HttpResponse with a RequestContext is. I'd argue :-) that these cases would be quite rare (in fact I can't even imagine one). And it'd be pity to use such delicious shortcut as 'render()' for the rare case. Especially if we would recommend it as the default way of returning responses from users' views because then almost nobody would use TemplateResponse thus defeating its value altogether. I understand why you don't like `render = TemplateResponse` but I think it's a minimal disturbance given the value that it provides. Anyway I believe everyone here has expressed their points of view completely so now it's a judgement call for a committer. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 Ivan here and think that >>> >>> from django.template.response import TemplateResponse >>> def my_view(request): >>> return TemplateResponse(request, 'foo.html') >>> >>> is worse than >>> >>> from django.shortcuts import render >>> def my_view(request): >>> return render(request, 'foo.html') I disagree. "TemplateResponse" is more explicit and readable. render() is confusing, because it doesn't actually render anything - it creates a lazy response. >>> >>> I think that the cases where user should prefer 'render' returning >>> HttpResponse over 'render' returning TemplateResponse are rare so the >>> API by itself should suggest TemplateResponse. TemplateResponse is >>> more flexible and can provide a performance benefit (the template >>> rendering can be prevented in some cases). >>> >>> I don't see much value in adding 'render' shortcut that just use >>> RequestContext after TemplateResponse is introduced - one can still >>> use render_to_response if TemplateResponse is undesired and one >>> shouldn't use such 'render' in other cases. 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 baked responses isn't very fair, imho. >>> >>> 'render' as alias for TemplateResponse seems fine for me: it is a >>> shortcut and it adds value by simplifying the API. >> >> 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 explicitness -- there's no doubting what >> TemplateResponse will return. I agree :). >> >> On the other hand, there *is* value in adding a render() shortcut -- >> because there will be a subset of cases where a TemplateResponse isn't >> needed, but a HttpResponse with a RequestContext is. I think that subset is quite large (basicaly, I didn't found a use case for a TemplateResponse in my apps yet). >> >> Yours, >> Russ Magee %-) > > If I got it right, you want to make default shortcut render() that > would not use TemplateResponse. > But then how one will alter 3rd-party rendered responses in middleware? You can always alter the 3-rd party view to render the response a bit differently, which should be easy with class-based views now. > I suggest people use TemplateResponse by default, and making render = > TemplateResponse just to be sure of this, > and render_to_response is "just 10 more characters" or a line to make > your own render that uses RequestContext. > I think, talking about "saving few characters" is not constructive. > So I'm talking about good architecture and code beauty. Having basicly the same thing under 2 names is not code beauty, imho - but I don't think we should go this way in this discussion. > I think your will to make render=render_to_response with > RequestContext means you want people to use render_to_response by > default. I would like to doing, what I did with direct_to_template() right now. If I decide TemplateResponse is a better alternative, I'll switch to that. > But I'd like if we have a way to make template creators to use > TemplateResponse by default. That would encourage better view reusing > in django. And that means we would have render=TemplateResponse. There is not point in having render shortcut then (apart from saving 10 characters). You can just tell people to use TempateResponse. Generally, I don't like the current render() that much, 'cause it still doesn't let you render a page with status different from 200 (something simillar to http://code.djangoproject.com/ticket/9081) -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 core/cache/base will be needed to handle the move towards > CACHE_SETTINGS > > B) pylibmc and memcached handle negative timeouts differently. The > expected behavior as laid out in template tests is how python- > memcached handles it (instant expiration). I had to do a fairly sad > looking hack to make pylibmc work, and is noted in a comment. > > C) The current version of pylibmc doesn't play nice with python sub- > interuptors, and thus, mod_wsgi. There is a commit (https://github.com/ > lericson/pylibmc/commit/ddd2f011f73d8ccc6347c5471eff378bef58dbd5) in > trunk that fixes this, but a release has not been given out. We may > want to be extra-communicative of this and the possible workarounds. > > D) This draft has gotten minimal review due ot the holiday, so I > expect there's at least two horrifically dumb mistakes in there. > However, because I lifted a great deal from Eric Florenzano's django- > newcache, I'm going to incorrectly blame him ;) As luck would have it, I've found exactly two points for comment (plus one can of worms) :-) Neither are horrifically dumb mistakes, though, just relatively minor issues: * 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. * You've got the CACHE_SETTINGS handling happening in the cache backend itself, whereas the historical arrangement has been to handle all the settings in the backend loader, and pass them into the backend instance as arguments. Now for the can of worms -- I'm wondering if there is some potential for doing a weasel job with respect to infinite timeouts. You rectified the library to ensure that negative timeout values are turned into instant expiration, which is for consistency with the other memcache backends. However, I can't find any specific reference in Django's docs to the behavior of cache backends when timeout is negative. I'm wondering if this might be the weasel way into getting infinite timeouts -- even if it's in conjunction with a clause like "if the backend supports them". Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 baked responses isn't very fair, imho. It's not "forcing". TemplateResponse is a transparent replacement for HttpResponse. Normal response middleware shouldn't event notice that it's working with a TemplateResponse (modulo possible bugs in its implementation). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 offer those people a replacement. Forcing them at >> the same time into the world of lazy baked responses isn't very fair, >> imho. > > It's not "forcing". TemplateResponse is a transparent replacement for > HttpResponse. Normal response middleware shouldn't event notice that it's > working with a TemplateResponse (modulo possible bugs in its > implementation). 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 contents), then changing to TemplateResponse will break this view. It's not entirely transparent, because rendering doesn't depend only on the template and it's context. This adds some complexity to writing view decorators and I don't know if I want to pay it for a feature I have no use case atm. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 contents), then changing to TemplateResponse will break this view. If you're talking about "right now" and "alter how a template is rendered" then this view either doesn't return an HttpResponse instance or returns its custom descendant. Hence such view won't be affected by introduction of a new shortcut or TemplateResponse. What I'm talking about is that currently a middleware or a decorator that expects a normal HttpResponse instance can only access its headers or completely rendered content. The laziness of TemplateResponse can't break it. May be I don't understand what you're trying to show here. Can you provide a small example? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 alter how >> a template is rendered (like current language, some settings or the >> database contents), then changing to TemplateResponse will break this >> view. > > If you're talking about "right now" and "alter how a template is rendered" > then this view either doesn't return an HttpResponse instance or returns its > custom descendant. Hence such view won't be affected by introduction of a > new shortcut or TemplateResponse. > > What I'm talking about is that currently a middleware or a decorator that > expects a normal HttpResponse instance can only access its headers or > completely rendered content. The laziness of TemplateResponse can't break > it. > > May be I don't understand what you're trying to show here. Can you provide a > small example? Sure. Maybe I'm just missing something (note: this doesn't have to be a setting - any side effect that can affect rendering, which includes the database). 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, settings.USE_L10N = settings.USE_L10N, False try: # If view uses HttpResponse, the template will be rendered with USE_L10N = False # If it uses TemplateResponse, nothing will be rendered (yet!) return view(*args, **kwargs) finally: # USE_L10N will be back to it's original value # and that value will be used at the time of baking settings.USE_L10N = old_value return decorated -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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, settings.USE_L10N = settings.USE_L10N, False try: # If view uses HttpResponse, the template will be rendered with USE_L10N = False # If it uses TemplateResponse, nothing will be rendered (yet!) return view(*args, **kwargs) finally: # USE_L10N will be back to it's original value # and that value will be used at the time of baking settings.USE_L10N = old_value return decorated Ugh :-(. Thanks, I'll keep it in my notebook of examples where imperative style sucks… But I see your point now. Indeed there are cases where TemplateResponse is not a transparent replacement for HttpResponse. I'll crawl back to my cave now and cry a little. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 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 never expire. And even a timeout of 1 second currently causes the cache template tag tests to fail. This may end up meaning we need to actually change the template tests, but within that constraint, I can't see a way to do it using _get_memcache_timeout. A bit more on this below your can of worms note > * You've got the CACHE_SETTINGS handling happening in the cache > backend itself, whereas the historical arrangement has been to handle > all the settings in the backend loader, and pass them into the backend > instance as arguments. > I'll look at how DATABASES settings are being handled a little bit more closely and get the patch up to snuff. > Now for the can of worms -- I'm wondering if there is some potential > for doing a weasel job with respect to infinite timeouts. You > rectified the library to ensure that negative timeout values are > turned into instant expiration, which is for consistency with the > other memcache backends. > > However, I can't find any specific reference in Django's docs to the > behavior of cache backends when timeout is negative. I'm wondering if > this might be the weasel way into getting infinite timeouts -- even if > it's in conjunction with a clause like "if the backend supports them". The only reference is implicit in the tests. the first ten or so tests for cache template tag use negative timeouts as a way to check that the cache tag doesn't pull in expired data. Based on your response, we could change these tests to work with infinite timeouts and trust users to know how their backend handles specific things, maybe making a note in the doc. -Jacob > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 use to respect that header, but it's no longer true. The cache middleware will cache a separate copy for each cookie value in the requests it receives, so a viewer will never receive another user's responses. (If we want to allow developers to avoid wasting memory on caching pages that vary by cookie, I have a patch for that.) If we want to keep that setting for some reason, the patch[1] that fixes bug #13283[2] needs to be applied. Turning on CACHE_MIDDLEWARE_ANONYMOUS_ONLY makes *every* page vary by cookie, so anyone with that setting enabled is getting a per-cookie cache instead of using the same cached page for everyone. (I serendipitously had that setting enabled for a news site on election night. Fun times.) - Niran [1] https://github.com/django/django/pull/4 [2] http://code.djangoproject.com/ticket/13283 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 > never expire. And even a timeout of 1 second currently causes the > cache template tag tests to fail. > Can't you just no-op a timeout=0 in the django backend, regardless of the actual memcache lib in use? ie. never send the 'set' command to pylibmc/python-memcache... Hmm. On further thinking, make it into a 'delete' call so any existing entry will be expired instantly. Maybe that's getting too magical? Rob :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 Dec 1, 3:55 pm, Robert Coup wrote: > 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 > > never expire. And even a timeout of 1 second currently causes the > > cache template tag tests to fail. > > Can't you just no-op a timeout=0 in the django backend, regardless of the > actual memcache lib in use? ie. never send the 'set' command to > pylibmc/python-memcache... > > Hmm. On further thinking, make it into a 'delete' call so any existing entry > will be expired instantly. Maybe that's getting too magical? > > Rob :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
