Re: #12180: Test case advice
On Mon, Nov 29, 2010 at 4:32 AM, Christophe Pettus wrote: > Hi, > > I'm updating the patch for #12180 to work with the dev version of 1.3, and > preparing a test case for it. Being new to the Django test suite, it's not > clear to me how to introduce a backend-specific and settings-file-specific > test (the test case requires PostgreSQL 8.2+ and AUTOCOMMIT: True in the > database options). Is there some quick guidance from those more experienced > than me? As Shai noted, backend specific tests are handled by checking for specific backend features, combined with the use of the @skipIfDBFeature and @skipUnlessDBFeature decorators. The regressiontests/backends directory contains a bunch of examples of how this can be done. Some features need to be detemined at runtime -- for example, the existence of transaction support under MySQL can't be determined until runtime. To support a feature that can't be determined until runtime, you put a hook into the confirm() function on the DatabaseFeatures class for the backend. However, we don't really have a precedent for tests that are dependent on the settings themselves -- i.e., we don't have a test that needs to be run twice (once with setting=True and once with setting=False). Ideally, I'd like to avoid introducing the need to run the test suite once for each possible AUTOCOMMIT setting. One possibility - the tests in the suite all run sequentially, and each test runs with a clean database connection; it might be possible to turn on autocommit for a single test, and then revert the setting later on. 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 Sun, Nov 28, 2010 at 11:30 PM, Jacob Kaplan-Moss wrote: > Hi Russ -- > > On Sun, Nov 28, 2010 at 1:13 AM, Russell Keith-Magee > wrote: >> For your consideration, I present a patch to resolve #12815 and >> #12816, adding a TemplateResponse and a render() shortcut. > > Good stuff. > > A couple of things though: > > * I'm really not a fan of "bake()" and ".baked" -- it really feels too > clever a name to me. I know there's a bit of precedent w.r.t. "baked" and > "fried" responses, but I still think the name's just non-obvious. > Especially to people who don't speak English natively. > > Can we just go with something bording like "render()" and ".rendered"? There is a slight complication -- the current API has a render() method in addition to bake(). bake() only works once; render() can be called (and assigned to render.content) at any time to get rendered content using the current template/context, even if bake() has been called. At one point in the history of the patch, the API had a bake() and force_bake(); I suppose we could use render() and force_render(). > * I think we should deprecate render_to_response() in favor of render(). > render_to_response() is just render(request=None, ...), right? Any > reason to keep both around? There's no particular reason to keep both around, other than the code churn that deprecation would entail. This is something that I have no problem deprecating on the 2.0 schedule, but migrating every use of render_to_response() over the next 18 months/2 releases seems like an extreme measure to enforce on the entire user base when maintaining render_to_response() doesn't take any real effort. 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 Mon, Nov 29, 2010 at 4:21 AM, Ivan Sagalaev wrote: > On 11/28/2010 10:13 AM, Russell Keith-Magee wrote: >> >> For your consideration, I present a patch to resolve #12815 and >> #12816, adding a TemplateResponse and a render() shortcut. > > Thank you! > >> - The render() shortcut doesn't use TemplateResponse. Since render() >> and TemplateReponse() have exactly the same prototype, I didn't see >> the value in adding a shortcut that just redirected to a different >> constructor. However, there is still value in making an easy-to-use >> render_to_response, for those situations where a TemplateResponse >> can't be used. > > I have a slight (about -0) concern about this… It might turned out as the > same mistake that was made with render_to_response() in the first place: it > wasn't powerful enough (i.e. it didn't use RequestContext) to be used as a > default shortcut. If people would like TemplateResponse they would be > frustrated that render() doesn't use it. Using TemplateResponse directly is > perfectly possible but then we have to explain to every newcomer why are > there two slightly different ways of doing one thing. I think that cases > where one wants to care about using pure HttpResponse instead of > TemplateResponse would be rare and it's better not be the default behavior. My counterargument would be this -- if you use TemplateResponse, there's no need to use a shortcut at all. Unlike HttpResponse, you don't need to construct a context, load a template and render it. The constructor for TemplateResponse is all you need. This is born out by the fact that the TemplateReponse shortcut isn't even a method definition -- it's a rename: render = TemplateResponse I don't see the point in just putting a rename into shortcuts; so we might as well use the shortcut for something that might be useful -- such as providing a way to easily use ResponseContext on normal HttpResponses. > P.S. Noticed a typo in the patch: > > @@ -164,6 +154,13 @@ > urlresolvers.set_urlconf(None) > > try: > + # Apply template response middleware and the bake the response > + # if the response can be baked > + if hasattr(response, 'bake') and callable(response.bake): > > The first line of the comment should be "and the*n* bake the response". Thanks - I've fixed this in my copy. 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 11/29/2010 02:58 PM, Russell Keith-Magee wrote: My counterargument would be this -- if you use TemplateResponse, there's no need to use a shortcut at all. Yes, this is what I understood from your reasoning. I'm concerned more with documentation. Namely, what are we going to suggest for usage in the tutorial. The nice short `render()` shortcut lacks the power of TemplateResponse and TemplateResponse is not *that* nice and short. -- 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
I agree with Jacob on the bake/baked thing.. but maybe it's just CakePHP coming to haunt me :S On Nov 29, 1:09 pm, Ivan Sagalaev wrote: > On 11/29/2010 02:58 PM, Russell Keith-Magee wrote: > > > My counterargument would be this -- if you use TemplateResponse, > > there's no need to use a shortcut at all. > > Yes, this is what I understood from your reasoning. I'm concerned more > with documentation. Namely, what are we going to suggest for usage in > the tutorial. The nice short `render()` shortcut lacks the power of > TemplateResponse and TemplateResponse is not *that* nice and short. -- 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.
.limit() on a QuerySet
Hi,
Before I put any work into this, I want to know if (a) I'm missing something
super-obvious in the QuerySet functionality, or (b) this idea has already been
explored and rejected.
Sometimes, it would be nice to get a slice of a QuerySet but *not* actually
evaluate the QuerySet; instead, leave it unevaluated. An example of this would
be an implementation of blog navigation:
context['previous_entry'] =
Entry.objects.filter(entry_date__lt=current.entry_date).order_by('-entry_date')[0]
context['next_entry'] =
Entry.objects.filter(entry_date__gt=current.entry_date).order_by('entry_date')[0]
This works fine, but it grabs the relevant object immediately. It would be
handy to have a syntax that continued to defer the execution of the query, in
case (for example) the navigation is cached by a template fragment {% cache $}
tag. Something like:
context['previous_entry'] =
Entry.objects.filter(entry_date__lt=current.entry_date).order_by('-entry_date').limit(limit=1,
offset=0)
context['next_entry'] =
Entry.objects.filter(entry_date__gt=current.entry_date).order_by('entry_date').limit(limit=1,
offset=0)
Then, in the template, {{ previous_entry.get }} could be used to fetch the
result.
Thoughts?
--
-- Christophe Pettus
x...@thebuild.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: .limit() on a QuerySet
On 11/29/2010 11:31 PM, Christophe Pettus wrote: Before I put any work into this, I want to know if (a) I'm missing something super-obvious in the QuerySet functionality, or (b) this idea has already been explored and rejected. Hi Christophe, Looks like you're indeed missing queryset slicing[1]. It is lazy. [1]: http://docs.djangoproject.com/en/dev/topics/db/queries/#limiting-querysets -- 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: .limit() on a QuerySet
On Nov 29, 2010, at 12:50 PM, Ivan Sagalaev wrote: > Looks like you're indeed missing queryset slicing[1]. It is lazy. > > [1]: > http://docs.djangoproject.com/en/dev/topics/db/queries/#limiting-querysets Bah, I was confusing indexing (not lazy) and slicing (lazy). Never mind, and thanks. :) -- -- Christophe Pettus x...@thebuild.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: Ticket #12248 (moving django.template.__init__ contents to django.template.base)
On Fri, Nov 26, 2010 at 8:38 PM, Russell Keith-Magee wrote: > Ok - looks like I had a couple of seriously loose screws last night. > I'll take another look today. Apologies for the confusion. I noticed that you merged the change in — thanks! I saw that you explicitly imported the names that used to live in django.template.__init__ instead of simply doing "from django.template.base import *" like I had, and I think that yours is the better solution there; it only brings in what used to live in __init__ (and thus is required for backward compatibility) without further polluting the __init__ namespace unnecessarily. Now I feel like I can hack on the django.template module without going crazy. :-D -- 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: Could the comments framework be more generic?
> Can you be specific on how the current setup is preventing you from > getting it done? I think the easiest way is to look at my code on bitbucket, for example my models.py: https://bitbucket.org/bolhoed/django_disqus_comments/src/b2c6fbb025f6/models.py. As you can see, I have to hack my own model manager and queryset, just to be able to use the Disqus API instead of models on the local database. > Apart from a model backend what other backends are we looking at to > store comments? Whatever you would want. If you make abstract base classes for getting comments for an object, getting the count of comments, and saving a new comment, everyone could make their own backend. You could use Twitter for comments (with a hashtag), Disqus, a nonsql database, textfiles... However, I would only ship the models backend by default. > If it is a clean proposal, it might be possible to convince the core > devs to break the backwards compatibility rule. You can count me in > for any kind of help regarding this task. Cool, thanks. I think my basic idea should be pretty clear: just offer an extra layer of abstraction above the ORM for the comments. I am not sure what the best way to do this would be, but I should have plenty of time this week to look into it. Cheers, Kevin -- 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)
I'm not going to get into the arguments about security of the various
hashing methods, other than to observe that there have been some
fairly misleading statements here.
As far as the proposal goes, I think this is a perfectly reasonable
feature request (and you should open a ticket about it if one does not
already exist).
I'd favor a solution where your setting mapped the algo name to the
actual function used:
PASSWORD_HASH_FUNCTIONS = { 'bcrypt':
myproject.myapp.bcrypt_hexdigest, 'sha1':
django.utils.hashcompat.sha_constructor, etc.}
Then we could put the existing hash functions (sha1, md5, etc.) in
that setting as the default, and get rid of the algo-checking code
that currently lives in auth.models. When we do a password comparison,
we simply pull the hash name, lookup the function, and away we go.
I don't think this will make it into 1.3, but it's a reasonable thing
to do and I think it would help improve all the special-case code that
currently lives in auth.models. The patch itself wouldn't be too hard,
and I'd be willing to write it myself if nobody else will.
-Paul
--
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.
#11675:Pyblic+Memcache changes, Draft #1
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 ;) -Jacob -- 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.
Django/Python Job
My client is in a immediate need for a front end engineer whi knows Django, Python, AJAX, and/or html5 . This is a full time position with a really good pay in Palo Alto, CA. Sent me your updated resume if interested. -- 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.
