Re: cursor.callproc()
> On Oct 22, 2014, at 5:56 PM, Shai Berger wrote: >> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote: >>> On 10/21/2014 04:04 PM, Shai Berger wrote: >>> I'd argue that in the common case, the user shouldn't care if the >>> function they are calling is implemented in Python or Procedural SQL >>> (assuming it is going to interact with the database either way), and so >>> it is good API design to abstact this detail away. >> >> Here is where we differ. I think calling a database stored procedure is >> fundamentally a different thing from calling a Python function (even one >> that accesses the database), and the difference should be obvious in the >> calling code. I don't think it is good API design to abstract away >> differences that the caller should be aware of. (For one example of a >> difference, database stored procedures "return a modified copy of the >> input arguments", which would be extremely unusual behavior for a normal >> Python function.) > That, of course, doesn't have to be the case for the wrapper API. Well, that's the problem, isn't it? A purpose-built nice Python wrapper for a particular stored procedure can certainly do something better, but I'm not sure what else a generic wrapper system could do. You don't know which parameters to an arbitrary proc might be output parameters (unless you try some kind of runtime introspection, or require a registration step where the user tells you about the signature; at that point you may as well just let the user write their own wrapper). There's a reason 'callproc' has the odd signature it does. Carl -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6F8CC704-DB07-4220-AF85-EBF03BD0141C%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
Re: cursor.callproc()
On Wed, Oct 22, 2014 at 12:35 PM, Carl Meyer wrote: > Here is where we differ. I think calling a database stored procedure is > fundamentally a different thing from calling a Python function (even one > that accesses the database), and the difference should be obvious in the > calling code. I don't think it is good API design to abstract away > differences that the caller should be aware of. (For one example of a > difference, database stored procedures "return a modified copy of the > input arguments", which would be extremely unusual behavior for a normal > Python function.) > > I think this is mostly a question of level. In an actual Django app that > uses stored procedures, I think it is quite likely a good idea for the > author of the app to provide a nice Python API that abstracts away the > internal implementation. But I think this API should be consciously > designed for-purpose (for example, it should likely return something > other than a possibly-modified copy of all its input arguments), and at > the level of Django core the benefits of a generic API that attempts to > mask the difference between Python functions and database stored > procedures are not enough to justify the magic required. > > Perhaps I'm wrong - but I'd definitely want to see the utility of such a > generic "magic" layer proved as an external library before it gets added > to core. > As someone who has used a very large number of stored procedures with Django, I am a solid -1 on adding a generic "magic" layer to Django. Stored procedures are purpose built. Their python usage should also be purpose built to match the various combinations of input/output parameters, return values, and result sets that are possible for a stored procedure. Regards, Michael Manfre -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBsDgj2S9W%3DVE9VXy-3U4uBQtgkhKetqbbyEMzWbYzqqTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: cursor.callproc()
Hi Carl, On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote: > On 10/21/2014 04:04 PM, Shai Berger wrote: > > I'd argue that in the common case, the user shouldn't care if the > > function they are calling is implemented in Python or Procedural SQL > > (assuming it is going to interact with the database either way), and so > > it is good API design to abstact this detail away. > > Here is where we differ. I think calling a database stored procedure is > fundamentally a different thing from calling a Python function (even one > that accesses the database), and the difference should be obvious in the > calling code. I don't think it is good API design to abstract away > differences that the caller should be aware of. (For one example of a > difference, database stored procedures "return a modified copy of the > input arguments", which would be extremely unusual behavior for a normal > Python function.) > That, of course, doesn't have to be the case for the wrapper API. > I think [...] at > the level of Django core the benefits of a generic API that attempts to > mask the difference between Python functions and database stored > procedures are not enough to justify the magic required. > > Perhaps I'm wrong - but I'd definitely want to see the utility of such a > generic "magic" layer proved as an external library before it gets added > to core. > I agree that this would be the prudent step to take. On second thought, I expect the benefit to prove quite small, just because people don't use all that many stored procedures in Django apps. Shai. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201410230256.13570.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
Re: django.db.models.field.subclassing issue
SubfieldBase is deprecated in Django 1.8, so I don't think there will be interest in fixing any issues with it. On Wednesday, October 22, 2014 7:11:05 AM UTC-4, Bobby Mozumder wrote: > > In the file subclassing.py, should the following: > > > def make_contrib(superclass, func=None): > """ > Returns a suitable contribute_to_class() method for the Field subclass. > > If 'func' is passed in, it is the existing contribute_to_class() > method on > the subclass and it is called before anything else. It is assumed in > this > case that the existing contribute_to_class() calls all the necessary > superclass methods. > """ > def contribute_to_class(self, cls, name): > if func: > func(self, cls, name) > else: > super(superclass, self).contribute_to_class(cls, name) > setattr(cls, self.name, Creator(self)) > > return contribute_to_class > > instead be: > > def make_contrib(superclass, func=None): > """ > Returns a suitable contribute_to_class() method for the Field subclass. > > If 'func' is passed in, it is the existing contribute_to_class() > method on > the subclass and it is called before anything else. It is assumed in > this > case that the existing contribute_to_class() calls all the necessary > superclass methods. > """ > def contribute_to_class(self, cls, name): > if func: > func(self, cls, name) > else: > super(superclass, self).contribute_to_class(cls, name) > setattr(cls, self.name, Creator(self)) > > return contribute_to_class > > Should the setattr() should be called only when there isn’t a > contribute_to_class() method. > > I ask because in my own custom field, I have a contribute_to_class() > function as well: > > def contribute_to_class(self, cls, name): > super(myCustomField, self).contribute_to_class(cls, name) > setattr(cls, self.name, myCustomCreator(self)) > > But, because of the setattr() in the SubfieldBase metaclass, my own > setattr() gets overwritten by the default set_attr().. I therefore can’t > have my own field of the same name with my own custom Creator(). > > Is this expected behavior? > > -bobby > > > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/08eba24b-7f8d-4ecc-9deb-18465415b900%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANNOUNCE] Bugfix releases issued
The first bugfix release in the 1.7 series is out, along with bugfix releases for the supported 1.4 and 1.6 release series, and what will hopefully be the final release of the 1.5 series, which is now past end-of-life. Full details are available on the Django project weblog: https://www.djangoproject.com/weblog/2014/oct/22/bugfix-releases-issued/ -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-9u3UFxtxY%3Dh-q-D8uJwmQ0s_b4cB1KP%2BZeOpv%2B8HoxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: cursor.callproc()
Hi Shai, On 10/21/2014 04:04 PM, Shai Berger wrote: > On Monday 20 October 2014 21:26:50 Carl Meyer wrote: >> Hi Marc, >> >> On 10/19/2014 12:54 AM, Marc Tamlyn wrote: >>> I guess now with migrations we have a nice way of running the SQL >>> against the database to create the stored procedures. >>> >>> However if we plan to make this a public API, it should be a nice one. >>> Something along the lines of db.procedures.proc_name(*args, **kwargs) >>> would be preferable I think. Obviously this requires more magic to make >>> it work (or explicit registration of your procedures). >> >> I know this is hypothetical, but I don't think that is a particularly >> nicer API, or that we should provide such syntactic sugar atop >> callproc(). Providing the procedure name as a string is not really a >> problem, and is preferable to doing `__getattr__` magic or requiring >> registration of procedures; the syntactic sugar just doesn't provide >> enough benefit to justify the magic, and all the various ways that that >> magic could confuse users and cause maintenance issues. >> > I respectfully disagree. The kind of "magic" Marc suggested lets you, as a > user. treat procedure calls as function calls; that is a very natural thing > to > do. Yes, I understand the attraction. > I'd argue that in the common case, the user shouldn't care if the function > they are calling is implemented in Python or Procedural SQL (assuming it is > going to interact with the database either way), and so it is good API design > to abstact this detail away. Here is where we differ. I think calling a database stored procedure is fundamentally a different thing from calling a Python function (even one that accesses the database), and the difference should be obvious in the calling code. I don't think it is good API design to abstract away differences that the caller should be aware of. (For one example of a difference, database stored procedures "return a modified copy of the input arguments", which would be extremely unusual behavior for a normal Python function.) I think this is mostly a question of level. In an actual Django app that uses stored procedures, I think it is quite likely a good idea for the author of the app to provide a nice Python API that abstracts away the internal implementation. But I think this API should be consciously designed for-purpose (for example, it should likely return something other than a possibly-modified copy of all its input arguments), and at the level of Django core the benefits of a generic API that attempts to mask the difference between Python functions and database stored procedures are not enough to justify the magic required. Perhaps I'm wrong - but I'd definitely want to see the utility of such a generic "magic" layer proved as an external library before it gets added to core. Carl -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5447DCE5.6060103%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
Re: cursor.callproc()
Hi Chris, On 10/22/2014 09:05 AM, Chris Foresman wrote: > Good points. I went looking for `callproc()` documentation and couldn't > find anything useful, which if I understand correctly is part of the > reason this thread started. So +1 on documenting it! > > The most complicated part of dealing with store procedures from a high > level is getting them in the database to begin with, and updating them > if they need to change. Obviously I'm just manually entering them via > the console, but it would be great if there was some consistent way to > add them to the database via Migrations or something similar. As Marc suggested, I think migrations do already solve this problem, via the RunSQL operation. (It doesn't offer any abstraction over writing the stored procedure, but I'm not sure what kind of abstraction would be useful there. It does provide a place to put it that ensures it will get run on every database - though previously you could use initial SQL for that purpose.) Carl -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5447D059.2060302%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
Re: cursor.callproc()
Good points. I went looking for `callproc()` documentation and couldn't find anything useful, which if I understand correctly is part of the reason this thread started. So +1 on documenting it! The most complicated part of dealing with store procedures from a high level is getting them in the database to begin with, and updating them if they need to change. Obviously I'm just manually entering them via the console, but it would be great if there was some consistent way to add them to the database via Migrations or something similar. On Tuesday, October 21, 2014 4:44:25 PM UTC-5, Shai Berger wrote: > > On Tuesday 21 October 2014 18:23:44 Chris Foresman wrote: > > Is there some benefit to using `.callproc()` over this? > > > > ``` python > > query = 'CALL sp_recommendation_engine(%s, %s)' > > profile = user.get_profile() > > cursor = connection.cursor() > > cursor.execute(query, [user.id, profile.id]) > > ``` > > > There are two benefits: > > 1) Unlike Python functions, SQL stored procedures can have output > parameters > (and input/output parameters). callproc() allows you to get these (it > returns > the sequence of parameters, with outputs placed appropriately), while > execute() can only return the procedure's return value (I'm not quite sure > about procedures yielding result-sets -- callproc() will let you fetch the > results, I'm not sure the same holds for execute() universally). > > 2) Surprisingly, stored procedure invocation syntax is not completely > standard; for example, on PostgreSQL, you should have > > query= 'SELECT sp_recommendation_engine(%s, %s)' > > HTH, > Shai. > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4ec3adbe-e240-4a80-bd8e-1f8a8eb5d229%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why doesn't ModelChoiceField.queryset support slicing?
I believe the problem is related to the fact that a sliced queryset cannot
be filtered (it currently raises an AssertionError when trying to do so).
If you need to produce a "top n results" queryset which can be filtered —
which is implicitely required for the queryset you pass to a
ModelChoiceField — you can base your condition on some subquery, for
instance :
class BookForm(forms.Form):
book = forms.ModelChoiceField(
queryset=Book.objects.filter(pk__in=Book.objects.order_by('-
rating')[:100].values_list('pk')))
I don't know if there is a better way to do that...
On Tuesday, October 21, 2014 6:41:29 PM UTC+2, Kamil Śliwak wrote:
>
> Hi
>
> I have just stumbled upon a problem with how ModelChoiceField handles its
> 'queryset' argument and I'd like to ask whether it's a deliberate design
> choice or if I should report it as a bug.
>
>
> Let's say you have a model called Book:
>
> class Book(models.Model):
> rating = models.IntegerField()
>
> You want to create a form that lets user select one of tghe top rated
> books. So you try:
>
> class BookForm(forms.Form):
> book = forms.ModelChoiceField(queryset =
> Book.objects.order_by('-rating')[:100])
>
> It appears to work - the form can be rendered and you can choose one of a
> hundered top-rated books. But when you submit, you get the following error:
>
> AssertionError: Cannot filter a query once a slice has been taken.
>>
>
> The error is caused by ModelChoiceField.to_python()
>
>
> validating the existence of the selected item by calling get() on the
> queryset:
>
> value = self.queryset.get(**{key: value})
>
> And this is not supported for sliced querysets as the error above states.
> It might have been be a deliberate choice not to support this use case in
> ModelChoiceField though I don't see any comments about that in the code or
> any mentions in ModelChoiceField.queryset
>
>
> docs. I would also expect it to be a common need. This and the fact that it
> can be trivially solved by replacing get() with SQL INTERSECT (implemented
> as operator & in Django) makes me suspect that there would be some issue
> with that.
>
> Can anyone shed some light on this? Are there any performance or
> database-combatibility issues involved? Or is it just a bug?
>
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/74c9b580-adcc-49ff-918a-c04ec5dc7ca6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Suggestion for @cache_page compatiblity with jQuery JSONP
Uhm, I don't think you can ignore the callback, isn't the callback what's
included in the response? As such for proper function the callback can't be
ignored.
Cheers,
Florian
On Wednesday, October 22, 2014 7:16:48 AM UTC+2, Luke Dupin wrote:
>
> Anyone that has used @cache_page with jquery's JSONP knows that it does
> nothing. The URL is different for every call, therefor nothing gets cached.
>
> I suggest that a parameter is added to @cache_page which causes certain
> URL variables to be removed from the URL before the url is cached. I'm
> picturing something like this:
> @cache_page(60 * 15, ignore_variables=('callback',))
>
> Another approach is to allow the user to pass REGEX(s) to sub out portions
> of the URL. This will allow more flexibility, but is probably a bit
> overkill.
>
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ca05cf09-4e31-4de4-8ba8-c2c9402b1fd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
django.db.models.field.subclassing issue
In the file subclassing.py, should the following: def make_contrib(superclass, func=None): """ Returns a suitable contribute_to_class() method for the Field subclass. If 'func' is passed in, it is the existing contribute_to_class() method on the subclass and it is called before anything else. It is assumed in this case that the existing contribute_to_class() calls all the necessary superclass methods. """ def contribute_to_class(self, cls, name): if func: func(self, cls, name) else: super(superclass, self).contribute_to_class(cls, name) setattr(cls, self.name, Creator(self)) return contribute_to_class instead be: def make_contrib(superclass, func=None): """ Returns a suitable contribute_to_class() method for the Field subclass. If 'func' is passed in, it is the existing contribute_to_class() method on the subclass and it is called before anything else. It is assumed in this case that the existing contribute_to_class() calls all the necessary superclass methods. """ def contribute_to_class(self, cls, name): if func: func(self, cls, name) else: super(superclass, self).contribute_to_class(cls, name) setattr(cls, self.name, Creator(self)) return contribute_to_class Should the setattr() should be called only when there isn’t a contribute_to_class() method. I ask because in my own custom field, I have a contribute_to_class() function as well: def contribute_to_class(self, cls, name): super(myCustomField, self).contribute_to_class(cls, name) setattr(cls, self.name, myCustomCreator(self)) But, because of the setattr() in the SubfieldBase metaclass, my own setattr() gets overwritten by the default set_attr().. I therefore can’t have my own field of the same name with my own custom Creator(). Is this expected behavior? -bobby -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/B459F14E-F899-4972-BB04-F9AA95326FD7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Suggestion for @cache_page compatiblity with jQuery JSONP
Anyone that has used @cache_page with jquery's JSONP knows that it does
nothing. The URL is different for every call, therefor nothing gets cached.
I suggest that a parameter is added to @cache_page which causes certain URL
variables to be removed from the URL before the url is cached. I'm
picturing something like this:
@cache_page(60 * 15, ignore_variables=('callback',))
Another approach is to allow the user to pass REGEX(s) to sub out portions
of the URL. This will allow more flexibility, but is probably a bit
overkill.
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3d0c35d2-ed2f-404a-98aa-fd88cc3c0165%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Why doesn't ModelChoiceField.queryset support slicing?
On Wednesday 22 October 2014 10:50:51 Marc Tamlyn wrote: > > As for a work around, using a ChoiceField directly shouldn't be > particularly difficult in this case. ModelChoiceField has some nice > features but it is limited. > Using a ChoiceField as a substitute for ModelChoiceField isn't hard, but one should be aware of the pitfalls. The obvious nicety handled by ModelChoiceField is the transformation from ids back to objects; the less obvious one is that a ModelChoiceField runs the query anew for every form; your ChoiceField cannot be initialized by a query in its definition, and needs to have its choices set in the form's __init__(). HTH, Shai. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201410221215.32597.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
Re: Why doesn't ModelChoiceField.queryset support slicing?
Personally I don't feel that it's a particularly common need, but I can see
your use case. More common is that a reasonable filter is applicable - say
books with a rating over 80.
As far as I know we don't have any support for SQL intersects and I don't
believe there are any plans to introduce it.
I do agree that this should be both documented and preferably raise an
error - please open a ticket.
As for a work around, using a ChoiceField directly shouldn't be
particularly difficult in this case. ModelChoiceField has some nice
features but it is limited.
Marc
On 21 Oct 2014 17:42, "Kamil Śliwak" wrote:
> Hi
>
> I have just stumbled upon a problem with how ModelChoiceField handles its
> 'queryset' argument and I'd like to ask whether it's a deliberate design
> choice or if I should report it as a bug.
>
>
> Let's say you have a model called Book:
>
> class Book(models.Model):
> rating = models.IntegerField()
>
> You want to create a form that lets user select one of tghe top rated
> books. So you try:
>
> class BookForm(forms.Form):
> book = forms.ModelChoiceField(queryset =
> Book.objects.order_by('-rating')[:100])
>
> It appears to work - the form can be rendered and you can choose one of a
> hundered top-rated books. But when you submit, you get the following error:
>
> AssertionError: Cannot filter a query once a slice has been taken.
>>
>
> The error is caused by ModelChoiceField.to_python()
>
> validating the existence of the selected item by calling get() on the
> queryset:
>
> value = self.queryset.get(**{key: value})
>
> And this is not supported for sliced querysets as the error above states.
> It might have been be a deliberate choice not to support this use case in
> ModelChoiceField though I don't see any comments about that in the code or
> any mentions in ModelChoiceField.queryset
>
> docs. I would also expect it to be a common need. This and the fact that it
> can be trivially solved by replacing get() with SQL INTERSECT (implemented
> as operator & in Django) makes me suspect that there would be some issue
> with that.
>
> Can anyone shed some light on this? Are there any performance or
> database-combatibility issues involved? Or is it just a bug?
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e264b254-4208-4e39-a50b-6657f8817996%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1H_Kt101T8-Qd7nJ%2BMFVbR0voQVaHGifUUiQGFWGiwi2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
