Re: Proposal for prepared statements API

[Anssi Kääriäinen]

On 03/26/2014 06:06 AM, Curtis Maloney wrote:



Further, as an "expert" feature, would it be unreasonable to
limit its use to cases where you know it will benefit, but
also only be used in a single connection?  True, this limits
its use cases somewhat, but it's still available when of benefit.


What do you mean by "single connection", persistent connections
are single connections and as you said above prepared statements
are local to the connection/session anyways…


And I would expect the prepared statement to persist between requests 
in that case.


If I thought we could rely on DB dis/connect signals [maybe we can, I 
don't know yet] we could teach prepared statements to track that and 
re-prepare themselves  on first use.


Just throwing ideas out there... seeing which ones excite :)
Django must know which connections have which statements prepared, and 
Django must also know the name for each prepared statement.


We can do this by having a map of SQL for the statement -> name of the 
prepared statement in the connection. On connection close the known 
statements are cleaned. An alternate way to do this is to have a 
connection -> prepared statement name map in the statement object 
itself. In that case connection close signals must be used to clean the 
map. This might be a cleaner design as connection object doesn't need to 
know about prepared statements. As a bonus we don't need to map SQL to 
statement names. The problem being that the same SQL doesn't necessarily 
mean we are executing the same plan (for example changes to search_path 
can cause problems here).


So, when you do ps = qs.prepare() you get a prepared statement object 
which knows the SQL needed for execution. When you do ps.execute() the 
statement object will check the used connection for existing prepared 
statements. If none exists, PREPARE is issued. If one exists, then the 
statement is reused.


I kind of like the ps = connection.prepare(qs) syntax. But this doesn't 
really solve anything, the connection variable is thread local, so doing 
ps = connection.prepare(qs) doesn't mean that the prepare is in effect 
in other threads. We still need to know which connections have which 
statements prepared. So, nothing is actually solved this way.


As for the foo=None/foo__isnull=True problems - I think we can do one 
step better than just documenting these cases, we can actually check if 
the given parameters lead to incorrect plan and raise an error on 
execute. I don't think we can prepare different plans for different 
statements - doing so can potentially mean preparing exponential amount 
of statements. We can't easily prepare different plans on execute either 
due to the way Django's QuerySet construction works.


 - Anssi

--
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/53328CD8.9040100%40thl.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Anssi Kääriäinen]

I'd like to solve this with a way to add methods to QuerySets. This 
would be useful for those who want get_or_none() or other similar 
shortcut methods which Django doesn't provide. But more importantly this 
would let third party apps to provide queryset methods.


If this was possible, then one could do something like this:

@register_qs_method
def get_or_none(self, *args, **kwargs):
try:
 return self.get(*args, **kwargs)
except ObjectDoesNotExist:
 return None

I don't know how ugly the magic needed for this would be. Quickly 
thinking the @register_qs_method doesn't need to do much else than 
assignment to QuerySet.__dict__. How to add the same method to 
dynamically created managers might be harder.


 - Anssi

On 03/26/2014 01:40 AM, Russell Keith-Magee wrote:


On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner 
mailto:f.apollo...@gmail.com>> wrote:


On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming
[Simplicity Media Ltd] wrote:

I'll give it a couple more days for a BDFL to gives the thumbs
up/down.


Well, we don't have BDFLs anymore and Shai already said he is -0
on it, count me in with a relatively strong -0 too. I'd be a bit
more open to it if you could a better name. That said I generally
agree with Shai about the validation, eg this should be handled by
the database constraints already -- otherwise selecting via get
doesn't make much sense imo.

Count me as a -0 as well. I simply don't see the problem with catching 
exceptions. Changing the name doesn't modify my objections.


I'm probably a true neutral 0 on a django.shortcuts method mirroring 
get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was 
proposing). I still don't see the point, but at least it's in a 
shortcuts module, and clearly labelled as such, not a method on a 
manager duplicating existing functionality.


Yours,
Russ Magee %-)

--
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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%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 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/53328F22.7000606%40thl.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Russell Keith-Magee]

On Wed, Mar 26, 2014 at 4:26 PM, Anssi Kääriäinen
wrote:

>  I'd like to solve this with a way to add methods to QuerySets. This
> would be useful for those who want get_or_none() or other similar shortcut
> methods which Django doesn't provide. But more importantly this would let
> third party apps to provide queryset methods.
>
> If this was possible, then one could do something like this:
>
> @register_qs_method
> def get_or_none(self, *args, **kwargs):
> try:
>  return self.get(*args, **kwargs)
> except ObjectDoesNotExist:
>  return None
>
>
Isn't this already possible by defining a custom queryset? And even easier
in 1.7 with the introduction of .as_manager()?

The only thing the custom Queryset approach doesn't allow is to monkey
patch the get_or_none method into *all* managers by default - but frankly,
I see that as a good thing.

Yours,
Russ Magee %-)

-- 
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/CAJxq849VqOGYmeqaVLnV78WpfS157N23bvE1hVHBUod6GMuGDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Anssi Kääriäinen]

On 03/26/2014 10:46 AM, Russell Keith-Magee wrote:
Isn't this already possible by defining a custom queryset? And even 
easier in 1.7 with the introduction of .as_manager()?


The only thing the custom Queryset approach doesn't allow is to monkey 
patch the get_or_none method into *all* managers by default - but 
frankly, I see that as a good thing.

Yeah, this should be possible.

I was thinking of solving the problem when one has two different base 
classes for a model. Creating automatically a queryset + manager for the 
model could be a nice addition. Something like using GIS + django-mptt 
simultaneously for a model, and then both of those automatically adding 
their queryset methods to the model's queryset. But, maybe this problem 
isn't worth solving (or more accurately, it is better solved explicitly 
by the user by providing a custom queryset inheriting from both 
GeoQuerySet and MPTTQuerySet).


 - Anssi

--
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/53329873.7010602%40thl.fi.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Curtis Maloney]

You could (ab)use MethodType to add a new method to the class, but you'd
want to make sure the Manager was using a custom QuerySet first [or force
it to if it weren't] so as not to alter it for all default Managers.

Just my 0.02 units of currency.

--
C



On 26 March 2014 19:26, Anssi Kääriäinen  wrote:

>  I'd like to solve this with a way to add methods to QuerySets. This
> would be useful for those who want get_or_none() or other similar shortcut
> methods which Django doesn't provide. But more importantly this would let
> third party apps to provide queryset methods.
>
> If this was possible, then one could do something like this:
>
> @register_qs_method
> def get_or_none(self, *args, **kwargs):
> try:
>  return self.get(*args, **kwargs)
> except ObjectDoesNotExist:
>  return None
>
> I don't know how ugly the magic needed for this would be. Quickly thinking
> the @register_qs_method doesn't need to do much else than assignment to
> QuerySet.__dict__. How to add the same method to dynamically created
> managers might be harder.
>
>  - Anssi
>
>
> On 03/26/2014 01:40 AM, Russell Keith-Magee wrote:
>
>
>  On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner  > wrote:
>
>>  On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity
>> Media Ltd] wrote:
>>>
>>> I'll give it a couple more days for a BDFL to gives the thumbs up/down.
>>>
>>
>> Well, we don't have BDFLs anymore and Shai already said he is -0 on it,
>> count me in with a relatively strong -0 too. I'd be a bit more open to it
>> if you could a better name. That said I generally agree with Shai about the
>> validation, eg this should be handled by the database constraints already
>> -- otherwise selecting via get doesn't make much sense imo.
>>
>
> Count me as a -0 as well. I simply don't see the problem with catching
> exceptions. Changing the name doesn't modify my objections.
>
>  I'm probably a true neutral 0 on a django.shortcuts method mirroring
> get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was
> proposing). I still don't see the point, but at least it's in a shortcuts
> module, and clearly labelled as such, not a method on a manager duplicating
> existing functionality.
>
>  Yours,
> Russ Magee %-)
>
>   --
> 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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%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 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/53328F22.7000606%40thl.fi
> .
>
> 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/CAG_XiSAvnwtx%2BO7Sv9QA9h0te1Nxb%2BT5vLmAhcHOCy8asOHjog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Bernie Sumption]

>
> we can't promote adding random strings to MIGRATION_MODULES as the 
> suggested way to "get around" migrations for tests.
>

I agree, my workaround is a hack. It would be better to introduce a flag or 
setting designed specifically for this use case.
 

> In my opinion, the whole point of migrations is that you know you have the 
> same schema everywhere, and it's especially important you use them during 
> tests.
>

If you view tests as a verification tool that is used before deployment or 
committing to check that the system is working as desired then yes, this is 
true. If you're practicing TDD, then tests are something else too - they're 
a development environment. They're the primary way of interacting with your 
code. Add a field, run tests. Rename it, run tests. Change its options, run 
tests.

The fact is, Django 1.6 and South supported this use case very well, Django 
1.7 does not.

-- 
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/ac7d9f74-691f-4ec8-8900-434f8e0a93ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Introduction and task proposal

[Daniel Pyrathon]

Hi all,

It's been a while since I submitted my GSOC proposal. Although I am 
currently under exams, is there anything you would recommend me to do at 
this point (other than hope that my proposal is successful)?

Thanks,
Daniel Pyrathon

On Thursday, March 20, 2014 6:05:40 AM UTC, Russell Keith-Magee wrote:
>
>
> For the benefit of those reading along at home; I gave some revised notes 
> and had a conversation with Daniel on IRC a couple of hours ago.
>
> Yours,
> Russ Magee %-)
>
>
> On Thu, Mar 20, 2014 at 4:10 AM, Daniel Pyrathon 
> 
> > wrote:
>
>> Hi!
>>
>> Thanks for all the comments yesterday. They really helped me make the 
>> proposal stronger.
>> I have changed to proposal to reflect the changes. Would anyone like to 
>> have a look and, possibly, comment more?
>>
>>
>> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#heading=h.wyxx4xxijubt
>>
>> Thanks,
>> Dan
>>
>> On Wednesday, March 19, 2014 7:32:10 AM UTC, Aymeric Augustin wrote:
>>
>>> On 19 mars 2014, at 06:27, Zach Borboa  wrote: 
>>>
>>> > Curious, how do you get REPL shell access to the server with 
>>> DEBUG=True with a vanilla Django deployment? 
>>>
>>> That part of the discussion was about adding the werkzeug interactive 
>>> debugger to Django’s default error page. 
>>>
>>> -- 
>>> Aymeric. 
>>>
>>>
>>>
>>>
>>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/16264cb7-3f44-434d-865a-8c33baa4d921%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/ad5d6016-2c6a-45b4-91c8-0e4500befc74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Cal Leeming [Simplicity Media Ltd]]

On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner 
> wrote:
>
>> On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity
>> Media Ltd] wrote:
>>>
>>> I'll give it a couple more days for a BDFL to gives the thumbs up/down.
>>>
>>
>> Well, we don't have BDFLs anymore and Shai already said he is -0 on it,
>> count me in with a relatively strong -0 too. I'd be a bit more open to it
>> if you could a better name. That said I generally agree with Shai about the
>> validation, eg this should be handled by the database constraints already
>> -- otherwise selecting via get doesn't make much sense imo.
>>
>
> Count me as a -0 as well. I simply don't see the problem with catching
> exceptions. Changing the name doesn't modify my objections.
>

Then why did first() [1] get added? The only difference is that first()
adds a reference to [0], but it still saves the equal amount of code and is
still there for the same reasons of convenience, no?

[1]
https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first


>
> I'm probably a true neutral 0 on a django.shortcuts method mirroring
> get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was
> proposing). I still don't see the point, but at least it's in a shortcuts
> module, and clearly labelled as such, not a method on a manager duplicating
> existing functionality.
>
> Yours,
> Russ Magee %-)
>
>  --
> 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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%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 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/CAHKQagHBH%2BCH2w%2BKtbbRPcjn6EW9HKnbEqDd5pvPf2pD-fPBiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for prepared statements API

[Aymeric Augustin]

2014-03-26 9:16 GMT+01:00 Anssi Kääriäinen :

> We can do this by having a map of SQL for the statement -> name of the
> prepared statement in the connection. On connection close the known
> statements are cleaned.


Yes, that seems correct.

Since prepared statements are connection-local, it makes sense to store
them on the connection object.

-- 
Aymeric.

-- 
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/CANE-7mUdvySSqdQ16qGrb%3DEMezbAZY0u7hkrHKH81p7WwudgBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Wim Feijen]

Hi Cal,

When we proposed to add get_or_none() , we actually ended up adding a 
first() -method. The primary motives were to have a clearer name and to 
stay in line with other existing api's.

In my opinion, get_or_none is too much a duplicate of first and I am 
therefore -1 of it being added. 

For those interested, I will copy the message of BDFL Jacob here:

Hi! 

After thinking a bit, I'm +1 on the idea, and I think 
`Queryset.first()` is the right name (which implies we should probably 
have a `last()` for completion). 

This mirrors the name used by a few other ORM/collection APIs that I 
think have really nice APIS: 

* SQLalchemy 
(http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first)
 
* Storm 
(http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first) 
* Backbone (http://backbonejs.org/#Collection-Underscore-Methods / 
http://documentcloud.github.com/underscore/#first) 

If someone produces a patch I'll review it and commit it. 

Jacob 

This was written as a response to Anssi's message:

For the record, I still do like this idea, specifically .get_or_none().

It seems there is significant support for this idea. I do think this method 
is Pythonic. There are cases where no match from get() isn't exceptional, 
and in such cases try-except just feels wrong.

The counter argument is that this is API bloat, and this will set an 
example for more API bloat.

In the end this is a decision with almost no technical considerations and a 
lot of "good taste" considerations. So, this seems like BDFL area.

If there are no signs from BDFL that .get_or_none() is acceptable, then 
lets bury this one. If it is acceptable, then I am willing to do all the 
work to get this committed.

 - Anssi

The whole thread is here:
https://groups.google.com/forum/#!searchin/django-developers/get_or_none$20jacob$20first/django-developers/3RwDxWKPZ_A/KNzxgP8L-V0J

Regards, Wim

On Wednesday, 26 March 2014 13:19:47 UTC+1, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
>
>
>
> On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner 
>> 
>> > wrote:
>>
>>> On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity 
>>> Media Ltd] wrote:

 I'll give it a couple more days for a BDFL to gives the thumbs up/down.

>>>  
>>> Well, we don't have BDFLs anymore and Shai already said he is -0 on it, 
>>> count me in with a relatively strong -0 too. I'd be a bit more open to it 
>>> if you could a better name. That said I generally agree with Shai about the 
>>> validation, eg this should be handled by the database constraints already 
>>> -- otherwise selecting via get doesn't make much sense imo.
>>>
>>  
>> Count me as a -0 as well. I simply don't see the problem with catching 
>> exceptions. Changing the name doesn't modify my objections.
>>
>
> Then why did first() [1] get added? The only difference is that first() 
> adds a reference to [0], but it still saves the equal amount of code and is 
> still there for the same reasons of convenience, no?
>
> [1] 
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first
>  
>
>>
>> I'm probably a true neutral 0 on a django.shortcuts method mirroring 
>> get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was 
>> proposing). I still don't see the point, but at least it's in a shortcuts 
>> module, and clearly labelled as such, not a method on a manager duplicating 
>> existing functionality.
>>
>> Yours,
>> Russ Magee %-)
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%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 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/1ef75fc6-90c2-4d70-9aa0-d2c1cac25c49%40googlegroups.com.
For more options, visit https://groups.g

Re: Migrations in Django 1.7 make unit testing models harder

[Andrew Godwin]

When I practice TDD I write the test to spec, and then write the model and
view code, so I usually have about the same amount of model changes as
otherwise (as, having written the tests, I usually have a clearer idea of
what fields I need). I agree that if you're incrementally writing tests on
top of models, however, it could be extra verbose, but bear in mind that
having hundreds of migrations on 1.7 is easily solved by a single
`squashmigrations` command - much easier than on South (and performance on
large migration sets should also be improved).

I'd be willing to keep the current contract of "things without a migrations
directory don't get migrated", but I suspect you're doing things on apps
that already have migrations (which makes my reticence to add a setting
even bigger - if you "syncdb" an app with migrations to a main database,
you have forever ruined the migration tracking on it). Would that work? Or
do you want to do this on apps which are already several migrations along?
(If that's the case, I suspect we might have to look at re-introducing
--update, which is going to be near-impossible to do before release with
the new creation system).

Andrew


On Wed, Mar 26, 2014 at 3:13 AM, Bernie Sumption wrote:

> we can't promote adding random strings to MIGRATION_MODULES as the
>> suggested way to "get around" migrations for tests.
>>
>
> I agree, my workaround is a hack. It would be better to introduce a flag
> or setting designed specifically for this use case.
>
>
>> In my opinion, the whole point of migrations is that you know you have
>> the same schema everywhere, and it's especially important you use them
>> during tests.
>>
>
> If you view tests as a verification tool that is used before deployment or
> committing to check that the system is working as desired then yes, this is
> true. If you're practicing TDD, then tests are something else too - they're
> a development environment. They're the primary way of interacting with your
> code. Add a field, run tests. Rename it, run tests. Change its options, run
> tests.
>
> The fact is, Django 1.6 and South supported this use case very well,
> Django 1.7 does not.
>
> --
> 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/ac7d9f74-691f-4ec8-8900-434f8e0a93ff%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/CAFwN1ur8KPPfKP-5tOs7j7nTzQCJr-ehVJqz51OJq-02FG_Grg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Paulo Poiati]

Well, I think this kind of feature is in the same category of my request: 
https://groups.google.com/forum/#!topic/django-developers/N6xazCaJC_E. I 
haven’t received so many feedbacks though.

It’s all about writing less code to reach the goal. I belive too much 
abstraction is not a good thing for a framework, but in common cases, like link 
the above, I think it’s ok.

I agree with some guys here, in the case of #get_or_none, manager#first almost 
always fit the role. So, I’m neutral in regard of that.



— 
[]’s
Paulo Poiati
blog.paulopoiati.com

On March 26, 2014 at 12:24:21 PM, Wim Feijen (w...@go2people.nl) wrote:

Hi Cal,

When we proposed to add get_or_none() , we actually ended up adding a first() 
-method. The primary motives were to have a clearer name and to stay in line 
with other existing api's.

In my opinion, get_or_none is too much a duplicate of first and I am therefore 
-1 of it being added. 

For those interested, I will copy the message of BDFL Jacob here:

Hi! 

After thinking a bit, I'm +1 on the idea, and I think 
`Queryset.first()` is the right name (which implies we should probably 
have a `last()` for completion). 

This mirrors the name used by a few other ORM/collection APIs that I 
think have really nice APIS: 

* SQLalchemy 
(http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first)
 
* Storm 
(http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first) 
* Backbone (http://backbonejs.org/#Collection-Underscore-Methods / 
http://documentcloud.github.com/underscore/#first) 

If someone produces a patch I'll review it and commit it. 

Jacob 

This was written as a response to Anssi's message:

For the record, I still do like this idea, specifically .get_or_none().

It seems there is significant support for this idea. I do think this method is 
Pythonic. There are cases where no match from get() isn't exceptional, and in 
such cases try-except just feels wrong.

The counter argument is that this is API bloat, and this will set an example 
for more API bloat.

In the end this is a decision with almost no technical considerations and a lot 
of "good taste" considerations. So, this seems like BDFL area.

If there are no signs from BDFL that .get_or_none() is acceptable, then lets 
bury this one. If it is acceptable, then I am willing to do all the work to get 
this committed.

 - Anssi

The whole thread is here:
https://groups.google.com/forum/#!searchin/django-developers/get_or_none$20jacob$20first/django-developers/3RwDxWKPZ_A/KNzxgP8L-V0J

Regards, Wim

On Wednesday, 26 March 2014 13:19:47 UTC+1, Cal Leeming [Simplicity Media Ltd] 
wrote:



On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee  
wrote:

On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner  wrote:
On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity Media 
Ltd] wrote:
I'll give it a couple more days for a BDFL to gives the thumbs up/down.
 
Well, we don't have BDFLs anymore and Shai already said he is -0 on it, count 
me in with a relatively strong -0 too. I'd be a bit more open to it if you 
could a better name. That said I generally agree with Shai about the 
validation, eg this should be handled by the database constraints already -- 
otherwise selecting via get doesn't make much sense imo.
 
Count me as a -0 as well. I simply don't see the problem with catching 
exceptions. Changing the name doesn't modify my objections.

Then why did first() [1] get added? The only difference is that first() adds a 
reference to [0], but it still saves the equal amount of code and is still 
there for the same reasons of convenience, no?

[1] 
https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first
 

I'm probably a true neutral 0 on a django.shortcuts method mirroring 
get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was 
proposing). I still don't see the point, but at least it's in a shortcuts 
module, and clearly labelled as such, not a method on a manager duplicating 
existing functionality.

Yours,
Russ Magee %-)

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%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 django-developers@googlegroups.com.
Visit

Re: Using namedtuple instead of pure tuples

[Adam Kaliński]

Hi, 

I improved my benchmarks: http://nbviewer.ipython.org/gist/adamkal/9171081

Alex was right about those variables and new benchmarks have proved it. 

I also created a draft of how it might look like for 
Options.get_field_by_name (as this returns 4-tuple):
https://github.com/adamkal/django/compare/namedtuple_draft
This is only a draft as I said. I think this might not be a good idea to 
change all index lookups to attr, but this example might show how this 
change would impact the code.  

What do you think? Is it worth changing? There are more places that might 
use such change also but get_fields_by_name sounds like good place to 
start. 

W dniu poniedziałek, 24 lutego 2014 09:43:43 UTC+1 użytkownik Adam Kaliński 
napisał:
>
> Good tips. Thanks! I'll improve them and post as soon as they're ready. 
> Moreover I was thinking that it might be nice to just modify Django to use 
> namedtuples and see how will that influence execution. The problem is that 
> it might be difficult to create reliable tests.  
> If you think that there is anything more missing please let me know.
>
> W dniu poniedziałek, 24 lutego 2014 03:01:07 UTC+1 użytkownik Alex_Gaynor 
> napisał:
>>
>> FWIW these benchmaks are not measuring accurately. Creating a tuple of 
>> the form "(1, 2, 3)" (notably, where all the members are literal constants) 
>> takes NO time actually, since it's an immutable container of all immutable 
>> items, the compiler is able to factor the work out. A benchmark, even as 
>> idiotically simple as:
>>
>> "a = 1; (1, 2, a)" would more accurately mirror the real world.
>>
>> Alex
>>
>>
>> On Sun, Feb 23, 2014 at 7:57 PM, Russell Keith-Magee <
>> rus...@keith-magee.com> wrote:
>>
>>>
>>> Hi Stratos,
>>>
>>> Thanks for providing those benchmarks -- that's really helpful. 
>>>
>>> However, It's all well and good to say that "Doing X takes 0.01s" or "X 
>>> is 50% slower than Y", but that if the time taken to do X is incredibly 
>>> small to start with, a 50% slowdown doesnt really matter that much. The 
>>> fact that namedtuple is slower than tuple is clear from your data; what 
>>> isn't clear is how much we should be concerned. Unfortunately, the raw time 
>>> data doesn't tell us how fast or slow your test machine is. 
>>>
>>> If you can provide a baseline for comparison, that would be very 
>>> helpful. In the past when we've done benchmarks, we've used:
>>>
>>>  * Invoking a no-op (i.e., pass)
>>>  * Invoking a function that performs a no-op.
>>>
>>> This essentially gives us an indication for the order of magnitude of 
>>> the time values you've provided, and allows us to say "creating a named 
>>> tuple has the same overhead as a single function call", (or 10 function 
>>> calls, or whatever is appropriate). This puts the benchmark into concrete 
>>> terms - nobody would do a code review and say "you need to remove 1 
>>> function call for speed purposes", but they might say "these 1000 function 
>>> calls seem excessive". 
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>>
>>> On Sun, Feb 23, 2014 at 2:01 AM, Stratos Moros  wrote:
>>>
 Completely unscientific microbenchmarks: 
 (gist
 )

 >>> from timeit import Timer

 ## creation
 # tuple
 >>> Timer('(1, 2, 3, 4, 5)').timeit()
 0.02694106101989746

 # namedtuple with args
 >>> Timer('T(1, 2, 3, 4, 5)', setup='''
 from collections import namedtuple
 T = namedtuple("T", "a b c d e")'''
 ).timeit()
 0.773979902267456

 # namedtuple with kwargs
 >>> Timer('T(a=1, b=2, c=3, d=4, e=5)', setup='''
 from collections import namedtuple
 T = namedtuple("T", "a b c d e")'''
 ).timeit()
 1.155663013458252 

 ## item access
 # tuple
 >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='t = (1, 2, 3, 4, 
 >>> 5)').timeit()
 0.3240630626678467

 # namedtuple with indices
 >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='''
 from collections import namedtuple
 T = namedtuple("T", "a b c d e")
 t = T(1, 2, 3, 4, 5)'''
 ).timeit()
 0.2994410991668701

 # namedtuple with attributes
 >>> Timer('t.a, t.b, t.c, t.d, t.e', setup='''
 from collections import namedtuple
 T = namedtuple("T", "a b c d e")
 t = T(1, 2, 3, 4, 5)'''
 ).timeit()
 0.9363529682159424

 It seems that the only significant slowdown is on a namedtuple's 
 creation. I imagine the impact would be negligible on a complete 
 request-response cycle, but that would have to be tested.

 Accessing a namedtuple's items using attributes is also somewhat 
 slower, but this wouldn't be a problem. Existing code would continue to 
 work with the same performance and users could decide for themselves which 
 way to access a namedtuple's items for new code.
  
 On 22 Feb 2014, at 18:37, Florian Apolloner wrote:

 On Saturday, February 22, 2014

Re: [GSOC] Introduction and task proposal

[Russell Keith-Magee]

Hi Daniel,

Nope - other than "cross your fingers" that your proposal is accepted :-)

But seriously...

If you haven't already, I'd suggest reading Django's contribution docs, and
getting your development environment set up. Make sure you can run Django's
test suite. If you're particularly enthused, try your hand at working on a
patch for an open ticket so you can get used to the toolchain and the
review process. That way you'll be up to speed with Django's development
process, so when the GSoC period starts, you'll be comfortable with our
basic process, so you'll just have to deal with the actual GSoC work.

Yours,
Russ Magee %-)

On Wed, Mar 26, 2014 at 7:22 PM, Daniel Pyrathon  wrote:

> Hi all,
>
> It's been a while since I submitted my GSOC proposal. Although I am
> currently under exams, is there anything you would recommend me to do at
> this point (other than hope that my proposal is successful)?
>
> Thanks,
> Daniel Pyrathon
>
>
> On Thursday, March 20, 2014 6:05:40 AM UTC, Russell Keith-Magee wrote:
>
>>
>> For the benefit of those reading along at home; I gave some revised notes
>> and had a conversation with Daniel on IRC a couple of hours ago.
>>
>> Yours,
>> Russ Magee %-)
>>
>>
>> On Thu, Mar 20, 2014 at 4:10 AM, Daniel Pyrathon wrote:
>>
>>> Hi!
>>>
>>> Thanks for all the comments yesterday. They really helped me make the
>>> proposal stronger.
>>> I have changed to proposal to reflect the changes. Would anyone like to
>>> have a look and, possibly, comment more?
>>>
>>> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFB
>>> kCXgy0Jwo/edit#heading=h.wyxx4xxijubt
>>>
>>> Thanks,
>>> Dan
>>>
>>> On Wednesday, March 19, 2014 7:32:10 AM UTC, Aymeric Augustin wrote:
>>>
 On 19 mars 2014, at 06:27, Zach Borboa  wrote:

 > Curious, how do you get REPL shell access to the server with
 DEBUG=True with a vanilla Django deployment?

 That part of the discussion was about adding the werkzeug interactive
 debugger to Django's default error page.

 --
 Aymeric.




  --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/16264cb7-3f44-434d-865a-
>>> 8c33baa4d921%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/ad5d6016-2c6a-45b4-91c8-0e4500befc74%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/CAJxq849CfFVLdgWD_Q3d-%2Bpk4%3DMX%3DWLzd%2BqNbQZHOZ%2Bumg_tjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Russell Keith-Magee]

On Wed, Mar 26, 2014 at 8:19 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

>
>
>
> On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner > > wrote:
>>
>>> On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity
>>> Media Ltd] wrote:

 I'll give it a couple more days for a BDFL to gives the thumbs up/down.

>>>
>>> Well, we don't have BDFLs anymore and Shai already said he is -0 on it,
>>> count me in with a relatively strong -0 too. I'd be a bit more open to it
>>> if you could a better name. That said I generally agree with Shai about the
>>> validation, eg this should be handled by the database constraints already
>>> -- otherwise selecting via get doesn't make much sense imo.
>>>
>>
>> Count me as a -0 as well. I simply don't see the problem with catching
>> exceptions. Changing the name doesn't modify my objections.
>>
>
> Then why did first() [1] get added? The only difference is that first()
> adds a reference to [0], but it still saves the equal amount of code and is
> still there for the same reasons of convenience, no?
>

first() was primarily added as an analog for latest().

Personally, I see a significant difference between first()/latest() and
get_or_none().

first()/latest() is a specific, common query that has been optimized: list
all, order by X, give me the first one.

get_or_none() is a second version of an existing query: get(), but with a
different return value. To me, this is duplication of an API, not a
different query.

In my ideal world, the get(default=None) approach would be what we would
do; but, as others have pointed out, default is a valid column name, so
this option isn't available to us. We already have a shortcut for
get_object_or_404; a matching get_object_or_none makes sense to me, and
puts the API where it make sense to me - as a shortcut for someone who is
repeating the "catch DoesNotExist" pattern regularly and wants an easier
way.

Yours,
Russ Magee %-)

-- 
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/CAJxq84_281FRq4eJ6mxjBfWREi_50naTg%2B6mcvLBKSozeQwjYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Anssi Kääriäinen]

On Thursday, March 27, 2014 3:10:13 AM UTC+2, Russell Keith-Magee wrote:
>
> In my ideal world, the get(default=None) approach would be what we would 
> do; but, as others have pointed out, default is a valid column name, so 
> this option isn't available to us. We already have a shortcut for 
> get_object_or_404; a matching get_object_or_none makes sense to me, and 
> puts the API where it make sense to me - as a shortcut for someone who is 
> repeating the "catch DoesNotExist" pattern regularly and wants an easier 
> way.
>

Actually I think we could use .get(default=None). The way to do this is:
  1. Deprecate direct use of .get(default=lookup_value), instead ask users 
to do .get(Q(default=lookup_value)).
  2. After deprecation, add support for 
.get(default=default_if_no_match_value)

This is somewhat confusing API - if you have a column named default, users 
*will* try to do .get(default=lookup_value), no matter how much we document 
this special case. OTOH I don't believe having field named default is that 
common.

Another similar idea is to add support for .get(__default=None). One can't 
have a field named __default, or at least it won't work in any sane way 
with the ORM.

Any support for these ideas?

 - Anssi

-- 
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/3cc0d818-f02b-4659-b611-3b36c7e8ff99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Introduction and task proposal

[Josh Smeaton]

If you haven't already got all your databases installed on your development 
machine, I *highly* recommend checking out 
https://github.com/jphalip/djangocore-box. It's a vagrant VM environment 
that already has MySQL, PostgreSQL, and SQLite installed (plus most GIS 
installations), along with various versions of python. Unfortunately it 
doesn't have Oracle - but being able to run tests on 3/4 databases is 
especially handy.

Josh

On Thursday, 27 March 2014 11:14:35 UTC+11, Russell Keith-Magee wrote:
>
>
> Hi Daniel,
>
> Nope - other than "cross your fingers" that your proposal is accepted :-)
>
> But seriously…
>
> If you haven't already, I'd suggest reading Django's contribution docs, 
> and getting your development environment set up. Make sure you can run 
> Django's test suite. If you're particularly enthused, try your hand at 
> working on a patch for an open ticket so you can get used to the toolchain 
> and the review process. That way you'll be up to speed with Django's 
> development process, so when the GSoC period starts, you'll be comfortable 
> with our basic process, so you'll just have to deal with the actual GSoC 
> work.
>
> Yours,
> Russ Magee %-)
>
> On Wed, Mar 26, 2014 at 7:22 PM, Daniel Pyrathon 
> 
> > wrote:
>
>> Hi all,
>>
>> It's been a while since I submitted my GSOC proposal. Although I am 
>> currently under exams, is there anything you would recommend me to do at 
>> this point (other than hope that my proposal is successful)?
>>
>> Thanks,
>> Daniel Pyrathon
>>
>>
>> On Thursday, March 20, 2014 6:05:40 AM UTC, Russell Keith-Magee wrote:
>>
>>>
>>> For the benefit of those reading along at home; I gave some revised 
>>> notes and had a conversation with Daniel on IRC a couple of hours ago.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>>
>>> On Thu, Mar 20, 2014 at 4:10 AM, Daniel Pyrathon wrote:
>>>
 Hi!

 Thanks for all the comments yesterday. They really helped me make the 
 proposal stronger.
 I have changed to proposal to reflect the changes. Would anyone like to 
 have a look and, possibly, comment more?

 https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFB
 kCXgy0Jwo/edit#heading=h.wyxx4xxijubt

 Thanks,
 Dan

 On Wednesday, March 19, 2014 7:32:10 AM UTC, Aymeric Augustin wrote:

> On 19 mars 2014, at 06:27, Zach Borboa  wrote: 
>
> > Curious, how do you get REPL shell access to the server with 
> DEBUG=True with a vanilla Django deployment? 
>
> That part of the discussion was about adding the werkzeug interactive 
> debugger to Django’s default error page. 
>
> -- 
> Aymeric. 
>
>
>
>
>  -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/16264cb7-3f44-434d-865a-
 8c33baa4d921%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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/ad5d6016-2c6a-45b4-91c8-0e4500befc74%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/70eba10d-cd77-4579-ad3c-ac4be8da6849%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.