Django test documentation example not respecting xUnit convention

2011-09-20 Thread James Pic 
Hello everybody,

Sorry if this topic has already been brought, I asked about it on IRC but
nobody answered.

Being a old user of xUnit patterns in several languages, i just figured that
there might be a mistake in django testing documentation example.

The example is: self.assertEqual(self.lion.speak(), 'The lion says "roar"')

Which corresponds to: assertEqual(actual, expected)

Wheras the xUnit convention is: assertEqual(expected, actual)

For poeple who are not already aware of this decade old convention: "By
convention, the expected value is specified first and the actual value
follows it". Source:
http://xunitpatterns.com/Assertion%20Method.html#Equality Assertion

Apparently, Python's unittest assertEqual documentation does not mention
this convention:
http://docs.python.org/library/unittest.html#unittest.TestCase.assertEqual

Why do you think Python took such a position against a decade old convention
in every language i had the chance to test in ?

What's your position ?

Regards

-- 
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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread Florian Apolloner 
Hi,

a) Does this matter at all? I mean what's the difference? You ask if they 
are equal and if not you get an error ;)
b) I think it's the wrong mailing list for design decisions python took…

Cheers,
Florian

-- 
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/-/-HFXX5yeQYgJ.
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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread Calvin Spealman 
On Sep 20, 2011 5:18 AM, "James Pic"  wrote:
>
> Hello everybody,
>
> Sorry if this topic has already been brought, I asked about it on IRC but
nobody answered.
>
> Being a old user of xUnit patterns in several languages, i just figured
that there might be a mistake in django testing documentation example.
>
> The example is: self.assertEqual(self.lion.speak(), 'The lion says
"roar"')
>
> Which corresponds to: assertEqual(actual, expected)
>
> Wheras the xUnit convention is: assertEqual(expected, actual)
>
> For poeple who are not already aware of this decade old convention: "By
convention, the expected value is specified first and the actual value
follows it". Source:
http://xunitpatterns.com/Assertion%20Method.html#Equality Assertion
>
> Apparently, Python's unittest assertEqual documentation does not mention
this convention:
http://docs.python.org/library/unittest.html#unittest.TestCase.assertEqual
>
> Why do you think Python took such a position against a decade old
convention in every language i had the chance to test in?

It wasn't a decade old convention when python 2.1 added the unittest package
a decade ago, to be fair.

>
> What's your position ?
>
> Regards
>
> --
> 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.

-- 
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.

is it time to start deprecating parts of contrib

2011-09-20 Thread ptone 
At DjangoCon.us there was positive reception to Jacob's thoughts that
Django core could be leaner - people liked the kernel analogy.

Talk of reducing contrib has been around a long time.

Per policy, it takes 3 minor versions to remove something from Django
- near as I can tell, a PendingDeprecation warning could be reversed
if there was a large change of opinion.

There is perhaps no more humorous a line in all of the Django docs
than this:

"Databrowse is very new and is currently under active development. It
may change substantially before the next Django release."

My top nominations for contrib apps to go away are:

Databrowse
webdesign
formtools

What are yours?

Given the 3-version deprecation process, I figure it could be time to
start pulling some weeds.

-Preston

-- 
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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread Daniel Moisset 
On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner wrote:

> Hi,
>
> a) Does this matter at all? I mean what's the difference? You ask if they
> are equal and if not you get an error ;)
>

Other xUnit framework actually show an error message explicit about it,
saying "expected 'foo', actual 'bar'". Python's unittest just says "foo !=
bar".

The difference is slightly more understandable error message when an
equality test fails: you know what the actual result was supposed to be


> b) I think it's the wrong mailing list for design decisions python took…
>

Or perhaps lack of design decision in this case? (I'm not sure it was
intentional)

Regards,
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-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.

ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Roald de Vries 

Hi all,

Is there a fundamental reason that I'm missing (other than "nobody's  
taken the trouble of writing it") that I can't do the following? If  
there isn't I'll create a ticket for it.


class R(Model):
user = ForeignKey(User)
my_model = ForeignKey('MyModel')
comment = CharField(max_length=100, blank=True)

class MyModel(Model):
users = ManyToManyField(User, through=R, null=True)

m = MyModel.objects.create()
u = User.objects.create_user('roald', 'downa...@gmail.com',  
'password')



# these things I can't do:
m.users.add(u)
m.users.add(u, comment='Blablabla')

Cheers, Roald

--
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: ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Łukasz Rekucki 
On 20 September 2011 15:52, Roald de Vries  wrote:
> Hi all,
>
> Is there a fundamental reason that I'm missing (other than "nobody's taken
> the trouble of writing it") that I can't do the following? If there isn't
> I'll create a ticket for it.
>
>    class R(Model):
>        user = ForeignKey(User)
>        my_model = ForeignKey('MyModel')
>        comment = CharField(max_length=100, blank=True)
>
>    class MyModel(Model):
>        users = ManyToManyField(User, through=R, null=True)
>
>    m = MyModel.objects.create()
>    u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
>
>
>    # these things I can't do:
>    m.users.add(u)
>    m.users.add(u, comment='Blablabla')
>
> Cheers, Roald
>

I'm 100% sure there's *at least one* ticket for this. You just need to
search for it and you'll probably find the discussion of this too.

-- 
Ł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-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: is it time to start deprecating parts of contrib

2011-09-20 Thread Jannis Leidel 

On 20.09.2011, at 14:13, ptone wrote:

> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
> 
> Talk of reducing contrib has been around a long time.
> 
> Per policy, it takes 3 minor versions to remove something from Django
> - near as I can tell, a PendingDeprecation warning could be reversed
> if there was a large change of opinion.
> 
> There is perhaps no more humorous a line in all of the Django docs
> than this:
> 
> "Databrowse is very new and is currently under active development. It
> may change substantially before the next Django release."
> 
> My top nominations for contrib apps to go away are:
> 
> Databrowse
> webdesign
> formtools

FYI, formtools is unlikely to go away anytime soon, as we've just
recently added a new class based views wizard [1]. Next step would
be to refactor the form preview tool to be class based, too [2].

Jannis

1: https://docs.djangoproject.com/en/dev/releases/1.4/#new-form-wizard
2: https://code.djangoproject.com/ticket/16174

-- 
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: ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Stephan Jaensch 
Hi Roald,

Am 20.09.2011 um 15:52 schrieb Roald de Vries:

> Hi all,
> 
> Is there a fundamental reason that I'm missing (other than "nobody's taken 
> the trouble of writing it") that I can't do the following? If there isn't 
> I'll create a ticket for it.

> 
>class R(Model):
>user = ForeignKey(User)
>my_model = ForeignKey('MyModel')
>comment = CharField(max_length=100, blank=True)
> 
>class MyModel(Model):
>users = ManyToManyField(User, through=R, null=True)
> 
>m = MyModel.objects.create()
>u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
> 
> 
># these things I can't do:
>m.users.add(u)
>m.users.add(u, comment='Blablabla')

https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary-manytomany

You can't use add() when specifying the intermediate model. You would have to 
check all fields of the intermediate model and make sure all of them have 
defaults or are allowed to be null. It might not be worth the trouble of 
implementing it.

Cheers,
Stephan

-- 
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: ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Roald de Vries 

On Sep 20, 2011, at 4:23 PM, Stephan Jaensch wrote:


Am 20.09.2011 um 15:52 schrieb Roald de Vries:

Is there a fundamental reason that I'm missing (other than  
"nobody's taken the trouble of writing it") that I can't do the  
following? If there isn't I'll create a ticket for it.




  class R(Model):
  user = ForeignKey(User)
  my_model = ForeignKey('MyModel')
  comment = CharField(max_length=100, blank=True)

  class MyModel(Model):
  users = ManyToManyField(User, through=R, null=True)

  m = MyModel.objects.create()
  u = User.objects.create_user('roald', 'downa...@gmail.com',  
'password')



  # these things I can't do:
  m.users.add(u)
  m.users.add(u, comment='Blablabla')


https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary- 
manytomany


You can't use add() when specifying the intermediate model. You  
would have to check all fields of the intermediate model and make  
sure all of them have defaults or are allowed to be null. It might  
not be worth the trouble of implementing it.


I don't see how this is different from the create method on the  
intermediary model.


Cheers, Roald

PS: I found an open ticket on this, https://code.djangoproject.com/ticket/9475

--
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: ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Johannes Dollinger 

Am 20.09.2011 um 15:57 schrieb Łukasz Rekucki:

> On 20 September 2011 15:52, Roald de Vries  wrote:
>> Hi all,
>> 
>> Is there a fundamental reason that I'm missing (other than "nobody's taken
>> the trouble of writing it") that I can't do the following? If there isn't
>> I'll create a ticket for it.
>> 
>>class R(Model):
>>user = ForeignKey(User)
>>my_model = ForeignKey('MyModel')
>>comment = CharField(max_length=100, blank=True)
>> 
>>class MyModel(Model):
>>users = ManyToManyField(User, through=R, null=True)
>> 
>>m = MyModel.objects.create()
>>u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
>> 
>> 
>># these things I can't do:
>>m.users.add(u)
>>m.users.add(u, comment='Blablabla')
>> 
>> Cheers, Roald
>> 
> 
> I'm 100% sure there's *at least one* ticket for this. You just need to
> search for it and you'll probably find the discussion of this too.

#9475 [1] is the ticket for the default value case. Russell's comments indicate 
that the other case (providing extra attributes for the intermediary model) may 
also be in scope for this ticket.

[1] https://code.djangoproject.com/ticket/9475

__
Johannes

-- 
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: ManyRelatedManager with explicit intermediary model

2011-09-20 Thread Tom Evans 
On Tue, Sep 20, 2011 at 4:12 PM, Roald de Vries  wrote:
>
> I don't see how this is different from the create method on the intermediary
> model.
>
> Cheers, Roald
>
> PS: I found an open ticket on this,
> https://code.djangoproject.com/ticket/9475
>

Here is the function definition for add() on related object manager:

add(obj1[, obj2, ...])

As you can see, it can be used to add multiple objects to the
relationship in one go, and therefore the arguments to this function
would need to change to support what you propose. This would require
going through the whole deprecation procedure (2/3 major releases
before it is gone), and I guess the pain outweighs the gain on that
one.

create() takes **kwargs, but those arguments relate to the instance
being created on the other end of the relationship, there would still
be no way to specify non-default values for the intermediate model.
You would have to do something similar to passing a defaults
dictionary to create(), which then makes it different to how create()
on an object manager works, and introduces another field that you
would have to do some magic to work around.

I guess the main thing is what's the point? The argument is over which
of these is prettier:

model_a_instance.modelb_set.add(model_b_instance)

and

Intermediate.objects.create(model_a=model_a_instance, model_b=model_b_instance)

Beauty contests in code are rather pointless - the documentation has
for a long time said that the latter is the only way you can do it,
and most developers are now used to that.

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-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.

Design decision for #1625 - Adding traceback to return value from send_robust when error occurs

2011-09-20 Thread Jim D. 
https://code.djangoproject.com/ticket/16245

Here's the quick summary:

send_robust() as you know is a special case of send() in the signals 
framework, which wraps each signal trigger in a try/except block so that an 
exception in one signal doesn't prevent the rest from firing.

This is great, but I've run into a problem when using this in production. 
The problem is that send_robust() does not capture the traceback at the 
point of the exception. As a result, though you can see which exception was 
raised, you can't see the traceback assocaited with that exception. This 
makes debugging exceptions that occur during send_robust extremely, 
extremely difficult.

I've contributed a patch to resolve this. In order to preserve backwards 
compatibility, my patch adds a kwarg append_traceback to send_robust() which 
allows one to optionally ensure the traceback is included. This seemed like 
the most straightforward solution that steps on the fewest toes, though in 
my opinion the traceback should be included by default and the old way 
deprecated.

The patch includes full tests and documentation. Right now it's stuck in 
design decision needed. Hopefully someone wouldn't mind taking a moment to 
review the ticket and patch and move it to ready for checkin. If there are 
concerns or questions or the patch need work I'd be happy to do what is 
required.

Many thanks...

-- 
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/-/HdK-7gZdmSsJ.
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.

Semantics when calling select_related repeatedly

2011-09-20 Thread Jeremy Dunck 
Currently, calling select_related causes the QS to forget previously
added fields.  Also, it seems that depth calls are not forgotten.

For example, cribbing from the tests here:
https://code.djangoproject.com/browser/django/trunk/tests/modeltests/select_related/tests.py#L129

If this:
 Species.objects.select_related('genus__family')
were replaced with
 Species.objects.select_related('genus__family').select_related('genus')
then the query count would go up.

That may be intuitive when written all at once, but consider when
'genus__family' is set by a default manager, and later some queryset
is constructed with select_related('genus').

Additionally, if it were:
  Species.objects.select_related(depth=1).select_related('genus__family')
I'm not sure what should happen.

It seems to me that calling .select_related should be additive, and if
you didn't want a previously select_related in effect, you should have
a way to reset it.  The .order_by() analog isn't available since
.select_related() means "select all related to max depth of 5".   So
we'd need a .select_related(depth=0) or similar.

So, each call would resolve to a list of fields.  depth=1 would be
shorthand for finding all the fields at depth  of 1 and adding it to
the set of previously .select_related fields.

Do people agree this is desirable?  I can see that this would be
backwards-incompatible since some people might be knowingly and
intentionally narrowing the previous calls with a shorter/shallower
call.  So then perhaps a "from __future__" sort of mechanism,
.select_related(additive=True) or
QuerySet(additive_select_related=True) or similar.

Or, if .select_related should not be additive, I'd like to see 1) docs
improved in this area and/or 2) a warning issued when a previous
.select_related was overridden.

Thoughts?

-- 
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-opening 5617?

2011-09-20 Thread Tom Christie 
Hi All,

  I recently bumped into the same issue as reported in 
#5617.  
(And duplicate #6377 .)
IE: Django's default 500 view uses a Context, not a RequestContext, which 
means any 500 templates which uses MEDIA_URL or suchlike won't work.

I thought I'd re-punt the suggestion given in one of the comments - attempt 
to render using the RequestContext, and only fall back to the Context if 
that fails.  It seems like a reasonable approach, but it looks like it's 
something that didn't ever get properly considered, because no-one pushed 
the issue to the list, as far as I can tell.

Where do we stand on this?  I'd have thought that a large amount of installs 
are having to define their own 500 view function, which does nothing more 
than the default view, other than to use a RequestContext so that the 
template can render correctly.  Would there be any value in re-opening the 
ticket given the suggested fallback approach?

Cheers,

  Tom.

-- 
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/-/hBlPW8dRGI0J.
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: Design decision for #1625 - Adding traceback to return value from send_robust when error occurs

2011-09-20 Thread Jeremy Dunck 
On Tue, Sep 20, 2011 at 9:00 AM, Jim D.  wrote:
> https://code.djangoproject.com/ticket/16245

I've looked at the patch and it seems good to me.

I have a suggestion:

Rather than (receiver, err, traceback), why not (receiver, exc_info)
where exc_info is the triple returned by sys.exc_info()?  There's no
harm in changing the meaning of the 2nd tuple element if people are
opting into the change.

Similarly, rather than append_traceback, why not call it
exc_info=True?  This parallels the logging module's use of the kwarg:
http://docs.python.org/library/logging.html#logging.Logger.debug

-- 
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: Semantics when calling select_related repeatedly

2011-09-20 Thread Javier Guerra Giraldez 
On Tue, Sep 20, 2011 at 11:29 AM, Jeremy Dunck  wrote:
> It seems to me that calling .select_related should be additive

+1

-- 
Javier

-- 
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: Design decision for #1625 - Adding traceback to return value from send_robust when error occurs

2011-09-20 Thread Jim D. 
Awesome, great suggestions both. That's a cleaner API and the implementation 
itself is even slightly cleaner.

I updated the patch and uploaded it to the ticket. If you or anyone else 
wants to review it and ideally move it forward, that would be excellent.

Thanks!

-- 
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/-/v_5hqdvT3LUJ.
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: Design decision for #1625 - Adding traceback to return value from send_robust when error occurs

2011-09-20 Thread Jeremy Dunck 
On Tue, Sep 20, 2011 at 12:09 PM, Jim D.  wrote:
> Awesome, great suggestions both. That's a cleaner API and the implementation
> itself is even slightly cleaner.
> I updated the patch and uploaded it to the ticket. If you or anyone else
> wants to review it and ideally move it forward, that would be excellent.
> Thanks!

Well, I meant to mark accepted as endorsement of the patch, but that
made me owner.

I can't own it since I'm not a core committer.

Setting it back to nobody set the status to "new".

Hopefully a core will agree this is a good approach.

-- 
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: is it time to start deprecating parts of contrib

2011-09-20 Thread Carl Meyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/20/2011 06:13 AM, ptone wrote:
> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
> 
> Talk of reducing contrib has been around a long time.
> 
> Per policy, it takes 3 minor versions to remove something from Django
> - near as I can tell, a PendingDeprecation warning could be reversed
> if there was a large change of opinion.
> 
> There is perhaps no more humorous a line in all of the Django docs
> than this:
> 
> "Databrowse is very new and is currently under active development. It
> may change substantially before the next Django release."
> 
> My top nominations for contrib apps to go away are:
> 
> Databrowse
> webdesign
> formtools

I would be +1 on starting with deprecation of both databrowse and
webdesign, -0 on formtools at this point for the same reason Jannis
mentioned; it is actually actively maintained and used, and recently got
some major improvements. In the abstract I do think that formtools is a
fine candidate to be an external app rather than live in contrib, I just
think we may as well start with the lower-hanging fruit here.

Databrowse could easily be spun off into an external app if anybody
cared to maintain it.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk547rMACgkQ8W4rlRKtE2cLvwCg6x/sCROjtIG6GBBFuQljV4pw
u+IAoMrXUYg7MLr61CNKPRYTfhPFIZWu
=6hxI
-END PGP SIGNATURE-

-- 
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.

confusing things in Trac UI (was: Design decision for #1625...)

2011-09-20 Thread Carl Meyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
> Well, I meant to mark accepted as endorsement of the patch, but that
> made me owner.

Yeah, this is confusing in our Trac UI. The "accept" radio button at the
bottom assigns the ticket to you, it doesn't actually do anything with
the triage state. To change the ticket from DDN to Accepted you'd use
the dropdown next to "Triage Stage" up in the box above.

I'd be in favor of just removing that "accept" radio button if it isn't
hard to do; doesn't do anything you can't do with the "reassign" option,
just gets confused with the triage state.

> I can't own it since I'm not a core committer.

Hmm, I wasn't aware of this policy. We don't seem to make real
consistent use of the "owned by" field, but as far as I was aware it was
just a way to signal that you were working on this ticket so someone
else with interest would check with you before diving in and doing a
bunch of work. I thought anybody could make use of this field if they
planned to push the ticket forward and wanted to signal that.

> Setting it back to nobody set the status to "new".

The "new" vs "assigned" in big letters up top is another thing in our
Trac UI that I think is at best useless, at worst confusing. AFAICT all
it depends on is whether the ticket is owned by someone, and I don't
consider that nearly important enough data (or well-maintained enough)
to put in big letters right up in the header. Triage state is something
we pay a lot more attention to, would seem to make more sense up there.
But I think Trac considers new/assigned to be the same piece of state as
e.g. "fixed" or "wontfix", and that is something that ought to be right
up top. So there may be no simple way to address this.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk55AqEACgkQ8W4rlRKtE2dxGwCgxuubCeRLq69F39wlRJjD8p0m
e8UAoOlXrFESAZCdwT89VzHYQGjLD4gC
=Ivsh
-END PGP SIGNATURE-

-- 
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: Design decision for #1625 - Adding traceback to return value from send_robust when error occurs

2011-09-20 Thread Carl Meyer 
Addressed the Trac-confusion stuff in a new thread to keep this focused.

On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
>
> Hopefully a core will agree this is a good approach.
>
I marked the ticket accepted as its something that should be fixed and the 
general approach looks fine to me - don't have time at the moment to review 
the patch in depth.

Carl

-- 
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/-/KYiuI3We2t8J.
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: is it time to start deprecating parts of contrib

2011-09-20 Thread Justin Holmes 
It depends how surgical this discussion is; if we're at the model
level, then it's pretty clear that we need to reinvent auth.User and
deprecate functionality accordingly.

I'm not hearing anyone say that contrib.auth is an undesired battery
tout court, but the sentiment that it fails to "get out of the way" is
basically universal, and has been for some time.

A small group of us began a brainstorm on day 2 of the sprints in
Portland.  It is ongoing here:

https://code.djangoproject.com/wiki/UserHasABadMotivator

On Tue, Sep 20, 2011 at 12:51 PM, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/20/2011 06:13 AM, ptone wrote:
>> At DjangoCon.us there was positive reception to Jacob's thoughts that
>> Django core could be leaner - people liked the kernel analogy.
>>
>> Talk of reducing contrib has been around a long time.
>>
>> Per policy, it takes 3 minor versions to remove something from Django
>> - near as I can tell, a PendingDeprecation warning could be reversed
>> if there was a large change of opinion.
>>
>> There is perhaps no more humorous a line in all of the Django docs
>> than this:
>>
>> "Databrowse is very new and is currently under active development. It
>> may change substantially before the next Django release."
>>
>> My top nominations for contrib apps to go away are:
>>
>> Databrowse
>> webdesign
>> formtools
>
> I would be +1 on starting with deprecation of both databrowse and
> webdesign, -0 on formtools at this point for the same reason Jannis
> mentioned; it is actually actively maintained and used, and recently got
> some major improvements. In the abstract I do think that formtools is a
> fine candidate to be an external app rather than live in contrib, I just
> think we may as well start with the lower-hanging fruit here.
>
> Databrowse could easily be spun off into an external app if anybody
> cared to maintain it.
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk547rMACgkQ8W4rlRKtE2cLvwCg6x/sCROjtIG6GBBFuQljV4pw
> u+IAoMrXUYg7MLr61CNKPRYTfhPFIZWu
> =6hxI
> -END PGP SIGNATURE-
>
> --
> 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.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

-- 
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: is it time to start deprecating parts of contrib

2011-09-20 Thread Paul McMillan 
I'm also +1 on deprecating Databrowse.

+0 on webdesign, since it's functionality that's probably in transient
use by the more invisible members of our community. If it were more
fleshed out, I'd say leave it, but since it's just that single
function, it should probably go eventually.

-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-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: confusing things in Trac UI (was: Design decision for #1625...)

2011-09-20 Thread Paul McMillan 
> I'd be in favor of just removing that "accept" radio button if it isn't
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.

This is a good idea. I made the same mistakes as a new contributor.
>
>> I can't own it since I'm not a core committer.

Unless this has changed very recently, this isn't the case. I've
definitely owned tickets long before I got into core.

> The "new" vs "assigned" in big letters up top is another thing in our
> Trac UI that I think is at best useless, at worst confusing.

Yes! Let's get rid of that. It still confuses me now even when I know
exactly what it means!

-- 
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: confusing things in Trac UI (was: Design decision for #1625...)

2011-09-20 Thread Jeremy Dunck 
On Tue, Sep 20, 2011 at 2:16 PM, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
>> Well, I meant to mark accepted as endorsement of the patch, but that
>> made me owner.
>

>> I can't own it since I'm not a core committer.
>
> Hmm, I wasn't aware of this policy. We don't seem to make real
> consistent use of the "owned by" field, but as far as I was aware it was
> just a way to signal that you were working on this ticket so someone
> else with interest would check with you before diving in and doing a
> bunch of work. I thought anybody could make use of this field if they
> planned to push the ticket forward and wanted to signal that.

Well, I mostly meant that I think it's RFC (pending running the full
suite) and because of that, I shouldn't be the owner.  I think the OP
hoped I'd check it in, and I was trying to make my intentions clear in
the thread.

-- 
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: confusing things in Trac UI (was: Design decision for #1625...)

2011-09-20 Thread Julien Phalip 
On 20 September 2011 14:16, Carl Meyer  wrote:

> On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
> > Well, I meant to mark accepted as endorsement of the patch, but that
> > made me owner.
>
> Yeah, this is confusing in our Trac UI. The "accept" radio button at the
> bottom assigns the ticket to you, it doesn't actually do anything with
> the triage state. To change the ticket from DDN to Accepted you'd use
> the dropdown next to "Triage Stage" up in the box above.
>
> I'd be in favor of just removing that "accept" radio button if it isn't
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.
>

I too am in favour of removing this button, if that's possible. It adds no
value and causes confusion.

> I can't own it since I'm not a core committer.
>
> Hmm, I wasn't aware of this policy. We don't seem to make real
> consistent use of the "owned by" field, but as far as I was aware it was
> just a way to signal that you were working on this ticket so someone
> else with interest would check with you before diving in and doing a
> bunch of work. I thought anybody could make use of this field if they
> planned to push the ticket forward and wanted to signal that.
>

There is actually a policy for using this field which more or less matches
your assumption. It is documented here:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#claiming-tickets

However, the doc could certainly do with further clarifications. Patches
welcome :P

Julien

-- 
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: Semantics when calling select_related repeatedly

2011-09-20 Thread Carl Meyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 09/20/2011 10:29 AM, Jeremy Dunck wrote:
> Currently, calling select_related causes the QS to forget previously
> added fields.  Also, it seems that depth calls are not forgotten.
> 
> For example, cribbing from the tests here:
> https://code.djangoproject.com/browser/django/trunk/tests/modeltests/select_related/tests.py#L129
> 
> If this:
>  Species.objects.select_related('genus__family')
> were replaced with
>  Species.objects.select_related('genus__family').select_related('genus')
> then the query count would go up.
> 
> That may be intuitive when written all at once, but consider when
> 'genus__family' is set by a default manager, and later some queryset
> is constructed with select_related('genus').
> 
> Additionally, if it were:
>   Species.objects.select_related(depth=1).select_related('genus__family')
> I'm not sure what should happen.
> 
> It seems to me that calling .select_related should be additive, and if
> you didn't want a previously select_related in effect, you should have
> a way to reset it.  The .order_by() analog isn't available since
> .select_related() means "select all related to max depth of 5".   So
> we'd need a .select_related(depth=0) or similar.
> 
> So, each call would resolve to a list of fields.  depth=1 would be
> shorthand for finding all the fields at depth  of 1 and adding it to
> the set of previously .select_related fields.
> 
> Do people agree this is desirable?  I can see that this would be
> backwards-incompatible since some people might be knowingly and
> intentionally narrowing the previous calls with a shorter/shallower
> call.  So then perhaps a "from __future__" sort of mechanism,
> .select_related(additive=True) or
> QuerySet(additive_select_related=True) or similar.
> 
> Or, if .select_related should not be additive, I'd like to see 1) docs
> improved in this area and/or 2) a warning issued when a previous
> .select_related was overridden.
> 
> Thoughts?

Coincidentally enough, this was just filed a few days ago [1]; after
talking it over with Jacob and Alex in IRC I accepted it, under pretty
much the same logic you just outlined. We thought the
backwards-compatibility issue was negligible, as the current behavior is
undocumented, counter-intuitive, arguably simply a bug, and the
consequences of the change are minor and easy to correct for. So yes, I
agree :-) And I also filed #16856 [2] to address the "no way to clear
it" issue.

Your observation that "depth" is currently sticky while fields are not
is a new one (to me); I'll make a note of that on the ticket.

Carl

 [1] https://code.djangoproject.com/ticket/16855
 [2] https://code.djangoproject.com/ticket/16856
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk55CgkACgkQ8W4rlRKtE2fGvACaAgEp/MEo5hn65Cf/3Pa1dsLL
0SsAoMw+5d5qQtDswUaI6eXEwx2fn3K2
=uGuP
-END PGP SIGNATURE-

-- 
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: Re-opening 5617?

2011-09-20 Thread Carl Meyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tom,

Thanks for bringing this to the list.

On 09/20/2011 10:32 AM, Tom Christie wrote:
>   I recently bumped into the same issue as reported in #5617
> .  (And duplicate #6377
> .)
> IE: Django's default 500 view uses a Context, not a RequestContext,
> which means any 500 templates which uses MEDIA_URL or suchlike won't work.
> 
> I thought I'd re-punt the suggestion given in one of the comments -
> attempt to render using the RequestContext, and only fall back to the
> Context if that fails.  It seems like a reasonable approach, but it
> looks like it's something that didn't ever get properly considered,
> because no-one pushed the issue to the list, as far as I can tell.
> 
> Where do we stand on this?  I'd have thought that a large amount of
> installs are having to define their own 500 view function, which does
> nothing more than the default view, other than to use a RequestContext
> so that the template can render correctly.  Would there be any value in
> re-opening the ticket given the suggested fallback approach?

Personally I have always made the 500 page simple and completely
standalone (all CSS inline in the page) so it has no external
dependencies, and have never had a problem with this approach.

The concern I have with the proposed try-and-try-again approach is that
it makes people think they can write a 500 template with all kinds of
dependencies on RequestContext, and then if there is an error that does
actually break one of their context processors, their 500 page will in
all likelihood be horribly broken. I think it's better to encourage 500
pages that are simple all the time rather than beautiful some of the
time and completely broken some of the time.

An approach I'd be more open to considering would be to have the default
handler500 manually inject STATIC_URL into the template context (without
using RequestContext). I think this alone would take care of the vast
majority of issues people have with this, and simply looking up a
setting is no more likely to raise additional errors than the process of
rendering a template itself is (whereas context processors might do
anything). (It shouldn't be MEDIA_URL; since Django 1.3 that setting is
only for user-uploaded media, which is not something that should be
needed on a 500 page).

Thoughts on this?

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk55DnMACgkQ8W4rlRKtE2czWQCfWXkYN9CznrNd78bD6HtE7fCN
t3kAnRHBK7jjE1LAtKrSSPZkG9OVVGyi
=CJAN
-END PGP SIGNATURE-

-- 
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: is it time to start deprecating parts of contrib

2011-09-20 Thread Markus Gattol 

>
> +0 on webdesign, since it's functionality that's probably in transient
> use by the more invisible members of our community. If it were more
> fleshed out, I'd say leave it, but since it's just that single
> function, it should probably go eventually.
>
I'd miss it even though it's just a tiny piece of code and trivial, it's 
quite useful when you mock up a site and thus need some text to get a 
feeling for its layout when there's lots of text involved. I am sure, as you 
say, there are quite a few people out there who would miss it too.

>

-- 
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/-/U7FBFWzheIcJ.
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: is it time to start deprecating parts of contrib

2011-09-20 Thread Gabriel Hurley 
+1 on deprecating databrowse. Dead code should be excised.

As for webdesign, why not roll the one piece in it (the marginally-useful 
lorem tag) into the main library and deprecate the hook in contrib?

-0 on deprecating formtools.

For the sake of argument I could see admindocs being deprecated and spun off 
into it's own app.

Otherwise I can't see any other contrib modules being deprecated in the near 
future.

All the best,

- Gabriel

-- 
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/-/x09VXWhBci8J.
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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread Russell Keith-Magee 
On Tue, Sep 20, 2011 at 8:18 PM, Daniel Moisset  wrote:
>
>
> On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner 
> wrote:
>>
>> Hi,
>>
>> a) Does this matter at all? I mean what's the difference? You ask if they
>> are equal and if not you get an error ;)
>
> Other xUnit framework actually show an error message explicit about it,
> saying "expected 'foo', actual 'bar'". Python's unittest just says "foo !=
> bar".
>
> The difference is slightly more understandable error message when an
> equality test fails: you know what the actual result was supposed to be
>
>>
>> b) I think it's the wrong mailing list for design decisions python took…
>
> Or perhaps lack of design decision in this case? (I'm not sure it was
> intentional)

It certainly wasn't intentionally reversed from the "convention"; it's
an artefact of Python's documentation not making the ordering
distinction, reinforced by the foo != bar output format that was
referred to.

Should the examples be changed? For my money, I don't think it makes a
whole lot of sense to adopt a convention that isn't reinforced by
Python at a language level.

For what it's worth, I also think the "convention" is bass ackwards...
you write "if variable == value", but you write "assertEqual(value,
variable)"? Where's the consistency in that?

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-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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread Alex Gaynor 
On Tue, Sep 20, 2011 at 8:01 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Tue, Sep 20, 2011 at 8:18 PM, Daniel Moisset 
> wrote:
> >
> >
> > On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner <
> f.apollo...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> a) Does this matter at all? I mean what's the difference? You ask if
> they
> >> are equal and if not you get an error ;)
> >
> > Other xUnit framework actually show an error message explicit about it,
> > saying "expected 'foo', actual 'bar'". Python's unittest just says "foo
> !=
> > bar".
> >
> > The difference is slightly more understandable error message when an
> > equality test fails: you know what the actual result was supposed to be
> >
> >>
> >> b) I think it's the wrong mailing list for design decisions python took…
> >
> > Or perhaps lack of design decision in this case? (I'm not sure it was
> > intentional)
>
> It certainly wasn't intentionally reversed from the "convention"; it's
> an artefact of Python's documentation not making the ordering
> distinction, reinforced by the foo != bar output format that was
> referred to.
>
> Should the examples be changed? For my money, I don't think it makes a
> whole lot of sense to adopt a convention that isn't reinforced by
> Python at a language level.
>
> For what it's worth, I also think the "convention" is bass ackwards...
> you write "if variable == value", but you write "assertEqual(value,
> variable)"? Where's the consistency in that?
>
> 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-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.
>
>
FWIW there was a thread either on python-dev, or maybe python-idea, or it
might have been the Python ticket tracker, about officially stating a
convention for (expected, actual) vs (actual, expected), the conclusion
(IIRC) was that they weren't documenting a preference, but if there was one,
it was (actual, expected).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: Django test documentation example not respecting xUnit convention

2011-09-20 Thread schinckel 
It isn't 'enforced' by Python at a language level, but as dmoisset stated, 
it makes the failure messages actually make sense:

"Expected 'foo', got 'bar'".

(paraphrasing failure message: don't have any failing tests to look at right 
now. YAY! :)

Matt.

>

-- 
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/-/3B4s7zenKmIJ.
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.