Re: Adding UNION/INTERSECT/EXCEPT to the ORM

[Sean Bleier]

>
> We cannot use the name "QuerySet.except()" since except is a reserved word
> in Python. Do you prefer minus() (as suggested by Florian), except_() (as
> done by SQLAlchemy), or something else?
>
>
Can I suggest using "QuerySet.difference"?   It's what python's sets use
for achieving the same functionality.

On Monday, December 26, 2016 at 6:28:15 PM UTC-5, Adam Johnson wrote:
>>
>> Yes it's different, they cannot be changed due to backwards compatibility
>> issues. They don't result in UNION in SQL, they union the filters on two
>> querysets that are on the same exact model.
>>
>> On 26 December 2016 at 21:00, Cristiano Coelho 
>> wrote:
>>
>>> Is this going to be different from the pipe ( | ) and and ( & )
>>> operators on querysets? If I'm not wrong those can already result in a
>>> union query (but not necessary, sometimes it just returns a query with an
>>> or/and condition)
>>>
>>>
>>> El viernes, 23 de diciembre de 2016, 11:12:40 (UTC-3), Florian Apolloner
>>> escribió:

 Hi,

 I have a currently WIP PR at https://github.com/django/django/pull/7727

 The usage is currently something like this:

 qs1 = User.objects.all().values('username')
 qs2 = Group.objects.all().values('name')
 results = qs1.union(qs).distinct().order_by('name')[:10]

 (order_by does not work though yet)

 So far I have a few questions:

  * Should .union/.intersect etc return a new type of queryset or stay
 with the base QuerySet class (probably less code duplication)
  * We currently have a few methods which check can_filter and error out
 accordingly (ie you cannot filter after slicing), but as the error message
 in https://github.com/django/django/blob/master/django/db/model
 s/query.py#L579 shows, this strongly relies on knowledge of the
 implementation of the filter. For combined querysets I basically need to
 limit everything aside from order by and limit/offset. Would a method like
 this make some sense (on the Query class):

 def is_allowed(self, action):
   if self.combinatorial and action not in ('set_operation', 'order_by',
 'slicing'):
 raise SomeError('Cannot use this method on an combinatorial
 queryset')
   elif action == 'filter' and (self.low_mark or self.high_mark):
 raise SomeError('Cannot filter after slicing')

  * set_operator in base.py feels a bit weird (
 https://github.com/django/django/pull/7727/files#diff-53fcf
 3ac0535307033e0cfabb85c5301) -- any better options?
  * How can I change the generated order_by clause to reference the
 columns "unqualified" (ie without table name), can I somehow just realias
 every column?

 Cheers,
 Florian

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/d38358ca-c97f-4bb0-a390-e38f3b4b8f6c%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/3084faa0-e097-4227-9a34-
> f870c8be6809%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: Make url patterns group kwargs more simple

[Sean Bleier]

You might want to check out Surlex[1], written by Cody Soyland.  It
basically does what you want.

[1] http://codysoyland.com/projects/surlex/documentation/


On Wed, May 28, 2014 at 8:54 AM, Alexandr Shurigin <
alexandr.shuri...@gmail.com> wrote:

> Hi all.
>
> What do you think about adding some extra default and more simpler syntax
> for url patterns?
>
> Now patterns looks little bit difficult, especially if you have long urls
> with 2-3 params.
>
> For example take a look into url.
>
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',
> views.GameNewsItem.as_view(), name="view_news_view")
>
> This is ‘good seo url’ for big project. This url have game genre, game
> slug name, /news/ and news slug name.
>
> For example this matches path /arcade/pacman/news/new-update-2014/
>
> This is pretty cool when site have such urls and support all url subpaths,
> user can simple remove some path in url and go other pages of site catalog
> structure.
>
> In presented example i wanted to show you this url entry shard to read
> (but not so difficult to write) when you supporting your project.
>
> When you have about 20-30 same style urls in one file, this makes your
> urls file unreadable :)
>
> Maybe allow user enter url masks in simpler way by adding some magic?
>
> For django is not problem make url regexps from string with ‘meta tags’
> and process it way like it work now. But i think user will be really happy
> to enter simpler (and shorter!) urls.
>
> I mean we allow user only describe his urls simpler.
>
> For example in ruby on rails user can enter urls like
>
> get 'products/:id/purchase' => 'catalog#purchase', as: :purchase
>
> Where :id is just shortcut for regexp pattern group.
>
> I think we (or me, no difference) can do same way.
>
> We can do it 2 ways:
>
> 1. hardcode some usually used tags (for example id, day, year, slug, any
> other) and words built from them (for example we understand that :id and
> :product_id have the same path type ([0-9]+)).
> 2. Make library for registering such tags like template tag library and
> add rules from #1 to it. Allowing way for users to extend library tags with
> their own.
>
> Using this way, we can get very simple and fancy urls. For example my game
> news url will look like:
>
> url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(),
> name="view_news_view")
>
> This will make urls very short, fast-readable and writable.
>
> Also we can skip in pattern masks ?P, for example from url pattern
>
> ([^/]+)
>
> we can simple compile
> (?P[^/]+)
>
> I think a lot of users will appreciate this feature. What you think?
>
> Django urls are not simple right now for users and looks little ugly,
> because 99% users reuse standard types of masks (id like - [0-9]+, slug
> like - [a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).
>
> But of course user can combine url shortcuts with their custom regexps.
>
>
>
> --
> Alexandr Shurigin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/etPan.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFtT_0KEgdyusp%3DhSn0z361zp%3DQvsy0f3-AOgi0UncveNNdsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: ttl method for cache

[Sean Bleier]

Hi Piotr,

For what it's worth, I have an implementation of ttl on django-redis-cache:
https://github.com/sebleier/django-redis-cache/commit/626a3263c428cf59b1428f5fc2aa638efd77346a

It's slightly different from your snippet in that if the key does not exist
(because it is expired or didn't exist in the first place), the returned
value will be 0 instead of None.  None is reserved for non-volatile keys
with no expirations.

–Sean


On Mon, May 5, 2014 at 1:16 PM, Piotr Gosławski
wrote:

> Hi!
>
> Since the contribution workflow is a bit confusing to me, I'll just leave
> it here.
> I think django's cache needs ttl (time to live) method that would return
> time left until specified key expires. I, for instance, needed one when
> writing
> a rate limiter. Without it I would have to store twice as much key-value
> pairs
> in cache. I ended up with a workaround that dynamically binds ttl method,
> but only for locmem and redis, since those are the backends I use.
>
> Here is my workoround, maybe it will be of some use:
> https://github.com/p-tr0/snipets/blob/master/django_cache_ttl.py
>
> I guess the proper way would be to add a method that just raises
> NotImplementedError and then cover it one backend at a time.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/07aa224a-3716-48c0-8af6-757d875c6d88%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFtT_09-ERyrWR%2BukAn0EZ0dc1Kcru5K3h3JXett2GT%3D0fqRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Sean Bleier]

I like the implementation referenced in the SO thread, but I would just
point out that `.get_or_none()` should accept both *args and **kwargs. `Q`
objects can be passed in as arguments to `.get()` and `.filter()`, so it's
only natural to allow that for `.get_or_none()`.


On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Just read through all those threads/tickets, here's my conclusion.
>
> #2659 was rejected 8 years ago [1] on the basis that it's a "feature
> creep", and that it "doesn't offer anything revolutionary". However the
> same could be said for .first() and .last(), yet those were accepted.
>
> #11352 was rejected by luke plant 2 years ago [4] based on the suggested
> implementation in that ticket, which is not the same implementation as what
> I'm proposing this time round. The design of `get_object_or_none` being
> added into shortcuts is not a good approach, and was right to be rejected.
>
> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352
> were rejected, both of which I've addressed above.
>
> First argument - `first()` and `.last()` have been added, yet the
> principle behind why they were added is the same as `.get_or_none()`.
> Second argument - The implementation being suggested in this thread is not
> the same as what has been suggested in the three rejected tickets.
> Third argument - Thread [2] had mostly positive feedback, but there was no
> BDFL decision specifically on `get_or_none`.
>
> If I'm missing something here, please let me know.
>
> Cal
>
> [1] https://code.djangoproject.com/ticket/2659
> [2]
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> [3] https://code.djangoproject.com/ticket/17546
> [4] https://code.djangoproject.com/ticket/11352
>
>
> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
>
>> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd]
>> wrote:
>> > Seems this issue was brought up several years ago, though the thread was
>> > later hijacked for other functionality and get_or_none fizzled out.
>> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
>> >
>> > In Django 1.6 there were convenience methods added for .first(), for the
>> > same principle of not having to catch an IndexError (or in this case, a
>> > DoesNotExist error);
>> >
>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
>> > s.query.QuerySet.first
>> >
>> > This seems to be wanted by several users, as seen here;
>> >
>> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
>> > -or-none-if-nothing-matches
>> >
>> > Seems to be quite an easy fix, just needs a proper patch.
>> >
>> > Any thoughts?
>> >
>> You linked the wrong thread.
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
>>
>> I was (and still am) for a get_or_none() that raises an exception when
>> it finds multiple objects, but we were overruled.
>>
>> Shai.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHKQagFCyR2GGcY%2BV%2BGzdR%3DKi3P9%2BTVbT4BzVD_bDoJBN1w6Qw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: Predicate as suggested new feature to extend url resolver process

[Sean Bleier]

I think what Rach is suggesting is different from @require_GET,
@require_POST, etc. The patch essentially makes a view invisible if
the predicate function returns False.

I'm not sure this would be good for inclusion to django, since you are
tying url resolution to application state .  This could have negative
implications, especially for performance.  On top of that, the same
functionality could be achieved by creating a function/class to route
the request further after django has initially routed the request.
This would be preferable because the performance hit would be isolated
to the resolved routing function/class.



On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss  wrote:
> I'm not sure I understand what you're proposing here. How is this
> different from @require_GET, @require_POST, and friends?
>
> Jacob
>
> On Wed, May 22, 2013 at 11:05 AM, Rach Belaid  wrote:
>> I just did a pull request resulting of my last Django sprints for
>> adding a new feature in Django.
>>
>> https://code.djangoproject.com/ticket/20479
>>
>> The idea is being able to have more control on the url resolving
>> process.
>>
>> I have no merit behind the idea of predicate. Predicate is one of my
>> favorite feature in Pyramid/Pylons to allow more complex and flexible
>> routing.
>>
>> I will be curious about feebacks? Do you like this idea of features ?
>>
>> The implementation is probably imperfect so don't be too harsh ;) we
>> can always fix the implementation.
>>
>> For people unaware about what is a predicate, I advice to check the
>> pyramid doc here:
>> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher slow?

[Sean Bleier]

JKM, I'm wondering if it would benefit the community to house
djangobench under https://github.com/django to give it more
visibility.  Just a thought.

On Thu, Oct 11, 2012 at 9:45 AM, ptone  wrote:
>
>
> On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> That said - could Django be faster? Sure. *Anything* can be improved.
>>
>> So, if you've got a suggestion, make it. If you think URL resolving is
>> the source of the problem, propose a way to improve the speed of URL
>> resolvers. If you think the template language is the problem, propose
>> a fix.
>
>
> To do my part to increase the signal:noise.
>
> I'll point out that just as writing a failing test is a great way to augment
> a bug report - contributing or improving a benchmark for:
>
> https://github.com/jacobian/djangobench
>
> would be a good way to contribute to a discussion around a particular
> performance improvement you're interested in seeing happen.
>
> -Preston
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/kI7jNl7gYwEJ.
>
> To post to this group, send email to django-developers@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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Javascript Testing

[Sean Bleier]

Hi Luke,

This looks like it could be really interesting or useful, but at the
> moment I can't quite see my way to working out how to use it. I'd really
> like to be able to:
>
> 1) apply a patch (or two) to my copy of Django
>

Would you like me to attach a patch to a ticket? I could attach it to
https://code.djangoproject.com/ticket/16193 or open a new ticket using a
more generic description of a javascript testing framework.


> 2) run an example test that proves something useful about the admin's
> javascript (for instance - or some other example app that is provided).
>
>
I recently added tests for URLify.js from the admin, that may give you a
better practical sense of how to test the admin.
https://github.com/sebleier/django/commit/3a358cc3a4c2fa9a1fda0d58c46309c9f7956d6a


Thanks,

--Sean

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Javascript Testing

[Sean Bleier]

Hello everyone,

A couple months ago I started work on a django branch [1] (with the help of
@jezdez) that introduces a framework for writing javascript unit tests using
QUnit[2].  I started with QUnit because Django already included jQuery in
the admin and seemed like a natural extension, but it would be nice to hear
opinions from people that know more about javascript testing than I.

Since I haven't touch it in a couple months, I thought I would share it with
django-developers to get some more eyes on it and discuss any missing
features or implementation details. It also be nice if Idan or any other
designery person could look it over and give some UI/UX advice.

Just to give a overview, the javascript testing framework is initiated by
first collecting static media and then starting a special runserver:

./manage.py collectstatic
./manage.py jstest

This starts a runserver that collects and serves everything you need to run
the javascript tests found within an installed app. More detail can be found
in these preliminary docs[3], though they need to be moved into their proper
place within the docs directory.

I'm hoping we can figure out a way forward so that we can start writing
tests for the admin and elsewhere.

Cheers,

--Sean


[1] https://github.com/sebleier/django/tree/qunit
[2] http://docs.jquery.com/Qunit
[3]
https://github.com/sebleier/django/blob/qunit/django/test/javascript/__init__.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: contrib.staticfiles app concerns

[Sean Bleier]

I agree with Carl,

> Staticfiles has a very specific, well-defined purpose (collecting media
> files from apps), which fills a major hole in the Django "story" for
> reusable apps.


IMHO contrib apps should have the following characteristics (and probably
more):
* Solves a problem that can be described in one short sentence.
* Solves a fundamental problem in web development, including problems
involving the reusable app paradigm.
* Doesn't restrict the programmer from using other tools to solve the same
problem.
* Promotes a convention among developers.

Staticfiles solves the problem of reusable app media collection and doesn't
restrict the developer from using something else. It also promotes the
convention of storing media within a "static" directory, which will help
adoption of new reusable apps.  To me, adding staticfiles to Django was a
logical move that will help the community.  Just my two cents.

Cheers,

--Sean

-- 
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: Patch: adding a msg parameter to assertContains and similar methods in the test client

[Sean Bleier]

>
>
> > def assertFormError(self, response, form, field, errors, msg=None):
> >...
> >self.fail(msg or "The field '%s' on form '%s' in context %d"
> >  " contains no errors" % (field, form, i))
>
> would become:
>
> prefix = msg and "%s: " % msg or ""
> self.fail("%sThe field '%s' on form '%s' in context %d"
>  " contains no errors" % (prefix, field, form, i))
>
> This preserves the best of both worlds - a rich failure message, plus
> the ability to add user-specific context to help identify the source
> of the problem in the test suite. This does differ from the behavior
> of the assert* functions in the standard library, but hopefully in a
> way that makes sense under the circumstances. Opinions?
>
> Yours,
> Russ Magee %-)
>
>
I like Russ's prefix idea.  I believe Christian's concern is that the
django's error messages do not give enough context for the programmer when
debuging.  Adding the prefix allows programmers to add that context without
blindly overridding the error message that django throws.

Karen is right about the name of msg if it is going to serve as a prefix to
the msg given to Python's assert* methods.  Something like msg_prefix or
prefix would be more appropriate IMO

Using Christian's example, I might change it to:

class TemplateTestCase(ClientTestCase):
   def testTemplateError(self):
   urls = [
   '/',
   '/home/',
   '/admin/',
   # etcetera ...
   ]
   for url in urls:
   response = self.client.get(url, follow=True)
   self.assertNotContains(
   response,
   settings.TEMPLATE_STRING_IF_INVALID,
   msg_prefix='Error in url %s' % url)

This way for the two cases in which assertNotContains can fail, you can have
errors messages like:
"Error in url /home/: Couldn't retrieve page: Response code was 404
(expected 200)"
or
"Error in url /home/: Response should not contain
'TEMPLATE_STRING_IF_INVALID"

--Sean

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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
-~--~~~~--~~--~--~---