Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'll drop it. Someone else can chime in if they want. Just to be clear, the 
work you all do on Django is much appreciated :) 

Thanks,
Dave
On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote:

> On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert  wrote:
>
>> Yeah, I hope I'm not coming off as being too pushy, but I'm just curious 
>> why that is. Mariusz or Adam, did what I said about it being *more* than 
>> just an alias for `filter().first()` make sense or am I missing something? 
>> (Different behavior for multiple results — on accident or otherwise)
>>
>
> Speaking for myself:
>
> I’d be against it because we’re getting into combinatorial territory with 
> diminishing returns. Adding this one opens the door to equally long and 
> repetitive threads in the future asking for all the others, and with less 
> room to push back each time.
>
> Currently, Django covers the common cases of “if you didn’t find a match, 
> 404” and “if there’s not exactly one result for this, throw an exception 
> and let me catch it”. The fact that you can make other variants kinda work 
> if you use first() or similar methods doesn’t, to me, obligate Django to 
> also provide the full matrix of methods doing all the someone-might-want-it 
> combinations of DoesNotExist, MultipleObjectsReturned, and None. People who 
> want specific behaviors not covered by the built-in stuff should write 
> their own, or somebody should make a 
> django-all-the-get-single-object-methods package and everybody who wants 
> one of these methods can install and use it.
>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c9d2559-6904-42c8-a1bf-a49904a9e4dan%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[James Bennett]

On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert 
wrote:

> Yeah, I hope I'm not coming off as being too pushy, but I'm just curious
> why that is. Mariusz or Adam, did what I said about it being *more* than
> just an alias for `filter().first()` make sense or am I missing something?
> (Different behavior for multiple results — on accident or otherwise)
>

Speaking for myself:

I’d be against it because we’re getting into combinatorial territory with
diminishing returns. Adding this one opens the door to equally long and
repetitive threads in the future asking for all the others, and with less
room to push back each time.

Currently, Django covers the common cases of “if you didn’t find a match,
404” and “if there’s not exactly one result for this, throw an exception
and let me catch it”. The fact that you can make other variants kinda work
if you use first() or similar methods doesn’t, to me, obligate Django to
also provide the full matrix of methods doing all the someone-might-want-it
combinations of DoesNotExist, MultipleObjectsReturned, and None. People who
want specific behaviors not covered by the built-in stuff should write
their own, or somebody should make a
django-all-the-get-single-object-methods package and everybody who wants
one of these methods can install and use it.

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_UjHey%3DnTq8y0zycbCAQe9Cx%3DMh%2BaVFDu1hjukmae3pg%40mail.gmail.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

> I'm not the first to suggest adding an additional shortcut, e.g. 
django.shortcuts.get_object_or_none which would work similarly to 
get_object_or_404

Personally I'm not a fan of it being in "shortcuts". It makes sense to me 
that the 404 ones are there because they are only useful in a 
request/response lifecycle. Seems like a good call to keep that out of the 
standard queryset methods. But `get_or_none` could be used anywhere, and 
ergonomically (?) it makes more sense to me that people (especially people 
new to Django) would naturally find and use it if it were right next to 
`get` and `get_or_create` (in docs, autocomplete, search in your codebase, 
etc.).

> I believe the main objection is against adding additional API to 
querysets.

Yeah, I hope I'm not coming off as being too pushy, but I'm just curious 
why that is. Mariusz or Adam, did what I said about it being *more* than 
just an alias for `filter().first()` make sense or am I missing something? 
(Different behavior for multiple results — on accident or otherwise)

Dave
On Monday, July 11, 2022 at 1:06:04 AM UTC-5 m...@feinheit.ch wrote:

> Hi
>
> I believe the main objection is against adding additional API to 
> querysets. get_object_or_404 only converts DoesNotExist into a 404 
> exception and doesn't handle MultipleObjectsReturned. 
>
> I'm not the first to suggest adding an additional shortcut, e.g. 
> django.shortcuts.get_object_or_none which would work similarly to 
> get_object_or_404 (and get_list_or_404 for that matter). The existing 
> shortcuts use functionality from several parts of Django (the ORM and the 
> request/response handling) which get_object_or_none wouldn't do, but its 
> behavior would be so close to what get_object_or_404 is doing that it may 
> be alright.
>
> OTOH even the implementation of this shortcut is so simple that I just add 
> it to each project when I have a need for it (I had a hard time finding it 
> because it comes up much less often than I thought it did). So I am not 
> proposing this addition personally but I wouldn't be against it either (if 
> that counts for anything).
>
> Best regards,
> Matthias
>
>
>
> def get_object_or_none(klass, *args, **kwargs):
> queryset = _get_queryset(klass)
> if not hasattr(queryset, "get"):
> klass__name = (
> klass.__name__ if isinstance(klass, type) else 
> klass.__class__.__name__
> )
> raise ValueError(
> "First argument to get_object_or_404() must be a Model, 
> Manager, "
> "or QuerySet, not '%s'." % klass__name
> )
> try:
> return queryset.get(*args, **kwargs)
> except queryset.model.DoesNotExist:
> return None
>
>
>
> On Sun, Jul 10, 2022 at 10:13 PM Dave Gaeddert  
> wrote:
>
>> Fair enough. To me, the `get_or_none` behavior with multiple results 
>> would still be to raise an exception (so it is just like `get` in that 
>> sense). And that’s the reason I personally don’t just see it as a shortcut 
>> for `filter().first()` — I have (as I’m sure others have) made the mistake 
>> before of *thinking* that I was using a unique query when that wasn’t 
>> necessarily true, so the multiple results exception has caught mistakes at 
>> runtime. I’d rather have that exception than use `filter().first()` and 
>> potentially show the wrong object to the wrong user, for example, and not 
>> figure out that I have a uniqueness/db problem. I like the fact that `get` 
>> raises those exceptions, I just think that try/except DoesNotExist/None is 
>> such a common behavior that a shortcut for *that* would actually be 
>> useful.
>>
>> Dave
>> On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:
>>
>>> I'm also against adding get_or_none(), for the same reasons. Adding a 
>>> method to shortcut something that can already be done doesn't seem worth it 
>>> to me.
>>>
>>> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak  
>>> wrote:
>>>
 I'm against it because it's already easily achievable and it's 
 debatable how it should behave with many results. IMO any new method would 
 be confusing and in the case of unique filtering 
 `get_or_none(unique_filters)` would be an alias for 
 `.filter(unique_filters).first()`. To me, this is duplication of an API.

 There are several -0 in the previous thread (Shai, Florian) and you can 
 count -1 from me.

 Best,
 Mariusz

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.

>>> To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-develop...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
  
 

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Matthias Kestenholz]

Hi

I believe the main objection is against adding additional API to querysets.
get_object_or_404 only converts DoesNotExist into a 404 exception and
doesn't handle MultipleObjectsReturned.

I'm not the first to suggest adding an additional shortcut, e.g.
django.shortcuts.get_object_or_none which would work similarly to
get_object_or_404 (and get_list_or_404 for that matter). The existing
shortcuts use functionality from several parts of Django (the ORM and the
request/response handling) which get_object_or_none wouldn't do, but its
behavior would be so close to what get_object_or_404 is doing that it may
be alright.

OTOH even the implementation of this shortcut is so simple that I just add
it to each project when I have a need for it (I had a hard time finding it
because it comes up much less often than I thought it did). So I am not
proposing this addition personally but I wouldn't be against it either (if
that counts for anything).

Best regards,
Matthias



def get_object_or_none(klass, *args, **kwargs):
queryset = _get_queryset(klass)
if not hasattr(queryset, "get"):
klass__name = (
klass.__name__ if isinstance(klass, type) else
klass.__class__.__name__
)
raise ValueError(
"First argument to get_object_or_404() must be a Model,
Manager, "
"or QuerySet, not '%s'." % klass__name
)
try:
return queryset.get(*args, **kwargs)
except queryset.model.DoesNotExist:
return None



On Sun, Jul 10, 2022 at 10:13 PM Dave Gaeddert 
wrote:

> Fair enough. To me, the `get_or_none` behavior with multiple results would
> still be to raise an exception (so it is just like `get` in that sense).
> And that’s the reason I personally don’t just see it as a shortcut for
> `filter().first()` — I have (as I’m sure others have) made the mistake
> before of *thinking* that I was using a unique query when that wasn’t
> necessarily true, so the multiple results exception has caught mistakes at
> runtime. I’d rather have that exception than use `filter().first()` and
> potentially show the wrong object to the wrong user, for example, and not
> figure out that I have a uniqueness/db problem. I like the fact that `get`
> raises those exceptions, I just think that try/except DoesNotExist/None is
> such a common behavior that a shortcut for *that* would actually be
> useful.
>
> Dave
> On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:
>
>> I'm also against adding get_or_none(), for the same reasons. Adding a
>> method to shortcut something that can already be done doesn't seem worth it
>> to me.
>>
>> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak 
>> wrote:
>>
>>> I'm against it because it's already easily achievable and it's debatable
>>> how it should behave with many results. IMO any new method would be
>>> confusing and in the case of unique filtering `get_or_none(unique_filters)`
>>> would be an alias for `.filter(unique_filters).first()`. To me, this is
>>> duplication of an API.
>>>
>>> There are several -0 in the previous thread (Shai, Florian) and you can
>>> count -1 from me.
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/dbee041d-4f80-4e61-bf0a-1d6f4e2e22e6n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANvPqgBCDjejMb_QrHpgZ%3DuZanCgCnwYb42-2-Mf8bmQ1cnL%3Dw%40mail.gmail.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

Fair enough. To me, the `get_or_none` behavior with multiple results would 
still be to raise an exception (so it is just like `get` in that sense). 
And that’s the reason I personally don’t just see it as a shortcut for 
`filter().first()` — I have (as I’m sure others have) made the mistake 
before of *thinking* that I was using a unique query when that wasn’t 
necessarily true, so the multiple results exception has caught mistakes at 
runtime. I’d rather have that exception than use `filter().first()` and 
potentially show the wrong object to the wrong user, for example, and not 
figure out that I have a uniqueness/db problem. I like the fact that `get` 
raises those exceptions, I just think that try/except DoesNotExist/None is 
such a common behavior that a shortcut for *that* would actually be useful.

Dave
On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:

> I'm also against adding get_or_none(), for the same reasons. Adding a 
> method to shortcut something that can already be done doesn't seem worth it 
> to me.
>
> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak  
> wrote:
>
>> I'm against it because it's already easily achievable and it's debatable 
>> how it should behave with many results. IMO any new method would be 
>> confusing and in the case of unique filtering `get_or_none(unique_filters)` 
>> would be an alias for `.filter(unique_filters).first()`. To me, this is 
>> duplication of an API.
>>
>> There are several -0 in the previous thread (Shai, Florian) and you can 
>> count -1 from me.
>>
>> Best,
>> Mariusz
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dbee041d-4f80-4e61-bf0a-1d6f4e2e22e6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

['Adam Johnson' via Django developers (Contributions to Django itself)]

I'm also against adding get_or_none(), for the same reasons. Adding a
method to shortcut something that can already be done doesn't seem worth it
to me.

On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak 
wrote:

> I'm against it because it's already easily achievable and it's debatable
> how it should behave with many results. IMO any new method would be
> confusing and in the case of unique filtering `get_or_none(unique_filters)`
> would be an alias for `.filter(unique_filters).first()`. To me, this is
> duplication of an API.
>
> There are several -0 in the previous thread (Shai, Florian) and you can
> count -1 from me.
>
> Best,
> Mariusz
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM20TNRrFpDamKu%2Bc_Dxxbh0KH5pJjxxmqYLjL6CNzAW7g%40mail.gmail.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Mariusz Felisiak]

I'm against it because it's already easily achievable and it's debatable 
how it should behave with many results. IMO any new method would be 
confusing and in the case of unique filtering `get_or_none(unique_filters)` 
would be an alias for `.filter(unique_filters).first()`. To me, this is 
duplication of an API.

There are several -0 in the previous thread (Shai, Florian) and you can 
count -1 from me.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

Hey Mariusz, thanks for the link — I found some other threads but not that 
one. Would you mind saying why you're personally against it (`get_or_none` 
specifically)?

At least how I read that thread, there was more debate about how to add it 
than whether to add it at all, and then Cal sort of "gave up" by suggesting 
a docs patch that I'm not sure ever happened anyway. I don't want to kick 
off a huge thing about it, but that one was 8 years ago and, like you said, 
it has come up a number of times over the years (maybe that's normal). 

Thanks!
Dave
On Wednesday, July 6, 2022 at 11:35:36 PM UTC-5 Mariusz Felisiak wrote:

> Hi,
>
> Adding `get_or_none()` was discussed several times and was always 
> rejected. This thread 
>  
> has a nice summary. Personally, I'm still against it.
>
> Best,
> Mariusz
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46daf75f-bb6b-457a-8889-47b148b20d61n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Mariusz Felisiak]

Hi,

Adding `get_or_none()` was discussed several times and was always 
rejected. This thread 
 
has a nice summary. Personally, I'm still against it.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c0b5246-fb86-43df-bcd1-0d088f1ba84dn%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'm new to this... anybody know how the best way to push this forward? Or 
who can make a decision on whether something could/should be added to 
Django? I see some other tickets/discussions about basically the same thing:
https://code.djangoproject.com/ticket/17546

A lot has changed in 10+ years... seems like this could be reconsidered.

On Tuesday, June 28, 2022 at 9:27:52 AM UTC-5 Dave Gaeddert wrote:

> > To begin with - thats the place I dont like .get() at all. The fact that
> > it might end up with multiple objects is a nuisance, but we cannot do
> > much about it for API compat reasons
> > ...
>
> For what it's worth, I agree with what you're saying here too. Having a 
> `unique_or_none` (and maybe `unique`) with that field checking could be 
> cool, but in the interest of actually getting a change into Django, I 
> assume `get_or_none` without that behavior is a much easier place to start.
>
> On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de 
> wrote:
>
>> Well from my own habits to use .get() only for unique filtering (>80% on 
>> pks only) I also see some benefit of a .get_or_none() variant - it would 
>> stop writing those exception handler wrappers over and over halfway 
>> during project realization. A ready-to-go official way would reduce that 
>> to a conditional expression from line one on.
>>
>> > .get_or_none() probably should allow to query only pks and
>> > unique_together fields, so there will be no third state?
>>
>> To begin with - thats the place I dont like .get() at all. The fact that 
>> it might end up with multiple objects is a nuisance, but we cannot do 
>> much about it for API compat reasons. Idea - if we want such a changed 
>> behavior - maybe call it "unique_or_none()" to make the difference 
>> clear? If its called .get_or_none() imho it is better to stick to .get() 
>> behavior regarding multiple objects (still raising).
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e21c2c22-5ba2-4421-8724-fa3f7e8f0b19n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

> To begin with - thats the place I dont like .get() at all. The fact that
> it might end up with multiple objects is a nuisance, but we cannot do
> much about it for API compat reasons
> ...

For what it's worth, I agree with what you're saying here too. Having a 
`unique_or_none` (and maybe `unique`) with that field checking could be 
cool, but in the interest of actually getting a change into Django, I 
assume `get_or_none` without that behavior is a much easier place to start.

On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de wrote:

> Well from my own habits to use .get() only for unique filtering (>80% on 
> pks only) I also see some benefit of a .get_or_none() variant - it would 
> stop writing those exception handler wrappers over and over halfway 
> during project realization. A ready-to-go official way would reduce that 
> to a conditional expression from line one on.
>
> > .get_or_none() probably should allow to query only pks and
> > unique_together fields, so there will be no third state?
>
> To begin with - thats the place I dont like .get() at all. The fact that 
> it might end up with multiple objects is a nuisance, but we cannot do 
> much about it for API compat reasons. Idea - if we want such a changed 
> behavior - maybe call it "unique_or_none()" to make the difference 
> clear? If its called .get_or_none() imho it is better to stick to .get() 
> behavior regarding multiple objects (still raising).
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b630d7a0-d832-41d0-985b-a7ae7ac1f1b6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Jörg Breitbart]

Well from my own habits to use .get() only for unique filtering (>80% on 
pks only) I also see some benefit of a .get_or_none() variant - it would 
stop writing those exception handler wrappers over and over halfway 
during project realization. A ready-to-go official way would reduce that 
to a conditional expression from line one on.


> .get_or_none() probably should allow to query only pks and
> unique_together fields, so there will be no third state?

To begin with - thats the place I dont like .get() at all. The fact that 
it might end up with multiple objects is a nuisance, but we cannot do 
much about it for API compat reasons. Idea - if we want such a changed 
behavior - maybe call it "unique_or_none()" to make the difference 
clear? If its called .get_or_none() imho it is better to stick to .get() 
behavior regarding multiple objects (still raising).


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9e322498-0909-cf3d-08bc-f62cca789f23%40netzkolchose.de.

RE: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Danilov Maxim]

I am completely agree with Jörg. 
Simply Mixin with own get_or_none help solve you, @Dave Gaeddert your asks.

Here we have Other big issue, which always omitted between Django developers in 
GET method: 

Multiple objects exception without Already received objects. 

Get made "len", len created one or many objects. We already loose time for that 
(init time * N objects). 
Probably I can catch Exception and decide in Exception, what I want to do with 
that objects. BUT! I cannot do it. Get throws error without received objects. 
If I want to get those objects, I should send again request to database. I 
should wait, again.

Can we add queryset with cached_objects in MultipleObjectsReturned Exeption? 
Yes. Definitely. Have we this yet? No



Mit freundlichen Grüßen,
DI Mag. Maxim Danilov

+43(681)207 447 76
ma...@wpsoft.at

-Original Message-
From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Jörg Breitbart
Sent: Friday, June 24, 2022 11:56 AM
To: django-developers@googlegroups.com
Subject: Re: Idea: Add .checked(/) to QuerySet as alternative to 
.filter() w/ .first()

@Dave Gaeddert
Since you mentioned it - what should a get_or_none method do about multiple 
objects? Still raise? Silently "cast" to None (imho semantically wrong)? Return 
the underlying queryset (or any other "multiple objects container thingy")?

The problem with .get() is - it may end in 3 different states (tristate
- None, one object, multiple objects), where only one state is the expected 
case. To me handling the other unexpected ones as exceptions seems to be a very 
common pattern in python (thus also newbies should be able to handle it 
properly in their code).

Now a .get_or_none() would shift the "good results" to (None, one
object) still leaving multiple objects out. Did we gain here anything? 
Not if multiple objects is still within reach (eg. uniqueness cannot be assumed 
from the filter conditions) - ppl would still have to write exception handling 
code. Just forgetting that is like a time bomb that might go off anytime a 
project aggregates more production data (welcome to error 500 websites / dying 
servers).

But if .get_or_none() would handle multiple objects without raising (eg. 
returning the queryset) - we haven't gained anything either, we just surfaced 
the fact, that .get is only a convenient function on top of filtered search 
queries. And ppl still have to deal with the tristate result in their code.

Maybe I am overlooking something - currently I dont see, how any of that might 
be helpful in terms of easier API usage.


Am 23.06.22 um 16:57 schrieb Dave Gaeddert:
> I'll lob in my 2 cents that I actually think `get_or_none` would be 
> great to have, in the same way that I imagine people think 
> `get_or_create` is useful. You can try/catch yourself in both cases 
> (example is basically the exact same 
> https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get-or-create), 
> but especially for people new to Django, having a method for it is a lot 
> easier to grasp. The MultipleObjectsReturned exception is more of a 
> modeling/uniqueness error in my experience (not sure I've ever written a 
> catch for this...), but doing .get and knowing it may not exist is super 
> common — much easier to have a method for that than force everyone to 
> think through all the ramifications of using .get vs .filter (and/or 
> .first) etc.
> 
> I'd also guess that people don't want to create a Manager if they don't 
> have to (which I'd also consider an advanced topic).
> 
> https://stackoverflow.com/questions/3090302/how-do-i-get-the-object-if-it-exists-or-none-if-it-does-not-exist-in-django
> 
> Dave
> 
> On Wednesday, June 22, 2022 at 5:27:52 AM UTC-5 j.bre...@netzkolchose.de 
> wrote:
> 
> I somewhat second what Adrian wrote:
> 
> - try-except handling seems to be the most idiomatic way to me
> - a flag altering API behavior as .get(..., raises=False) might come
> handy, and to avoid naming collisions in arguments this could also be
> shaped as a separate get_or_none() method - but: I somewhat doubt its
> usefulness just cluttering the API further for low benefit, also
> nothing
> stops you from wrapping the exception way into such a query helper
> (or a
> more advanced resemblance of .get as Uri does). In fact the exception
> will create a tiny runtime overhead on interpreter side, but thats
> really tiny compared to the db roundtrip (thus against the whole .get +
> helper runtime).
> 
> Imho a chaining .checked() method on the manager/queryset is not a good
> idea, as it might create more API ambiguity - What should .checked()
> do,
> if it is not followed by .get()?
> 
> Cheers, jerc

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Jörg Breitbart]

@Dave Gaeddert
Since you mentioned it - what should a get_or_none method do about 
multiple objects? Still raise? Silently "cast" to None (imho 
semantically wrong)? Return the underlying queryset (or any other 
"multiple objects container thingy")?


The problem with .get() is - it may end in 3 different states (tristate 
- None, one object, multiple objects), where only one state is the 
expected case. To me handling the other unexpected ones as exceptions 
seems to be a very common pattern in python (thus also newbies should be 
able to handle it properly in their code).


Now a .get_or_none() would shift the "good results" to (None, one 
object) still leaving multiple objects out. Did we gain here anything? 
Not if multiple objects is still within reach (eg. uniqueness cannot be 
assumed from the filter conditions) - ppl would still have to write 
exception handling code. Just forgetting that is like a time bomb that 
might go off anytime a project aggregates more production data (welcome 
to error 500 websites / dying servers).


But if .get_or_none() would handle multiple objects without raising (eg. 
returning the queryset) - we haven't gained anything either, we just 
surfaced the fact, that .get is only a convenient function on top of 
filtered search queries. And ppl still have to deal with the tristate 
result in their code.


Maybe I am overlooking something - currently I dont see, how any of that 
might be helpful in terms of easier API usage.



Am 23.06.22 um 16:57 schrieb Dave Gaeddert:
I'll lob in my 2 cents that I actually think `get_or_none` would be 
great to have, in the same way that I imagine people think 
`get_or_create` is useful. You can try/catch yourself in both cases 
(example is basically the exact same 
https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get-or-create), 
but especially for people new to Django, having a method for it is a lot 
easier to grasp. The MultipleObjectsReturned exception is more of a 
modeling/uniqueness error in my experience (not sure I've ever written a 
catch for this...), but doing .get and knowing it may not exist is super 
common — much easier to have a method for that than force everyone to 
think through all the ramifications of using .get vs .filter (and/or 
.first) etc.


I'd also guess that people don't want to create a Manager if they don't 
have to (which I'd also consider an advanced topic).


https://stackoverflow.com/questions/3090302/how-do-i-get-the-object-if-it-exists-or-none-if-it-does-not-exist-in-django

Dave

On Wednesday, June 22, 2022 at 5:27:52 AM UTC-5 j.bre...@netzkolchose.de 
wrote:


I somewhat second what Adrian wrote:

- try-except handling seems to be the most idiomatic way to me
- a flag altering API behavior as .get(..., raises=False) might come
handy, and to avoid naming collisions in arguments this could also be
shaped as a separate get_or_none() method - but: I somewhat doubt its
usefulness just cluttering the API further for low benefit, also
nothing
stops you from wrapping the exception way into such a query helper
(or a
more advanced resemblance of .get as Uri does). In fact the exception
will create a tiny runtime overhead on interpreter side, but thats
really tiny compared to the db roundtrip (thus against the whole .get +
helper runtime).

Imho a chaining .checked() method on the manager/queryset is not a good
idea, as it might create more API ambiguity - What should .checked()
do,
if it is not followed by .get()?

Cheers, jerch



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com 
.


--
netzkolchose.de UG (haftungsbeschränkt)
Geschäftsführer: Jörg Breitbart
Handelsregister: HRB 504791 Amtsgericht Jena
Steuer-Nr.: 161/115/07450
USt-IdNr.: DE268234065

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/18eb5df7-85fd-8e8a-3632-351d90da50d3%40netzkolchose.de.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'll lob in my 2 cents that I actually think `get_or_none` would be great 
to have, in the same way that I imagine people think `get_or_create` is 
useful. You can try/catch yourself in both cases (example is basically the 
exact same 
https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get-or-create), 
but especially for people new to Django, having a method for it is a lot 
easier to grasp. The MultipleObjectsReturned exception is more of a 
modeling/uniqueness error in my experience (not sure I've ever written a 
catch for this...), but doing .get and knowing it may not exist is super 
common — much easier to have a method for that than force everyone to think 
through all the ramifications of using .get vs .filter (and/or .first) etc.

I'd also guess that people don't want to create a Manager if they don't 
have to (which I'd also consider an advanced topic).

https://stackoverflow.com/questions/3090302/how-do-i-get-the-object-if-it-exists-or-none-if-it-does-not-exist-in-django

Dave

On Wednesday, June 22, 2022 at 5:27:52 AM UTC-5 j.bre...@netzkolchose.de 
wrote:

> I somewhat second what Adrian wrote:
>
> - try-except handling seems to be the most idiomatic way to me
> - a flag altering API behavior as .get(..., raises=False) might come 
> handy, and to avoid naming collisions in arguments this could also be 
> shaped as a separate get_or_none() method - but: I somewhat doubt its 
> usefulness just cluttering the API further for low benefit, also nothing 
> stops you from wrapping the exception way into such a query helper (or a 
> more advanced resemblance of .get as Uri does). In fact the exception 
> will create a tiny runtime overhead on interpreter side, but thats 
> really tiny compared to the db roundtrip (thus against the whole .get + 
> helper runtime).
>
> Imho a chaining .checked() method on the manager/queryset is not a good 
> idea, as it might create more API ambiguity - What should .checked() do, 
> if it is not followed by .get()?
>
> Cheers, jerch
>
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Jörg Breitbart]

I somewhat second what Adrian wrote:

- try-except handling seems to be the most idiomatic way to me
- a flag altering API behavior as .get(..., raises=False) might come 
handy, and to avoid naming collisions in arguments this could also be 
shaped as a separate get_or_none() method - but: I somewhat doubt its 
usefulness just cluttering the API further for low benefit, also nothing 
stops you from wrapping the exception way into such a query helper (or a 
more advanced resemblance of .get as Uri does). In fact the exception 
will create a tiny runtime overhead on interpreter side, but thats 
really tiny compared to the db roundtrip (thus against the whole .get + 
helper runtime).


Imho a chaining .checked() method on the manager/queryset is not a good 
idea, as it might create more API ambiguity - What should .checked() do, 
if it is not followed by .get()?


Cheers, jerch



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2dc8265b-44c2-6112-084f-07cea4589834%40netzkolchose.de.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[אורי]

I don't like get() and catching exceptions. What I usually do is something
like this:

foo_list = Foo.objects.filter(x=x)
if (len(foo_list) == 1):
foo = foo_list[0]

And if I need else, I can assign None or whatever. The advantage in this
way is that you don't get an exception, and you deal with all numbers of
elements except 1, not only 0 (it can be 2 or 3 for example). And you don't
have to catch exceptions for multiple and does-not-exist. Many times I
don't need else, I just don't do anything if the number of elements
received is not 1.

Uri.
אורי
u...@speedy.net


On Tue, Jun 21, 2022 at 10:50 AM Adrian Torres Justo 
wrote:

> A common idiom is also
>
> ```
> try:
> foo = Foo.objects.get(x="foo")
> except Foo.DoesNotExist:
> foo = None
> ```
>
> which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only
> argument on `get` that returns `None` if not found
>
> ```
> foo = Foo.objects.get(x="foo", strict=False)
> # or
> foo = Foo.objects.get(x="foo", raises=False)
> ```
>
> As it stands your current proposal isn't much different from filter() then
> first(), IMO, the method names change but the amount of chaining is the
> same.
> On Monday, June 20, 2022 at 9:34:08 PM UTC+2 stev...@gmail.com wrote:
>
>> It is a common idiom to use `.filter(<...>).first()` as a
>> replacement for `.get(<...>)` when `None` is wanted instead of an exception
>> when no match is found. That works, but wouldn't the intention be more
>> clear if that could be written as something like
>>
>> .checked(False).get(<...>)
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/eb6a2bc2-b72f-49ff-9e90-12913ad876c9n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeGH7eZqECsCbnC8ifG%2BgOfFW_SY5ug2P-DqYmti4hpmTA%40mail.gmail.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Adrian Torres Justo]

A common idiom is also

```
try:
foo = Foo.objects.get(x="foo")
except Foo.DoesNotExist:
foo = None
```

which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only 
argument on `get` that returns `None` if not found

```
foo = Foo.objects.get(x="foo", strict=False)
# or
foo = Foo.objects.get(x="foo", raises=False)
```

As it stands your current proposal isn't much different from filter() then 
first(), IMO, the method names change but the amount of chaining is the 
same.
On Monday, June 20, 2022 at 9:34:08 PM UTC+2 stev...@gmail.com wrote:

> It is a common idiom to use `.filter(<...>).first()` as a 
> replacement for `.get(<...>)` when `None` is wanted instead of an exception 
> when no match is found. That works, but wouldn't the intention be more 
> clear if that could be written as something like
>
> .checked(False).get(<...>)
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb6a2bc2-b72f-49ff-9e90-12913ad876c9n%40googlegroups.com.

Re: Idea

[Christian González]

Am 21.10.21 um 13:31 schrieb Jet Ezra:
Well, this looks like a cool attempt but still lacking the python 
part. I would like to update the DOM just with Python not anything 
like Javascript. From what I have read from the links above, I have 
realised that we are writing HTML that has already been covered up 
with JS, but in my issue, we are trying to run independent of JS just 
like we see in C# where one writes C# instead of JS in .NET


Dttempts like djhtmx and django-htmx to add that python functionality, 
but they are far from perfect. With bare HTMX, you need no extra Js.
Django-htmlx is just a small wrapper to help including htmx into Django, 
does nothing more. And djhtmx adds a few helpers to create a 
"components" system, similar to django-unicorn. But when it comes to 
bigger projects, this is error prone as it lacks interactions between 
components.


But fo rmy part, I would *love* to see HTMX "included" in Django, as it 
seems to be the perfect couple, if done right.


Christian






On Wed, Oct 20, 2021 at 6:16 PM 'Adam Johnson' via Django developers 
(Contributions to Django itself)  
wrote:


Check out htmx as a way to avoid needing JavaScript in your Django
applications: https://htmx.org/

Example app: https://github.com/adamchainz/django-htmx

On Sun, 19 Sept 2021 at 00:00, Jet Ezra  wrote:

I know this may not be necessary at the moment because we are
comfortable depending on front-end frameworks, but I have my
two ideas here:

1. what if django alone without any framework can be used to
design progressive web apps, with routers that do not reload
the page, we currently have one of the best routing but what
if they support SPAs this time?

2. what if we could instead of Javascript in the templates, we
write python, case in example is forexample how we write C# in
.NET withing our templates not writing JavaScript. Currently
Django is requiring its developer to again go ahead and learn
JS too, what if we remove that??

-- 
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 view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/bdefe58e-b26f-434e-a83f-36917b81f936n%40googlegroups.com

.

-- 
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 view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAMyDDM2N6zFK7p0VA8e-Y-DwpCSsePH3O5q3g1P7O8O8-Vi5kA%40mail.gmail.com

.



--
jet
--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMjc0xUSKYUgJrrUOTscr0%2BT8xLABqwF%3DK9BmDANyLVTuNS%2BKQ%40mail.gmail.com 
.


--
Dr. Christian González
https://nerdocs.at

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad6962d2-8c5d-0af3-e4c0-fa9e9921055a%40nerdocs.at.

Re: Idea

[Jet Ezra]

Well, this looks like a cool attempt but still lacking the python part. I
would like to update the DOM just with Python not anything like Javascript.
>From what I have read from the links above, I have realised that we are
writing HTML that has already been covered up with JS, but in my issue, we
are trying to run independent of JS just like we see in C# where one writes
C# instead of JS in .NET



On Wed, Oct 20, 2021 at 6:16 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Check out htmx as a way to avoid needing JavaScript in your Django
> applications: https://htmx.org/
>
> Example app: https://github.com/adamchainz/django-htmx
>
> On Sun, 19 Sept 2021 at 00:00, Jet Ezra  wrote:
>
>> I know this may not be necessary at the moment because we are comfortable
>> depending on front-end frameworks, but I have my two ideas here:
>>
>> 1. what if django alone without any framework can be used to design
>> progressive web apps, with routers that do not reload the page, we
>> currently have one of the best routing but what if they support SPAs this
>> time?
>>
>> 2. what if we could instead of Javascript in the templates, we write
>> python, case in example is forexample how we write C# in .NET withing our
>> templates not writing JavaScript. Currently Django is requiring its
>> developer to again go ahead and learn JS too, what if we remove that??
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/bdefe58e-b26f-434e-a83f-36917b81f936n%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2N6zFK7p0VA8e-Y-DwpCSsePH3O5q3g1P7O8O8-Vi5kA%40mail.gmail.com
> 
> .
>


-- 
jet

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMjc0xUSKYUgJrrUOTscr0%2BT8xLABqwF%3DK9BmDANyLVTuNS%2BKQ%40mail.gmail.com.

Re: Idea

['Adam Johnson' via Django developers (Contributions to Django itself)]

Check out htmx as a way to avoid needing JavaScript in your Django
applications: https://htmx.org/

Example app: https://github.com/adamchainz/django-htmx

On Sun, 19 Sept 2021 at 00:00, Jet Ezra  wrote:

> I know this may not be necessary at the moment because we are comfortable
> depending on front-end frameworks, but I have my two ideas here:
>
> 1. what if django alone without any framework can be used to design
> progressive web apps, with routers that do not reload the page, we
> currently have one of the best routing but what if they support SPAs this
> time?
>
> 2. what if we could instead of Javascript in the templates, we write
> python, case in example is forexample how we write C# in .NET withing our
> templates not writing JavaScript. Currently Django is requiring its
> developer to again go ahead and learn JS too, what if we remove that??
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bdefe58e-b26f-434e-a83f-36917b81f936n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2N6zFK7p0VA8e-Y-DwpCSsePH3O5q3g1P7O8O8-Vi5kA%40mail.gmail.com.

Re: Idea

[Curtis Maloney]

Additionally, incorporating DRF [or any other 3rd party lib] into core would 
lock them into Django's release cycle.

As for built-in REST/API features, Django provides `JsonResponse` already, so 
the main piece lacking is de/serialisers.

The built in serializer framework is well suited to generating fixtures, and 
_can_ be bent to serialising your data for APIs, but does not provide any 
solution for validating input.

Our existing input validation solution - Forms - is not so good at handling 
complex or deeply nested data structures.

However, in recent years tools, like pydantic and marshmallow, have begun 
filling this space.

One place we could help everyone is by providing a JSON request-body parsing 
utility.

--
Curtis


On Thu, 16 Sep 2021, at 10:58, Benny wrote:
> There are serializers and dictionaries built into the Django models system 
> that I’ve had zero problems leveraging for building out JSON (or REST-like) 
> objects for endpoint purposes. I personally believe integrating DRF into 
> Django would needlessly bloat it. The two play together perfectly fine if you 
> really need them both.
> 
> I’d recommend digging around in the guts of Django. You’ll find some pretty 
> neat things there!
> 
> Just my 2 cents,
> Benny  
> 
>> On Sep 15, 2021, at 6:36 PM, Michael Urban  wrote:
>> 
>> For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t never 
>> felt like a great fit for Django projects. It’s very Rails-y.
>> 
>> It would be amazing to have an official Django contrib package for REST.
>> 
>> Never going to happen, but needs to be said.
>> 
>> Best,
>> Mike 
>> 
>> On Wed, Sep 15, 2021 at 4:40 PM 'Adam Johnson' via Django developers 
>> (Contributions to Django itself)  wrote:
>>> DRF remains an extension to Django. We don't want Django to depend on it.
>>> 
>>> But you're free to set up a startproject template that includes the 
>>> settings, and use that. 
>>> https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template
>>> 
>>> On Tue, 14 Sept 2021 at 08:44, abdul azeez  wrote:
 Pls can we make django come with django reest framework settings when you 
 start a project 
 
 
 -- 
 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 view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com
  
 .
>>> 
>>> 
>>> -- 
>>> 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 view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%40mail.gmail.com
>>>  
>>> .
>> 
>> 
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CADyXHNar2-0TqdRi%2ButYwn8qd%2Bh34ZtyoxvuwNQ%3DMSB%2B%2B82NiA%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/81908113-FAF5-4DE9-B84F-FCC3DDFF7453%40twosensedesign.com
>  
> .

-- 
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 view this discussion on th

Re: Idea

[Benny]

There are serializers and dictionaries built into the Django models system that 
I’ve had zero problems leveraging for building out JSON (or REST-like) objects 
for endpoint purposes. I personally believe integrating DRF into Django would 
needlessly bloat it. The two play together perfectly fine if you really need 
them both.

I’d recommend digging around in the guts of Django. You’ll find some pretty 
neat things there!

Just my 2 cents,
Benny  

> On Sep 15, 2021, at 6:36 PM, Michael Urban  wrote:
> 
> 
> For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t never 
> felt like a great fit for Django projects. It’s very Rails-y.
> 
> It would be amazing to have an official Django contrib package for REST.
> 
> Never going to happen, but needs to be said.
> 
> Best,
> Mike 
> 
>> On Wed, Sep 15, 2021 at 4:40 PM 'Adam Johnson' via Django developers 
>> (Contributions to Django itself)  wrote:
>> DRF remains an extension to Django. We don't want Django to depend on it.
>> 
>> But you're free to set up a startproject template that includes the 
>> settings, and use that. 
>> https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template
>> 
>>> On Tue, 14 Sept 2021 at 08:44, abdul azeez  wrote:
>>> Pls can we make django come with django reest framework settings when you 
>>> start a project
>>> -- 
>>> 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 view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com.
>> 
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%40mail.gmail.com.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADyXHNar2-0TqdRi%2ButYwn8qd%2Bh34ZtyoxvuwNQ%3DMSB%2B%2B82NiA%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/81908113-FAF5-4DE9-B84F-FCC3DDFF7453%40twosensedesign.com.

Re: Idea

[Michael Urban]

For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t
never felt like a great fit for Django projects. It’s very Rails-y.

It would be amazing to have an official Django contrib package for REST.

Never going to happen, but needs to be said.

Best,
Mike

On Wed, Sep 15, 2021 at 4:40 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> DRF remains an extension to Django. We don't want Django to depend on it.
>
> But you're free to set up a startproject template that includes the
> settings, and use that.
> https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template
>
> On Tue, 14 Sept 2021 at 08:44, abdul azeez  wrote:
>
>> Pls can we make django come with django reest framework settings when you
>> start a project
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyXHNar2-0TqdRi%2ButYwn8qd%2Bh34ZtyoxvuwNQ%3DMSB%2B%2B82NiA%40mail.gmail.com.

Re: Idea

['Adam Johnson' via Django developers (Contributions to Django itself)]

DRF remains an extension to Django. We don't want Django to depend on it.

But you're free to set up a startproject template that includes the
settings, and use that.
https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template

On Tue, 14 Sept 2021 at 08:44, abdul azeez  wrote:

> Pls can we make django come with django reest framework settings when you
> start a project
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%40mail.gmail.com.

Re: Idea for Rollback Migration Rules

[Dwight Gunning]

The first case is definitely a source of friction for me too. Django 
management commands could help but it's still up to the developer to 
remember to run them. I'd prefer to have the VCS identify and help resolve 
these situations right when they arise. 

The second case seems to be discouraged by the docs: "you are encouraged to 
make migrations freely and not worry about how many you have". Following 
this guideline, it will only be in rare situations that already applied 
migrations will be modified. Therefore I don't see a need for framework 
support in resolving this.

Back to the VCS idea and as an aside to Django development:

Looking at the git docs, a post-checkout script could compare the two 
branches and provide a warning about any change to the migrations in the 
working tree. Looks like others have thought down the same lines:
 - 
https://stackoverflow.com/questions/32682293/django-migrations-workflow-with-multiple-dev-branches
 - https://cheesecakelabs.com/blog/really-annoys-django-migrations/

I think I'll look into adapting the post-checkout hook in this gist 
, which differences in PHP 
`composer.lock` files.

Dwight
--

On Sunday, July 5, 2020 at 5:36:16 AM UTC+2 Lorenzo Peña wrote:

> See if this solves part of the problem 
> https://github.com/lorinkoz/django-unmigrate
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/40bb69f4-4a8f-40ce-8e3e-73369451134dn%40googlegroups.com.

Re: Idea for Rollback Migration Rules

[Lorenzo Peña]

See if this solves part of the problem 
https://github.com/lorinkoz/django-unmigrate

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b20072b9-359d-4777-8635-40966f4b7575o%40googlegroups.com.

Re: Idea for Rollback Migration Rules

[Josh Smeaton]

I run into the problem you're trying to solve often and it's quite 
frustrating. I don't think storing the migration text in the database is 
the right solution - I don't know why, but it just *feels* wrong.

Such a rollback would only support SQL based migrations - any RunPython 
migration operations would not be safe to run as the code has changed 
underneath.

On Friday, 19 June 2020 23:15:31 UTC+10, Alexander Lyabah wrote:
>
> I just have a very small idea, maybe I can get a feedback about it here.
>
> What if db will store not only migration name but also migration itself, 
> so the system can rollback the migration even if migration file is 
> no-longer exists.
>
>
> *Cases when it can be useful:*
>
> when I switch between branched in my git-repo I want to roll-back 
> migrations that were removed and apply new migrations.
>
> When I change migration itself, I want to roll-back its previous version 
> and apply a new changed version.
>
>
> Let me know what you think about it, I hope it is a right place to share 
> ideas like that.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/babfcb07-6a7f-4566-9d43-88551b947b0bo%40googlegroups.com.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Collin Anderson]

You could probably also just monkey patch like so:

from django.db.models import Manager, QuerySet
Manager.ident = QuerySet.ident = lambda self, pk: self.get(pk=pk)

On Wed, Nov 7, 2018 at 3:33 PM C. Kirby  wrote:

> I bit the bullet and put together a small app to handle this, with maybe
> even less typing. It monkey patches all installed models so you can run
> Model.ident_(pk)
> Can be found at https://github.com/ckirby/django-model-ident
>
> Chaim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4bdacfe9-8fca-4b59-a15d-27553c731d4e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[C. Kirby]

I bit the bullet and put together a small app to handle this, with maybe 
even less typing. It monkey patches all installed models so you can run 
Model.ident_(pk)
Can be found at https://github.com/ckirby/django-model-ident

Chaim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4bdacfe9-8fca-4b59-a15d-27553c731d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Daniel Chimeno]

This is something I've also experimented while working with a shell, I 
often mislead the .get(pk), with .get(pk=pk), 
but only at the shell, not in the views or other places (not sure why).
For that, I'm -1 to to include it in the core, and possible the best place 
is a third package app like django-extensions or similar.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d4db960d-1e9a-4321-9e0a-610e78532295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[ludovic coues]

When experimenting with code in the shell, debugging or troubleshooting, I
personally tend to do a lot of get. I know some object cause issue so I try
to get them to poke them and see what's the problem.

When trying to get them, if I have the id, I always try to type
Model.objects.get(id). Sometimes I correct myself before typing enter but
that's something to remember and amount to a lot of little irritation,
sometimes while trying to solve elusive issues or trying to fix asap some
major issues in prod.


Maybe that feature belong in a third party app. Monkey-patching is a thing.

On Tue, Nov 6, 2018, 08:48 James Bennett  I still don't understand the problem this is solving; is typing "pk=" (or
> "id=") that much of a burden? Or that frequently left out by accident?
>
> As it stands, I agree with Adam that this adds implementation complexity
> (including potential future implementation complexity, as Ivan noted) and
> proliferates different ways to do the same thing, without presenting much
> in the way of concrete arguments for why it's needed. If there's a really
> convincing case to be made for this, I'm open to reading it when it's made,
> but for now I'd be -1 on the whole thing.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg9ocm_LmZSGbQG%3DEB2U0Z%2BOF5eupJFwK3OWbyz46JDj5Q%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  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTZ6Nm4Hwm_oKBRbdzxztORgD%3DAAsFkZBPXnPULJhC2Egg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[James Bennett]

I still don't understand the problem this is solving; is typing "pk=" (or
"id=") that much of a burden? Or that frequently left out by accident?

As it stands, I agree with Adam that this adds implementation complexity
(including potential future implementation complexity, as Ivan noted) and
proliferates different ways to do the same thing, without presenting much
in the way of concrete arguments for why it's needed. If there's a really
convincing case to be made for this, I'm open to reading it when it's made,
but for now I'd be -1 on the whole thing.

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

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Tom Forbes]

I feel this would be a good addition to just .get(), I’ve wanted this while
working with the shell. Model.objects.get(pk) feels very natural to me, and
the common Model.objects.get(pk=pk) always felt overly verbose.




On 5 November 2018 at 22:37:52, Josh Smeaton (josh.smea...@gmail.com) wrote:

I'm in the same boat as Simon - I've wanted this many times in the last few
months, but only when working at the shell. I'd be +1 for get and -1 for
filter also.

On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote:
>
> As I've mentioned on the ticket I've been wishing get(pk) could translate
> to get(pk=pk) for a while but I never got to suggest it. Probably because I
> didn't feel like adding (pk=...) was really that long. I'd note that most
> of the
> times I wished this existed was when doing some object manipulations
> through a Django shell.
>
> I'm not convinced this would be as useful for `filter()` though as I don't
> recall wanting to retrieve a set of objects matching a value I know will
> be unique.
>
> Something to keep in mind as well is whether or not we want to allow
> this to be coupled with extra args and kwargs.
>
> e.g.
>
> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>
> I'd be in favor of preventing pk and kwarg or Q args mixing.
>
> Count me +1 for the get() case and -1 for the filter() one.
>
> Simon
>
> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>
>> Hi,
>> I'm creating this topic to see if there is interest to implement
>> positional arguments in queryset filtering.
>>
>> Current situation
>>
>> Currently the only way to use positional arguments to filter can be
>> either:
>>
>>- Passing a single or multiple Q objects:
>>
>>MyClass.objects.filter(Q(key=value))
>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>
>>
>>
>>- Passing a couple is also working (not sure if this is a happy
>>accident, should it be removed?)
>>
>>MyClass.objects.filter((key, value))
>>
>>
>>
>>- Combination of both is also proven to work
>>
>>MyClass.objects.filter((key, value), Q(other_key=value))
>>
>>
>>
>> Suggestion
>>
>> This feature suggestion is to leverage the case when a non-Q / non couple
>> object is passed, so it implicitly interpreted as the value for the model's
>> pk.
>>
>> This could ease/simplify code by omitting pk when this is the only
>> filter used:
>>
>>
>> MyClass.objects.get(value)
>> # Translates into: MyClass.objects.get(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(value)
>> # Translates into: MyClass.objects.filter(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(Q(value))
>> # Translates into: MyClass.objects.filter(Q(pk=value))
>>
>> Do you think it's worth it? It could be leveraged to simplify many
>> situations.
>> I'd be happy to proceed to the development myself if this is something
>> gathering interest.
>>
> --
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ba9128d7-9e49-4269-b3a3-9995a998b491%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

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

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Josh Smeaton]

I'm in the same boat as Simon - I've wanted this many times in the last few 
months, but only when working at the shell. I'd be +1 for get and -1 for 
filter also.

On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote:
>
> As I've mentioned on the ticket I've been wishing get(pk) could translate
> to get(pk=pk) for a while but I never got to suggest it. Probably because I
> didn't feel like adding (pk=...) was really that long. I'd note that most 
> of the
> times I wished this existed was when doing some object manipulations
> through a Django shell.
>
> I'm not convinced this would be as useful for `filter()` though as I don't
> recall wanting to retrieve a set of objects matching a value I know will
> be unique.
>
> Something to keep in mind as well is whether or not we want to allow
> this to be coupled with extra args and kwargs.
>
> e.g.
>
> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>
> I'd be in favor of preventing pk and kwarg or Q args mixing.
>
> Count me +1 for the get() case and -1 for the filter() one.
>
> Simon
>
> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>
>> Hi, 
>> I'm creating this topic to see if there is interest to implement 
>> positional arguments in queryset filtering.
>>
>> Current situation 
>>
>> Currently the only way to use positional arguments to filter can be 
>> either:
>>
>>- Passing a single or multiple Q objects: 
>>
>>MyClass.objects.filter(Q(key=value))
>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>
>>
>>
>>- Passing a couple is also working (not sure if this is a happy 
>>accident, should it be removed?) 
>>
>>MyClass.objects.filter((key, value))
>>
>>
>>
>>- Combination of both is also proven to work 
>>
>>MyClass.objects.filter((key, value), Q(other_key=value))
>>
>>
>>
>> Suggestion 
>>
>> This feature suggestion is to leverage the case when a non-Q / non couple 
>> object is passed, so it implicitly interpreted as the value for the model's 
>> pk.
>>
>> This could ease/simplify code by omitting pk when this is the only 
>> filter used:
>>
>>
>> MyClass.objects.get(value)
>> # Translates into: MyClass.objects.get(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(value)
>> # Translates into: MyClass.objects.filter(pk=value)
>>
>>
>> or 
>>
>>
>> MyClass.objects.filter(Q(value))
>> # Translates into: MyClass.objects.filter(Q(pk=value))
>>  
>>
>> Do you think it's worth it? It could be leveraged to simplify many 
>> situations.
>> I'd be happy to proceed to the development myself if this is something 
>> gathering interest.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba9128d7-9e49-4269-b3a3-9995a998b491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

(Sorry, accidental send.)

Consider adding a custom __call__ method to your manager class that would
only accept values for pk lookup, nothing else. That way you can save four
additional characters (qs(123) vs qs.get(id=123)) and that would be
something I'm not against seeing in django, provided it's convenient enough
and simple enough (not allowing arbitrary stuff that should be passed to
filter() is the key, I think).

It would require further discussion to decide how different such a method
should be from .get() - I can think of a few improvements I could find
useful in shell but some of them might not for will in the current queryset
api.

Ivan.

On Thu, 1 Nov 2018, 19:41 Ivan Anishchuk,  wrote:

> Not closely related, but what about composite keys? I think having such an
> implicit arg interpretation would make it much more complicated to use,
> say, a combination of charfield and integerfield as your key (primary or
> foreign doesn't matter): what does .get(('string', 123)) mean?
> .get(string=123) or .get(field1='string', field2=123)?
>
> Actually, I think passing pairs isn't such a good idea either, but I can
> see some benefits over using dicts or unpacked args. (Assuming Q objects
> are not desired, for whatever reason.)
>
> I'd prefer being sure which fields correspond to which values and about
> their order in the resulting query over saving three bytes on average (id=
> or pk=).
>
> On the other hand, perhaps using a custom manager class would work in your
> case, consider adding a separate method
>
>
> On Thu, 1 Nov 2018, 11:47 Adam Johnson,  wrote:
>
>> Count me as -1 too, it doesn't seem worth it to me to save the 3
>> characters 'pk='. It would increase complexity of implementation and
>> complexity of comprehension ("two ways to do it").
>>
>> On Wed, 31 Oct 2018 at 23:00, Ian Foote  wrote:
>>
>>> I'm not in favour of this, it's too implicit for my liking and I don't
>>> think any gains outweigh the increased complexity of implementation.
>>>
>>> Ian
>>>
>>> On Wed, 31 Oct 2018 at 19:04, charettes  wrote:
>>>
 My main concern with allowing extra args and kwargs to be mixed with
 the proposed
 pk arg notation is that it would allow lookups such as

 get(Q(is_active=True), pk)

 Simon

 Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>
> *I'm not convinced this would be as useful for `filter()` though as I
> don't*
> *recall wanting to retrieve a set of objects matching a value I know
> will*
> *be unique.*
>
> The .filter() could be used for update
>
> e.g.:
> Mymodel.objects.filter(1).update(key=value)
>
> This is also bringing consistency in the code, but I agree this could
> be misleading.
> The .get() is the main purpose.
>
> *Something to keep in mind as well is whether or not we want to allow*
> *this to be coupled with extra args and kwargs.*
>
> Currently only kwargs are supposed to be used with get/filter. The
> only args that can be used currently are Q() objects (and couples but I
> think it's an issue).
> This proposed design suggestion is to also allow scalar values
> (strings, int, etc) too.
>
>
> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>>
>> As I've mentioned on the ticket I've been wishing get(pk) could
>> translate
>> to get(pk=pk) for a while but I never got to suggest it. Probably
>> because I
>> didn't feel like adding (pk=...) was really that long. I'd note that
>> most of the
>> times I wished this existed was when doing some object manipulations
>> through a Django shell.
>>
>> I'm not convinced this would be as useful for `filter()` though as I
>> don't
>> recall wanting to retrieve a set of objects matching a value I know
>> will
>> be unique.
>>
>> Something to keep in mind as well is whether or not we want to allow
>> this to be coupled with extra args and kwargs.
>>
>> e.g.
>>
>> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>>
>> I'd be in favor of preventing pk and kwarg or Q args mixing.
>>
>> Count me +1 for the get() case and -1 for the filter() one.
>>
>> Simon
>>
>> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>>
>>> Hi,
>>> I'm creating this topic to see if there is interest to implement
>>> positional arguments in queryset filtering.
>>>
>>> Current situation
>>>
>>> Currently the only way to use positional arguments to filter can be
>>> either:
>>>
>>>- Passing a single or multiple Q objects:
>>>
>>>MyClass.objects.filter(Q(key=value))
>>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>>
>>>
>>>
>>>- Passing a couple is also working (not sure if this is a happy
>>>accident, should it be removed?)
>>>
>>>MyCla

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

Not closely related, but what about composite keys? I think having such an
implicit arg interpretation would make it much more complicated to use,
say, a combination of charfield and integerfield as your key (primary or
foreign doesn't matter): what does .get(('string', 123)) mean?
.get(string=123) or .get(field1='string', field2=123)?

Actually, I think passing pairs isn't such a good idea either, but I can
see some benefits over using dicts or unpacked args. (Assuming Q objects
are not desired, for whatever reason.)

I'd prefer being sure which fields correspond to which values and about
their order in the resulting query over saving three bytes on average (id=
or pk=).

On the other hand, perhaps using a custom manager class would work in your
case, consider adding a separate method

On Thu, 1 Nov 2018, 11:47 Adam Johnson,  wrote:

> Count me as -1 too, it doesn't seem worth it to me to save the 3
> characters 'pk='. It would increase complexity of implementation and
> complexity of comprehension ("two ways to do it").
>
> On Wed, 31 Oct 2018 at 23:00, Ian Foote  wrote:
>
>> I'm not in favour of this, it's too implicit for my liking and I don't
>> think any gains outweigh the increased complexity of implementation.
>>
>> Ian
>>
>> On Wed, 31 Oct 2018 at 19:04, charettes  wrote:
>>
>>> My main concern with allowing extra args and kwargs to be mixed with the
>>> proposed
>>> pk arg notation is that it would allow lookups such as
>>>
>>> get(Q(is_active=True), pk)
>>>
>>> Simon
>>>
>>> Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :

 *I'm not convinced this would be as useful for `filter()` though as I
 don't*
 *recall wanting to retrieve a set of objects matching a value I know
 will*
 *be unique.*

 The .filter() could be used for update

 e.g.:
 Mymodel.objects.filter(1).update(key=value)

 This is also bringing consistency in the code, but I agree this could
 be misleading.
 The .get() is the main purpose.

 *Something to keep in mind as well is whether or not we want to allow*
 *this to be coupled with extra args and kwargs.*

 Currently only kwargs are supposed to be used with get/filter. The only
 args that can be used currently are Q() objects (and couples but I think
 it's an issue).
 This proposed design suggestion is to also allow scalar values
 (strings, int, etc) too.


 On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>
> As I've mentioned on the ticket I've been wishing get(pk) could
> translate
> to get(pk=pk) for a while but I never got to suggest it. Probably
> because I
> didn't feel like adding (pk=...) was really that long. I'd note that
> most of the
> times I wished this existed was when doing some object manipulations
> through a Django shell.
>
> I'm not convinced this would be as useful for `filter()` though as I
> don't
> recall wanting to retrieve a set of objects matching a value I know
> will
> be unique.
>
> Something to keep in mind as well is whether or not we want to allow
> this to be coupled with extra args and kwargs.
>
> e.g.
>
> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>
> I'd be in favor of preventing pk and kwarg or Q args mixing.
>
> Count me +1 for the get() case and -1 for the filter() one.
>
> Simon
>
> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>
>> Hi,
>> I'm creating this topic to see if there is interest to implement
>> positional arguments in queryset filtering.
>>
>> Current situation
>>
>> Currently the only way to use positional arguments to filter can be
>> either:
>>
>>- Passing a single or multiple Q objects:
>>
>>MyClass.objects.filter(Q(key=value))
>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>
>>
>>
>>- Passing a couple is also working (not sure if this is a happy
>>accident, should it be removed?)
>>
>>MyClass.objects.filter((key, value))
>>
>>
>>
>>- Combination of both is also proven to work
>>
>>MyClass.objects.filter((key, value), Q(other_key=value))
>>
>>
>>
>> Suggestion
>>
>> This feature suggestion is to leverage the case when a non-Q / non
>> couple object is passed, so it implicitly interpreted as the value for 
>> the
>> model's pk.
>>
>> This could ease/simplify code by omitting pk when this is the only
>> filter used:
>>
>>
>> MyClass.objects.get(value)
>> # Translates into: MyClass.objects.get(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(value)
>> # Translates into: MyClass.objects.filter(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(Q(value))
>> # Translat

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Adam Johnson]

Count me as -1 too, it doesn't seem worth it to me to save the 3 characters
'pk='. It would increase complexity of implementation and complexity of
comprehension ("two ways to do it").

On Wed, 31 Oct 2018 at 23:00, Ian Foote  wrote:

> I'm not in favour of this, it's too implicit for my liking and I don't
> think any gains outweigh the increased complexity of implementation.
>
> Ian
>
> On Wed, 31 Oct 2018 at 19:04, charettes  wrote:
>
>> My main concern with allowing extra args and kwargs to be mixed with the
>> proposed
>> pk arg notation is that it would allow lookups such as
>>
>> get(Q(is_active=True), pk)
>>
>> Simon
>>
>> Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>>>
>>> *I'm not convinced this would be as useful for `filter()` though as I
>>> don't*
>>> *recall wanting to retrieve a set of objects matching a value I know
>>> will*
>>> *be unique.*
>>>
>>> The .filter() could be used for update
>>>
>>> e.g.:
>>> Mymodel.objects.filter(1).update(key=value)
>>>
>>> This is also bringing consistency in the code, but I agree this could be
>>> misleading.
>>> The .get() is the main purpose.
>>>
>>> *Something to keep in mind as well is whether or not we want to allow*
>>> *this to be coupled with extra args and kwargs.*
>>>
>>> Currently only kwargs are supposed to be used with get/filter. The only
>>> args that can be used currently are Q() objects (and couples but I think
>>> it's an issue).
>>> This proposed design suggestion is to also allow scalar values (strings,
>>> int, etc) too.
>>>
>>>
>>> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:

 As I've mentioned on the ticket I've been wishing get(pk) could
 translate
 to get(pk=pk) for a while but I never got to suggest it. Probably
 because I
 didn't feel like adding (pk=...) was really that long. I'd note that
 most of the
 times I wished this existed was when doing some object manipulations
 through a Django shell.

 I'm not convinced this would be as useful for `filter()` though as I
 don't
 recall wanting to retrieve a set of objects matching a value I know will
 be unique.

 Something to keep in mind as well is whether or not we want to allow
 this to be coupled with extra args and kwargs.

 e.g.

 Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')

 I'd be in favor of preventing pk and kwarg or Q args mixing.

 Count me +1 for the get() case and -1 for the filter() one.

 Simon

 Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>
> Hi,
> I'm creating this topic to see if there is interest to implement
> positional arguments in queryset filtering.
>
> Current situation
>
> Currently the only way to use positional arguments to filter can be
> either:
>
>- Passing a single or multiple Q objects:
>
>MyClass.objects.filter(Q(key=value))
>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>
>
>
>- Passing a couple is also working (not sure if this is a happy
>accident, should it be removed?)
>
>MyClass.objects.filter((key, value))
>
>
>
>- Combination of both is also proven to work
>
>MyClass.objects.filter((key, value), Q(other_key=value))
>
>
>
> Suggestion
>
> This feature suggestion is to leverage the case when a non-Q / non
> couple object is passed, so it implicitly interpreted as the value for the
> model's pk.
>
> This could ease/simplify code by omitting pk when this is the only
> filter used:
>
>
> MyClass.objects.get(value)
> # Translates into: MyClass.objects.get(pk=value)
>
>
> or
>
>
> MyClass.objects.filter(value)
> # Translates into: MyClass.objects.filter(pk=value)
>
>
> or
>
>
> MyClass.objects.filter(Q(value))
> # Translates into: MyClass.objects.filter(Q(pk=value))
>
>
> Do you think it's worth it? It could be leveraged to simplify many
> situations.
> I'd be happy to proceed to the development myself if this is something
> gathering interest.
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a29eed0a-687a-4964-aec3-a25eeeb6f441%40googlegroups.com
>> 
>> .

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Ian Foote]

I'm not in favour of this, it's too implicit for my liking and I don't
think any gains outweigh the increased complexity of implementation.

Ian

On Wed, 31 Oct 2018 at 19:04, charettes  wrote:

> My main concern with allowing extra args and kwargs to be mixed with the
> proposed
> pk arg notation is that it would allow lookups such as
>
> get(Q(is_active=True), pk)
>
> Simon
>
> Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>>
>> *I'm not convinced this would be as useful for `filter()` though as I
>> don't*
>> *recall wanting to retrieve a set of objects matching a value I know will*
>> *be unique.*
>>
>> The .filter() could be used for update
>>
>> e.g.:
>> Mymodel.objects.filter(1).update(key=value)
>>
>> This is also bringing consistency in the code, but I agree this could be
>> misleading.
>> The .get() is the main purpose.
>>
>> *Something to keep in mind as well is whether or not we want to allow*
>> *this to be coupled with extra args and kwargs.*
>>
>> Currently only kwargs are supposed to be used with get/filter. The only
>> args that can be used currently are Q() objects (and couples but I think
>> it's an issue).
>> This proposed design suggestion is to also allow scalar values (strings,
>> int, etc) too.
>>
>>
>> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>>>
>>> As I've mentioned on the ticket I've been wishing get(pk) could translate
>>> to get(pk=pk) for a while but I never got to suggest it. Probably
>>> because I
>>> didn't feel like adding (pk=...) was really that long. I'd note that
>>> most of the
>>> times I wished this existed was when doing some object manipulations
>>> through a Django shell.
>>>
>>> I'm not convinced this would be as useful for `filter()` though as I
>>> don't
>>> recall wanting to retrieve a set of objects matching a value I know will
>>> be unique.
>>>
>>> Something to keep in mind as well is whether or not we want to allow
>>> this to be coupled with extra args and kwargs.
>>>
>>> e.g.
>>>
>>> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>>>
>>> I'd be in favor of preventing pk and kwarg or Q args mixing.
>>>
>>> Count me +1 for the get() case and -1 for the filter() one.
>>>
>>> Simon
>>>
>>> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :

 Hi,
 I'm creating this topic to see if there is interest to implement
 positional arguments in queryset filtering.

 Current situation

 Currently the only way to use positional arguments to filter can be
 either:

- Passing a single or multiple Q objects:

MyClass.objects.filter(Q(key=value))
MyClass.objects.filter(Q(key=value), Q(other_key=value))



- Passing a couple is also working (not sure if this is a happy
accident, should it be removed?)

MyClass.objects.filter((key, value))



- Combination of both is also proven to work

MyClass.objects.filter((key, value), Q(other_key=value))



 Suggestion

 This feature suggestion is to leverage the case when a non-Q / non
 couple object is passed, so it implicitly interpreted as the value for the
 model's pk.

 This could ease/simplify code by omitting pk when this is the only
 filter used:


 MyClass.objects.get(value)
 # Translates into: MyClass.objects.get(pk=value)


 or


 MyClass.objects.filter(value)
 # Translates into: MyClass.objects.filter(pk=value)


 or


 MyClass.objects.filter(Q(value))
 # Translates into: MyClass.objects.filter(Q(pk=value))


 Do you think it's worth it? It could be leveraged to simplify many
 situations.
 I'd be happy to proceed to the development myself if this is something
 gathering interest.

>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a29eed0a-687a-4964-aec3-a25eeeb6f441%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

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[charettes]

My main concern with allowing extra args and kwargs to be mixed with the 
proposed
pk arg notation is that it would allow lookups such as

get(Q(is_active=True), pk)

Simon

Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>
> *I'm not convinced this would be as useful for `filter()` though as I 
> don't*
> *recall wanting to retrieve a set of objects matching a value I know will*
> *be unique.*
>
> The .filter() could be used for update
>
> e.g.:
> Mymodel.objects.filter(1).update(key=value)
>
> This is also bringing consistency in the code, but I agree this could be 
> misleading.
> The .get() is the main purpose.
>
> *Something to keep in mind as well is whether or not we want to allow*
> *this to be coupled with extra args and kwargs.*
>
> Currently only kwargs are supposed to be used with get/filter. The only 
> args that can be used currently are Q() objects (and couples but I think 
> it's an issue).
> This proposed design suggestion is to also allow scalar values (strings, 
> int, etc) too.
>
>
> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>>
>> As I've mentioned on the ticket I've been wishing get(pk) could translate
>> to get(pk=pk) for a while but I never got to suggest it. Probably because 
>> I
>> didn't feel like adding (pk=...) was really that long. I'd note that most 
>> of the
>> times I wished this existed was when doing some object manipulations
>> through a Django shell.
>>
>> I'm not convinced this would be as useful for `filter()` though as I don't
>> recall wanting to retrieve a set of objects matching a value I know will
>> be unique.
>>
>> Something to keep in mind as well is whether or not we want to allow
>> this to be coupled with extra args and kwargs.
>>
>> e.g.
>>
>> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>>
>> I'd be in favor of preventing pk and kwarg or Q args mixing.
>>
>> Count me +1 for the get() case and -1 for the filter() one.
>>
>> Simon
>>
>> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>>
>>> Hi, 
>>> I'm creating this topic to see if there is interest to implement 
>>> positional arguments in queryset filtering.
>>>
>>> Current situation 
>>>
>>> Currently the only way to use positional arguments to filter can be 
>>> either:
>>>
>>>- Passing a single or multiple Q objects: 
>>>
>>>MyClass.objects.filter(Q(key=value))
>>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>>
>>>
>>>
>>>- Passing a couple is also working (not sure if this is a happy 
>>>accident, should it be removed?) 
>>>
>>>MyClass.objects.filter((key, value))
>>>
>>>
>>>
>>>- Combination of both is also proven to work 
>>>
>>>MyClass.objects.filter((key, value), Q(other_key=value))
>>>
>>>
>>>
>>> Suggestion 
>>>
>>> This feature suggestion is to leverage the case when a non-Q / non 
>>> couple object is passed, so it implicitly interpreted as the value for the 
>>> model's pk.
>>>
>>> This could ease/simplify code by omitting pk when this is the only 
>>> filter used:
>>>
>>>
>>> MyClass.objects.get(value)
>>> # Translates into: MyClass.objects.get(pk=value)
>>>
>>>
>>> or
>>>
>>>
>>> MyClass.objects.filter(value)
>>> # Translates into: MyClass.objects.filter(pk=value)
>>>
>>>
>>> or 
>>>
>>>
>>> MyClass.objects.filter(Q(value))
>>> # Translates into: MyClass.objects.filter(Q(pk=value))
>>>  
>>>
>>> Do you think it's worth it? It could be leveraged to simplify many 
>>> situations.
>>> I'd be happy to proceed to the development myself if this is something 
>>> gathering interest.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a29eed0a-687a-4964-aec3-a25eeeb6f441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Antwan]

*I'm not convinced this would be as useful for `filter()` though as I don't*
*recall wanting to retrieve a set of objects matching a value I know will*
*be unique.*

The .filter() could be used for update

e.g.:
Mymodel.objects.filter(1).update(key=value)

This is also bringing consistency in the code, but I agree this could be 
misleading.
The .get() is the main purpose.

*Something to keep in mind as well is whether or not we want to allow*
*this to be coupled with extra args and kwargs.*

Currently only kwargs are supposed to be used with get/filter. The only 
args that can be used currently are Q() objects (and couples but I think 
it's an issue).
This proposed design suggestion is to also allow scalar values (strings, 
int, etc) too.


On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>
> As I've mentioned on the ticket I've been wishing get(pk) could translate
> to get(pk=pk) for a while but I never got to suggest it. Probably because I
> didn't feel like adding (pk=...) was really that long. I'd note that most 
> of the
> times I wished this existed was when doing some object manipulations
> through a Django shell.
>
> I'm not convinced this would be as useful for `filter()` though as I don't
> recall wanting to retrieve a set of objects matching a value I know will
> be unique.
>
> Something to keep in mind as well is whether or not we want to allow
> this to be coupled with extra args and kwargs.
>
> e.g.
>
> Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>
> I'd be in favor of preventing pk and kwarg or Q args mixing.
>
> Count me +1 for the get() case and -1 for the filter() one.
>
> Simon
>
> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>
>> Hi, 
>> I'm creating this topic to see if there is interest to implement 
>> positional arguments in queryset filtering.
>>
>> Current situation 
>>
>> Currently the only way to use positional arguments to filter can be 
>> either:
>>
>>- Passing a single or multiple Q objects: 
>>
>>MyClass.objects.filter(Q(key=value))
>>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>
>>
>>
>>- Passing a couple is also working (not sure if this is a happy 
>>accident, should it be removed?) 
>>
>>MyClass.objects.filter((key, value))
>>
>>
>>
>>- Combination of both is also proven to work 
>>
>>MyClass.objects.filter((key, value), Q(other_key=value))
>>
>>
>>
>> Suggestion 
>>
>> This feature suggestion is to leverage the case when a non-Q / non couple 
>> object is passed, so it implicitly interpreted as the value for the model's 
>> pk.
>>
>> This could ease/simplify code by omitting pk when this is the only 
>> filter used:
>>
>>
>> MyClass.objects.get(value)
>> # Translates into: MyClass.objects.get(pk=value)
>>
>>
>> or
>>
>>
>> MyClass.objects.filter(value)
>> # Translates into: MyClass.objects.filter(pk=value)
>>
>>
>> or 
>>
>>
>> MyClass.objects.filter(Q(value))
>> # Translates into: MyClass.objects.filter(Q(pk=value))
>>  
>>
>> Do you think it's worth it? It could be leveraged to simplify many 
>> situations.
>> I'd be happy to proceed to the development myself if this is something 
>> gathering interest.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/169297f4-3b10-4677-8197-805acb7ad283%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[charettes]

As I've mentioned on the ticket I've been wishing get(pk) could translate
to get(pk=pk) for a while but I never got to suggest it. Probably because I
didn't feel like adding (pk=...) was really that long. I'd note that most 
of the
times I wished this existed was when doing some object manipulations
through a Django shell.

I'm not convinced this would be as useful for `filter()` though as I don't
recall wanting to retrieve a set of objects matching a value I know will
be unique.

Something to keep in mind as well is whether or not we want to allow
this to be coupled with extra args and kwargs.

e.g.

Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')

I'd be in favor of preventing pk and kwarg or Q args mixing.

Count me +1 for the get() case and -1 for the filter() one.

Simon

Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>
> Hi, 
> I'm creating this topic to see if there is interest to implement 
> positional arguments in queryset filtering.
>
> Current situation 
>
> Currently the only way to use positional arguments to filter can be either:
>
>- Passing a single or multiple Q objects: 
>
>MyClass.objects.filter(Q(key=value))
>MyClass.objects.filter(Q(key=value), Q(other_key=value))
>
>
>
>- Passing a couple is also working (not sure if this is a happy 
>accident, should it be removed?) 
>
>MyClass.objects.filter((key, value))
>
>
>
>- Combination of both is also proven to work 
>
>MyClass.objects.filter((key, value), Q(other_key=value))
>
>
>
> Suggestion 
>
> This feature suggestion is to leverage the case when a non-Q / non couple 
> object is passed, so it implicitly interpreted as the value for the model's 
> pk.
>
> This could ease/simplify code by omitting pk when this is the only filter 
> used:
>
>
> MyClass.objects.get(value)
> # Translates into: MyClass.objects.get(pk=value)
>
>
> or
>
>
> MyClass.objects.filter(value)
> # Translates into: MyClass.objects.filter(pk=value)
>
>
> or 
>
>
> MyClass.objects.filter(Q(value))
> # Translates into: MyClass.objects.filter(Q(pk=value))
>  
>
> Do you think it's worth it? It could be leveraged to simplify many 
> situations.
> I'd be happy to proceed to the development myself if this is something 
> gathering interest.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1c33a94d-5bf8-46f6-a9b7-0e0929842acc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Better support for javascript heavy sites

[Emil Stenström]

On Saturday, 30 May 2015 18:51:33 UTC+2, Emil Stenström wrote:
>
> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
> the title "Why Django Sucks". The idea was to follow in the footsteps of 
> great conference talks like these: 
> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 
>
> These talks are great because they encourage people to take an outside, 
> critical, perspective of Django and where it's going. 
>

Here's my talk if anyone is interested: 
https://www.youtube.com/watch?v=Niq-HoraNPo

-- 
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/89b5b586-00a0-4625-9811-e7257dc404dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Better support for javascript heavy sites

[Emil Stenström]

My conclusions to all the feedback in the three different threads are this:

   - You don't agree about the general need to support heavier javascript 
   apps "out of the box" in Django
   - You are open to discussion about specific features being added...
   - ... but to be considered here they first need to be extremely popular 
   in the community (see South)
   
I will still start working on these features as third party apps, we'll see 
where this goes.

On Saturday, 30 May 2015 18:55:54 UTC+2, Emil Stenström wrote:
>
>
> On Saturday, 30 May 2015 18:51:33 UTC+2, Emil Stenström wrote:
>>
>> *I will split the specific suggestions into three different e-mail 
>> threads, so we can discuss them separately*. 
>>
>
> Here's are the three different proposals:
> https://groups.google.com/forum/#!topic/django-developers/fRPXSGnPng0
> https://groups.google.com/forum/#!topic/django-developers/gawpGr9EtKM
> https://groups.google.com/forum/#!topic/django-developers/FmBM8VdxJ08 
>

-- 
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/4b80aac2-a809-487a-8070-b38620303e77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Better support for javascript heavy sites

[Collin Anderson]

Hi Emil,

I also like "server sent events" (EventSource). They get through proxies 
much more reliably than WebSockets. :)

"You would start the process separately, add a script tag to your page, and 
all clients that connected to the page would be connected to the process. 
Now Django could push messages through that process as part of the 
request-response cycle, and all clients would be notified. Other processes 
(a cron job?) could do the same."

Have you thought about how to scale this across multiple machines?

Thanks,
Collin


On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote:
>
> Hi! 
>
> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
> the title "Why Django Sucks". The idea was to follow in the footsteps of 
> great conference talks like these: 
> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 
>
> These talks are great because they encourage people to take an outside, 
> critical, perspective of Django and where it's going. 
>
> My talk was well received, with many both interested and skeptical 
> questions afterwards. Unfortunately, the final video was missing the 
> sound, so the camera crew is working on fixing that now. I'll post it to 
> this thread as soon as I get it. Meanwhile, here's a text summary: 
>
> --- 
>
> The theme for my talk was that Django's bad support for Javascript heavy 
> sites. Everyone is using javascript for their sites nowadays. Problem 
> is, Django (and large parts if the Django community) has long had a 
> approach to Javascript that can be summed up with Simon Willison's reply 
> to someone asking for AJAX support in 2005: 
>
> "For me "Ajax support" really is pure marketing fluff - as far as I'm 
> concerned EVERY web framework supports Ajax unless it does something 
> truly moronic like refuse to let you output documents that don't have 
> the standard header/footer template." 
> Source: http://bit.ly/django2005 
>
> The problem with this mindset (I'm not picking at Simon from 10 years 
> ago) is that the web as large is moving towards MORE javascript, with 
> live notifications, live updating templates, and reusable template 
> components. And these are hard to implement in Django as things work 
> today. I see this is the biggest competitive disadvantage Django has 
> going forward. 
>
> So, what specific features am I proposing? I will get to a specific set 
> of features soon. But first I want to make clear that a completely 
> different set of features could get us to the same goal. That is: it's 
> possible to agree on the broader goal for Django, and disagree on my 
> specific set of features. If you don't agree on the features, I would 
> love to see your proposed feature list. 
>
> Just to give one alternate path: In that old thread from 2005, Jacob 
> Kaplan-Moss suggested exposing the ORM through Javascript with an RPC API: 
> https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J 
>
> Jacobs suggestion is interesting, but I have three other features that I 
> would like to discuss. I think they would greatly ease building 
> javascript heavy sites with Django. 
>
> *I will split the specific suggestions into three different e-mail 
> threads, so we can discuss them separately*. 
>
> Here's a short intro to them: 
>
> 1. Template Components 
> React.js popularized the notion that in front-end development, code 
> organization should be based on interface components, not split up into 
> HTML, Javascript and CSS. It's simply a different way to organize the 
> code for your front-end, that I strongly think Django should make 
> easier. (read more in separate thread) 
>
> 2. Support a client side template language 
> The multiple template engine work has made it possible to switch out 
> Django Templates with another engine. One of the most powerful things 
> this enables is to use a template language that is executable both on 
> the server and client. This means you can do the same kind of live 
> updates to your page that the Meteor.js people are doing, and just 
> re-render parts of the DOM as a direct result of a database update. 
> (read more in separate thread) 
>
> 3. Support Server-Sent Events 
> If you want a snappy user experience, polling isn't enough. There are 
> two major ways to get out of the request-response cycle. Namely: 
> websockets and server-sent events. Server-Sent Events have a much 
> simpler protocol, and could be implemented with asyncio (no external 
> dependencies except for backwards compatibility) in a performant way. It 
> would be a great reason to choose Django over other frameworks. (read 
> more in separate thread) 
>
> --- 
>
> This is not a "request for features". I am in no way saying that I think 
> you should build things for me. Instead I'm willing to work on  them 
> together with anyone interested, if these are features that the core 
> team would be interested in. 
>
> But first I would like to see if you: 
> 1. Agree on

Re: Idea: Better support for javascript heavy sites

[Emil Stenström]

On Saturday, 30 May 2015 18:51:33 UTC+2, Emil Stenström wrote:
>
> *I will split the specific suggestions into three different e-mail 
> threads, so we can discuss them separately*. 
>

Here's are the three different proposals:
https://groups.google.com/forum/#!topic/django-developers/fRPXSGnPng0
https://groups.google.com/forum/#!topic/django-developers/gawpGr9EtKM
https://groups.google.com/forum/#!topic/django-developers/FmBM8VdxJ08 

-- 
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/89ed6aab-2266-4847-8c4c-dcb6f9729633%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

The survey is now "live". I saved the original responses separately, but 
some questions have been added or changed, so please respond again if you 
are willing. Thanks again for everyone's help and feedback in constructing 
the questions and I look forward to sharing the results.

On Saturday, May 2, 2015 at 8:27:34 PM UTC-4, Tim Graham wrote:
>
> I made a few edits based on recent feedback. I'll publicize it via the 
> djangoproject.com some time next week.
>
> On Wednesday, April 29, 2015 at 1:59:20 AM UTC-4, Markus Holtermann wrote:
>>
>> It's an amazing idea. Thanks for putting it up, Aymeric and Tim!
>>
>> Can we add a question regarding usage of test frameworks (i.e., 
>> unittest2, py.test, nose) similar to "Which popular third-party apps do you 
>> rely on?" For example "Which test frameworks do you use?" - "unittest2, 
>> py.test, nose, other". That would allow us to see if we should / can 
>> include features in django.test that may require a specific framework 
>> without excluding too many people of our community.
>>
>> /Markus
>>
>> On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>>>
>>>  I wrote in that thread too why I dont like such fast releases and at 
>>> least someone else asked too to give more options on that one question, on 
>>> the developer mailing list its kinda only some people who are writing not 
>>> reflecting all the developers such an survey maybe reach more of them and 
>>> then the answer about such an important question shouldnt be reduced to 3 
>>> little options a handfull people decided on, that wouldnt reflect what 
>>> people really want if they cant choose an real answer.
>>>
>>> Am 27.04.2015 02:46, schrieb Tim Graham:
>>>  
>>> The idea of the release schedule question is to form consensus on the 
>>> options that have already been proposed in the "1.9 release planning 
>>> "
>>>  
>>> thread. If you have a different idea, please propose it there.
>>>
>>> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 

  I like the idea of an survey, but find the release question with only 
 3 options quite limited, how about to allow there to put own numbers 
 instead of giving fixed answers or at least an other field?

 Am 25.04.2015 14:29, schrieb Tim Graham:
  
 Aymeric and I put together a draft:


 https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform

 All questions are optional so you can just click through it to view the 
 questions. We'll probably clear any responses before its finalized anyway.

 Let us know if you think we should make any additions or changes.

 On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano 
 wrote: 
>
> Great idea. 
> The questions look good enough to me.
>
>  I love django-apps or libraries shipped in python packages. One of 
> the reason I love Django is the fact that it didn't frenetically add 
> stuff 
> to the framework just because it's cool.
> The good thing of python packages is that you can get some data from 
> pypi (downloads) and github (clones). But we can't do that with contrib 
> apps unfortunately.
>
>  Federico
>
>
> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>>
>> I had an idea to conduct a survey to get a sense of how developers 
>> are using Django. I first had the idea when the question of maintenance 
>> of 
>> the Oracle GIS backend came up. We really have no idea whether or not 
>> anyone is actually using that backend, and it would be helpful to know 
>> so 
>> we are not wasting resources on unused features. Also there's the 
>> question 
>> of how often to release Django. I think it would be nice to make that 
>> decision based on some data from the community.
>>
>> Is anyone is interested in coordinating such a survey (collating 
>> questions, preparing the online survey, etc.).
>>
>> Some question ideas to get started:
>>
>> Which database backend(s) do you use?
>> [ ] Checkbox for each one
>>
>> Which contrib apps do you use?
>> [ ] Checkbox for each one
>>
>> How often would you like to see new major version of Django released?
>> [ ] List some options, probably between 6 and 9 months.
>>
>> Describe which version of Django you use (check all the apply):
>> [ ] I only use long-term support releases.
>> [ ] I upgrade to the latest stable version as quickly as possible.
>> [ ] I run off of master.
>> [ ] I upgrade Django when the version I am using is nearing the end 
>> of its support (or after).
>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>  
>   -- 
 You received this message because you are subscribed to the Goo

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

I made a few edits based on recent feedback. I'll publicize it via the 
djangoproject.com some time next week.

On Wednesday, April 29, 2015 at 1:59:20 AM UTC-4, Markus Holtermann wrote:
>
> It's an amazing idea. Thanks for putting it up, Aymeric and Tim!
>
> Can we add a question regarding usage of test frameworks (i.e., unittest2, 
> py.test, nose) similar to "Which popular third-party apps do you rely on?" 
> For example "Which test frameworks do you use?" - "unittest2, py.test, 
> nose, other". That would allow us to see if we should / can include 
> features in django.test that may require a specific framework without 
> excluding too many people of our community.
>
> /Markus
>
> On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>>
>>  I wrote in that thread too why I dont like such fast releases and at 
>> least someone else asked too to give more options on that one question, on 
>> the developer mailing list its kinda only some people who are writing not 
>> reflecting all the developers such an survey maybe reach more of them and 
>> then the answer about such an important question shouldnt be reduced to 3 
>> little options a handfull people decided on, that wouldnt reflect what 
>> people really want if they cant choose an real answer.
>>
>> Am 27.04.2015 02:46, schrieb Tim Graham:
>>  
>> The idea of the release schedule question is to form consensus on the 
>> options that have already been proposed in the "1.9 release planning 
>> "
>>  
>> thread. If you have a different idea, please propose it there.
>>
>> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 
>>>
>>>  I like the idea of an survey, but find the release question with only 
>>> 3 options quite limited, how about to allow there to put own numbers 
>>> instead of giving fixed answers or at least an other field?
>>>
>>> Am 25.04.2015 14:29, schrieb Tim Graham:
>>>  
>>> Aymeric and I put together a draft:
>>>
>>>
>>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>>>
>>> All questions are optional so you can just click through it to view the 
>>> questions. We'll probably clear any responses before its finalized anyway.
>>>
>>> Let us know if you think we should make any additions or changes.
>>>
>>> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano 
>>> wrote: 

 Great idea. 
 The questions look good enough to me.

  I love django-apps or libraries shipped in python packages. One of 
 the reason I love Django is the fact that it didn't frenetically add stuff 
 to the framework just because it's cool.
 The good thing of python packages is that you can get some data from 
 pypi (downloads) and github (clones). But we can't do that with contrib 
 apps unfortunately.

  Federico


 On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>
> I had an idea to conduct a survey to get a sense of how developers are 
> using Django. I first had the idea when the question of maintenance of 
> the 
> Oracle GIS backend came up. We really have no idea whether or not anyone 
> is 
> actually using that backend, and it would be helpful to know so we are 
> not 
> wasting resources on unused features. Also there's the question of how 
> often to release Django. I think it would be nice to make that decision 
> based on some data from the community.
>
> Is anyone is interested in coordinating such a survey (collating 
> questions, preparing the online survey, etc.).
>
> Some question ideas to get started:
>
> Which database backend(s) do you use?
> [ ] Checkbox for each one
>
> Which contrib apps do you use?
> [ ] Checkbox for each one
>
> How often would you like to see new major version of Django released?
> [ ] List some options, probably between 6 and 9 months.
>
> Describe which version of Django you use (check all the apply):
> [ ] I only use long-term support releases.
> [ ] I upgrade to the latest stable version as quickly as possible.
> [ ] I run off of master.
> [ ] I upgrade Django when the version I am using is nearing the end of 
> its support (or after).
> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>  
   -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/f14071d1-c570

Re: Idea/request for help: Django Developers Community Survey

[Markus Holtermann]

It's an amazing idea. Thanks for putting it up, Aymeric and Tim!

Can we add a question regarding usage of test frameworks (i.e., unittest2, 
py.test, nose) similar to "Which popular third-party apps do you rely on?" 
For example "Which test frameworks do you use?" - "unittest2, py.test, 
nose, other". That would allow us to see if we should / can include 
features in django.test that may require a specific framework without 
excluding too many people of our community.

/Markus

On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>
>  I wrote in that thread too why I dont like such fast releases and at 
> least someone else asked too to give more options on that one question, on 
> the developer mailing list its kinda only some people who are writing not 
> reflecting all the developers such an survey maybe reach more of them and 
> then the answer about such an important question shouldnt be reduced to 3 
> little options a handfull people decided on, that wouldnt reflect what 
> people really want if they cant choose an real answer.
>
> Am 27.04.2015 02:46, schrieb Tim Graham:
>  
> The idea of the release schedule question is to form consensus on the 
> options that have already been proposed in the "1.9 release planning 
> " 
> thread. If you have a different idea, please propose it there.
>
> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 
>>
>>  I like the idea of an survey, but find the release question with only 3 
>> options quite limited, how about to allow there to put own numbers instead 
>> of giving fixed answers or at least an other field?
>>
>> Am 25.04.2015 14:29, schrieb Tim Graham:
>>  
>> Aymeric and I put together a draft:
>>
>>
>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>>
>> All questions are optional so you can just click through it to view the 
>> questions. We'll probably clear any responses before its finalized anyway.
>>
>> Let us know if you think we should make any additions or changes.
>>
>> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote: 
>>>
>>> Great idea. 
>>> The questions look good enough to me.
>>>
>>>  I love django-apps or libraries shipped in python packages. One of the 
>>> reason I love Django is the fact that it didn't frenetically add stuff to 
>>> the framework just because it's cool.
>>> The good thing of python packages is that you can get some data from 
>>> pypi (downloads) and github (clones). But we can't do that with contrib 
>>> apps unfortunately.
>>>
>>>  Federico
>>>
>>>
>>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 

 I had an idea to conduct a survey to get a sense of how developers are 
 using Django. I first had the idea when the question of maintenance of the 
 Oracle GIS backend came up. We really have no idea whether or not anyone 
 is 
 actually using that backend, and it would be helpful to know so we are not 
 wasting resources on unused features. Also there's the question of how 
 often to release Django. I think it would be nice to make that decision 
 based on some data from the community.

 Is anyone is interested in coordinating such a survey (collating 
 questions, preparing the online survey, etc.).

 Some question ideas to get started:

 Which database backend(s) do you use?
 [ ] Checkbox for each one

 Which contrib apps do you use?
 [ ] Checkbox for each one

 How often would you like to see new major version of Django released?
 [ ] List some options, probably between 6 and 9 months.

 Describe which version of Django you use (check all the apply):
 [ ] I only use long-term support releases.
 [ ] I upgrade to the latest stable version as quickly as possible.
 [ ] I run off of master.
 [ ] I upgrade Django when the version I am using is nearing the end of 
 its support (or after).
 [ ] I don't bother upgrading Django, even if it becomes unsupported.
  
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>   -- 
> You received this message because you are s

Re: Idea/request for help: Django Developers Community Survey

[Thorsten Sanders]

I wrote in that thread too why I dont like such fast releases and at 
least someone else asked too to give more options on that one question, 
on the developer mailing list its kinda only some people who are writing 
not reflecting all the developers such an survey maybe reach more of 
them and then the answer about such an important question shouldnt be 
reduced to 3 little options a handfull people decided on, that wouldnt 
reflect what people really want if they cant choose an real answer.


Am 27.04.2015 02:46, schrieb Tim Graham:
The idea of the release schedule question is to form consensus on the 
options that have already been proposed in the "1.9 release planning 
" 
thread. If you have a different idea, please propose it there.


On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote:

I like the idea of an survey, but find the release question with
only 3 options quite limited, how about to allow there to put own
numbers instead of giving fixed answers or at least an other field?

Am 25.04.2015 14:29, schrieb Tim Graham:

Aymeric and I put together a draft:


https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform



All questions are optional so you can just click through it to
view the questions. We'll probably clear any responses before its
finalized anyway.

Let us know if you think we should make any additions or changes.

On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico
Capoano wrote:

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages.
One of the reason I love Django is the fact that it didn't
frenetically add stuff to the framework just because it's cool.
The good thing of python packages is that you can get some
data from pypi (downloads) and github (clones). But we can't
do that with contrib apps unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham
wrote:

I had an idea to conduct a survey to get a sense of how
developers are using Django. I first had the idea when
the question of maintenance of the Oracle GIS backend
came up. We really have no idea whether or not anyone is
actually using that backend, and it would be helpful to
know so we are not wasting resources on unused features.
Also there's the question of how often to release Django.
I think it would be nice to make that decision based on
some data from the community.

Is anyone is interested in coordinating such a survey
(collating questions, preparing the online survey, etc.).

Some question ideas to get started:

Which database backend(s) do you use?
[ ] Checkbox for each one

Which contrib apps do you use?
[ ] Checkbox for each one

How often would you like to see new major version of
Django released?
[ ] List some options, probably between 6 and 9 months.

Describe which version of Django you use (check all the
apply):
[ ] I only use long-term support releases.
[ ] I upgrade to the latest stable version as quickly as
possible.
[ ] I run off of master.
[ ] I upgrade Django when the version I am using is
nearing the end of its support (or after).
[ ] I don't bother upgrading Django, even if it becomes
unsupported.

-- 
You received this message because you are subscribed to the

Google Groups "Django developers (Contributions to Django
itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-develop...@googlegroups.com .
To post to this group, send email to django-d...@googlegroups.com
.
Visit this group at
http://groups.google.com/group/django-developers
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%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+

Re: Idea/request for help: Django Developers Community Survey

[Tino de Bruijn]

Hi,

Mark, I tend to do the same. Your proposed split of that question makes
sense to me.

Maybe a bit onto the details, but the last question about leaving an email
adres ("If you'd like to enter your name and email address so we can
follow-up if we have any questions about your responses. Please enter that
information below.") is a little oddly constructed...

Tino

On Mon, Apr 27, 2015 at 10:32 AM, Mark Bailey 
wrote:

> I think the survey is a great idea.
>
> Following on from Shai's question "one big project, or many small
> ones?"... I am the latter, so the "which version" doesn't really work for
> me even with multiple answers allowed.  I tend to:
>  . Start each new project with the latest stable version.
>  . Upgrade existing projects to latest stable version if I'm doing major
> rework (and have time to deal with any upgrade issues).
>  . Leave well alone for projects that are running happily.
>  . I don't have any really old projects, but I'll keep them all on
> supported versions.
>
> Splitting into 2 questions would be one way to capture this.  Maybe:
>
> When starting a new project which version of Django you use:
>  [ ] I use the latest long-term support release.
>  [ ] I use the latest stable version.
>  [ ] I run off of master.
>  [ ] I use a "favourite" version.
>
> For existing projects when do you upgrade Django:
>  [ ] When there is a new long-term support release.
>  [ ] When there is a new stable version.
>  [ ] I run off of master.
>  [ ] When I want a new feature.
>  [ ] When I am working on that project again.
>  [ ] When the version I am using is nearing the end of its support (or
> after).
>  [ ] I don't bother upgrading Django, even if it becomes unsupported.
>
> Cheers,
>
> Mark.
>
> --
> 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/5a176c0d-8d8a-4edc-8ca0-97ed05a2c9ba%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/CANQFsQB5tP1SObYmLatqw_-EkhU-mezH6JaCGmAeMazLpDUnfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Mark Bailey]

I think the survey is a great idea.

Following on from Shai's question "one big project, or many small ones?"... 
I am the latter, so the "which version" doesn't really work for me even 
with multiple answers allowed.  I tend to:
 . Start each new project with the latest stable version.
 . Upgrade existing projects to latest stable version if I'm doing major 
rework (and have time to deal with any upgrade issues).
 . Leave well alone for projects that are running happily.
 . I don't have any really old projects, but I'll keep them all on 
supported versions.

Splitting into 2 questions would be one way to capture this.  Maybe:

When starting a new project which version of Django you use:
 [ ] I use the latest long-term support release.
 [ ] I use the latest stable version.
 [ ] I run off of master.
 [ ] I use a "favourite" version.

For existing projects when do you upgrade Django:
 [ ] When there is a new long-term support release.
 [ ] When there is a new stable version.
 [ ] I run off of master.
 [ ] When I want a new feature.
 [ ] When I am working on that project again.
 [ ] When the version I am using is nearing the end of its support (or 
after).
 [ ] I don't bother upgrading Django, even if it becomes unsupported.

Cheers,

Mark.

-- 
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/5a176c0d-8d8a-4edc-8ca0-97ed05a2c9ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

The idea of the release schedule question is to form consensus on the 
options that have already been proposed in the "1.9 release planning 
" 
thread. If you have a different idea, please propose it there.

On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote:
>
>  I like the idea of an survey, but find the release question with only 3 
> options quite limited, how about to allow there to put own numbers instead 
> of giving fixed answers or at least an other field?
>
> Am 25.04.2015 14:29, schrieb Tim Graham:
>  
> Aymeric and I put together a draft:
>
>
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>
> All questions are optional so you can just click through it to view the 
> questions. We'll probably clear any responses before its finalized anyway.
>
> Let us know if you think we should make any additions or changes.
>
> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote: 
>>
>> Great idea. 
>> The questions look good enough to me.
>>
>>  I love django-apps or libraries shipped in python packages. One of the 
>> reason I love Django is the fact that it didn't frenetically add stuff to 
>> the framework just because it's cool.
>> The good thing of python packages is that you can get some data from pypi 
>> (downloads) and github (clones). But we can't do that with contrib apps 
>> unfortunately.
>>
>>  Federico
>>
>>
>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>>>
>>> I had an idea to conduct a survey to get a sense of how developers are 
>>> using Django. I first had the idea when the question of maintenance of the 
>>> Oracle GIS backend came up. We really have no idea whether or not anyone is 
>>> actually using that backend, and it would be helpful to know so we are not 
>>> wasting resources on unused features. Also there's the question of how 
>>> often to release Django. I think it would be nice to make that decision 
>>> based on some data from the community.
>>>
>>> Is anyone is interested in coordinating such a survey (collating 
>>> questions, preparing the online survey, etc.).
>>>
>>> Some question ideas to get started:
>>>
>>> Which database backend(s) do you use?
>>> [ ] Checkbox for each one
>>>
>>> Which contrib apps do you use?
>>> [ ] Checkbox for each one
>>>
>>> How often would you like to see new major version of Django released?
>>> [ ] List some options, probably between 6 and 9 months.
>>>
>>> Describe which version of Django you use (check all the apply):
>>> [ ] I only use long-term support releases.
>>> [ ] I upgrade to the latest stable version as quickly as possible.
>>> [ ] I run off of master.
>>> [ ] I upgrade Django when the version I am using is nearing the end of 
>>> its support (or after).
>>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>>  
>>   -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%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/b2c3d0ac-1a8e-4a70-9fb7-24bf6e0e1581%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Thorsten Sanders]

I like the idea of an survey, but find the release question with only 3 
options quite limited, how about to allow there to put own numbers 
instead of giving fixed answers or at least an other field?


Am 25.04.2015 14:29, schrieb Tim Graham:

Aymeric and I put together a draft:

https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform

All questions are optional so you can just click through it to view 
the questions. We'll probably clear any responses before its finalized 
anyway.


Let us know if you think we should make any additions or changes.

On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote:

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages. One of
the reason I love Django is the fact that it didn't frenetically
add stuff to the framework just because it's cool.
The good thing of python packages is that you can get some data
from pypi (downloads) and github (clones). But we can't do that
with contrib apps unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:

I had an idea to conduct a survey to get a sense of how
developers are using Django. I first had the idea when the
question of maintenance of the Oracle GIS backend came up. We
really have no idea whether or not anyone is actually using
that backend, and it would be helpful to know so we are not
wasting resources on unused features. Also there's the
question of how often to release Django. I think it would be
nice to make that decision based on some data from the community.

Is anyone is interested in coordinating such a survey
(collating questions, preparing the online survey, etc.).

Some question ideas to get started:

Which database backend(s) do you use?
[ ] Checkbox for each one

Which contrib apps do you use?
[ ] Checkbox for each one

How often would you like to see new major version of Django
released?
[ ] List some options, probably between 6 and 9 months.

Describe which version of Django you use (check all the apply):
[ ] I only use long-term support releases.
[ ] I upgrade to the latest stable version as quickly as possible.
[ ] I run off of master.
[ ] I upgrade Django when the version I am using is nearing
the end of its support (or after).
[ ] I don't bother upgrading Django, even if it becomes
unsupported.

--
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/f14071d1-c570-483a-abd2-833e1b47ab4d%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/553CC38C.6030802%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Wim Feijen]

Hi,

"How often would you like to see new major version of Django released?"
currently lists three options, which are close to one another. I would like 
to have: 12 months, as well as an open option. Is it an idea to add those? 
Detailed release schedules are not necessary, in my opinion.

"I follow Django development through:"
I would like to add "Newsletter" as an option. Lincoln Loop has a really 
nice newsletter I can recommend. 

Best regards,

Wim



On Sunday, 26 April 2015 08:34:15 UTC+2, Shai Berger wrote:
>
> Hi, 
>
> On Saturday 25 April 2015 15:29:30 Tim Graham wrote: 
> > Aymeric and I put together a draft: 
> > 
> > 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxW 
> > w/viewform 
> > 
> > All questions are optional so you can just click through it to view the 
> > questions. We'll probably clear any responses before its finalized 
> anyway. 
> > 
> > Let us know if you think we should make any additions or changes. 
> > 
>
> This looks great, thanks for putting it together. There are only a few 
> things 
> I'd like to add. 
>
> First of all, a question I find interesting about the general use pattern: 
> "Do 
> you use Django mainly for one big project, or many small ones?" I'm not 
> sure 
> what's the best way to phrase it, but I think it may be important for 
> interpreting other answers (e.g. larger projects will probably tend to 
> move 
> slower w.r.t releases, will tend to use more contrib and 3rd-party apps, 
> etc). 
>
> In "components": Request processing (URLs, middleware, view decorators). 
> Also, while not a "component" per se, Django's documentation is often 
> cited as 
> a valuable resource, and a lot of effort goes into it; I'm not sure adding 
> it 
> as a component adds value, but perhaps we should ask about topic guides 
> vs. 
> reference or something of the sort. 
>  
> In the question about "contrib" apps, should we include the removed apps 
> (comments, markup, formtools, localflavor)? 
>
> In the list of 3rd-party backends: I'm not sure what are the criteria for 
> being in this list; two other 3rd-patyr backends I'm aware of are django- 
> pyodbc-azure (which I've used) and the proprietary mxODBC-django. 
>
> Again, thanks for the initiative, 
>
> 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/f4a58426-bdf8-47b4-9077-befc243c828b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Shai Berger]

Hi,

On Saturday 25 April 2015 15:29:30 Tim Graham wrote:
> Aymeric and I put together a draft:
> 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxW
> w/viewform
> 
> All questions are optional so you can just click through it to view the
> questions. We'll probably clear any responses before its finalized anyway.
> 
> Let us know if you think we should make any additions or changes.
> 

This looks great, thanks for putting it together. There are only a few things 
I'd like to add.

First of all, a question I find interesting about the general use pattern: "Do 
you use Django mainly for one big project, or many small ones?" I'm not sure 
what's the best way to phrase it, but I think it may be important for 
interpreting other answers (e.g. larger projects will probably tend to move 
slower w.r.t releases, will tend to use more contrib and 3rd-party apps, etc).

In "components": Request processing (URLs, middleware, view decorators).
Also, while not a "component" per se, Django's documentation is often cited as 
a valuable resource, and a lot of effort goes into it; I'm not sure adding it 
as a component adds value, but perhaps we should ask about topic guides vs. 
reference or something of the sort.

In the question about "contrib" apps, should we include the removed apps 
(comments, markup, formtools, localflavor)?

In the list of 3rd-party backends: I'm not sure what are the criteria for 
being in this list; two other 3rd-patyr backends I'm aware of are django-
pyodbc-azure (which I've used) and the proprietary mxODBC-django.

Again, thanks for the initiative,

Shai.

Re: Idea/request for help: Django Developers Community Survey

[Carl Meyer]

On 04/25/2015 06:29 AM, Tim Graham wrote:
> Aymeric and I put together a draft:
> 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
> 
> All questions are optional so you can just click through it to view the
> questions. We'll probably clear any responses before its finalized anyway.
> 
> Let us know if you think we should make any additions or changes.

Looks good to me! Thanks for putting that together. Looking forward to
seeing the results.

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/553C1F22.7080100%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Idea/request for help: Django Developers Community Survey

[Marc Tamlyn]

I would suggest IRC and/or Github should be options on the "I follow Django
development" question.

I'd also suggest we ask a couple of open ended questions along the line of
"What's your favourite thing about Django" and "What's your least favourite
thing about Django". I've found interesting responses from people before
along those lines.

Marc

On 25 April 2015 at 13:29, Tim Graham  wrote:

> Aymeric and I put together a draft:
>
>
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>
> All questions are optional so you can just click through it to view the
> questions. We'll probably clear any responses before its finalized anyway.
>
> Let us know if you think we should make any additions or changes.
>
>
> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote:
>>
>> Great idea.
>> The questions look good enough to me.
>>
>> I love django-apps or libraries shipped in python packages. One of the
>> reason I love Django is the fact that it didn't frenetically add stuff to
>> the framework just because it's cool.
>> The good thing of python packages is that you can get some data from pypi
>> (downloads) and github (clones). But we can't do that with contrib apps
>> unfortunately.
>>
>> Federico
>>
>>
>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:
>>>
>>> I had an idea to conduct a survey to get a sense of how developers are
>>> using Django. I first had the idea when the question of maintenance of the
>>> Oracle GIS backend came up. We really have no idea whether or not anyone is
>>> actually using that backend, and it would be helpful to know so we are not
>>> wasting resources on unused features. Also there's the question of how
>>> often to release Django. I think it would be nice to make that decision
>>> based on some data from the community.
>>>
>>> Is anyone is interested in coordinating such a survey (collating
>>> questions, preparing the online survey, etc.).
>>>
>>> Some question ideas to get started:
>>>
>>> Which database backend(s) do you use?
>>> [ ] Checkbox for each one
>>>
>>> Which contrib apps do you use?
>>> [ ] Checkbox for each one
>>>
>>> How often would you like to see new major version of Django released?
>>> [ ] List some options, probably between 6 and 9 months.
>>>
>>> Describe which version of Django you use (check all the apply):
>>> [ ] I only use long-term support releases.
>>> [ ] I upgrade to the latest stable version as quickly as possible.
>>> [ ] I run off of master.
>>> [ ] I upgrade Django when the version I am using is nearing the end of
>>> its support (or after).
>>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>>
>>  --
> 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/f14071d1-c570-483a-abd2-833e1b47ab4d%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/CAMwjO1EiqZOaUm2g%2BCuwMDvDG_%2ByWVUayymAhZ-7jK5syLNarg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

Aymeric and I put together a draft:

https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform

All questions are optional so you can just click through it to view the 
questions. We'll probably clear any responses before its finalized anyway.

Let us know if you think we should make any additions or changes.

On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote:
>
> Great idea.
> The questions look good enough to me.
>
> I love django-apps or libraries shipped in python packages. One of the 
> reason I love Django is the fact that it didn't frenetically add stuff to 
> the framework just because it's cool.
> The good thing of python packages is that you can get some data from pypi 
> (downloads) and github (clones). But we can't do that with contrib apps 
> unfortunately.
>
> Federico
>
>
> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:
>>
>> I had an idea to conduct a survey to get a sense of how developers are 
>> using Django. I first had the idea when the question of maintenance of the 
>> Oracle GIS backend came up. We really have no idea whether or not anyone is 
>> actually using that backend, and it would be helpful to know so we are not 
>> wasting resources on unused features. Also there's the question of how 
>> often to release Django. I think it would be nice to make that decision 
>> based on some data from the community.
>>
>> Is anyone is interested in coordinating such a survey (collating 
>> questions, preparing the online survey, etc.).
>>
>> Some question ideas to get started:
>>
>> Which database backend(s) do you use?
>> [ ] Checkbox for each one
>>
>> Which contrib apps do you use?
>> [ ] Checkbox for each one
>>
>> How often would you like to see new major version of Django released?
>> [ ] List some options, probably between 6 and 9 months.
>>
>> Describe which version of Django you use (check all the apply):
>> [ ] I only use long-term support releases.
>> [ ] I upgrade to the latest stable version as quickly as possible.
>> [ ] I run off of master.
>> [ ] I upgrade Django when the version I am using is nearing the end of 
>> its support (or after).
>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>
>

-- 
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/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Federico Capoano]

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages. One of the 
reason I love Django is the fact that it didn't frenetically add stuff to 
the framework just because it's cool.
The good thing of python packages is that you can get some data from pypi 
(downloads) and github (clones). But we can't do that with contrib apps 
unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:
>
> I had an idea to conduct a survey to get a sense of how developers are 
> using Django. I first had the idea when the question of maintenance of the 
> Oracle GIS backend came up. We really have no idea whether or not anyone is 
> actually using that backend, and it would be helpful to know so we are not 
> wasting resources on unused features. Also there's the question of how 
> often to release Django. I think it would be nice to make that decision 
> based on some data from the community.
>
> Is anyone is interested in coordinating such a survey (collating 
> questions, preparing the online survey, etc.).
>
> Some question ideas to get started:
>
> Which database backend(s) do you use?
> [ ] Checkbox for each one
>
> Which contrib apps do you use?
> [ ] Checkbox for each one
>
> How often would you like to see new major version of Django released?
> [ ] List some options, probably between 6 and 9 months.
>
> Describe which version of Django you use (check all the apply):
> [ ] I only use long-term support releases.
> [ ] I upgrade to the latest stable version as quickly as possible.
> [ ] I run off of master.
> [ ] I upgrade Django when the version I am using is nearing the end of its 
> support (or after).
> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>

-- 
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/8a4ac444-2b4e-4321-ad34-8e8e6f8131ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Aymeric Augustin]

That's a great idea!

Like all Internet polls the results may be biased by the population who 
answers. We may not get answers from the least active parts of the community. 
However it would give us /some/ data instead of opinions.

I'm happy to contribute to defining the questions.

-- 
Aymeric.

> Le 18 avr. 2015 à 01:00, Tim Graham  a écrit :
> 
> I had an idea to conduct a survey to get a sense of how developers are using 
> Django. I first had the idea when the question of maintenance of the Oracle 
> GIS backend came up. We really have no idea whether or not anyone is actually 
> using that backend, and it would be helpful to know so we are not wasting 
> resources on unused features. Also there's the question of how often to 
> release Django. I think it would be nice to make that decision based on some 
> data from the community.
> 
> Is anyone is interested in coordinating such a survey (collating questions, 
> preparing the online survey, etc.).
> 
> Some question ideas to get started:
> 
> Which database backend(s) do you use?
> [ ] Checkbox for each one
> 
> Which contrib apps do you use?
> [ ] Checkbox for each one
> 
> How often would you like to see new major version of Django released?
> [ ] List some options, probably between 6 and 9 months.
> 
> Describe which version of Django you use (check all the apply):
> [ ] I only use long-term support releases.
> [ ] I upgrade to the latest stable version as quickly as possible.
> [ ] I run off of master.
> [ ] I upgrade Django when the version I am using is nearing the end of its 
> support (or after).
> [ ] I don't bother upgrading Django, even if it becomes unsupported.
> -- 
> 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/b3853a7c-8134-4a56-8913-4126fca9b600%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/299B31C8-ED56-4FC0-BDDD-25577FEE2178%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Idea about authentication

[Florian Apolloner]

We already committed a fix for pbkdf2, the DOS vector no longer exists (at 
least not in this form): 
https://github.com/django/django/commit/68540fe4df44492571bc610a0a043d3d02b3d320
 


On Thursday, October 3, 2013 9:56:14 AM UTC+2, Ram Rachum wrote:
>
> Hi everybody,
>
> I've submitted the patch, and corrected it, and it's been sitting on the 
> issue tracker for 2 weeks without anyone commenting. Does anyone care to 
> discuss this? I want to have this merged in, or discuss any problems in 
> merging it in. 
>
>
> On Sun, Sep 15, 2013 at 11:27 PM, Ram Rachum 
> > wrote:
>
>> Submitted patch:
>>
>> https://code.djangoproject.com/ticket/21105#comment:1
>>
>> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>>
>>>
>>> On Sep 15, 2013, at 2:59 PM, Florian Apolloner  
>>> wrote:
>>>
>>> Hi Ram,
>>>
>>> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:

 Florian, I'm not sure that you read my message carefully enough. I'm *not 
 *proposing to reduce the time that PBKDF2  takes to hash.

>>>
>>> By replacing the password with a hash before running it through PBKDF2 
>>> you are reducing that time for every password longer than the hash… And 
>>> given the way PBKDF2 works you'll reduce it by quite a bit (note that all 
>>> of this only applies to passwords longer than the hash, so it's probably 
>>> pretty academical). Either way, we'd at least need a new hasher class since 
>>> it would be backwards incompatible. Independent of that we'd have to 
>>> evaluate if pre-hashing the password could make  PBKDF2 less secure 
>>> (probably not to likely, but who knows).
>>>
>>>
>>> According to Thomas Porin in the context of bcrypt pre-hashing the 
>>> password is fine (and we already do this in Django 1.6). I see no reason 
>>> the same wouldn't hold true for PBKDF2.
>>>
>>> -
>>> Donald Stufft
>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>>> DCFA 
>>>
>>>  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/iuSE5Y4R3hg/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48f1d111-e8e0-4c16-bec3-1af1cd1aa1f9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Ram Rachum]

Hi everybody,

I've submitted the patch, and corrected it, and it's been sitting on the
issue tracker for 2 weeks without anyone commenting. Does anyone care to
discuss this? I want to have this merged in, or discuss any problems in
merging it in.


On Sun, Sep 15, 2013 at 11:27 PM, Ram Rachum  wrote:

> Submitted patch:
>
> https://code.djangoproject.com/ticket/21105#comment:1
>
> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>
>>
>> On Sep 15, 2013, at 2:59 PM, Florian Apolloner 
>> wrote:
>>
>> Hi Ram,
>>
>> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>>
>>> Florian, I'm not sure that you read my message carefully enough. I'm *not
>>> *proposing to reduce the time that PBKDF2  takes to hash.
>>>
>>
>> By replacing the password with a hash before running it through PBKDF2
>> you are reducing that time for every password longer than the hash… And
>> given the way PBKDF2 works you'll reduce it by quite a bit (note that all
>> of this only applies to passwords longer than the hash, so it's probably
>> pretty academical). Either way, we'd at least need a new hasher class since
>> it would be backwards incompatible. Independent of that we'd have to
>> evaluate if pre-hashing the password could make  PBKDF2 less secure
>> (probably not to likely, but who knows).
>>
>>
>> According to Thomas Porin in the context of bcrypt pre-hashing the
>> password is fine (and we already do this in Django 1.6). I see no reason
>> the same wouldn't hold true for PBKDF2.
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/iuSE5Y4R3hg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Idea about authentication

[Florian Apolloner]

Hi,

there are a few things which worry me about this patch (aside from the note 
from charettes). You write "and the DoS attack vector is avoided" which is 
not true, hashing functions are by design CPU-intensive so you are not 
avoiding DoS, even if hashing now consistently takes less (for short 
passwords more) time you still can DoS a site. Avoiding the DoS vector in 
this case would mean something like rate limiting… And curious, why are you 
not able to run the tests, it's as simple as "cd tests; ./runtests". No 
offense, but copying those few lines and adding a broken test isn't really 
helping that much…

I am also not sure if we would want to use this as default hasher at all, 
the current default isn't that bad and puts a limit onto the hashing like 
yours does (granted, a bit later timewise, but as I said before changing 
the hash function is not a longterm solution).

Cheers,
Florian

On Sunday, September 15, 2013 10:27:16 PM UTC+2, Ram Rachum wrote:
>
> Submitted patch:
>
> https://code.djangoproject.com/ticket/21105#comment:1
>
> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>>
>>
>> On Sep 15, 2013, at 2:59 PM, Florian Apolloner  
>> wrote:
>>
>> Hi Ram,
>>
>> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>>
>>> Florian, I'm not sure that you read my message carefully enough. I'm *not 
>>> *proposing to reduce the time that PBKDF2  takes to hash.
>>>
>>
>> By replacing the password with a hash before running it through PBKDF2 
>> you are reducing that time for every password longer than the hash… And 
>> given the way PBKDF2 works you'll reduce it by quite a bit (note that all 
>> of this only applies to passwords longer than the hash, so it's probably 
>> pretty academical). Either way, we'd at least need a new hasher class since 
>> it would be backwards incompatible. Independent of that we'd have to 
>> evaluate if pre-hashing the password could make  PBKDF2 less secure 
>> (probably not to likely, but who knows).
>>
>>
>> According to Thomas Porin in the context of bcrypt pre-hashing the 
>> password is fine (and we already do this in Django 1.6). I see no reason 
>> the same wouldn't hold true for PBKDF2.
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>> DCFA 
>>
>>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Ram Rachum]

Submitted patch:

https://code.djangoproject.com/ticket/21105#comment:1

On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>
>
> On Sep 15, 2013, at 2:59 PM, Florian Apolloner 
> > 
> wrote:
>
> Hi Ram,
>
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>
>> Florian, I'm not sure that you read my message carefully enough. I'm *not 
>> *proposing to reduce the time that PBKDF2  takes to hash.
>>
>
> By replacing the password with a hash before running it through PBKDF2 you 
> are reducing that time for every password longer than the hash… And given 
> the way PBKDF2 works you'll reduce it by quite a bit (note that all of this 
> only applies to passwords longer than the hash, so it's probably pretty 
> academical). Either way, we'd at least need a new hasher class since it 
> would be backwards incompatible. Independent of that we'd have to evaluate 
> if pre-hashing the password could make  PBKDF2 less secure (probably not to 
> likely, but who knows).
>
>
> According to Thomas Porin in the context of bcrypt pre-hashing the 
> password is fine (and we already do this in Django 1.6). I see no reason 
> the same wouldn't hold true for PBKDF2.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Donald Stufft]

On Sep 15, 2013, at 2:59 PM, Florian Apolloner  wrote:

> Hi Ram,
> 
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
> Florian, I'm not sure that you read my message carefully enough. I'm not 
> proposing to reduce the time that PBKDF2  takes to hash.
> 
> By replacing the password with a hash before running it through PBKDF2 you 
> are reducing that time for every password longer than the hash… And given the 
> way PBKDF2 works you'll reduce it by quite a bit (note that all of this only 
> applies to passwords longer than the hash, so it's probably pretty 
> academical). Either way, we'd at least need a new hasher class since it would 
> be backwards incompatible. Independent of that we'd have to evaluate if 
> pre-hashing the password could make  PBKDF2 less secure (probably not to 
> likely, but who knows).

According to Thomas Porin in the context of bcrypt pre-hashing the password is 
fine (and we already do this in Django 1.6). I see no reason the same wouldn't 
hold true for PBKDF2.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Idea about authentication

[Florian Apolloner]

Hi Ram,

On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>
> Florian, I'm not sure that you read my message carefully enough. I'm *not 
> *proposing to reduce the time that PBKDF2  takes to hash.
>

By replacing the password with a hash before running it through PBKDF2 you 
are reducing that time for every password longer than the hash… And given 
the way PBKDF2 works you'll reduce it by quite a bit (note that all of this 
only applies to passwords longer than the hash, so it's probably pretty 
academical). Either way, we'd at least need a new hasher class since it 
would be backwards incompatible. Independent of that we'd have to evaluate 
if pre-hashing the password could make  PBKDF2 less secure (probably not to 
likely, but who knows).

Florian

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Donald Stufft]

We'd want to use SHA256 but that's an OK thing to do AFAIK. I wouldn't agree to 
it in a security patch because it breaks backwards compatibility in a much 
larger way than the patch we did does.

In fact we already do this with the bcrypt hasher in Django 1.6+ to solve a 
password truncation issue (Bcrypt truncates the input password before hashing 
it).

https://code.djangoproject.com/ticket/20138

http://security.stackexchange.com/questions/6623/pre-hash-password-before-applying-bcrypt-to-avoid-restricting-password-length


On Sep 15, 2013, at 5:45 AM, Ram Rachum  wrote:

> Thanks Curtis!
> 
> I thought about my idea and realized it makes a brute-force attack easier, 
> and we'd have to make the hashing stronger to compensate... Making the 
> computation time longer for the real users logging in... So yeah, it won't 
> help.
> 
> But then I had another idea. So PBKDF2 takes a longer time to calculate for 
> longer passwords. Maybe the solution is to fix that? That would be more 
> elegant than limiting passwords to 4096 (because then dos attackers can still 
> attack using 4096-long passwords, and while not as slow as megabytes-long 
> password, it's still slow.)
> 
> What if instead of calculating the PBKDF2 hash of the password, we'll 
> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
> passwords wouldn't depend on their length, and we wouldn't even have to place 
> a limit of 4096 characters on passwords-- An attacker could try a 1MB-long 
> password but it would slow us down the same amount as trying "123456" would. 
> 
> What do you think? 
> 
> On Sunday, September 15, 2013 12:25:32 PM UTC+3, Curtis Maloney wrote:
> Actually, you'd just speed up their attack, since most failed attempts would 
> be quicker than others.
> 
> If you look in the crypto utils, you'll see a "constant time compare" ... 
> this is a common thing in crypto circles to avoid leaking "how close" the 
> guess was by how quickly the mismatch was found.
> 
> This is a class of "side channel attach"... worth reading up on if you want 
> to get further into crypto: http://en.wikipedia.org/wiki/Side_channel_attack
> 
> --
> Curtis
> 
> 
> 
> On 15 September 2013 19:00, Ram Rachum  wrote:
> Hi guys,
> 
> I just saw the new release announcement and I had an idea.
> 
> What if, in addition to sorting the hard to compute hash for every password, 
> we will also store the sha 1 hash of the first 5 characters ofthe password's 
> sha1 hash? Wouldn't this allow us to quickly rule out 99% of passwords, 
> thereby defending against dos attacks, while atthe same time not letting an 
> attacker who obtained the hashes to get the passwords?
> 
> I'm not a security expert, just brainstorming.
> 
> Thanks,
> Ram.
> 
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Idea about authentication

[Ram Rachum]

Florian, I'm not sure that you read my message carefully enough. I'm *not 
*proposing 
to reduce the time that PBKDF2 takes to hash. I'm proposing to keep that 
time just as long, but make it independent on the password length.

On Sunday, September 15, 2013 1:12:31 PM UTC+3, Florian Apolloner wrote:
>
>
>
> On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote:
>
>> What if instead of calculating the PBKDF2 hash of the password, we'll 
>> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
>> passwords wouldn't depend on their length, and we wouldn't even have to 
>> place a limit of 4096 characters on passwords-- An attacker could try a 
>> 1MB-long password but it would slow us down the same amount as trying 
>> "123456" would. 
>>
>
> PBKDF2 takes long by design… A better long term solution would be to rate 
> limit password attempts…
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Florian Apolloner]

On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote:

> What if instead of calculating the PBKDF2 hash of the password, we'll 
> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
> passwords wouldn't depend on their length, and we wouldn't even have to 
> place a limit of 4096 characters on passwords-- An attacker could try a 
> 1MB-long password but it would slow us down the same amount as trying 
> "123456" would. 
>

PBKDF2 takes long by design… A better long term solution would be to rate 
limit password attempts…

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Ram Rachum]

Thanks Curtis!

I thought about my idea and realized it makes a brute-force attack easier, 
and we'd have to make the hashing stronger to compensate... Making the 
computation time longer for the real users logging in... So yeah, it won't 
help.

But then I had another idea. So PBKDF2 takes a longer time to calculate for 
longer passwords. Maybe the solution is to fix that? That would be more 
elegant than limiting passwords to 4096 (because then dos attackers can 
still attack using 4096-long passwords, and while not as slow as 
megabytes-long password, it's still slow.)

What if instead of calculating the PBKDF2 hash of the password, we'll 
calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
passwords wouldn't depend on their length, and we wouldn't even have to 
place a limit of 4096 characters on passwords-- An attacker could try a 
1MB-long password but it would slow us down the same amount as trying 
"123456" would. 

What do you think? 

On Sunday, September 15, 2013 12:25:32 PM UTC+3, Curtis Maloney wrote:
>
> Actually, you'd just speed up their attack, since most failed attempts 
> would be quicker than others.
>
> If you look in the crypto utils, you'll see a "constant time compare" ... 
> this is a common thing in crypto circles to avoid leaking "how close" the 
> guess was by how quickly the mismatch was found.
>
> This is a class of "side channel attach"... worth reading up on if you 
> want to get further into crypto: 
> http://en.wikipedia.org/wiki/Side_channel_attack
>
> --
> Curtis
>
>
>
> On 15 September 2013 19:00, Ram Rachum  >wrote:
>
>> Hi guys,
>>
>> I just saw the new release announcement and I had an idea.
>>
>> What if, in addition to sorting the hard to compute hash for every 
>> password, we will also store the sha 1 hash of the first 5 characters ofthe 
>> password's sha1 hash? Wouldn't this allow us to quickly rule out 99% of 
>> passwords, thereby defending against dos attacks, while atthe same time not 
>> letting an attacker who obtained the hashes to get the passwords?
>>
>> I'm not a security expert, just brainstorming.
>>
>> Thanks,
>> Ram.
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Re: Idea about authentication

[Curtis Maloney]

Actually, you'd just speed up their attack, since most failed attempts
would be quicker than others.

If you look in the crypto utils, you'll see a "constant time compare" ...
this is a common thing in crypto circles to avoid leaking "how close" the
guess was by how quickly the mismatch was found.

This is a class of "side channel attach"... worth reading up on if you want
to get further into crypto: http://en.wikipedia.org/wiki/Side_channel_attack

--
Curtis



On 15 September 2013 19:00, Ram Rachum  wrote:

> Hi guys,
>
> I just saw the new release announcement and I had an idea.
>
> What if, in addition to sorting the hard to compute hash for every
> password, we will also store the sha 1 hash of the first 5 characters ofthe
> password's sha1 hash? Wouldn't this allow us to quickly rule out 99% of
> passwords, thereby defending against dos attacks, while atthe same time not
> letting an attacker who obtained the hashes to get the passwords?
>
> I'm not a security expert, just brainstorming.
>
> Thanks,
> Ram.
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Idea for i18n fields

[akaariai]

On Jul 2, 12:59 am, Ric  wrote:
> Hi there,
>
> i have got a simple approach to make all django fields with a full
> i18n support
>
> the django.models.fields.Field class can be subclassed like this
>
> from django.db import models
> from django.utils.translation import get_language
>
> class i18nField(models.Field):
>
>     def __init__(self, i18n = False, *args, **kwargs)
>         self.i18n = i18n
>         models.Field.__init__(self, *args, **kwargs)
>
>     def db_column_get(self):
>         if not self.i18n:
>             return self._db_column or self.name
>         return "%s_%s" % (
>             self._db_column or self.name,
>             get_language().lower()
>             )
>
>     def db_column_set(self, value):
>         self._db_column = value
>
>     def _column_set(self, value):
>         pass
>
>     db_column = property(db_column_get, db_column_set)
>     column = property(db_column_get, _column_set)
>
> then you can declare all other subfields as usual
>
> this work in that way: you need a separate db column for every
> language installed.
> a field called "name" needs to create ("name_%s" % code for code in
> languages) columns
>
> so the framework automatically select the right column in every query.
>
> problems:
>  - serializing objects, you need to serialize all all fields, not just
> current language
>  - many to many fields, to work they need to create an extra column in
> every througth table, a column to store the language code.
>  - during sync db you need to create a column for every language
> installed
>
> after two years on an i18n django site, i found this simple solution.
> there are some small problems, that can be fixed if we put a i18n
> option when you init a field, and solve some issue during syncdb
> command and serialization of objects.
>
>  for me is a very simple approch,
> it automatically filter, sort and output the right queryset for your
> language, and when you access a field you get the current language, it
> works for every field, ForeignKeys too.
>
>  and it works in admin (with no changes at all)
>
> let me know what you think.

>From my point of view there are a couple of problems with this
approach:
  - The idea of putting a column for all translated languages for
every field directly to the base table is not feasible for many use
cases. If you have 10 translated fields in your model, and you have 10
languages, that is already 100 fields. If you happen to need an index
on one field, you need 10 indexes. For example in EU you might need to
have the possibility to have the model translated in all official EU
languages. That is over 20 languages you need to support right there.
For the EU use case it is better to have a translations table
containing the translations of one language in one row.
  - This approach makes it hard to fetch all the translations of the
model. How does this work for NOT NULL fields?
  - There are ways to have proper fields for every translation in the
DB table. It is better that there is 'name' field which fetches the
default language according to the currently active language, and then
there are the translated fields ('name_fi', 'name_en', ...) if you
need those. See django-transmeta for one such solution (http://
code.google.com/p/django-transmeta/).

For some use cases your solution definitely can be handy. But my
feeling is that this does not belong to core (not that I have any
power in deciding that). The biggest reason for this is that the more
I have worked in different multilingual projects, the more certain I
am that there is no single solution to model translations. At least no
single solution how to handle the database layout part of it.

 - Anssi

-- 
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: idea for using RequestContext by default

[Jacob Kaplan-Moss]

On Tue, Jan 5, 2010 at 9:38 AM, Russell Keith-Magee
 wrote:
> To clarify your position Jacob - are you advocating that
> shortcuts.render() should return a TemplateReponse? Or are you
> suggesting that we add a TemplateResponse *and* a shortcut.render()
> that is an analog of render_to_response, but with a RequestContext?

I don't particularly care how ``render`` works internally -- I'm not
totally sold on ``TemplateResponse``, but I'm also not against it
really. I'm just really sick of
``context_instance=RequestContext(request)``.

Jacob

--

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

Re: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 11:00 PM, Jacob Kaplan-Moss  wrote:
> On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
>  wrote:
>> I haven't taken the temperature of anyone else in the core, but you
>> can take it as read that Simon and myself are both +1. The sprint this
>> weekend would be a great opportunity to advocate for inclusion of
>> this. With a few tests and documentation, Simon's patch could easily
>> be made trunk-ready.
>
> I'm also +1 on something like ``TemplateResponse``, and especially
> ``django.shortcuts.render(request, template, context)``.

To clarify your position Jacob - are you advocating that
shortcuts.render() should return a TemplateReponse? Or are you
suggesting that we add a TemplateResponse *and* a shortcut.render()
that is an analog of render_to_response, but with a RequestContext?

Russ %-)

--

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

Re: idea for using RequestContext by default

[Ben Firshman]

On 5 Jan 2010, at 15:00, Jacob Kaplan-Moss wrote:

> On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
>  wrote:
>> I haven't taken the temperature of anyone else in the core, but you
>> can take it as read that Simon and myself are both +1. The sprint  
>> this
>> weekend would be a great opportunity to advocate for inclusion of
>> this. With a few tests and documentation, Simon's patch could easily
>> be made trunk-ready.
>
> I'm also +1 on something like ``TemplateResponse``, and especially
> ``django.shortcuts.render(request, template, context)``.

I ran across a really frustrating problem with TemplateResponse.

TemplateResponses typically get baked by a response middleware because  
that's the first place the content is accessed. However, if there are  
any template errors, you don't see a sensible traceback because pretty  
debug pages aren't shown for exceptions raised in middleware.

Is there any reason why exceptions in middleware aren't handled?

Ben

--

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

Re: idea for using RequestContext by default

[Jacob Kaplan-Moss]

On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
 wrote:
> I haven't taken the temperature of anyone else in the core, but you
> can take it as read that Simon and myself are both +1. The sprint this
> weekend would be a great opportunity to advocate for inclusion of
> this. With a few tests and documentation, Simon's patch could easily
> be made trunk-ready.

I'm also +1 on something like ``TemplateResponse``, and especially
``django.shortcuts.render(request, template, context)``.

Jacob

--

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

Re: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Certainly - and Simon made exactly this proposal during the review of
> the CSRF work. Simon even provided a sample implementation:
> 
> http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1

Thanks! I keep missing nice things on django-dev@ due to many *-dev 
lists traffic :-(

--

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

Re: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 9:23 PM, Ivan Sagalaev
 wrote:
> Russell Keith-Magee wrote:
>> I'm in complete agreement with Simon on this point. I fail to see the
>> benefit of decorators in this context.
>
> I can see one valid point that "render_to" guys have. Which is,
> incidentally, has nothing to do with the decorator syntax. An
> HttpResponse with an opaque string as its content is hard to alter after
> it is returned from a view (one of the precedents was the old
> CsrfMiddleware was parsing HTML to inject a token). And most of the real
> use-cases for this are about adding something to the view's context
> before it blends in a template. Right now the only way to do it is with
> context processors but they are global, not per-view, which is not
> convenient.
>
> I think it can be solved another way, by something like a special
> HttpResponse subclass -- TemplateResponse. It can keep a template and
> its context separate until the very last moment when its contents is
> asked and only then do render a template.
>
> This will allow extension of the views:
>
>     # some library:
>
>     def library_view(request):
>         # ...
>         return TemplateReponse('template.html', context = { ... })
>
>     # user code:
>
>     def my_view(request):
>         response = library_view(request)
>         response.context.update({ ... })
>         return response
>
> Russel, can you see something like this in Django trunk?

Certainly - and Simon made exactly this proposal during the review of
the CSRF work. Simon even provided a sample implementation:

http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1

(Ignore the bits about the CSRF implementation - the interesting bits
are near the end of the message)

I haven't taken the temperature of anyone else in the core, but you
can take it as read that Simon and myself are both +1. The sprint this
weekend would be a great opportunity to advocate for inclusion of
this. With a few tests and documentation, Simon's patch could easily
be made trunk-ready.

Yours,
Russ Magee %-)

--

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

Re: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> I'm in complete agreement with Simon on this point. I fail to see the
> benefit of decorators in this context.

I can see one valid point that "render_to" guys have. Which is, 
incidentally, has nothing to do with the decorator syntax. An 
HttpResponse with an opaque string as its content is hard to alter after 
it is returned from a view (one of the precedents was the old 
CsrfMiddleware was parsing HTML to inject a token). And most of the real 
use-cases for this are about adding something to the view's context 
before it blends in a template. Right now the only way to do it is with 
context processors but they are global, not per-view, which is not 
convenient.

I think it can be solved another way, by something like a special 
HttpResponse subclass -- TemplateResponse. It can keep a template and 
its context separate until the very last moment when its contents is 
asked and only then do render a template.

This will allow extension of the views:

 # some library:

 def library_view(request):
 # ...
 return TemplateReponse('template.html', context = { ... })

 # user code:

 def my_view(request):
 response = library_view(request)
 response.context.update({ ... })
 return response

Russel, can you see something like this in Django trunk?

--

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

Re: idea for using RequestContext by default

[Yuri Baburov]

Hi Davor,

On Tue, Jan 5, 2010 at 5:06 PM, rebus_  wrote:
> Hi,
>
> This is the "natural" sequence of doing things anyway, i don't see why
> would you shuffle it around.
>
> 1. process stuff into variables
> 2. add said variables to a ContextRequest
> 3. send said ContextRequest to a template for rendering.
Nothing is shuffled around.
But we came to a bikeshed discussion.
> In the example buttman gave in his link [1] you could say you don't
> even need to specify a template. You could just have a decorator that
> says "this function is a view and when it returns take the name of the
> function and generate template name or even if it is ajax request
> append _ajax to template name". This is however even more implicit,
> though it could save you some typing.
>
> [1] http://github.com/nbv4/flightloggin/blob/master/logbook/views.py
>
>
>> This decorator intercepts `request` argument.
>> When you have 2 or more ways to return anything from function, it
>> looks much better.
>> Moreover, visually it looks much better too: this important
>> information of what page is rendered to each template is always right
>> here.
>
> Personally I don't find this readable at all:
>
> @render_to('my/template.html')
> def my_view(request, param):
>   if param == 'something':
>       return {'data': 'some_data'}
>   elif something_else():
>       return HttpResponse('not found anything at all')
>   else:
>       return {'data': 'some_other_data'}, 'another/template.html'
>
> You explicitly set a template at the beginning of the view but few
> lines after it you mention yet another template.
> When someone is reading your code this could lead to confusion. What
> happens when you need to debug lets say few hundred line view? You
> could even forget that you used another template in it and pull your
> hair out why my/template.html doesn't produce wanted result.
Please, no imaginary arguments.

> Also, it doesn't either look or work much more different then:
>
> def my_view(request, param)
>  template = 'my/template.html'
>  if param == 'something':
>    context = {'some':context}
>  elif something_else():
>    context = {'some_other':context}
>    template = 'another/template.html'
>  return render_to_response(template, context,
> context_instance=RequestContext(request))
Compare to:
@render_to()
def my_view(request, param)
  template = 'my/template.html'
  if param == 'something':
context = {'some':context}
  elif something_else():
context = {'some_other':context}
template = 'another/template.html'
  return context, template

render_to is made to translate
 "return render_to_response(template, context,
context_instance=RequestContext(request))"
into "return context, template".

If you like the longer version, or don't see the difference, what else to talk?

In bikeshed question of what to use, render_to or render_to_response(),
the winner is clearly the smarter render shortcut, proposed in different thread.
"render(template, context, request)".

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

--

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

Re: idea for using RequestContext by default

[rebus_]

Hi,

This is the "natural" sequence of doing things anyway, i don't see why
would you shuffle it around.

1. process stuff into variables
2. add said variables to a ContextRequest
3. send said ContextRequest to a template for rendering.

In the example buttman gave in his link [1] you could say you don't
even need to specify a template. You could just have a decorator that
says "this function is a view and when it returns take the name of the
function and generate template name or even if it is ajax request
append _ajax to template name". This is however even more implicit,
though it could save you some typing.

[1] http://github.com/nbv4/flightloggin/blob/master/logbook/views.py


> This decorator intercepts `request` argument.
> When you have 2 or more ways to return anything from function, it
> looks much better.
> Moreover, visually it looks much better too: this important
> information of what page is rendered to each template is always right
> here.

Personally I don't find this readable at all:

@render_to('my/template.html')
def my_view(request, param):
   if param == 'something':
   return {'data': 'some_data'}
   elif something_else():
   return HttpResponse('not found anything at all')
   else:
   return {'data': 'some_other_data'}, 'another/template.html'

You explicitly set a template at the beginning of the view but few
lines after it you mention yet another template.
When someone is reading your code this could lead to confusion. What
happens when you need to debug lets say few hundred line view? You
could even forget that you used another template in it and pull your
hair out why my/template.html doesn't produce wanted result.

Also, it doesn't either look or work much more different then:

def my_view(request, param)
  template = 'my/template.html'
  if param == 'something':
context = {'some':context}
  elif something_else():
context = {'some_other':context}
template = 'another/template.html'
  return render_to_response(template, context,
context_instance=RequestContext(request))

Just my 2 cents,

--
Davor Lučić

--

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

Re: idea for using RequestContext by default

[buttman]

> > I much prefer the @render_to() syntax. This way, I can think of my
> > view functions as "context variable creators", instead of "response
> > returners". I think of view functions as a sort of context processor
> > thats only meant for one specific template.
>
> I'm in complete agreement with Simon on this point. I fail to see the
> benefit of decorators in this context. However, it's easy to find
> several negative points:
>
>  * The "accept a request, return a response"  view contract makes
> sense, and is consistent with other layers in the Django stack.
>  * Special handling is required in the decorator when a view needs to
> return HttpResponseRedirect (or any other non-template-rendered
> response). This says nothing for the case where you need to return a
> non-200 response *and* templated content.

I actually just checked one of my views, and the version of @render_to
that comes with django-annoying does indeed let you return
ResponseRedirect objects. For an example, look at this code:

http://github.com/nbv4/flightloggin/blob/master/logbook/views.py

which is currently in production and it works fine. If request.POST
exists, it will save a form and then issue a ResponseRedirect,
otherwise, it'll create some variables and then return locals(), which
the decorator will then handle.

>  * The return value for views becomes a tuple with a convention,
> rather than an explicit single (response) object.

I don't understand this part. tuples? With the decorator views return
dictionaries.

> So - I'm fairly confident in saying that this isn't going to happen in
> Django trunk.

Fine with me. Either I import it from annoying.decorators or
django.shortcuts, it don't make no difference to me...

--

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

Re: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 1:57 AM, buttman  wrote:
> On Jan 2, 5:52 pm, Simon Willison  wrote:
>> On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
>>
>> > In the discussions on CSRF there have been several proposals to
>> > include RequestContext by default in render_to_response or in a
>> > similar function. As a side note to my previous post, I'd like to
>> > mention my favorite way to do this: render_to , see:
>>
>> >http://www.djangosnippets.org/snippets/821/
>>
>> So here's how that's supposed to work:
>>
>> @render_to('my/template.html')
>> def my_view(request, param):
>>     return {'data': 'some_data'}
>>
>> I have to admit I don't understand the appeal of this syntax at all.
>> How is it any better than this? :
>>
>> def my_view(request, param):
>>     return render('my/template.html', {'data': 'some_data'})
>>
>> The decorator implementation is more complicated, makes debugging
>> trickier (since decorators confuse stack traces and other debugging
>> tools) and doesn't save any typing. What are the advantages?
>>
>> I'm a big fan of decorators for things like caching/memoization, but I
>> don't understand why they provide any advantage for the above. I'm not
>> a fan of the current @permalink decorator in Django for the same
>> reason - if a decorator simply changes the syntax for how arguments
>> are passed to a function, what's the point of using them?
>>
>> Cheers,
>>
>> Simon
>
> I much prefer the @render_to() syntax. This way, I can think of my
> view functions as "context variable creators", instead of "response
> returners". I think of view functions as a sort of context processor
> thats only meant for one specific template.

I'm in complete agreement with Simon on this point. I fail to see the
benefit of decorators in this context. However, it's easy to find
several negative points:

 * The "accept a request, return a response"  view contract makes
sense, and is consistent with other layers in the Django stack.
 * Special handling is required in the decorator when a view needs to
return HttpResponseRedirect (or any other non-template-rendered
response). This says nothing for the case where you need to return a
non-200 response *and* templated content.
 * The return value for views becomes a tuple with a convention,
rather than an explicit single (response) object.

So - I'm fairly confident in saying that this isn't going to happen in
Django trunk.

However, this position doesn't prevent you from using this approach in
your own code, so if you're a fan of using decorators in this way,
feel free to do so.

Yours,
Russ Magee %-)

--

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

Re: idea for using RequestContext by default

[buttman]

On Jan 2, 5:52 pm, Simon Willison  wrote:
> On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
>
> > In the discussions on CSRF there have been several proposals to
> > include RequestContext by default in render_to_response or in a
> > similar function. As a side note to my previous post, I'd like to
> > mention my favorite way to do this: render_to , see:
>
> >http://www.djangosnippets.org/snippets/821/
>
> So here's how that's supposed to work:
>
> @render_to('my/template.html')
> def my_view(request, param):
>     return {'data': 'some_data'}
>
> I have to admit I don't understand the appeal of this syntax at all.
> How is it any better than this? :
>
> def my_view(request, param):
>     return render('my/template.html', {'data': 'some_data'})
>
> The decorator implementation is more complicated, makes debugging
> trickier (since decorators confuse stack traces and other debugging
> tools) and doesn't save any typing. What are the advantages?
>
> I'm a big fan of decorators for things like caching/memoization, but I
> don't understand why they provide any advantage for the above. I'm not
> a fan of the current @permalink decorator in Django for the same
> reason - if a decorator simply changes the syntax for how arguments
> are passed to a function, what's the point of using them?
>
> Cheers,
>
> Simon

I much prefer the @render_to() syntax. This way, I can think of my
view functions as "context variable creators", instead of "response
returners". I think of view functions as a sort of context processor
thats only meant for one specific template.

Almost every single view I have ever written (more or less) follows
this pattern:

process stuff into variables -> add said variables to a ContextRequest
-> send said ContextRequest to a template for rendering.

With @render_to, it allows me to delegate all the rendering crap to
the decorator, while the view function gets to focus on what is really
there for; creating extra variables to be passed on to the template.
It makes things simpler for me and adds readability.

Also, I've never had a problem with the decorator messing up
tracebacks.

--

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

Re: idea for using RequestContext by default

[Yuri Baburov]

Hi Simon,

Readability is all about lots of tiny details.

I suppose you meant this:
def my_view(request, param):
return render('my/template.html', {'data': 'some_data'}, request)

This decorator intercepts `request` argument.
When you have 2 or more ways to return anything from function, it
looks much better.
Moreover, visually it looks much better too: this important
information of what page is rendered to each template is always right
here.

@render_to('my/template.html')
def my_view(request, param):
if param == 'something':
return {'data': 'some_data'}
elif something_else():
return HttpResponse('not found anything at all')
else:
return {'data': 'some_other_data'}, 'another/template.html'

What both render_to decorator and render() still miss, is extendability.
I think, Django still misses a lot when it comes to views/templates
extensibility.
Look at 3rd-party apps or django contribs. You can freely use their
models, but 90% of cases you can't reuse their views.

def your_view(request, param):
if param == 'something2':
return login(request, template='login.html') +
{'additional_key':'additional_value'} # how do I do this?!
else:
return my_view(request, param, template='your/template.html')
+ {'additional_key':'additional_value'} # or how do I do this?

How to make these lines of code effective and readable at all?
Some views don't provide template= option, some call it differently...

You are now only able to add middleware to extend already generated
HttpResponses.
I think, RequestContext was made to make such extendability more
simple, but it was (almost?) never used in that way.

We had discussion both about this issue and
render_to/render/render_to_response already in django-developers.
http://groups.google.com/group/django-developers/browse_frm/thread/f53fea4a0551ab7c/64956c854776f4e8
Still not found excellent solution.

On Sun, Jan 3, 2010 at 4:52 AM, Simon Willison  wrote:
> On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
>> In the discussions on CSRF there have been several proposals to
>> include RequestContext by default in render_to_response or in a
>> similar function. As a side note to my previous post, I'd like to
>> mention my favorite way to do this: render_to , see:
>>
>> http://www.djangosnippets.org/snippets/821/
>
> So here's how that's supposed to work:
>
> @render_to('my/template.html')
> def my_view(request, param):
>    return {'data': 'some_data'}
>
> I have to admit I don't understand the appeal of this syntax at all.
> How is it any better than this? :
>
> def my_view(request, param):
>    return render('my/template.html', {'data': 'some_data'})
>
> The decorator implementation is more complicated, makes debugging
> trickier (since decorators confuse stack traces and other debugging
> tools) and doesn't save any typing. What are the advantages?
>
> I'm a big fan of decorators for things like caching/memoization, but I
> don't understand why they provide any advantage for the above. I'm not
> a fan of the current @permalink decorator in Django for the same
> reason - if a decorator simply changes the syntax for how arguments
> are passed to a function, what's the point of using them?
>
> Cheers,
>
> Simon

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

--

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

Re: idea for using RequestContext by default

[Simon Willison]

On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
> In the discussions on CSRF there have been several proposals to
> include RequestContext by default in render_to_response or in a
> similar function. As a side note to my previous post, I'd like to
> mention my favorite way to do this: render_to , see:
>
> http://www.djangosnippets.org/snippets/821/

So here's how that's supposed to work:

@render_to('my/template.html')
def my_view(request, param):
return {'data': 'some_data'}

I have to admit I don't understand the appeal of this syntax at all.
How is it any better than this? :

def my_view(request, param):
return render('my/template.html', {'data': 'some_data'})

The decorator implementation is more complicated, makes debugging
trickier (since decorators confuse stack traces and other debugging
tools) and doesn't save any typing. What are the advantages?

I'm a big fan of decorators for things like caching/memoization, but I
don't understand why they provide any advantage for the above. I'm not
a fan of the current @permalink decorator in Django for the same
reason - if a decorator simply changes the syntax for how arguments
are passed to a function, what's the point of using them?

Cheers,

Simon

--

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

Re: idea for using RequestContext by default

[Will LaShell]

On Wed, 2009-12-30 at 14:28 -0800, Wim Feijen wrote:
> Hello,
> 
> In the discussions on CSRF there have been several proposals to
> include RequestContext by default in render_to_response or in a
> similar function. As a side note to my previous post, I'd like to
> mention my favorite way to do this: render_to , see:

The  generic view function  direct_to_template already handles this
need.  If anything we could add a line in the documentation or tutorials
pointing this usage out.

> http://www.djangosnippets.org/snippets/821/
> 
> Best regards,
> 
> Wim Feijen

--

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

Re: Idea with respect to full-text indexing

[Brian Beck]

Hi Jeroen,

Sorry about the closed blog comments, that entry was getting dozens of
spam comments per day even though we use MT-Blacklist.

Anyway, your idea seems sound; I'd have to make or see an example
implementation and try it out to know if it's the best way to go.
Given the current state of search-api, experimentation is definitely
the best way towards progress.

--
Brian Beck
Adventurer of the First Order


--~--~-~--~~~---~--~~
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Idea for ManyTomManyField extention

[Russell Keith-Magee]

On 7/30/06, Neilen Marais <[EMAIL PROTECTED]
> wrote:
This should be completely compatible with ordinary use of m2mrelations. It would be problematic if either Tag or Image had anyfields in common with ImageTagInfo, but that would presumably bechecked at model creation type.
One could object that this is a bit "magic" or implicit or evenambiguous. On some days I might even be inclined to agree ;)  All inall it seems quite workable to me though.
I can't speak for others, but for me, this ambiguity is a big problem. While the ambiguity could be avoided with some extra validation to ensure that field names don't overlap, the 'related_name' field (and the consequent potential for model collisions) causes enough difficulty with newcomers without adding additional ambiguity in m2m field definitions.
 Another option I can think of is to add extra fields to the relatedmodels, eg.
Image.objects.filter(tags__name='the truth', imagetaginfo__extra_tag_info='suspect')I'm not sure this is much better - same ambiguity, just a different model being affected.
For me, a good syntax would stand out as obvious - 'oh - that's a field tied to the relation', rather than 'is that a model field or a relation field... I don't know... check models.py...". I don't know what the right syntax is - but what you have proposed isn't it. Any other suggestions?
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 [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/django-developers  -~--~~~~--~~--~--~---

Re: Idea for ManyTomManyField extention

[Neilen Marais]

Hi Ian

On Sat, 29 Jul 2006 11:36:17 +1000, Ian Holsman wrote:

> but personally I just use foreign keys on the middle table, as I  
> think it makes the code more readable, and allows you to be more
> flexible with it. (for example a M2M with a generic flavor)

Like the intermediary model described here: 
http://www.djangoproject.com/documentation/models/m2m_intermediary/
?

Actually I kinda like the idea of having an explicit definition of the m2m
link table, but what I also want is the ability to use the standard m2m
manager on instances of the related objects.  I.e. image.tags.all() gives
me all the tags related to this image in a query set, rather than having
to go [i.tag for i in image.intermediary_set.all()] or similar.

> What I would like to see (and might already be there.. I haven't  
> looked to closely lately) is a common naming standard for the  
> relationships
> (foreign, one-to-one,  or many) so that I can just switch a M2M to a  
> Foreign key in the model with no effect on the code which uses it.
> 
> (django might do this.. it's been a while since I used M2M)

I think it already does this for the reverse m2m relation (I think), e.g.
using the models I defined before Tag objects have an 'image_set' manager.
I'm not quite sure this is what you're talking about though.

> regards
> Ian

Cheers
Neilen

-- 
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Idea for ManyTomManyField extention

[Neilen Marais]

Hi Russ

On Sat, 29 Jul 2006 20:46:49 +0800, Russell Keith-Magee wrote:

> On 7/29/06, Neilen Marais <[EMAIL PROTECTED]> wrote:
>>
>>
>> I'm just testing the waters to see what people think about an extended
>> ManyToManyField type that allows the addition of extra info to a link
>> withouth having to use an intermediary table/model like here:
>> http://www.djangoproject.com/documentation/models/m2m_intermediary/ .
>>
> 
> Hi Neilen,
> 
> I agree that your suggestion covers a significant modelling use case. I'm
> not sure I agree with your suggested syntax, but completely separate from
> that issue, I can see one major problem.

I'm not strongly attached to the specific syntax suggested, so let's
move on :)

> How do you compose a query over the intermediary model? What is the filter()
> syntax that accesses the intermediary table from the models that are being
> related? The existing search syntax is well suited to traversing 1-N and N-N
> relations, but in N-N relations, the intermediary table is essentially
> transparent. I can't see any obvious syntax extension that would allow
> access to the intermediary table.

My simple-minded idea is to simply have the extra link info appear as
part of the tag. e.g.

Image.objects.filter(tags__name='the truth, honest', 
 tags__extra_tag_info='suspect') 

using the model definitions from my original post, assuming
extra_tag_info is a CharField in ImageTagInfo. Similarly, it would
appear as part of the image_set on Tag:

Tag.objects.filter(name='the truth, honest',
   image_set__extra_tag_info='suspect')

The idea here is that the 'extra_tag_info' applies to the specific
tag/image relation, and not the tag/image itself of course. Perhaps a
better field name would have been 'relation_info' rather than
'extra_tag_info'.

This should be completely compatible with ordinary use of m2m
relations. It would be problematic if either Tag or Image had any
fields in common with ImageTagInfo, but that would presumably be
checked at model creation type.

One could object that this is a bit "magic" or implicit or even
ambiguous. On some days I might even be inclined to agree ;)  All in
all it seems quite workable to me though.

Another option I can think of is to add extra fields to the related
models, eg.

Image.objects.filter(tags__name='the truth', 
 imagetaginfo__extra_tag_info='suspect')

How to ask for this behaviour at model definition time may require
some careful thought though.

> Suggestions for improving this situation are welcome, but
> wholesale changes to the Django query syntax are not an option - existing
> models and queries must continue to work as-is.

Pretty much agree violently :)

Regards
Neilen

> 
> Yours,
> Russ Magee %-)
>
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Idea for ManyTomManyField extention

[Russell Keith-Magee]

On 7/29/06, Neilen Marais <[EMAIL PROTECTED]
> wrote:
I'm just testing the waters to see what people think about an extendedManyToManyField type that allows the addition of extra info to a linkwithouth having to use an intermediary table/model like here:
http://www.djangoproject.com/documentation/models/m2m_intermediary/
 .Hi Neilen,I agree that your suggestion covers a significant modelling use case. I'm not sure I agree with your suggested syntax, but completely separate from that issue, I can see one major problem. 
How do you compose a query over the intermediary model? What is the filter() syntax that accesses the intermediary table from the models that are being related? The existing search syntax is well suited to traversing 1-N and N-N relations, but in N-N relations, the intermediary table is essentially transparent. I can't see any obvious syntax extension that would allow access to the intermediary table.
That said, the existing m2m-intermediary solution doesn't inherit the 'nice' N-N query syntax. However, there is a syntax that works, and it is unambiguous. Suggestions for improving this situation are welcome, but wholesale changes to the Django query syntax are not an option - existing models and queries must continue to work as-is.
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 [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/django-developers  -~--~~~~--~~--~--~---

Re: Idea for ManyTomManyField extention

[Ian Holsman]

Hi Neilen.I think this would be a good idea, as I frequently have a M2M type relationship with one or two fields on that field.but personally I just use foreign keys on the middle table, as I think it makes the code more readable, and allows you to be moreflexible with it. (for example a M2M with a generic flavor)What I would like to see (and might already be there.. I haven't looked to closely lately) is a common naming standard for the relationships(foreign, one-to-one,  or many) so that I can just switch a M2M to a Foreign key in the model with no effect on the code which uses it.(django might do this.. it's been a while since I used M2M)regardsIanOn 29/07/2006, at 8:50 AM, Neilen Marais wrote:HiI'm just testing the waters to see what people think about an extendedManyToManyField type that allows the addition of extra info to a linkwithouth having to use an intermediary table/model like here:http://www.djangoproject.com/documentation/models/m2m_intermediary/ .Using the intermediary table is not horrible, but my objections are: - It adds an unnecesary level of indirection when all that is desiredis to add some info to a relation. - If extra info is to be added to an existing app it may requirequite a few of code changes and also extra work to do datamigration.Let me describe how I'd like it to work. The model definition shouldlook something like this:from django.db import modelsclass Tag(models.Model):    name = models.CharField(maxlength=255)class ImageTagInfo(models.Model):    # Something so that a seperate table is not created. Perhaps using    # a different base class from models.Model could be done instead?    extra_tag_info = models.SomeFieldType()class Image(models.Model):    # various image info fields...    tags = model.ManyToManyField(Tag, link_info=ImageTagInfo)In use it should work exactly like a normal m2m relation, except thatthe additional fields described in ImageTagInfo should be added to theresulting Tag objects when accessed through the Image.tags m2mmanager, while the same fields should be added to Image objectsaccessed through the Tag.image_set m2m manager. Perhaps some checks or name mangling of the ImageTagInfo fieldnamescould be done to prevent field name conflicts between the models. Itmay also be a good idea to have the Tag objects accessed through theImage m2m manager be subclasses of both Tag and ImageTagInfo, andsimilarly the images should be subclasses of both ImageTagInfo andImage when accessed through the Tag.image_set m2m manager.This idea could be implemented on the DB side by adding theImageTagInfo fields to the m2m link table.Does this sound like a good idea? Bad idea? If someone is willing todo the work, would the patches be accepted?RegardsNeilen-- you know its kind of tragic we live in the new worldbut we've lost the magic-- Battery 9 (www.battery9.co.za)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/django-developers  -~--~~~~--~~--~--~---

Re: idea for magic removal - delegate all DB-IO to the manager?

[hugo]

>The problem is, I'm not sure what it would mean in the case where the
>object is "enlisted" in a unit of work. Basically, it would be a method
>with very odd semantics in the vast majority of cases ( ie running in a
>webserver in Django).

Agreed, that might be complicated to explain. So better just stick to
using the UnitOfWork as the sole db-IO-arbitrator.

bye, Georg

Re: idea for magic removal - delegate all DB-IO to the manager?

[Robert Wittams]

hugo wrote:
>>This way, individual items would no longer need to have a .save method.
>>They would always be saved by the unit of work.
> 
> 
> I think I still would keep the object .save() method - just to make the
> simple case still as simple as the current code is - the programmer
> shouldn't need to worry about units of work if he doesn't need
> transactions.

The problem is, I'm not sure what it would mean in the case where the
object is "enlisted" in a unit of work. Basically, it would be a method
with very odd semantics in the vast majority of cases ( ie running in a
webserver in Django).

The only vaguely sensible thing for it to mean is "commit the whole unit
of work", and that is really "not obvious" from the name and location of
the method.

Making it commit "just that object", or "that object and any which are
related to it and in need of saving", will lead to even more wierd
behaviour - ie bits of transactions being committed with and without stuff.

I think there could be a very simple method, maybe django.db.save() or
something, which would save the default unit of work. We could have a
system so a default unit of work is created implicitly, so the
middleware would only have to commit it in the end ( ie call that
method). And the only people who need to know about this method are
people using the db api outside of the web system.

Re: idea for magic removal - delegate all DB-IO to the manager?

[hugo]

>So in the usual case, this would get done implicitly by some middleware,
>ie there would be a request scoped unit of work that would be used by
>managers unless told otherwise, and it would call save() if the request
>works, or it would discard it on an exception.

Yes, that sounds good to me.

>This way, individual items would no longer need to have a .save method.
>They would always be saved by the unit of work.

I think I still would keep the object .save() method - just to make the
simple case still as simple as the current code is - the programmer
shouldn't need to worry about units of work if he doesn't need
transactions.

Could this possibly done with the event system, where objects post
events that are catched by default UnitOfWork objects, while managers
are allowed to hook into those events and mask them from the default
UnitOfWork and pass them on to their explicitly given UnitOfWork? This
could scale nicely:

- the simplest case will just use objects as before, posting to one
request-bound UnitOfWork. This gives you the same as we currently have.
- you can have managers that have different connections, but just use
the default UnitOfWork for those connections (managed by some
middleware). This would give you the possibility for easy multiple
connections.
- or you can have explicit UnitOfWork objects to manually manage all
your transaction needs. This gives you full control.

Events have the benefit of being dynamically scoped, so it could be
easier to hook into the event chain - objects would just post events on
.save(), as would managers, UnitOfWork would be the consumers. But I
don't know wether Loui (or PyDispatch) allows to mask events from other
receivers, so maybe it's not the right way to do (I did something
similar once with exceptions in Python, as exceptions are the most
useful dynamically scoped core language element available).

The idea would be to have a chain of responsibility for handling DB IO
and to delegate that from object to manager to unit-of-work, with
everyone in the chaing having the opportunity to divert flow of data
and with sensible default handlers that behave much like Django behaves
now.

bye, Georg

Re: idea for magic removal - delegate all DB-IO to the manager?

[Robert Wittams]

hugo wrote:
> Hi,
> 
> how about delegating _all_ DB-IO to the manager with magic removal?
> Currently all class-based selects are handled by the manager, while
> object-based selects and updates/inserts are handled by the objects
> themselves.
> 
> How about internally delegating updates and object-based selects to the
> manager? This would allow classes to define multiple managers that use
> _different_ database connections and so solve one of our bigger
> problems in Django:
> 
> class Polls(models.Base):
> 
>title = models.CharField()
> 
>write_objects = models.Manager()
>read_objects = models.LoadBalancingManager([list_of_connections])
> 
> This (can't say wether it uses the actual names of classes, but you
> should get the idea) would define a model that has a manager used for
> writing (of course the programmer has to make sure) that will use the
> default database connection. The LoadBalancingManager would be one that
> only handles selects and gets a list of connections to use for that.

I think some assurance would need to be made that the default (ie first)
manager was able to do all management tasks. Otherwise generic stuff (eg
admin) will have a hard time.

Pretty easy to do:

class Polls(Model):
title = CharField()

objects = DelegatingManager()
objects.writer = Manager()
objects.reader = LoadBalancingManager(settings.CONNECTION_SET)

or something like that.

> 
> Additionally we could allow an optional parameter to the .save() method
> to give a different manager,

This would also be needed for object creation, if you didn't want to
save using the default manager.


> Additionally the manager could have a .save() method itself that not
> only saves one object with it's associated objects, but would save all
> objects that are currently marked as "dirty" - that way users could
> define the scope of a transaction themselves. Either they .save() on
> the object and so the transaction would include the object and all
> subsequently added/changed objects that were dependend on that "lead"
> object, or they call .save() on the manager to update all outstanding
> changes (and therefore have a big transaction including all stuff).
> This wouldn't fully solve #9, as it doesn't include a full manual
> transaction support, but it would solve many situations where the
> programmer either has one object with related stuff or multiple loosely
> related objects.
> 
> Comments?
> 
> bye, Georg

The issue I see here is that any one manager is only concerned with the
objects of one class. One possibility is to introduce a UnitOfWork
class, which just keeps track of updates.

I can't really come up with any API for explicit transactional stuff
without adding a few more parameters some places...

Maybe

unit = UnitOfWork()

polls = Poll.objects.using(unit)
# This returns a copy of the manager that will
# post all updates to this unit.
# Any other managers obtained through this manager here will implicitly
# use the same unit.
poll = polls.find_one(pk=3)
poll.choice_set[0].name = "Yessir!!"
# So this marks the first choice as dirty,
# via choices.objects.with(unit), which will be passed on to the unit.

unit.save()

# This will save the choice stuff, by calling back to the choice manager
# to actually do the update. All the updates are done in a transaction,
# possibly with two phase commit if we get fancy (writes to
# different dbs.)

So in the usual case, this would get done implicitly by some middleware,
ie there would be a request scoped unit of work that would be used by
managers unless told otherwise, and it would call save() if the request
works, or it would discard it on an exception.

This way, individual items would no longer need to have a .save method.
They would always be saved by the unit of work.

The issues are :
* Do we need a way to force newly created items to get an id? I think
just a way to get access to the normal unit of work is enough. Then you
can call save, and any objects you were using will have their ids filled
in.

Thoughts?

Re: Idea for a new badge

[Jacob Kaplan-Moss]

I've fixed that problem; thanks for pointing it out, Luke.

Jacob

Re: Idea for a new badge

[Petar Marić]

Link is not http://media.djang...angowish126x70.gif'? its
http://media.djang...angowish126x70.gif

On 11/6/05, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Sun, 6 Nov 2005 20:24:43 +0100 Petar Marić wrote:
>
> > I wanted to use this idea for my blog, then figured this could
> > interest a few more people:
> >
> > You know that orange bar on top of
> > http://media.djangoproject.com/img/badges/djangowish126x70.gif ?
>
> This happens to have highlighted a config error somewhere on
> media.djangoproject.com, as this image doesn't load in Konqueror.
> Instead of just displaying it, it prompts:
>
>Open 'http://media.djang...angowish126x70.gif'?
>Type: image/gif, image/gif
>
>
> Look at the headers, I get this:
>
> Connection: keep-alive
> Date: Sun, 06 Nov 2005 20:05:48 GMT
> Last-Modified: Fri, 04 Nov 2005 19:35:14 GMT
> Content-Length: 5051
> ETag: 1393956625
> Accept-Ranges: bytes
> Content-Type: image/gif, image/gif
> Server: lighttpd/1.3.13
>
> Konqueror does display it correctly inline in a page by the way.
>
> Luke
> --
> "I spilled spot remover on my dog. Now he's gone." (Steven Wright)
>
> Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
>


--
Petar Marić
*e-mail: [EMAIL PROTECTED]
*mobile: +381 (64) 6122467

*icq: 224720322
*skype: petar_maric
*web: http://www.petarmaric.com/