subject:"Idea"

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

2022-07-20 Thread 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()

2022-07-14 Thread 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()

2022-07-14 Thread 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()

2022-07-11 Thread 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()

2022-07-10 Thread 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()

2022-07-10 Thread '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()

2022-07-09 Thread 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()

2022-07-08 Thread 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()

2022-07-06 Thread 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()

2022-07-06 Thread 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()

2022-06-28 Thread 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()

2022-06-26 Thread 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()

2022-06-24 Thread 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, jerch
> 
> 
> 
> -- 
> Y

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

2022-06-24 Thread 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
<mailto: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
<https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com?utm_medium=email_source=footer>.

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

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

2022-06-23 Thread 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.

Feature Idea: extend dumpdata command with django-filters

2022-06-23 Thread Diego Margoni

I recently had the need to dump a huge table using the Django dumpdata 
command but I only needed a subset of records base on some standard filter.

I think there is already an external package for this, but for basic 
filtering I think it would be useful to have it integrated in Django simply 
adding a parameter to *dumpdata *command..

I would already have a pr ready for this, just wanna know if it might be 
useful.

-- 
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/e32686e8-f7d4-4d96-9cb8-98763a47eb0an%40googlegroups.com.

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

2022-06-22 Thread 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()

2022-06-21 Thread אורי

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()

2022-06-21 Thread 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.

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

2022-06-20 Thread Steve Jorgensen

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/d5802d27-0f60-4d52-93e9-953b571c9d41n%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

2022-06-07 Thread Maciek Olko

Ah, thank you for explaining. I missed the point and the existing setting,
sorry.

Cheers,
Maciej

wt., 7 cze 2022 o 11:26 Florian Apolloner 
napisał(a):

> Hi Maciej,
>
> You can already customize the cookie name via a setting. What this request
> is asking is customization based on the request object which is not that
> common. Did you check that you configured your applications correctly to
> use different cookie names (
> https://docs.djangoproject.com/en/4.0/ref/settings/#session-cookie-name)?
>
> > I wonder if using a Django project code name as part of session cookie
> for new projects would have a potential to be considered as an accepted
> feature.
>
> has not been considered (as far as I know) and is something I'd be
> strongly against.
>
> Cheers,
> Florian
>
> On Monday, June 6, 2022 at 11:51:24 PM UTC+2 macie...@gmail.com wrote:
>
>> Hi Dan and Carlton,
>>
>> In my current company I am impacted by conflicting session cookie name.
>> We have several internal tools built on Django, available in the internal
>> network under the same top-level domain. The scope of session cookies
>> apparently was set on more than one service to a wildcard. Majority of
>> users use only one of services in day-to-day work, so it's not impacting a
>> big number of people.
>>
>> I personally would be +1 for exposing a method to easily and without
>> copying much code one was able to change it.
>>
>> I wonder if using a Django project code name as part of session cookie
>> for new projects would have a potential to be considered as an accepted
>> feature.
>>
>> Kind regards,
>> Maciej
>>
>> pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):
>>
>>> Hi Carlton, thanks for the response.
>>>
>>> An external package might be useful, although the code majority of the
>>> code would be the copied SessionMiddleware code and the tiny changes to
>>> allow a dynamic cookie name, so my thoughts is that this might be "too
>>> small" for a published pypi package?
>>>
>>> But since I haven't found a similar request earlier on this mailing list
>>> or the issue tracker, it seems that it might be really niche, as you say!
>>>
>>> Best regards,
>>> Dan
>>>
>>> --
>>> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/08a438ff-9d7a-47e0-abe2-d68a7dd20935n%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/CALYYG80d1ngzzxCOJs3-M494BGLssVGRMgmQEUWopFGeXXghoQ%40mail.gmail.com.

Re: Feature Idea: Allow setting session cookie name dynamically

2022-06-07 Thread Florian Apolloner

Hi Maciej,

You can already customize the cookie name via a setting. What this request 
is asking is customization based on the request object which is not that 
common. Did you check that you configured your applications correctly to 
use different cookie names 
(https://docs.djangoproject.com/en/4.0/ref/settings/#session-cookie-name)?

> I wonder if using a Django project code name as part of session cookie 
for new projects would have a potential to be considered as an accepted 
feature.

has not been considered (as far as I know) and is something I'd be strongly 
against.

Cheers,
Florian

On Monday, June 6, 2022 at 11:51:24 PM UTC+2 macie...@gmail.com wrote:

> Hi Dan and Carlton,
>
> In my current company I am impacted by conflicting session cookie name. We 
> have several internal tools built on Django, available in the internal 
> network under the same top-level domain. The scope of session cookies 
> apparently was set on more than one service to a wildcard. Majority of 
> users use only one of services in day-to-day work, so it's not impacting a 
> big number of people.
>
> I personally would be +1 for exposing a method to easily and without 
> copying much code one was able to change it.
>
> I wonder if using a Django project code name as part of session cookie for 
> new projects would have a potential to be considered as an accepted feature.
>
> Kind regards,
> Maciej
>
> pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):
>
>> Hi Carlton, thanks for the response.
>>
>> An external package might be useful, although the code majority of the 
>> code would be the copied SessionMiddleware code and the tiny changes to 
>> allow a dynamic cookie name, so my thoughts is that this might be "too 
>> small" for a published pypi package?
>>
>> But since I haven't found a similar request earlier on this mailing list 
>> or the issue tracker, it seems that it might be really niche, as you say!
>>
>> Best regards,
>> Dan
>>
>> -- 
>> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/08a438ff-9d7a-47e0-abe2-d68a7dd20935n%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

2022-06-06 Thread Maciek Olko

Hi Dan and Carlton,

In my current company I am impacted by conflicting session cookie name. We
have several internal tools built on Django, available in the internal
network under the same top-level domain. The scope of session cookies
apparently was set on more than one service to a wildcard. Majority of
users use only one of services in day-to-day work, so it's not impacting a
big number of people.

I personally would be +1 for exposing a method to easily and without
copying much code one was able to change it.

I wonder if using a Django project code name as part of session cookie for
new projects would have a potential to be considered as an accepted feature.

Kind regards,
Maciej

pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):

> Hi Carlton, thanks for the response.
>
> An external package might be useful, although the code majority of the
> code would be the copied SessionMiddleware code and the tiny changes to
> allow a dynamic cookie name, so my thoughts is that this might be "too
> small" for a published pypi package?
>
> But since I haven't found a similar request earlier on this mailing list
> or the issue tracker, it seems that it might be really niche, as you say!
>
> Best regards,
> Dan
>
> --
> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/CALYYG81HK-M2erdz4j5Jtp3h8J3vOaPj-qvE7rMPFRNiqKY1uA%40mail.gmail.com.

Re: Feature Idea: Allow setting session cookie name dynamically

2022-06-06 Thread Dan Strokirk

Hi Carlton, thanks for the response.

An external package might be useful, although the code majority of the code 
would be the copied SessionMiddleware code and the tiny changes to allow a 
dynamic cookie name, so my thoughts is that this might be "too small" for a 
published pypi package?

But since I haven't found a similar request earlier on this mailing list or 
the issue tracker, it seems that it might be really niche, as you say!

Best regards,
Dan

-- 
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/01a91019-8d54-4322-a295-dbfdc12dfab9n%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

2022-06-05 Thread Carlton Gibson

Hey Dan.

Thanks for following up here.

Just to recap, my reasoning on the ticket was that it's quite a niche
use-case. For me, just use the custom SessionMiddleware, or put that in a
third-party package for multi-tenancy folks to maintain together. (Or so
would be my opening thought... -- interested to see others' thoughts.)

Kind regards,
Carlton

Aside: Searching, there are lots of disparate resources for multi-tenant
deploys; slightly orthogonal to your exact suggestion here, I imagine
there's good work to be done corralling the interested parties and
patterns. Maybe one of the existing resources already does this... 樂




On Thu, 2 Jun 2022 at 14:47, Dan Strokirk  wrote:

> Hi,
>
> Currently it's only possible to use a single session cookie, but it can be
> useful in a multi-tenant application to use multiple session cookies. To
> solve this we currently use our own, slightly modified SessionMiddleware
> class that we keep in sync with the official implementation and re-apply
> the patch during each Django upgrade.
>
>
> Proposal: Adding a new get_cookie_name or get_cookie_params method to
> the SessionMiddleware class might be one way to implement this, which means
> that you can then then use your own subclassed middleware to easily
> override it. It would take the request and response objects as arguments.
>
> If this seems like a reasonable feature to add I'd be glad to supply a
> patch.
>
> (I've previously submitted a WONTFIX ticket for this, perhaps a little
> over-eager :) https://code.djangoproject.com/ticket/33760)
>
> Best regards,
> Dan
>
> --
> 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/879fbda1-c8f6-4995-a3d0-7b2cbe5bc282n%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/CAJwKpyROabEZPD2N%2BgQfJxGWh4TW%2BiZe1w5O0P8C4aKdS9nHwA%40mail.gmail.com.

Feature Idea: Allow setting session cookie name dynamically

2022-06-02 Thread Dan Strokirk

Hi,

Currently it's only possible to use a single session cookie, but it can be 
useful in a multi-tenant application to use multiple session cookies. To 
solve this we currently use our own, slightly modified SessionMiddleware 
class that we keep in sync with the official implementation and re-apply 
the patch during each Django upgrade.


Proposal: Adding a new get_cookie_name or get_cookie_params method to 
the SessionMiddleware class might be one way to implement this, which means 
that you can then then use your own subclassed middleware to easily 
override it. It would take the request and response objects as arguments.

If this seems like a reasonable feature to add I'd be glad to supply a 
patch.

(I've previously submitted a WONTFIX ticket for this, perhaps a little 
over-eager :) https://code.djangoproject.com/ticket/33760)

Best regards,
Dan

-- 
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/879fbda1-c8f6-4995-a3d0-7b2cbe5bc282n%40googlegroups.com.

Re: Feature Idea for overwrite_default_connection context manager

2022-06-01 Thread Alexander Lyabah

That's a great idea, actually. Thank you

On Wednesday, June 1, 2022 at 4:56:31 PM UTC+3 Adam Johnson wrote:

> Modifying the connections object seems like the wrong way to approach 
> this, as it's not intended for mutation. Did you consider writing a 
> database router and then having a context manager that affects the router's 
> state? 
> https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#topics-db-multi-db-routing
>  
> . That is the API Django supports for moving queries to different databases.
>
> On Wed, Jun 1, 2022 at 2:21 PM Alexander Lyabah  
> wrote:
>
>> In some of the previous version on Django I had a very useful context 
>> manager.
>>
>> from contextlib import ContextDecorator
>> from django.db import connections
>>
>> class overwrite_default_connection(ContextDecorator):
>> prev_default = None
>> write_connection = None
>> 
>> def __init__(self, write_connection):
>> self.write_connection = write_connection 
>> 
>> def __enter__(self):
>> self.prev_default = connections['default']
>> connections['default'] = connections[self.write_connection]
>> return self
>>
>> def __exit__(self, *exc):
>> connections['default'] = self.prev_default
>> return False
>>
>> Which allows me to overwrite default connection. It is very useful when 
>> you use a jupyter notebook and you need to switch between db connections 
>> that have different data but the same structure (django models)
>>
>> But the shared implementation of that context manager stops working 
>> recently
>>
>> ValueError: Subqueries aren't allowed across different databases. Force 
>> the inner query to be evaluated using `list(inner_query)`.
>>
>> But I'm wondering wouldn't it be useful to have that kind of manager in 
>> the core Django functionality, or it is a stupid idea?
>>
>> Thank you
>>
>> -- 
>> 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/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/cbe7f3b8-0f8b-49c3-b3e8-7c58fe612c90n%40googlegroups.com.

Re: Feature Idea for overwrite_default_connection context manager

2022-06-01 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Modifying the connections object seems like the wrong way to approach this,
as it's not intended for mutation. Did you consider writing a database
router and then having a context manager that affects the router's state?
https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#topics-db-multi-db-routing
. That is the API Django supports for moving queries to different databases.

On Wed, Jun 1, 2022 at 2:21 PM Alexander Lyabah 
wrote:

> In some of the previous version on Django I had a very useful context
> manager.
>
> from contextlib import ContextDecorator
> from django.db import connections
>
> class overwrite_default_connection(ContextDecorator):
> prev_default = None
> write_connection = None
>
> def __init__(self, write_connection):
> self.write_connection = write_connection
>
> def __enter__(self):
> self.prev_default = connections['default']
> connections['default'] = connections[self.write_connection]
> return self
>
> def __exit__(self, *exc):
> connections['default'] = self.prev_default
> return False
>
> Which allows me to overwrite default connection. It is very useful when
> you use a jupyter notebook and you need to switch between db connections
> that have different data but the same structure (django models)
>
> But the shared implementation of that context manager stops working
> recently
>
> ValueError: Subqueries aren't allowed across different databases. Force
> the inner query to be evaluated using `list(inner_query)`.
>
> But I'm wondering wouldn't it be useful to have that kind of manager in
> the core Django functionality, or it is a stupid idea?
>
> Thank you
>
> --
> 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/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAMyDDM0WUdGP3RKZzmNDq7VYYxoXQqXaJW8wRGU57Tr8174CdQ%40mail.gmail.com.

Feature Idea for overwrite_default_connection context manager

2022-06-01 Thread Alexander Lyabah

In some of the previous version on Django I had a very useful context 
manager.

from contextlib import ContextDecorator
from django.db import connections

class overwrite_default_connection(ContextDecorator):
prev_default = None
write_connection = None

def __init__(self, write_connection):
self.write_connection = write_connection 

def __enter__(self):
self.prev_default = connections['default']
connections['default'] = connections[self.write_connection]
return self

def __exit__(self, *exc):
connections['default'] = self.prev_default
return False

Which allows me to overwrite default connection. It is very useful when you 
use a jupyter notebook and you need to switch between db connections that 
have different data but the same structure (django models)

But the shared implementation of that context manager stops working recently

ValueError: Subqueries aren't allowed across different databases. Force the 
inner query to be evaluated using `list(inner_query)`.

But I'm wondering wouldn't it be useful to have that kind of manager in the 
core Django functionality, or it is a stupid idea?

Thank you

-- 
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/ad453105-2116-40c9-a1ff-9571bfb080d1n%40googlegroups.com.

Re: A new feature idea

2021-10-25 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Hi Ath

In my experience the analytics that website operators are interested in
varies vastly between projects. There are also many competing popular
solutions.

I don't think we'd include any analytics package inside Django at this
point. But I don't mean to discourage you, it could be a good project for
you to learn from developing as a third party package.

—Adam

On Mon, 25 Oct 2021 at 09:11, Ath Tripathi  wrote:

> I was seeing some website and came across a blog site, which have a small
> section which show monthly visits and other things like that.
> An idea came in my mind that to make a admin like page which show total
> website visits,modal read and write,update,deletion , many filters to
> filter on basis of week,day,months and years.
>
> Just like an inbuilt analytics for website, I am ready to work on this on
> my own just want to know your ideas and views.
>
> --
> 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/54e4c509-2eae-4d50-a8e2-d3bb6cc3da34n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/54e4c509-2eae-4d50-a8e2-d3bb6cc3da34n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAMyDDM37A4BAjz6vR_5%2B89-U8DO%3DnK9R2v0kj9%2BH6FPDz%2BocfQ%40mail.gmail.com.

A new feature idea

2021-10-25 Thread Ath Tripathi

I was seeing some website and came across a blog site, which have a small 
section which show monthly visits and other things like that.
An idea came in my mind that to make a admin like page which show total 
website visits,modal read and write,update,deletion , many filters to 
filter on basis of week,day,months and years.

Just like an inbuilt analytics for website, I am ready to work on this on 
my own just want to know your ideas and views.

-- 
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/54e4c509-2eae-4d50-a8e2-d3bb6cc3da34n%40googlegroups.com.

Re: Idea

2021-10-21 Thread 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

Re: Idea

2021-10-21 Thread 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

2021-10-20 Thread '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.

Idea

2021-09-18 Thread Jet Ezra

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.

Re: Idea

2021-09-15 Thread 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 the web visit

Re: Idea

2021-09-15 Thread 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

2021-09-15 Thread 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

2021-09-15 Thread '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.

Idea

2021-09-14 Thread abdul azeez

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.

Re: need a good idea

2021-04-10 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Hi

Check out the wiki page:
https://code.djangoproject.com/wiki/SummerOfCode2021

Adam

On Fri, 9 Apr 2021 at 05:05, fake man  wrote:

> Hello there ,
> can u please tell me what is a good idea or proposal for GSOC 2021
>
> thanks
>
> --
> 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/f70894f7-1f92-4ef3-8c8c-dcc297d5f492n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/f70894f7-1f92-4ef3-8c8c-dcc297d5f492n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Adam

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

need a good idea

2021-04-09 Thread fake man

Hello there ,
can u please tell me what is a good idea or proposal for GSOC 2021

thanks

-- 
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/f70894f7-1f92-4ef3-8c8c-dcc297d5f492n%40googlegroups.com.

Re: Django Project idea query

2021-03-26 Thread Muskan Vaswan

This is something that I find myself interested in too! Specifically in the 
part involving AVS.

Here is a little confusion I have:
So far, ASV hasn't been integrated into djangobench repo itself (If I'm not 
missing anything too crucial). So, most of the work that has been put in 
thus far has been on this repository 
<https://github.com/smithdc1/django-asv> by David Smith, right?
Would a task for GSoC be then, to migrate more of Django's benchmarks to 
ASV, and add them to this repository? Or would it be to add AVS to the 
django/djangobench repository itself? Basically, where would we be expected 
to contribute, in other words, to which of the repositories would it make 
more sense to contribute to?

*Khushi*, having a shared interest in this topic that has so many 
possibilities, it perhaps might be helpful for us to navigate the project 
together and help each other out! 

Regards
Muskan Vaswan


On Wednesday, 24 March 2021 at 16:38:39 UTC+5:30 khushik...@gmail.com wrote:

> Hello Carlton!
> Thank you for guiding me, I am looking into the bugs and will let you know 
> if I am stuck anywhere.
> I appreciate that you were able to give some suggestions on how to move 
> forward.
> Yours sincerely
> Khushi
>
> On Wednesday, 24 March 2021 at 14:24:29 UTC+5:30 carlton...@gmail.com 
> wrote:
>
>> Hi Khushi. 
>>
>> Thanks for the interest. This is a good topic. 
>>
>> Particularly with the async changes it's really important that we can 
>> profile changes. 
>> See https://github.com/django/django/pull/13651
>> This adds async signal dispatch, which would allow us a fully-async 
>> request-response pathway (assuming you didn't use sync components inside 
>> that)
>> *but *it's currently stalled for the performance concerns. 
>> That's just one example. 
>>
>> From https://github.com/django/djangobench/issues/38
>> First step I'd say is to see if you can set up the benchmarking (and ASV) 
>> locally, and get playing with it. 
>> Then I'd play a bit and comment with your first impressions (I'd say 
>> 'findings' but that might imply more than you really need — just get going)
>>
>> David has been pushing the effort there, in his free time, and I'm quite 
>> sure he'd welcome input. 
>> I know others are very keen in this area and will jump in as soon as you 
>> show progress. 
>>
>> Hopefully that gets you started. (Summary: Get up and running, then I'm 
>> sure you can get more feedback.) 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote:
>>
>>> Hello All!
>>> I am participating in GSOC 2021. I was looking at some of the project 
>>> lists and I am interested in the Django Benchmarking project idea. I would 
>>> like to know more about the tasks and operations involved in this project 
>>> idea. I am looking forward to contributing to the Django committee with my 
>>> work.
>>> Thank you
>>>
>>>  
>>>
>>

-- 
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/e141e3c8-5962-4e74-97c7-09b2d9dbc33cn%40googlegroups.com.

Re: Django Project idea query

2021-03-24 Thread Khushi Kaushal

Hello Carlton!
Thank you for guiding me, I am looking into the bugs and will let you know 
if I am stuck anywhere.
I appreciate that you were able to give some suggestions on how to move 
forward.
Yours sincerely
Khushi

On Wednesday, 24 March 2021 at 14:24:29 UTC+5:30 carlton...@gmail.com wrote:

> Hi Khushi. 
>
> Thanks for the interest. This is a good topic. 
>
> Particularly with the async changes it's really important that we can 
> profile changes. 
> See https://github.com/django/django/pull/13651
> This adds async signal dispatch, which would allow us a fully-async 
> request-response pathway (assuming you didn't use sync components inside 
> that)
> *but *it's currently stalled for the performance concerns. 
> That's just one example. 
>
> From https://github.com/django/djangobench/issues/38
> First step I'd say is to see if you can set up the benchmarking (and ASV) 
> locally, and get playing with it. 
> Then I'd play a bit and comment with your first impressions (I'd say 
> 'findings' but that might imply more than you really need — just get going)
>
> David has been pushing the effort there, in his free time, and I'm quite 
> sure he'd welcome input. 
> I know others are very keen in this area and will jump in as soon as you 
> show progress. 
>
> Hopefully that gets you started. (Summary: Get up and running, then I'm 
> sure you can get more feedback.) 
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote:
>
>> Hello All!
>> I am participating in GSOC 2021. I was looking at some of the project 
>> lists and I am interested in the Django Benchmarking project idea. I would 
>> like to know more about the tasks and operations involved in this project 
>> idea. I am looking forward to contributing to the Django committee with my 
>> work.
>> Thank you
>>
>>  
>>
>

-- 
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/ef52faea-4ad5-44be-a77d-0c3222bc9921n%40googlegroups.com.

Re: Django Project idea query

2021-03-24 Thread Carlton Gibson

Hi Khushi. 

Thanks for the interest. This is a good topic. 

Particularly with the async changes it's really important that we can 
profile changes. 
See https://github.com/django/django/pull/13651
This adds async signal dispatch, which would allow us a fully-async 
request-response pathway (assuming you didn't use sync components inside 
that)
*but *it's currently stalled for the performance concerns. 
That's just one example. 

>From https://github.com/django/djangobench/issues/38
First step I'd say is to see if you can set up the benchmarking (and ASV) 
locally, and get playing with it. 
Then I'd play a bit and comment with your first impressions (I'd say 
'findings' but that might imply more than you really need — just get going)

David has been pushing the effort there, in his free time, and I'm quite 
sure he'd welcome input. 
I know others are very keen in this area and will jump in as soon as you 
show progress. 

Hopefully that gets you started. (Summary: Get up and running, then I'm 
sure you can get more feedback.) 

Kind Regards,

Carlton

On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote:

> Hello All!
> I am participating in GSOC 2021. I was looking at some of the project 
> lists and I am interested in the Django Benchmarking project idea. I would 
> like to know more about the tasks and operations involved in this project 
> idea. I am looking forward to contributing to the Django committee with my 
> work.
> Thank you
>
>  
>

-- 
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/36fcf0ee-a898-4b43-82ca-c5dc3e0144b8n%40googlegroups.com.

Django Project idea query

2021-03-23 Thread Khushi Kaushal

Hello All!
I am participating in GSOC 2021. I was looking at some of the project lists 
and I am interested in the Django Benchmarking project idea. I would like 
to know more about the tasks and operations involved in this project idea. 
I am looking forward to contributing to the Django committee with my work.
Thank you

 

-- 
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/fd72ec40-4cca-447b-a991-03c9e705ecabn%40googlegroups.com.

Re: Advancing with the Triage & Review Team idea.

2020-10-06 Thread Carlton Gibson

First pass at a PR to DEP 10 https://github.com/django/deps/pull/71

On Tuesday, 6 October 2020 at 10:43:53 UTC+2 Carlton Gibson wrote:

> OK, I've added Jon, Simon and Tim to Nick on the T team. 
>
> That has GitHub's Triage permission, so you can do various Triage-y like 
> things to PRs. 
> (Possibly you already could given membership of other teams but...) 
>
> I've also invited Hasan and David. They'll need to accept, as not already 
> Django org members. 
>
> This on the basis of the previous discussion, and no objections here. 
>
> Thank you all for your contributions and welcome aboard Hasan and David, 
> in particular. 
>
> I'd like to extend this further, but that'll do for today. 
>
> I'll have a look at an adjustment to DEP 10 later on. I'd like to push 
> that change forward. 
> Thanks all. 
> C. 
>
> On Tuesday, 6 October 2020 at 02:49:35 UTC+2 timog...@gmail.com wrote:
>
>> I'm in favor of the proposal. It seems good to empower the people doing 
>> the work and remove some red tape regarding such a limited number of people 
>> who can approve a PR. I don't think Simon's approvals should carry less 
>> weight merely because he wasn't re-elected to the technical board. Now that 
>> the technical board election is open to the entire DSF, most people voting 
>> probably don't follow day-to-day Django development anyway -- I can't say 
>> that I do. Actually, I haven't even followed DEP 10 close enough to know 
>> that my approval is no longer sufficient for Mariusz to merge his own 
>> rather trivial PR, or that in voting for the technical board, I was voting 
>> for who could approve PRs. It seems needlessly restrictive.
>> On Monday, October 5, 2020 at 10:33:15 AM UTC-4 carlton...@gmail.com 
>> wrote:
>>
>>> Thanks Simon. 
>>>
>>> There are two parts to this: 
>>>
>>> * the team, with the Triage and Review permission. 
>>> * Whether they can approve Mariusz’ PRs over the weekend. (And other 
>>> times…)
>>>
>>> I could take the previous discussion for a Yes on the first part, and 
>>> just invite more people. (I should probably just do that.) 
>>>
>>> BUT I’d like to resolve the second point here (it’s needed for the 
>>> examples given).
>>>  
>>> I think it might need an edit to DEP 10… as per here:
>>>
>>> https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26
>>>
>>> If so, I’m happy to type that up but I guess some pointer from the new 
>>> TB that it would be acceptable would be good. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>>
>>> On 5 Oct 2020, at 15:46, charettes  wrote:
>>>
>>> I like the idea but I don't feel comfortable vouching for it given my 
>>> conflict of interest.
>>>
>>> I'll just say that It does feel weird that folks on this list which are 
>>> the main active contributors outside of a few members of the currently 
>>> elected TB don't have access to basic triaging and reviewing features on 
>>> Github. It feels like these permissions would be way more useful to them, 
>>> and the active contributors members of the TB that are not mentioned here, 
>>> than to members of the TB themselves given the rare times they have to step 
>>> in on a Github issue (mainly DEPs? so far).
>>>
>>> Cheers,
>>> Simon
>>>
>>> Le samedi 3 octobre 2020 à 03:53:46 UTC-4, carlton...@gmail.com a 
>>> écrit :
>>>
>>>> Hi all.
>>>>
>>>> With the new Technical Board elected (Well done to everyone there!) we 
>>>> have an important workflow that’s not covered by DEP 10. 
>>>>
>>>> Specifically, this scenario: 
>>>>
>>>> - An issue comes in covering some esoteric corner of the ORM 
>>>> — generation of column aliases for group by clauses say. 
>>>>
>>>> - Mariusz picks this up and opens a PR fixing said issue. 
>>>>
>>>> - Simon reviews PR and approves it. 
>>>>
>>>> - Mariusz merges. 
>>>>
>>>> Up until now this has been covered by Simon’s role on the TB as, under 
>>>> DEP 10, TB members are allowed to approve a Merger’s PR. Officially the PR 
>>>> here would now require further approval from Claude or myself before 
>>>> Mariusz could proceed. 
>>>>
>>>> This is a symptom of a wider issue. 
>>>>
>>>> Frequently, for

Re: Advancing with the Triage & Review Team idea.

2020-10-06 Thread Carlton Gibson

OK, I've added Jon, Simon and Tim to Nick on the T team. 

That has GitHub's Triage permission, so you can do various Triage-y like 
things to PRs. 
(Possibly you already could given membership of other teams but...) 

I've also invited Hasan and David. They'll need to accept, as not already 
Django org members. 

This on the basis of the previous discussion, and no objections here. 

Thank you all for your contributions and welcome aboard Hasan and David, in 
particular. 

I'd like to extend this further, but that'll do for today. 

I'll have a look at an adjustment to DEP 10 later on. I'd like to push that 
change forward. 
Thanks all. 
C. 

On Tuesday, 6 October 2020 at 02:49:35 UTC+2 timog...@gmail.com wrote:

> I'm in favor of the proposal. It seems good to empower the people doing 
> the work and remove some red tape regarding such a limited number of people 
> who can approve a PR. I don't think Simon's approvals should carry less 
> weight merely because he wasn't re-elected to the technical board. Now that 
> the technical board election is open to the entire DSF, most people voting 
> probably don't follow day-to-day Django development anyway -- I can't say 
> that I do. Actually, I haven't even followed DEP 10 close enough to know 
> that my approval is no longer sufficient for Mariusz to merge his own 
> rather trivial PR, or that in voting for the technical board, I was voting 
> for who could approve PRs. It seems needlessly restrictive.
> On Monday, October 5, 2020 at 10:33:15 AM UTC-4 carlton...@gmail.com 
> wrote:
>
>> Thanks Simon. 
>>
>> There are two parts to this: 
>>
>> * the team, with the Triage and Review permission. 
>> * Whether they can approve Mariusz’ PRs over the weekend. (And other 
>> times…)
>>
>> I could take the previous discussion for a Yes on the first part, and 
>> just invite more people. (I should probably just do that.) 
>>
>> BUT I’d like to resolve the second point here (it’s needed for the 
>> examples given).
>>  
>> I think it might need an edit to DEP 10… as per here:
>>
>> https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26
>>
>> If so, I’m happy to type that up but I guess some pointer from the new TB 
>> that it would be acceptable would be good. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>>
>> On 5 Oct 2020, at 15:46, charettes  wrote:
>>
>> I like the idea but I don't feel comfortable vouching for it given my 
>> conflict of interest.
>>
>> I'll just say that It does feel weird that folks on this list which are 
>> the main active contributors outside of a few members of the currently 
>> elected TB don't have access to basic triaging and reviewing features on 
>> Github. It feels like these permissions would be way more useful to them, 
>> and the active contributors members of the TB that are not mentioned here, 
>> than to members of the TB themselves given the rare times they have to step 
>> in on a Github issue (mainly DEPs? so far).
>>
>> Cheers,
>> Simon
>>
>> Le samedi 3 octobre 2020 à 03:53:46 UTC-4, carlton...@gmail.com a écrit :
>>
>>> Hi all.
>>>
>>> With the new Technical Board elected (Well done to everyone there!) we 
>>> have an important workflow that’s not covered by DEP 10. 
>>>
>>> Specifically, this scenario: 
>>>
>>> - An issue comes in covering some esoteric corner of the ORM 
>>> — generation of column aliases for group by clauses say. 
>>>
>>> - Mariusz picks this up and opens a PR fixing said issue. 
>>>
>>> - Simon reviews PR and approves it. 
>>>
>>> - Mariusz merges. 
>>>
>>> Up until now this has been covered by Simon’s role on the TB as, under 
>>> DEP 10, TB members are allowed to approve a Merger’s PR. Officially the PR 
>>> here would now require further approval from Claude or myself before 
>>> Mariusz could proceed. 
>>>
>>> This is a symptom of a wider issue. 
>>>
>>> Frequently, for example, Marisuz makes a small PR on the weekend. I'm 
>>> not working Monday, so it has to wait until Tuesday morning for me to see 
>>> it and Approve it.
>>>
>>> Meanwhile one or more regular contributors have taken the time to look 
>>> at the PR and approve it.
>>>
>>> A couple of actual examples:
>>>
>>> 1. Made indexes tests use required_db_features.
>>> https://github.com/django/django/pull/13432
>>> Approved by Hasan and Tim.
>>>
>>> 2.

Re: Advancing with the Triage & Review Team idea.

2020-10-05 Thread Tim Graham

I'm in favor of the proposal. It seems good to empower the people doing the 
work and remove some red tape regarding such a limited number of people who 
can approve a PR. I don't think Simon's approvals should carry less weight 
merely because he wasn't re-elected to the technical board. Now that the 
technical board election is open to the entire DSF, most people voting 
probably don't follow day-to-day Django development anyway -- I can't say 
that I do. Actually, I haven't even followed DEP 10 close enough to know 
that my approval is no longer sufficient for Mariusz to merge his own 
rather trivial PR, or that in voting for the technical board, I was voting 
for who could approve PRs. It seems needlessly restrictive.
On Monday, October 5, 2020 at 10:33:15 AM UTC-4 carlton...@gmail.com wrote:

> Thanks Simon. 
>
> There are two parts to this: 
>
> * the team, with the Triage and Review permission. 
> * Whether they can approve Mariusz’ PRs over the weekend. (And other 
> times…)
>
> I could take the previous discussion for a Yes on the first part, and just 
> invite more people. (I should probably just do that.) 
>
> BUT I’d like to resolve the second point here (it’s needed for the 
> examples given).
>  
> I think it might need an edit to DEP 10… as per here:
>
> https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26
>
> If so, I’m happy to type that up but I guess some pointer from the new TB 
> that it would be acceptable would be good. 
>
> Kind Regards,
>
> Carlton
>
>
>
>
> On 5 Oct 2020, at 15:46, charettes  wrote:
>
> I like the idea but I don't feel comfortable vouching for it given my 
> conflict of interest.
>
> I'll just say that It does feel weird that folks on this list which are 
> the main active contributors outside of a few members of the currently 
> elected TB don't have access to basic triaging and reviewing features on 
> Github. It feels like these permissions would be way more useful to them, 
> and the active contributors members of the TB that are not mentioned here, 
> than to members of the TB themselves given the rare times they have to step 
> in on a Github issue (mainly DEPs? so far).
>
> Cheers,
> Simon
>
> Le samedi 3 octobre 2020 à 03:53:46 UTC-4, carlton...@gmail.com a écrit :
>
>> Hi all.
>>
>> With the new Technical Board elected (Well done to everyone there!) we 
>> have an important workflow that’s not covered by DEP 10. 
>>
>> Specifically, this scenario: 
>>
>> - An issue comes in covering some esoteric corner of the ORM — generation 
>> of column aliases for group by clauses say. 
>>
>> - Mariusz picks this up and opens a PR fixing said issue. 
>>
>> - Simon reviews PR and approves it. 
>>
>> - Mariusz merges. 
>>
>> Up until now this has been covered by Simon’s role on the TB as, under 
>> DEP 10, TB members are allowed to approve a Merger’s PR. Officially the PR 
>> here would now require further approval from Claude or myself before 
>> Mariusz could proceed. 
>>
>> This is a symptom of a wider issue. 
>>
>> Frequently, for example, Marisuz makes a small PR on the weekend. I'm not 
>> working Monday, so it has to wait until Tuesday morning for me to see it 
>> and Approve it.
>>
>> Meanwhile one or more regular contributors have taken the time to look at 
>> the PR and approve it.
>>
>> A couple of actual examples:
>>
>> 1. Made indexes tests use required_db_features.
>> https://github.com/django/django/pull/13432
>> Approved by Hasan and Tim.
>>
>> 2. Corrected docstring quotes in various code.
>> https://github.com/django/django/pull/13445
>> Approved by David and Hasan .
>>
>> David, Hasan and Tim are all regular features on PRs, Trac, and here, 
>> making PRs, reviewing, commenting, helping to triage and so on. Tim is 
>> Django's #1 all-time contributor. Hasan has made nearly 200 commits and it 
>> there every week taking on issues from the backlog. David is a newer 
>> arrival, has been super active and offered good input across the board, 
>> both here and on third-party packages. 
>>
>> It seems clear that their approval should be enough for a Merger PR to 
>> progress. 
>>
>>
>>
>> Proposal:
>>
>> Some time ago I proposed a Triage and Review Team.
>>
>> https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ
>>
>> I began this but it ran into the DEP 10 changes, and I stopped working on 
>> it to let that go through. With the new TB in place, I'd like to bring that 
>> back now, granting PR Approval power, a

Re: Advancing with the Triage & Review Team idea.

2020-10-05 Thread Carlton Gibson

Thanks Simon. 

There are two parts to this: 

* the team, with the Triage and Review permission. 
* Whether they can approve Mariusz’ PRs over the weekend. (And other times…)

I could take the previous discussion for a Yes on the first part, and just 
invite more people. (I should probably just do that.) 

BUT I’d like to resolve the second point here (it’s needed for the examples 
given).
 
I think it might need an edit to DEP 10… as per here:
https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26
 
<https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26>

If so, I’m happy to type that up but I guess some pointer from the new TB that 
it would be acceptable would be good. 

Kind Regards,

Carlton




> On 5 Oct 2020, at 15:46, charettes  wrote:
> 
> I like the idea but I don't feel comfortable vouching for it given my 
> conflict of interest.
> 
> I'll just say that It does feel weird that folks on this list which are the 
> main active contributors outside of a few members of the currently elected TB 
> don't have access to basic triaging and reviewing features on Github. It 
> feels like these permissions would be way more useful to them, and the active 
> contributors members of the TB that are not mentioned here, than to members 
> of the TB themselves given the rare times they have to step in on a Github 
> issue (mainly DEPs? so far).
> 
> Cheers,
> Simon
> 
> Le samedi 3 octobre 2020 à 03:53:46 UTC-4, carlton...@gmail.com 
> <http://gmail.com/> a écrit :
> Hi all.
> 
> With the new Technical Board elected (Well done to everyone there!) we have 
> an important workflow that’s not covered by DEP 10. 
> 
> Specifically, this scenario: 
> 
> - An issue comes in covering some esoteric corner of the ORM — generation of 
> column aliases for group by clauses say. 
> 
> - Mariusz picks this up and opens a PR fixing said issue. 
> 
> - Simon reviews PR and approves it. 
> 
> - Mariusz merges. 
> 
> Up until now this has been covered by Simon’s role on the TB as, under DEP 
> 10, TB members are allowed to approve a Merger’s PR. Officially the PR here 
> would now require further approval from Claude or myself before Mariusz could 
> proceed. 
> 
> This is a symptom of a wider issue. 
> 
> Frequently, for example, Marisuz makes a small PR on the weekend. I'm not 
> working Monday, so it has to wait until Tuesday morning for me to see it and 
> Approve it.
> 
> Meanwhile one or more regular contributors have taken the time to look at the 
> PR and approve it.
> 
> A couple of actual examples:
> 
> 1. Made indexes tests use required_db_features.
> https://github.com/django/django/pull/13432 
> <https://github.com/django/django/pull/13432>
> Approved by Hasan and Tim.
> 
> 2. Corrected docstring quotes in various code.
> https://github.com/django/django/pull/13445 
> <https://github.com/django/django/pull/13445>
> Approved by David and Hasan .
> 
> David, Hasan and Tim are all regular features on PRs, Trac, and here, making 
> PRs, reviewing, commenting, helping to triage and so on. Tim is Django's #1 
> all-time contributor. Hasan has made nearly 200 commits and it there every 
> week taking on issues from the backlog. David is a newer arrival, has been 
> super active and offered good input across the board, both here and on 
> third-party packages. 
> 
> It seems clear that their approval should be enough for a Merger PR to 
> progress. 
> 
> 
> 
> 
> Proposal:
> 
> Some time ago I proposed a Triage and Review Team.
> 
> https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ 
> <https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ>
> I began this but it ran into the DEP 10 changes, and I stopped working on it 
> to let that go through. With the new TB in place, I'd like to bring that back 
> now, granting PR Approval power, at least for Merge PRs.
> 
> The idea was to have a team for folks that are active on repo. This would 
> provide some recognition for efforts, allow extra hands to help manage 
> tickets — closing spam ones seems relevant this week…  — and so on. 
> 
> The GitHub Team I created has GitHub’s Triage role. This allows for one thing 
> to request a review from a Merger. Nick is the only member of that team 
> currently (see above about pausing) but it’s worked well when he's reviewed 
> PRs from the backlog, seen that they're ≈ready and asked for a review from 
> me. This has been very helpful, and quite smooth. (It’s in a similar vein to 
> marking tickets on Trac Ready for Commit, which also helps them to show about 
> the mass.) 
> 
> Ultimately I think a Triage & Review Tea

Re: Advancing with the Triage & Review Team idea.

2020-10-05 Thread charettes

I like the idea but I don't feel comfortable vouching for it given my 
conflict of interest.

I'll just say that It does feel weird that folks on this list which are the 
main active contributors outside of a few members of the currently elected 
TB don't have access to basic triaging and reviewing features on Github. It 
feels like these permissions would be way more useful to them, and the 
active contributors members of the TB that are not mentioned here, than to 
members of the TB themselves given the rare times they have to step in on a 
Github issue (mainly DEPs? so far).

Cheers,
Simon

Le samedi 3 octobre 2020 à 03:53:46 UTC-4, carlton...@gmail.com a écrit :

> Hi all.
>
> With the new Technical Board elected (Well done to everyone there!) we 
> have an important workflow that’s not covered by DEP 10. 
>
> Specifically, this scenario: 
>
> - An issue comes in covering some esoteric corner of the ORM — generation 
> of column aliases for group by clauses say. 
>
> - Mariusz picks this up and opens a PR fixing said issue. 
>
> - Simon reviews PR and approves it. 
>
> - Mariusz merges. 
>
> Up until now this has been covered by Simon’s role on the TB as, under DEP 
> 10, TB members are allowed to approve a Merger’s PR. Officially the PR here 
> would now require further approval from Claude or myself before Mariusz 
> could proceed. 
>
> This is a symptom of a wider issue. 
>
> Frequently, for example, Marisuz makes a small PR on the weekend. I'm not 
> working Monday, so it has to wait until Tuesday morning for me to see it 
> and Approve it.
>
> Meanwhile one or more regular contributors have taken the time to look at 
> the PR and approve it.
>
> A couple of actual examples:
>
> 1. Made indexes tests use required_db_features.
> https://github.com/django/django/pull/13432
> Approved by Hasan and Tim.
>
> 2. Corrected docstring quotes in various code.
> https://github.com/django/django/pull/13445
> Approved by David and Hasan .
>
> David, Hasan and Tim are all regular features on PRs, Trac, and here, 
> making PRs, reviewing, commenting, helping to triage and so on. Tim is 
> Django's #1 all-time contributor. Hasan has made nearly 200 commits and it 
> there every week taking on issues from the backlog. David is a newer 
> arrival, has been super active and offered good input across the board, 
> both here and on third-party packages. 
>
> It seems clear that their approval should be enough for a Merger PR to 
> progress. 
>
>
> Proposal:
>
> Some time ago I proposed a Triage and Review Team.
>
> https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ
>
> I began this but it ran into the DEP 10 changes, and I stopped working on 
> it to let that go through. With the new TB in place, I'd like to bring that 
> back now, granting PR Approval power, at least for Merge PRs.
>
> The idea was to have a team for folks that are active on repo. This would 
> provide some recognition for efforts, allow extra hands to help manage 
> tickets — closing spam ones seems relevant this week…  — and so on. 
>
> The GitHub Team I created has GitHub’s Triage role. This allows for one 
> thing to request a review from a Merger. Nick is the only member of that 
> team currently (see above about pausing) but it’s worked well when he's 
> reviewed PRs from the backlog, seen that they're ≈ready and asked for a 
> review from me. This has been very helpful, and quite smooth. (It’s in a 
> similar vein to marking tickets on Trac Ready for Commit, which also helps 
> them to show about the mass.) 
>
> Ultimately I think a Triage & Review Team is an opportunity to widen the 
> contributor pool and spread the work.
>
> I would suggest the following list for members to flesh out the team 
> initially. Happy to add more, but the idea was currently active (if 
> you're offended I missed you, sorry, do shout! — not intentional. ) 
>
> - David Smith
>
> - Hasan Ramezani
>
> - Jon Dufresne
>
> - Nick Pope
>
> - Simon Charette 
>
> - Tim Graham
>
> (I didn’t include Mergers or TB members.)
>
> Some other points: 
>
> - I’d like to start measuring non-commit contributions somehow. This is 
> something I’m thinking about but for now I think by-eye is sufficient. 
>
> - I’d be happy to make the list twice as long. 
>
> - As I say, currently active — we should review each cycle. 
>
> - It’s still all men — but the team would provide a way of recognising 
> anyone finding Triage as a Hobby appealing, so I’d hope it would act as 
> an incentive to participate, with a clear path to recognition (and from 
> there candidacy in a TB election say…)
>
> Hopefully that’s clear enough. Can I ask fo

Advancing with the Triage & Review Team idea.

2020-10-03 Thread Carlton Gibson

Hi all.

With the new Technical Board elected (Well done to everyone there!) we have
an important workflow that’s not covered by DEP 10.

Specifically, this scenario:

- An issue comes in covering some esoteric corner of the ORM — generation
of column aliases for group by clauses say.

- Mariusz picks this up and opens a PR fixing said issue.

- Simon reviews PR and approves it.

- Mariusz merges.

Up until now this has been covered by Simon’s role on the TB as, under DEP
10, TB members are allowed to approve a Merger’s PR. Officially the PR here
would now require further approval from Claude or myself before Mariusz
could proceed.

This is a symptom of a wider issue.

Frequently, for example, Marisuz makes a small PR on the weekend. I'm not
working Monday, so it has to wait until Tuesday morning for me to see it
and Approve it.

Meanwhile one or more regular contributors have taken the time to look at
the PR and approve it.

A couple of actual examples:

1. Made indexes tests use required_db_features.
https://github.com/django/django/pull/13432
Approved by Hasan and Tim.

2. Corrected docstring quotes in various code.
https://github.com/django/django/pull/13445
Approved by David and Hasan .

David, Hasan and Tim are all regular features on PRs, Trac, and here,
making PRs, reviewing, commenting, helping to triage and so on. Tim is
Django's #1 all-time contributor. Hasan has made nearly 200 commits and it
there every week taking on issues from the backlog. David is a newer
arrival, has been super active and offered good input across the board,
both here and on third-party packages.

It seems clear that their approval should be enough for a Merger PR to
progress.

Proposal:

Some time ago I proposed a Triage and Review Team.

https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ

I began this but it ran into the DEP 10 changes, and I stopped working on
it to let that go through. With the new TB in place, I'd like to bring that
back now, granting PR Approval power, at least for Merge PRs.

The idea was to have a team for folks that are active on repo. This would
provide some recognition for efforts, allow extra hands to help manage
tickets — closing spam ones seems relevant this week…  — and so on.

The GitHub Team I created has GitHub’s Triage role. This allows for one
thing to request a review from a Merger. Nick is the only member of that
team currently (see above about pausing) but it’s worked well when he's
reviewed PRs from the backlog, seen that they're ≈ready and asked for a
review from me. This has been very helpful, and quite smooth. (It’s in a
similar vein to marking tickets on Trac Ready for Commit, which also helps
them to show about the mass.)

Ultimately I think a Triage & Review Team is an opportunity to widen the
contributor pool and spread the work.

I would suggest the following list for members to flesh out the team
initially. Happy to add more, but the idea was currently active (if you're
offended I missed you, sorry, do shout! — not intentional. )

- David Smith

- Hasan Ramezani

- Jon Dufresne

- Nick Pope

- Simon Charette

- Tim Graham

(I didn’t include Mergers or TB members.)

Some other points:

- I’d like to start measuring non-commit contributions somehow. This is
something I’m thinking about but for now I think by-eye is sufficient.

- I’d be happy to make the list twice as long.

- As I say, currently active — we should review each cycle.

- It’s still all men — but the team would provide a way of recognising
anyone finding Triage as a Hobby appealing, so I’d hope it would act as an
incentive to participate, with a clear path to recognition (and from there
candidacy in a TB election say…)

Hopefully that’s clear enough. Can I ask for thoughts, and if we’re keen,
what would we need to do to make it formal?

Thanks all.

Kind regards, Carlton

Re: Idea for Rollback Migration Rules

2020-07-04 Thread 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
<https://gist.github.com/lyrixx/5867424>, 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
>

Re: Idea for Rollback Migration Rules

2020-07-04 Thread 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

2020-07-04 Thread 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: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-10-26 Thread David Foster

*Requesting reviewers* for the latest iteration of the PR to bulk-associate 
many-to-many relationships.

*The new PR to review*, which is *only a documentation change* showing how 
to bulk-associate many-to-many relationships, is here: 
https://github.com/django/django/pull/11948 

In case it's useful, the previous PR which actually introduced two new 
methods "add_relations" and "remove_relations" is here: 
https://github.com/django/django/pull/11899

It was previously argued that the implementation of "add_relations" and 
"remove_relations" was simple enough that only a documentation change might 
be needed. But after seeing the relatively complex boilerplate that the 
proposed documentation suggests, *I'm still leaning toward putting in 
dedicated "add_relations" and "remove_relations" methods.* Comments here? 
Put them on the umbrella Trac ticket: 
https://code.djangoproject.com/ticket/30828

Cheers,
David Foster | Seattle, WA, USA


On Sunday, October 13, 2019 at 3:39:12 PM UTC-7, David Foster wrote:
>
> Here's the link to the PR for review: 
> https://github.com/django/django/pull/11899
>
> (Apologies for the double-post)
>
> - David
>
> On Sunday, October 13, 2019 at 3:37:07 PM UTC-7, David Foster wrote:
>>
>> I've created a PR which is waiting for review, if someone has time.
>>
>> According to Trac, the next step is:
>>
>> For anyone except the patch author to review the patch using the patch 
>> review checklist 
>> <https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist>
>>  and 
>> either mark the ticket as "Ready for checkin" if everything looks good, or 
>> leave comments for improvement and mark the ticket as "Patch needs 
>> improvement".
>>
>> Thanks for any help.
>>
>> - David
>>
>> On Tuesday, October 1, 2019 at 11:06:15 PM UTC-7, David Foster wrote:
>>>
>>> Trac ticket created: https://code.djangoproject.com/ticket/30828
>>>
>>> On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote:
>>>>
>>>> Hey David,
>>>> I like this idea, while I don’t think the use case is common there have 
>>>> been a few times where I’ve needed this and got around it by 
>>>> creating/modifying the through model in bulk. Having a method that does 
>>>> this would be good IMO.
>>>>
>>>> Unless anyone has strong opinions against this then can you make a 
>>>> ticket? 
>>>>
>>>> Tom
>>>>
>>>> On 30 Sep 2019, at 02:14, David Foster  wrote:
>>>>
>>>> 
>>>> Here is another API variation I might suggest:
>>>>
>>>> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
>>>> # --- OR ---
>>>> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=
>>>> False)
>>>>
>>>> This has the advantages of being more similar to the existing add() API 
>>>> and not requiring a special function import.
>>>>
>>>> For bulk_disassociate() the analogous API would be:
>>>>
>>>> M1.m2_set.remove_pairs(*[(m1, m2), ...])
>>>> # --- OR ---
>>>> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
>>>>
>>>> - David
>>>>
>>>> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster 
>>>> wrote:
>>>>>
>>>>> Given the following example model:
>>>>>
>>>>> class M1(models.Model):
>>>>> m2_set = models.ManyToManyField('M2')
>>>>>
>>>>> It is already possible to associate *one* M1 with *many* M2s with a 
>>>>> single DB query:
>>>>>
>>>>> m1.m2_set.add(*m2s)
>>>>>
>>>>> However it's more difficult to associate *many* M1s with *many* M2s, 
>>>>> particularly if you want to skip associations that already exist.
>>>>>
>>>>> # NOTE: Does NOT skip associations that already exist!
>>>>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>>>>> M1_M2 = M1.m2_set.through
>>>>> M1_M2.objects.bulk_create([
>>>>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>>>>> for (m1_id, m2_id) in
>>>>> m1_and_m2_id_tuples
>>>>> ])
>>>>>
>>>>> What if we could do something like the following instead:
>>>>>
>>>>> bulk_asso

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-10-13 Thread David Foster

Here's the link to the PR for review: 
https://github.com/django/django/pull/11899

(Apologies for the double-post)

- David

On Sunday, October 13, 2019 at 3:37:07 PM UTC-7, David Foster wrote:
>
> I've created a PR which is waiting for review, if someone has time.
>
> According to Trac, the next step is:
>
> For anyone except the patch author to review the patch using the patch 
> review checklist 
> <https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist>
>  and 
> either mark the ticket as "Ready for checkin" if everything looks good, or 
> leave comments for improvement and mark the ticket as "Patch needs 
> improvement".
>
> Thanks for any help.
>
> - David
>
> On Tuesday, October 1, 2019 at 11:06:15 PM UTC-7, David Foster wrote:
>>
>> Trac ticket created: https://code.djangoproject.com/ticket/30828
>>
>> On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote:
>>>
>>> Hey David,
>>> I like this idea, while I don’t think the use case is common there have 
>>> been a few times where I’ve needed this and got around it by 
>>> creating/modifying the through model in bulk. Having a method that does 
>>> this would be good IMO.
>>>
>>> Unless anyone has strong opinions against this then can you make a 
>>> ticket? 
>>>
>>> Tom
>>>
>>> On 30 Sep 2019, at 02:14, David Foster  wrote:
>>>
>>> 
>>> Here is another API variation I might suggest:
>>>
>>> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
>>> # --- OR ---
>>> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=
>>> False)
>>>
>>> This has the advantages of being more similar to the existing add() API 
>>> and not requiring a special function import.
>>>
>>> For bulk_disassociate() the analogous API would be:
>>>
>>> M1.m2_set.remove_pairs(*[(m1, m2), ...])
>>> # --- OR ---
>>> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
>>>
>>> - David
>>>
>>> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>>>>
>>>> Given the following example model:
>>>>
>>>> class M1(models.Model):
>>>> m2_set = models.ManyToManyField('M2')
>>>>
>>>> It is already possible to associate *one* M1 with *many* M2s with a 
>>>> single DB query:
>>>>
>>>> m1.m2_set.add(*m2s)
>>>>
>>>> However it's more difficult to associate *many* M1s with *many* M2s, 
>>>> particularly if you want to skip associations that already exist.
>>>>
>>>> # NOTE: Does NOT skip associations that already exist!
>>>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>>>> M1_M2 = M1.m2_set.through
>>>> M1_M2.objects.bulk_create([
>>>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>>>> for (m1_id, m2_id) in
>>>> m1_and_m2_id_tuples
>>>> ])
>>>>
>>>> What if we could do something like the following instead:
>>>>
>>>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>>>> # --- OR ---
>>>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>>>>
>>>> I propose to write and add a *bulk_associate()* method to Django. I 
>>>> also propose to add a paired *bulk_disassociate()* method.
>>>>
>>>> *1. Does this sound like a good idea in general?*
>>>>
>>>>
>>>> In more detail, I propose adding the specific APIs, importable from 
>>>> *django.db*:
>>>>
>>>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>>>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>>>>
>>>> def bulk_associate(
>>>> M1_m2_set: ManyToManyDescriptor,
>>>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>>>> *, assert_no_collisions: bool=True) -> None:
>>>> """
>>>> Creates many (M1, M2) associations with O(1) database queries.
>>>> 
>>>> If any requested associations already exist, then they will be left 
>>>> alone.
>>>> 
>>>> If you assert that none of the requested associations already exist,
>>>> you can pass assert_no_collisions=True to save 1 database query.
>>>> """
>>>>

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-10-13 Thread David Foster

I've created a PR which is waiting for review, if someone has time.

According to Trac, the next step is:

For anyone except the patch author to review the patch using the patch 
review checklist 
<https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist>
 and 
either mark the ticket as "Ready for checkin" if everything looks good, or 
leave comments for improvement and mark the ticket as "Patch needs 
improvement".

Thanks for any help.

- David

On Tuesday, October 1, 2019 at 11:06:15 PM UTC-7, David Foster wrote:
>
> Trac ticket created: https://code.djangoproject.com/ticket/30828
>
> On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote:
>>
>> Hey David,
>> I like this idea, while I don’t think the use case is common there have 
>> been a few times where I’ve needed this and got around it by 
>> creating/modifying the through model in bulk. Having a method that does 
>> this would be good IMO.
>>
>> Unless anyone has strong opinions against this then can you make a 
>> ticket? 
>>
>> Tom
>>
>> On 30 Sep 2019, at 02:14, David Foster  wrote:
>>
>> 
>> Here is another API variation I might suggest:
>>
>> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
>> # --- OR ---
>> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False
>> )
>>
>> This has the advantages of being more similar to the existing add() API 
>> and not requiring a special function import.
>>
>> For bulk_disassociate() the analogous API would be:
>>
>> M1.m2_set.remove_pairs(*[(m1, m2), ...])
>> # --- OR ---
>> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
>>
>> - David
>>
>> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>>>
>>> Given the following example model:
>>>
>>> class M1(models.Model):
>>> m2_set = models.ManyToManyField('M2')
>>>
>>> It is already possible to associate *one* M1 with *many* M2s with a 
>>> single DB query:
>>>
>>> m1.m2_set.add(*m2s)
>>>
>>> However it's more difficult to associate *many* M1s with *many* M2s, 
>>> particularly if you want to skip associations that already exist.
>>>
>>> # NOTE: Does NOT skip associations that already exist!
>>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>>> M1_M2 = M1.m2_set.through
>>> M1_M2.objects.bulk_create([
>>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>>> for (m1_id, m2_id) in
>>> m1_and_m2_id_tuples
>>> ])
>>>
>>> What if we could do something like the following instead:
>>>
>>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>>> # --- OR ---
>>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>>>
>>> I propose to write and add a *bulk_associate()* method to Django. I 
>>> also propose to add a paired *bulk_disassociate()* method.
>>>
>>> *1. Does this sound like a good idea in general?*
>>>
>>>
>>> In more detail, I propose adding the specific APIs, importable from 
>>> *django.db*:
>>>
>>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>>>
>>> def bulk_associate(
>>> M1_m2_set: ManyToManyDescriptor,
>>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>>> *, assert_no_collisions: bool=True) -> None:
>>> """
>>> Creates many (M1, M2) associations with O(1) database queries.
>>> 
>>> If any requested associations already exist, then they will be left 
>>> alone.
>>> 
>>> If you assert that none of the requested associations already exist,
>>> you can pass assert_no_collisions=True to save 1 database query.
>>> """
>>> pass
>>>
>>> def bulk_associate_ids(
>>> M1_m2_set: ManyToManyDescriptor,
>>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
>>> *, assert_no_collisions: bool=True) -> None:
>>> pass
>>>
>>> If assert_no_collisions is False then (1 filter) query and (1 
>>> bulk_create) query will be performed.
>>> If assert_no_collisions is True then only (1 bulk_create) will be 
>>> performed.
>>>
>>> def bulk_disassociate(
>>> M1_m2_set: ManyToManyDescriptor,
>>> m1_m2_tuples: 'List[Tuple[M1

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-10-02 Thread David Foster

Trac ticket created: https://code.djangoproject.com/ticket/30828

On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote:
>
> Hey David,
> I like this idea, while I don’t think the use case is common there have 
> been a few times where I’ve needed this and got around it by 
> creating/modifying the through model in bulk. Having a method that does 
> this would be good IMO.
>
> Unless anyone has strong opinions against this then can you make a ticket? 
>
> Tom
>
> On 30 Sep 2019, at 02:14, David Foster > 
> wrote:
>
> 
> Here is another API variation I might suggest:
>
> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
> # --- OR ---
> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False)
>
> This has the advantages of being more similar to the existing add() API 
> and not requiring a special function import.
>
> For bulk_disassociate() the analogous API would be:
>
> M1.m2_set.remove_pairs(*[(m1, m2), ...])
> # --- OR ---
> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
>
> - David
>
> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>>
>> Given the following example model:
>>
>> class M1(models.Model):
>> m2_set = models.ManyToManyField('M2')
>>
>> It is already possible to associate *one* M1 with *many* M2s with a 
>> single DB query:
>>
>> m1.m2_set.add(*m2s)
>>
>> However it's more difficult to associate *many* M1s with *many* M2s, 
>> particularly if you want to skip associations that already exist.
>>
>> # NOTE: Does NOT skip associations that already exist!
>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>> M1_M2 = M1.m2_set.through
>> M1_M2.objects.bulk_create([
>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>> for (m1_id, m2_id) in
>> m1_and_m2_id_tuples
>> ])
>>
>> What if we could do something like the following instead:
>>
>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>> # --- OR ---
>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>>
>> I propose to write and add a *bulk_associate()* method to Django. I also 
>> propose to add a paired *bulk_disassociate()* method.
>>
>> *1. Does this sound like a good idea in general?*
>>
>>
>> In more detail, I propose adding the specific APIs, importable from 
>> *django.db*:
>>
>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>>
>> def bulk_associate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>> *, assert_no_collisions: bool=True) -> None:
>> """
>> Creates many (M1, M2) associations with O(1) database queries.
>> 
>> If any requested associations already exist, then they will be left 
>> alone.
>> 
>> If you assert that none of the requested associations already exist,
>> you can pass assert_no_collisions=True to save 1 database query.
>> """
>> pass
>>
>> def bulk_associate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
>> *, assert_no_collisions: bool=True) -> None:
>> pass
>>
>> If assert_no_collisions is False then (1 filter) query and (1 
>> bulk_create) query will be performed.
>> If assert_no_collisions is True then only (1 bulk_create) will be 
>> performed.
>>
>> def bulk_disassociate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
>> """
>> Deletes many (M1, M2) associations with O(1) database queries.
>> """
>> pass
>>
>> def bulk_disassociate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
>> pass
>>
>> The database connection corresponding to the M1_M2 through-table will be 
>> used.
>>
>> *2. Any comments on the specific API or capabilities?*
>>
>>
>> If this sounds good I'd be happy to open an item on Trac and submit a PR.
>>
> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/49b45d05-836f-4512-91b8-8e4dbb55f6a4%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/49b45d05-836f-4512-91b8-8e4dbb55f6a4%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/a02a1a95-9da6-4212-8e79-595c60a2fa56%40googlegroups.com.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-10-01 Thread Tom Forbes

Hey David,
I like this idea, while I don’t think the use case is common there have been a 
few times where I’ve needed this and got around it by creating/modifying the 
through model in bulk. Having a method that does this would be good IMO.

Unless anyone has strong opinions against this then can you make a ticket? 

Tom

>> On 30 Sep 2019, at 02:14, David Foster  wrote:
> 
> Here is another API variation I might suggest:
> 
> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
> # --- OR ---
> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False)
> 
> This has the advantages of being more similar to the existing add() API and 
> not requiring a special function import.
> 
> For bulk_disassociate() the analogous API would be:
> 
> M1.m2_set.remove_pairs(*[(m1, m2), ...])
> # --- OR ---
> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
> 
> - David
> 
>> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>> Given the following example model:
>> 
>> class M1(models.Model):
>> m2_set = models.ManyToManyField('M2')
>> 
>> It is already possible to associate one M1 with many M2s with a single DB 
>> query:
>> 
>> m1.m2_set.add(*m2s)
>> 
>> However it's more difficult to associate many M1s with many M2s, 
>> particularly if you want to skip associations that already exist.
>> 
>> # NOTE: Does NOT skip associations that already exist!
>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>> M1_M2 = M1.m2_set.through
>> M1_M2.objects.bulk_create([
>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>> for (m1_id, m2_id) in
>> m1_and_m2_id_tuples
>> ])
>> 
>> What if we could do something like the following instead:
>> 
>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>> # --- OR ---
>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>> 
>> I propose to write and add a bulk_associate() method to Django. I also 
>> propose to add a paired bulk_disassociate() method.
>> 
>> 1. Does this sound like a good idea in general?
>> 
>> 
>> In more detail, I propose adding the specific APIs, importable from 
>> django.db:
>> 
>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>> 
>> def bulk_associate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>> *, assert_no_collisions: bool=True) -> None:
>> """
>> Creates many (M1, M2) associations with O(1) database queries.
>> 
>> If any requested associations already exist, then they will be left 
>> alone.
>> 
>> If you assert that none of the requested associations already exist,
>> you can pass assert_no_collisions=True to save 1 database query.
>> """
>> pass
>> 
>> def bulk_associate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
>> *, assert_no_collisions: bool=True) -> None:
>> pass
>> 
>> If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
>> query will be performed.
>> If assert_no_collisions is True then only (1 bulk_create) will be performed.
>> 
>> def bulk_disassociate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
>> """
>> Deletes many (M1, M2) associations with O(1) database queries.
>> """
>> pass
>> 
>> def bulk_disassociate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
>> pass
>> 
>> The database connection corresponding to the M1_M2 through-table will be 
>> used.
>> 
>> 2. Any comments on the specific API or capabilities?
>> 
>> 
>> If this sounds good I'd be happy to open an item on Trac and submit a PR.
> 
> -- 
> 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/49b45d05-836f-4512-91b8-8e4dbb55f6a4%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/A1F23375-5004-40D1-9B77-775E337CB53F%40tomforb.es.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-09-29 Thread David Foster

Here is another API variation I might suggest:

M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
# --- OR ---
M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False)

This has the advantages of being more similar to the existing add() API and 
not requiring a special function import.

For bulk_disassociate() the analogous API would be:

M1.m2_set.remove_pairs(*[(m1, m2), ...])
# --- OR ---
M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])

- David

On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>
> Given the following example model:
>
> class M1(models.Model):
> m2_set = models.ManyToManyField('M2')
>
> It is already possible to associate *one* M1 with *many* M2s with a 
> single DB query:
>
> m1.m2_set.add(*m2s)
>
> However it's more difficult to associate *many* M1s with *many* M2s, 
> particularly if you want to skip associations that already exist.
>
> # NOTE: Does NOT skip associations that already exist!
> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
> M1_M2 = M1.m2_set.through
> M1_M2.objects.bulk_create([
> M1_M2(m1_id=m1_id, m2_id=m2_id)
> for (m1_id, m2_id) in
> m1_and_m2_id_tuples
> ])
>
> What if we could do something like the following instead:
>
> bulk_associate(M1.m2_set, [(m1, m2), ...])
> # --- OR ---
> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>
> I propose to write and add a *bulk_associate()* method to Django. I also 
> propose to add a paired *bulk_disassociate()* method.
>
> *1. Does this sound like a good idea in general?*
>
>
> In more detail, I propose adding the specific APIs, importable from 
> *django.db*:
>
> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>
> def bulk_associate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]',
> *, assert_no_collisions: bool=True) -> None:
> """
> Creates many (M1, M2) associations with O(1) database queries.
> 
> If any requested associations already exist, then they will be left 
> alone.
> 
> If you assert that none of the requested associations already exist,
> you can pass assert_no_collisions=True to save 1 database query.
> """
> pass
>
> def bulk_associate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
> *, assert_no_collisions: bool=True) -> None:
> pass
>
> If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
> query will be performed.
> If assert_no_collisions is True then only (1 bulk_create) will be 
> performed.
>
> def bulk_disassociate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
> """
> Deletes many (M1, M2) associations with O(1) database queries.
> """
> pass
>
> def bulk_disassociate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
> pass
>
> The database connection corresponding to the M1_M2 through-table will be 
> used.
>
> *2. Any comments on the specific API or capabilities?*
>
>
> If this sounds good I'd be happy to open an item on Trac and submit a PR.
>

-- 
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/49b45d05-836f-4512-91b8-8e4dbb55f6a4%40googlegroups.com.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-09-26 Thread David Foster

Errata: The proposed default value for assert_no_collisions is False rather 
than True, for safety.

On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>
> Given the following example model:
>
> class M1(models.Model):
> m2_set = models.ManyToManyField('M2')
>
> It is already possible to associate *one* M1 with *many* M2s with a 
> single DB query:
>
> m1.m2_set.add(*m2s)
>
> However it's more difficult to associate *many* M1s with *many* M2s, 
> particularly if you want to skip associations that already exist.
>
> # NOTE: Does NOT skip associations that already exist!
> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
> M1_M2 = M1.m2_set.through
> M1_M2.objects.bulk_create([
> M1_M2(m1_id=m1_id, m2_id=m2_id)
> for (m1_id, m2_id) in
> m1_and_m2_id_tuples
> ])
>
> What if we could do something like the following instead:
>
> bulk_associate(M1.m2_set, [(m1, m2), ...])
> # --- OR ---
> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>
> I propose to write and add a *bulk_associate()* method to Django. I also 
> propose to add a paired *bulk_disassociate()* method.
>
> *1. Does this sound like a good idea in general?*
>
>
> In more detail, I propose adding the specific APIs, importable from 
> *django.db*:
>
> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>
> def bulk_associate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]',
> *, assert_no_collisions: bool=True) -> None:
> """
> Creates many (M1, M2) associations with O(1) database queries.
> 
> If any requested associations already exist, then they will be left 
> alone.
> 
> If you assert that none of the requested associations already exist,
> you can pass assert_no_collisions=True to save 1 database query.
> """
> pass
>
> def bulk_associate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
> *, assert_no_collisions: bool=True) -> None:
> pass
>
> If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
> query will be performed.
> If assert_no_collisions is True then only (1 bulk_create) will be 
> performed.
>
> def bulk_disassociate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
> """
> Deletes many (M1, M2) associations with O(1) database queries.
> """
> pass
>
> def bulk_disassociate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
> pass
>
> The database connection corresponding to the M1_M2 through-table will be 
> used.
>
> *2. Any comments on the specific API or capabilities?*
>
>
> If this sounds good I'd be happy to open an item on Trac and submit a PR.
>

-- 
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/74c15393-9312-48bc-ac06-a3d4360b3432%40googlegroups.com.

Feature idea: bulk_associate: Add ManyToMany relationships in bulk

2019-09-26 Thread David Foster

Given the following example model:

class M1(models.Model):
m2_set = models.ManyToManyField('M2')

It is already possible to associate *one* M1 with *many* M2s with a single 
DB query:

m1.m2_set.add(*m2s)

However it's more difficult to associate *many* M1s with *many* M2s, 
particularly if you want to skip associations that already exist.

# NOTE: Does NOT skip associations that already exist!
m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
M1_M2 = M1.m2_set.through
M1_M2.objects.bulk_create([
M1_M2(m1_id=m1_id, m2_id=m2_id)
for (m1_id, m2_id) in
m1_and_m2_id_tuples
])

What if we could do something like the following instead:

bulk_associate(M1.m2_set, [(m1, m2), ...])
# --- OR ---
bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])

I propose to write and add a *bulk_associate()* method to Django. I also 
propose to add a paired *bulk_disassociate()* method.

*1. Does this sound like a good idea in general?*


In more detail, I propose adding the specific APIs, importable from 
*django.db*:

M1 = TypeVar('M1', bound=Model)  # M1 extends Model
M2 = TypeVar('M2', bound=Model)  # M2 extends Model

def bulk_associate(
M1_m2_set: ManyToManyDescriptor,
m1_m2_tuples: 'List[Tuple[M1, M2]]',
*, assert_no_collisions: bool=True) -> None:
"""
Creates many (M1, M2) associations with O(1) database queries.

If any requested associations already exist, then they will be left 
alone.

If you assert that none of the requested associations already exist,
you can pass assert_no_collisions=True to save 1 database query.
"""
pass

def bulk_associate_ids(
M1_m2_set: ManyToManyDescriptor,
m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
*, assert_no_collisions: bool=True) -> None:
pass

If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
query will be performed.
If assert_no_collisions is True then only (1 bulk_create) will be performed.

def bulk_disassociate(
M1_m2_set: ManyToManyDescriptor,
m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
"""
Deletes many (M1, M2) associations with O(1) database queries.
"""
pass

def bulk_disassociate_ids(
M1_m2_set: ManyToManyDescriptor,
m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
pass

The database connection corresponding to the M1_M2 through-table will be 
used.

*2. Any comments on the specific API or capabilities?*


If this sounds good I'd be happy to open an item on Trac and submit a PR.

-- 
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/3ca80bdc-8bc9-4304-8723-6e23302e1364%40googlegroups.com.

Re: Queries about the project idea Improving the Less Popular Backends

2019-04-11 Thread Dingfan Zhao

Hello, 

Thanks for your reply. I will start contributing patches now. 

Regards,
Dingfan

-- 
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/a4dd1618-8d25-434e-b02a-0021d1255bb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queries about the project idea Improving the Less Popular Backends

2019-04-09 Thread Asif Saif Uddin

You are too late to propose the proposal for review. Now it's your call fix 
as many good issues related to your proposal so that the core mentors can 
gauge your ability to be selected for gsoc this year. if you could 
contribute some good patches you might be a very good candidate for gsoc 
next year with your contribution history and might get early helps to 
prepare a solid proposal.

good luck!

On Tuesday, April 9, 2019 at 10:05:23 PM UTC+6, Dingfan Zhao wrote:
>
> Hello, 
>
> Thanks for your reply! I am working on the proposal now since the deadline 
> is quite tight. I finished the proposal just now and hope you could give me 
> some advice on it. 
>
>
> https://docs.google.com/document/d/1tlGWuf_uBS-1GvxwMoSyyh5xUmB4b5gVg4vRFGaMDZg/edit
>
> I will start contributing to some issues during these days to convince 
> other contributors in the community, but maybe after the deadline for 
> submitting the proposal since the deadline is just 2 hours later :)
>
> Regards,
> Dingfan
>
> On Tuesday, 9 April 2019 09:57:52 UTC+8, Asif Saif Uddin wrote:
>>
>> yes, you can select some relevant issues which help to fix a much bigger 
>> problem. so try to understand the bigger ideas coming out of some of the 
>> related issues. deadline is very close. it would be better to have the 
>> draft submitted here and fix at least one or two related issues to convince 
>> the core team and the community that ypu are capable to complete what you 
>> are proposing.
>>
>> Cheers!
>>
>> Asif
>>
>> On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote:
>>>
>>> Hello guys, 
>>>
>>> I am year 4 students in Singapore and I would like to contribute to 
>>> Django in GSoC this summer. The project idea that I am interested in is 
>>> Improving the less popular backends. However, the project description is 
>>> kind of vague and I am not able to catch the exact requirements for this 
>>> project. 
>>>
>>> In my view, the key for this project is to build some features for less 
>>> popular backends to make it support equal operations with other backends. I 
>>> appreciate if someone can give me some advice. 
>>>
>>> For example, I did a search in Django raising ticket page and I set up 
>>> some filters: 
>>> https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id
>>>
>>> May I understand it like I would select some issues from these tickets 
>>> and solve them in order to fulfill this project idea? 
>>>
>>> Any advice is appreciated in advance! Thanks a lot. 
>>>
>>> Regards
>>>
>>

-- 
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/25cb899e-3aee-4123-a8b9-00434b47396e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queries about the project idea Improving the Less Popular Backends

2019-04-09 Thread Dingfan Zhao

Hello, 

Thanks for your reply! I am working on the proposal now since the deadline 
is quite tight. I finished the proposal just now and hope you could give me 
some advice on it. 

https://docs.google.com/document/d/1tlGWuf_uBS-1GvxwMoSyyh5xUmB4b5gVg4vRFGaMDZg/edit

I will start contributing to some issues during these days to convince 
other contributors in the community, but maybe after the deadline for 
submitting the proposal since the deadline is just 2 hours later :)

Regards,
Dingfan

On Tuesday, 9 April 2019 09:57:52 UTC+8, Asif Saif Uddin wrote:
>
> yes, you can select some relevant issues which help to fix a much bigger 
> problem. so try to understand the bigger ideas coming out of some of the 
> related issues. deadline is very close. it would be better to have the 
> draft submitted here and fix at least one or two related issues to convince 
> the core team and the community that ypu are capable to complete what you 
> are proposing.
>
> Cheers!
>
> Asif
>
> On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote:
>>
>> Hello guys, 
>>
>> I am year 4 students in Singapore and I would like to contribute to 
>> Django in GSoC this summer. The project idea that I am interested in is 
>> Improving the less popular backends. However, the project description is 
>> kind of vague and I am not able to catch the exact requirements for this 
>> project. 
>>
>> In my view, the key for this project is to build some features for less 
>> popular backends to make it support equal operations with other backends. I 
>> appreciate if someone can give me some advice. 
>>
>> For example, I did a search in Django raising ticket page and I set up 
>> some filters: 
>> https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id
>>
>> May I understand it like I would select some issues from these tickets 
>> and solve them in order to fulfill this project idea? 
>>
>> Any advice is appreciated in advance! Thanks a lot. 
>>
>> Regards
>>
>

-- 
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/4da2a1cb-43fe-426b-be33-164ae6aaa4f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queries about the project idea Improving the Less Popular Backends

2019-04-08 Thread Asif Saif Uddin

yes, you can select some relevant issues which help to fix a much bigger 
problem. so try to understand the bigger ideas coming out of some of the 
related issues. deadline is very close. it would be better to have the 
draft submitted here and fix at least one or two related issues to convince 
the core team and the community that ypu are capable to complete what you 
are proposing.

Cheers!

Asif

On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote:
>
> Hello guys, 
>
> I am year 4 students in Singapore and I would like to contribute to Django 
> in GSoC this summer. The project idea that I am interested in is Improving 
> the less popular backends. However, the project description is kind of 
> vague and I am not able to catch the exact requirements for this project. 
>
> In my view, the key for this project is to build some features for less 
> popular backends to make it support equal operations with other backends. I 
> appreciate if someone can give me some advice. 
>
> For example, I did a search in Django raising ticket page and I set up 
> some filters: 
> https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id
>
> May I understand it like I would select some issues from these tickets and 
> solve them in order to fulfill this project idea? 
>
> Any advice is appreciated in advance! Thanks a lot. 
>
> Regards
>

-- 
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/449e90b3-9665-4bdb-b8e6-a5f702587ae2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Queries about the project idea Improving the Less Popular Backends

2019-04-08 Thread Dingfan Zhao

Hello guys,

I am year 4 students in Singapore and I would like to contribute to Django
in GSoC this summer. The project idea that I am interested in is Improving
the less popular backends. However, the project description is kind of
vague and I am not able to catch the exact requirements for this project.

In my view, the key for this project is to build some features for less
popular backends to make it support equal operations with other backends. I
appreciate if someone can give me some advice.

For example, I did a search in Django raising ticket page and I set up some
filters:
https://code.djangoproject.com/query?status=new=Database+layer+(models%2C+ORM)=id=summary=status=owner=type=component=version=1=id

May I understand it like I would select some issues from these tickets and
solve them in order to fulfill this project idea?

Any advice is appreciated in advance! Thanks a lot.

Regards

--
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/57e26ea3-8b6d-4d9f-96b5-04c3e487e085%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 19 PROPOSAL IDEA

2019-03-18 Thread Carlton Gibson

Hi Chinmay. 

Thanks for your interest. A 13 year old ticket would certainly be a 
nice-to-close. 

Some quick thoughts: 


   1. We're close to the deadline here, so can you turn this into a final 
   proposal? (Look at the example for a previous 
   year: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 — we need 
   something like this.) 
   2. You've begun well telling us who you are. But tell us more in your 
   proposal. We don't know you already and need to be confident that you'd be 
   likely to succeed in your project. 
   3. We already use select2 for the autocomplete in the 
   admin. https://select2.org. This would integrate well with that by the 
   looks of it. 
   4. Would this take 12 weeks? If not there are lots of Admin tickets 
   
<https://code.djangoproject.com/query?status=assigned=new=contrib.admin=Accepted=id=summary=status=owner=type=component=version=1=id>
 — 
   I'm sure we can help find some, but any related target ticket you identify 
   are all for the good. 

Time is short here. :)

Kind Regards,

Carlton


On Thursday, 14 March 2019 01:03:33 UTC+1, Chinmay Relkar wrote:
>
> Hi,
>My name is Chinmay Relkar. I'm a final year undergrad from India. 
> This is about my GSOC proposal idea. 
>
>While playing with django, I've always come across the absence of 
> bidirectional ManyToMany feature ticketed at
> *code.djangoproject.com/ticket/897 
> <http://code.djangoproject.com/ticket/897>*. 
> I would like to work on this feature as a part of the GSOC program. 
> 
>To me this feature feels a bit small for a 12 week program. So 
> here's something I would like to add on:
>
> While adding a Model item in the admin interface with a ManyToMany 
> field, we get a MultiSelectWindow to choose multiple items of the related 
> model. This UI isn't very intuitive.
> 
> Taking inspiration from the Chips Component defined in Material Design 
> Guidelines at *https://material.io/design/components/chips.html 
> <https://material.io/design/components/chips.html>* I would like to 
> implement FilterChip for the same multi select window. The example of which 
> is attached below. 
>
> This is not a final proposal. I hope I'm not too late to share this here. 
>
> I'm eagerly waiting for a response of feedback and suggestions. 
>
> About my experience with Django, I've been working with it for past 2 
> years. Completed a total of 3 projects, one of which is live at *acsinet.net 
> <http://acsinet.net/>* with a heavily customised admin panel.
>
> Talking about my level of expertise, I'm not a master to be true. But I 
> can customise any component of Django according to the stated requirements. 
> This is a very rough sketch of the proposal. Any suggestions, remarks or 
> comments will be of great help. 
>
> Hoping to get a feedback soon. 
>
> Regards,
> Chinmay Relkar
>

-- 
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/93cfee50-72be-4068-b700-dccc5d932b88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSOC 19 PROPOSAL IDEA

2019-03-13 Thread Chinmay Relkar

Hi,
My name is Chinmay Relkar. I'm a final year undergrad from India.
This is about my GSOC proposal idea.

While playing with django, I've always come across the absence of
bidirectional ManyToMany feature ticketed at
*code.djangoproject.com/ticket/897
<http://code.djangoproject.com/ticket/897>*.
I would like to work on this feature as a part of the GSOC program.

To me this feature feels a bit small for a 12 week program. So
here's something I would like to add on:

While adding a Model item in the admin interface with a ManyToMany
field, we get a MultiSelectWindow to choose multiple items of the related
model. This UI isn't very intuitive.

Taking inspiration from the Chips Component defined in Material Design
Guidelines at *https://material.io/design/components/chips.html
<https://material.io/design/components/chips.html>* I would like to
implement FilterChip for the same multi select window. The example of which
is attached below.

This is not a final proposal. I hope I'm not too late to share this here.

I'm eagerly waiting for a response of feedback and suggestions.

About my experience with Django, I've been working with it for past 2
years. Completed a total of 3 projects, one of which is live at *acsinet.net
<http://acsinet.net/>* with a heavily customised admin panel.

Talking about my level of expertise, I'm not a master to be true. But I can
customise any component of Django according to the stated requirements.
This is a very rough sketch of the proposal. Any suggestions, remarks or
comments will be of great help.

Hoping to get a feedback soon.

Regards,
Chinmay Relkar

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

Re: GSoC 2019 Project Idea

2019-03-03 Thread PARTH PATIL

Hey Carlton,

Thanks for your feedback.
I would try to think of something which is more inclined towards core 
functionality of Django :)

On Monday, March 4, 2019 at 1:52:39 AM UTC+5:30, Carlton Gibson wrote:
>
> Hi Parth. 
>
> I'm guessing this would be out of scope for Django: it's sounds like the 
> sort of functionality that we prefer to live in third-party apps, rather 
> than in Django itself. 
> (It sounds like a good enough idea — there are plenty of Jekyll, or other 
> static, sites out there, but just not something for core.) 
>
> As I just posted elsewhere, I'm looking to work on the GSoC stuff over the 
> next couple of weeks. 
>
> Kind Regards,
>
> Carlton
>
>
> On Sunday, 3 February 2019 11:04:07 UTC+1, PARTH PATIL wrote:
>>
>> Hey, I had a project idea for GSoC.
>> I wanted to make a tool which will help to port static projects like 
>> Jekyll to Django directly.
>> I am still thinking about the details of the idea.
>>
>> But I want to know:
>>
>>- is this idea feasible/useful?
>>    - Does there already exist a similar tool for this?
>>- Is this a good idea for GSoC?
>>
>> I got this idea last year when I was working on my club website which was 
>> written using Jekyll and I had to port it to Django framework since it was 
>> going to be hosted on our college server which had Django backend.
>> The problem was we constantly had to update the website with post, so I 
>> was just left with the option to rewrite all the code natively in Django. 
>> That's why I thought of making a tool which will take a Jekyll project and 
>> convert it to Django app, with proper views and models etc.
>>
>>  
>>
>

-- 
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/92087e41-680b-4662-b600-db9528e9ae13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2019 Project Idea

2019-03-03 Thread Carlton Gibson

Hi Parth. 

I'm guessing this would be out of scope for Django: it's sounds like the 
sort of functionality that we prefer to live in third-party apps, rather 
than in Django itself. 
(It sounds like a good enough idea — there are plenty of Jekyll, or other 
static, sites out there, but just not something for core.) 

As I just posted elsewhere, I'm looking to work on the GSoC stuff over the 
next couple of weeks. 

Kind Regards,

Carlton


On Sunday, 3 February 2019 11:04:07 UTC+1, PARTH PATIL wrote:
>
> Hey, I had a project idea for GSoC.
> I wanted to make a tool which will help to port static projects like 
> Jekyll to Django directly.
> I am still thinking about the details of the idea.
>
> But I want to know:
>
>- is this idea feasible/useful?
>- Does there already exist a similar tool for this?
>- Is this a good idea for GSoC?
>
> I got this idea last year when I was working on my club website which was 
> written using Jekyll and I had to port it to Django framework since it was 
> going to be hosted on our college server which had Django backend.
> The problem was we constantly had to update the website with post, so I 
> was just left with the option to rewrite all the code natively in Django. 
> That's why I thought of making a tool which will take a Jekyll project and 
> convert it to Django app, with proper views and models etc.
>
>  
>

-- 
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/6552d234-0ea4-4729-a7d6-8e5688bdb736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC 2019 Project Idea

2019-02-03 Thread PARTH PATIL

Hey, I had a project idea for GSoC.
I wanted to make a tool which will help to port static projects like Jekyll 
to Django directly.
I am still thinking about the details of the idea.

But I want to know:

   - is this idea feasible/useful?
   - Does there already exist a similar tool for this?
   - Is this a good idea for GSoC?

I got this idea last year when I was working on my club website which was 
written using Jekyll and I had to port it to Django framework since it was 
going to be hosted on our college server which had Django backend.
The problem was we constantly had to update the website with post, so I was 
just left with the option to rewrite all the code natively in Django. 
That's why I thought of making a tool which will take a Jekyll project and 
convert it to Django app, with proper views and models etc.

 

-- 
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/92a5f672-4ab3-41a9-a93c-38422a121794%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Idea

2019-02-03 Thread PARTH PATIL

Hey, can you elaborate on what your idea is?

On Thursday, January 31, 2019 at 4:54:36 PM UTC+5:30, gaurav jain wrote:
>
> from django.db import models
> from django.contrib.auth.models import User
>
> class CommenInfo(models.Model):
> archived = models.BooleanField(default=False)
> created_at = models.DateTimeField(auto_now_add=True)
> updated_at = models.DateTimeField(auto_now=True)
>
> def delete(self):
> self.archived = True
> super().save()
>
> class Meta:
> abstract = True
> class Team(CommenInfo):
> pass
>
>
>

-- 
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/02ed1aa7-c22a-4588-8b3e-5815f59a5e74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC Idea

2019-01-31 Thread gaurav jain

from django.db import models
from django.contrib.auth.models import User

class CommenInfo(models.Model):
archived = models.BooleanField(default=False)
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)

def delete(self):
self.archived = True
super().save()

class Meta:
abstract = True
class Team(CommenInfo):
pass


-- 
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/73471eba-70a9-416d-8877-1d3c94555fe4%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

2018-11-07 Thread 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

2018-11-07 Thread 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

2018-11-06 Thread 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

2018-11-06 Thread 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

2018-11-05 Thread 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

2018-11-05 Thread 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

2018-11-05 Thread 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

2018-11-01 Thread '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
>>>

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

2018-11-01 Thread '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 mul

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

2018-11-01 Thread 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

2018-10-31 Thread 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

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

2018-10-31 Thread 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

2018-10-31 Thread 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

2018-10-31 Thread 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.

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

2018-10-31 Thread Antwan

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/b30b52f4-479b-4342-885b-2ce78af6f70e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-04-17 Thread David Seddon

Hi JP,

That's a good point, sorry I didn't make it clear.

The fork is installed from within the requirements file but you can also 
see it here, on the ticket_27923 
branch: https://github.com/seddonym/django/tree/ticket_27923

I've updated the README to help.

I'd be interested to hear if anyone thinks it's worth me making a pull 
request for this.

David

On Sunday, 16 April 2017 23:59:31 UTC+1, jp...@yourlabs.org wrote:
>
> Hello David,
>
> Is it possible to try to use it as part of the Django fork you mention, 
> instead of the app ?
>
> I couldn't find any link on your github profile, your website and google 
> but perhaps I've missed it.
>
> Thanks !
>
> Best
> <3
>

-- 
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/d4904940-91be-4f65-a16d-d39de1ffc382%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-04-16 Thread jpic

Hello David,

Is it possible to try to use it as part of the Django fork you mention, 
instead of the app ?

I couldn't find any link on your github profile, your website and google 
but perhaps I've missed it.

Thanks !

Best
<3

-- 
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/36fb761d-76cf-4e23-a0e2-ca6d315d1182%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

2017-03-19 Thread Asif Saifuddin

I have been working to understand the complexity for few months.

I will try to share my findings very soon. Lets see where I can reach
before the deadline.

On Mon, Mar 20, 2017 at 12:26 AM, Tim Graham <timogra...@gmail.com> wrote:

> It could be a suitable project, however, it's too late to develop a
> proposal of that complexity for this summer. A prospective student would
> need to demonstrate significant understanding of the ORM before I would
> advise them to tackle that topic.
>
> On Sunday, March 19, 2017 at 1:16:02 PM UTC-4, Asif Saifuddin wrote:
>>
>> Hi,
>>
>> I have been working on understanding previous works related to composite
>> ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on
>> Fields API/RelationField API improvement/clean ups etc.
>>
>> Is it a good idea to prepare something like this for gsoc this year?
>>
>> I have also trying to prepare a dep for my plans of improvements.
>>
>> Thanks,
>>
>> Asif
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-developers/EWJdT4EVqbg/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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/6a60f20a-8b15-49f4-9c15-
> ea7c17003bde%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6a60f20a-8b15-49f4-9c15-ea7c17003bde%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CAKAqTgpvV8y%2ByMUOKkBPvvbQJW9nc2sDsmY3B1BSAD-muE23kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

2017-03-19 Thread Tim Graham

It could be a suitable project, however, it's too late to develop a 
proposal of that complexity for this summer. A prospective student would 
need to demonstrate significant understanding of the ORM before I would 
advise them to tackle that topic.

On Sunday, March 19, 2017 at 1:16:02 PM UTC-4, Asif Saifuddin wrote:
>
> Hi,
>
> I have been working on understanding previous works related to composite 
> ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on 
> Fields API/RelationField API improvement/clean ups etc.
>
> Is it a good idea to prepare something like this for gsoc this year?
>
> I have also trying to prepare a dep for my plans of improvements.
>
> Thanks,
>
> Asif
>

-- 
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/6a60f20a-8b15-49f4-9c15-ea7c17003bde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

2017-03-19 Thread Asif Saifuddin

Hi,

I have been working on understanding previous works related to composite 
ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on 
Fields API/RelationField API improvement/clean ups etc.

Is it a good idea to prepare something like this for gsoc this year?

I have also trying to prepare a dep for my plans of improvements.

Thanks,

Asif

-- 
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/372c3bc6-c618-43a7-aed7-da099c63e31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-03-14 Thread David Seddon

I've put together a brief proof of concept here:

https://github.com/seddonym/formsignals

It demonstrates what you could do with post_init, post_clean and post_save 
signals, which I've also implemented in a fork of Django (no test coverage 
or documentation yet though).

The concept it demonstrates is two apps, a blog app and a priority app. 
 The priority app is a pluggable app, unknown to the blog app, that allows 
users to mark blog entries as 'priority', providing they also put the word 
"Priority" in the title.  (Bizarre example but I wanted to demonstrate why 
you might want to use post_clean.)

The main place to look is in the receivers file here: 
https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py

I don't think this is a nice as subclassing the form in the first place, 
but that's not an option unless the maintainer of the blog app has exposed 
a way of hooking into it.  As you can see you get a fair amount of power to 
encapsulate different logic between apps with very little code.

I think the use cases for pre_init, pre_clean and pre_save are more niche, 
but it probably makes sense to include them for completeness.

Would value any comments!

On Monday, 6 March 2017 19:08:29 UTC, David Seddon wrote:
>
> Hi all,
>
> One thing I've always found challenging with Django is to adjust the 
> functionality of forms from other apps.  An example might be to add an 
> extra field to a login form provided by a third party module.
>
> What I end up doing is often overriding the urlconf, view and form class. 
>  Or, worse, monkey patching the form class.
>
> A much nicer way to do this would be to add a few well chosen signals to 
> forms.
>
> Potential ones could be:
>
> - post_init
> - post_clean
> - post_save (for ModelForms)
>
> I'd be happy to do a pull request for this, but just wondered what people 
> think.
>
> David
>

-- 
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/eb1dd68c-7006-4141-bace-045b87562f18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-03-10 Thread Aymeric Augustin

Hello,

> On 10 Mar 2017, at 10:25, Florian Apolloner  wrote:
> 
> On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote:
> What are the next steps?  Shall I create a pull request, or does this need 
> more consensus first?
> 
> Imo absolutely more consensus, especially (to minimize the work for you), 
> please do not just suggest the signals but also their signatures and also 
> outline usecases for each of them. Once you outline the signatures it will be 
> easier for others to understand what you can do with them etc…

I suspect there hasn't been much feedback because people have been used to 
doing without form signals. My own reaction was more a knee-jerk about signals 
than anything else.

The justification you offered made sense, but was terse. If you had the time to 
write down the use cases and to justify the design of the API in a DEP, that 
could help a lot (but I'm not saying this is a prerequisite, for fear of 
sounding like I'm resorting to bureaucracy to block changes I'm not fully 
comfortable with).

Best regards,

-- 
Aymeric.

-- 
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/F7AAF2CE-0F4E-4230-B450-F7CF2AF6083C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-03-10 Thread Florian Apolloner

On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote:
>
> What are the next steps?  Shall I create a pull request, or does this need 
> more consensus first?
>

Imo absolutely more consensus, especially (to minimize the work for you), 
please do not just suggest the signals but also their signatures and also 
outline usecases for each of them. Once you outline the signatures it will 
be easier for others to understand what you can do with them etc…

-- 
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/d9dee51f-7db4-4572-a99c-a874e8686f0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-03-10 Thread David Seddon

I've created a ticket for this 
here: https://code.djangoproject.com/ticket/27923#ticket

What are the next steps?  Shall I create a pull request, or does this need 
more consensus first?

David

On Wednesday, 8 March 2017 17:46:12 UTC, Melvyn Sopacua wrote:
>
> On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote:
>
> > On Monday 06 March 2017 10:10:41 David Seddon wrote:
>
> > > Hi all,
>
> > > 
>
> > > One thing I've always found challenging with Django is to adjust the
>
> > > functionality of forms from other apps. An example might be to add
>
> > > an extra field to a login form provided by a third party module.
>
> > > 
>
> > > What I end up doing is often overriding the urlconf, view and form
>
> > > class. Or, worse, monkey patching the form class.
>
> > > 
>
> > > A much nicer way to do this would be to add a few well chosen
>
> > > signals
>
> > > to forms.
>
> > > 
>
> > > Potential ones could be:
>
> > > 
>
> > > - post_init
>
> > 
>
> > Putting in a +1 and use case for pre_init: Inject dynamically
>
> > generated form.prefix.
>
> > 
>
> > Right now I have to inject PrefixedFormView in every view using it and
>
> > carefully watch my mro of already complex views.
>
> > 
>
> > Use case is having several modals containing forms on a single page
>
> > ("Edit this", "Add related", "New this"). They need to be prefixed to
>
> > deal with naming conflicts since id_{fieldname} will not be page
>
> > unique anymore.
>
> > 
>
> > With the signal, I can do away with the view mixin and the WrappedForm
>
> > is solely responsible for it.
>
> > I have no preference for the technology used (signal, hook, injection,
>
> > new buzzword), as long as the net result is that the object creating
>
> > the prefix can handle the prefix for all views.
>
> > 
>
> > Is there a ticket yet?
>
> > 
>
>  
>
> Apologies for the formatting.
>
> https://gist.github.com/melvyn-sopacua/dbf3c8f71023d6fc261131cb0a851f58
>
>  
>
>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
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/57a6f703-9498-450e-ab02-361651683c55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

2017-03-08 Thread Melvyn Sopacua

On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote:
> On Monday 06 March 2017 10:10:41 David Seddon wrote:
> > Hi all,
> > 
> > One thing I've always found challenging with Django is to adjust the
> > functionality of forms from other apps.  An example might be to add
> > an extra field to a login form provided by a third party module.
> > 
> > What I end up doing is often overriding the urlconf, view and form
> > class. Or, worse, monkey patching the form class.
> > 
> > A much nicer way to do this would be to add a few well chosen
> > signals
> > to forms.
> > 
> > Potential ones could be:
> > 
> > - post_init
> 
> Putting in a +1 and use case for pre_init: Inject dynamically
> generated form.prefix.
> 
> Right now I have to inject PrefixedFormView in every view using it and
> carefully watch my mro of already complex views.
> 
> Use case is having several modals containing forms on a single page
> ("Edit this", "Add related", "New this"). They need to be prefixed to
> deal with naming conflicts since id_{fieldname} will not be page
> unique anymore.
> 
> With the signal, I can do away with the view mixin and the WrappedForm
> is solely responsible for it.
> I have no preference for the technology used (signal, hook, injection,
> new buzzword), as long as the net result is that the object creating
> the prefix can handle the prefix for all views.
> 
> Is there a ticket yet?
> 

Apologies for the formatting.
https://gist.github.com/melvyn-sopacua/dbf3c8f71023d6fc261131cb0a851f58


-- 
Melvyn Sopacua

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

1 2 3 4 >

1 - 100 of 341 matches

Mail list logo