Feature idea

[Bruno Ribeiro da Silva]

Hello everyone,

I have this simple idea that I think django could benefit from, which would
be the option to create a user by an invitation from the django admin page.
So the person who is creating a new user doesn't have to type a password
neither a username for this new user. He would only fill a form with an
email that the invitation would be sent to. Something like a reset password
link but to add a new user.

Do you think it would be useful? That would be accepted as a PR for some
version in the future? What are your thoughts?

I would like to implement it and contribute to django, but I need feedback
from you guys.


Thanks!

-- 
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

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

Feature idea

[Dj Gilcrease]

There are currently several modules / apps that require auto discovery
based on whats listed in INSTALLED_APPS. admin, django_nav, and the
proposed startup.py and I know one or two other apps that use similar
methods but cannot remember their names off the top of my head.

I would like to propose a new setting AUTODISCOVER, an iterable of
module names to automatically load from each INSTALLED_APP after the
settings have been initialized. This would default to

AUTODISCOVER = (,)
_REQUIRED_AUTODISCOVER = ('startup',) #Assuming the startup.py
proposal is accepted

_REQUIRED_AUTODISCOVER is a separate setting in default_settings.py
that is combined with AUTODISCOVER during settings initialization

AUTODISCOVER = _REQUIRED_AUTODISCOVER + AUTODISCOVER

which will ensure the required auto discover modules are processed
first by the new autodiscover module

Currently each app / module that needs to be autodiscovered in some
way needs to re-implement something very similar to the admin
autodiscover @ 
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/__init__.py

I think the new module should be @ django.core.autodiscover, look like
http://dpaste.com/hold/201868/ and be loaded immediately after
settings initialization.

Obviously for backwards compatibility the current django.contrib.admin
autodiscover needs to remain and function as it did, but should be
modified to look like http://dpaste.com/hold/201874/ to prevent the
admin from attempting to register itself twice if admin is already
being loaded by the new autodiscover method.


Dj Gilcrease

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

Re: Feature idea

[Tim Graham]

I don't think this registration model is common on most websites.

On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva 
wrote:
>
> Hello everyone,
>
> I have this simple idea that I think django could benefit from, which 
> would be the option to create a user by an invitation from the django admin 
> page. So the person who is creating a new user doesn't have to type a 
> password neither a username for this new user. He would only fill a form 
> with an email that the invitation would be sent to. Something like a reset 
> password link but to add a new user.
>
> Do you think it would be useful? That would be accepted as a PR for some 
> version in the future? What are your thoughts?
>
> I would like to implement it and contribute to django, but I need feedback 
> from you guys.
>
>
> Thanks!
>
> -- 
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>

-- 
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/2c949269-59f5-4332-8803-c2958f789336%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Aymeric Augustin]

Hello,

I wouldn’t dismiss the idea so quickly. Adding staff users from your company is 
a fairly common use case.

Currently you have to email them a password and ask them to change it. This 
doesn’t set a good example.

The better solution is SSO with the corporate directory (often ActiveDirectory 
or Google Apps), but not every project has taken the time to configure that.

Best regards,

-- 
Aymeric.

> On 16 Nov 2016, at 20:59, Tim Graham  wrote:
> 
> I don't think this registration model is common on most websites.
> 
> On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva 
> wrote:
> Hello everyone,
> 
> I have this simple idea that I think django could benefit from, which would 
> be the option to create a user by an invitation from the django admin page. 
> So the person who is creating a new user doesn't have to type a password 
> neither a username for this new user. He would only fill a form with an email 
> that the invitation would be sent to. Something like a reset password link 
> but to add a new user.
> 
> Do you think it would be useful? That would be accepted as a PR for some 
> version in the future? What are your thoughts?
> 
> I would like to implement it and contribute to django, but I need feedback 
> from you guys.
> 
> 
> Thanks!
> 
> -- 
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
> 
> -- 
> 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/2c949269-59f5-4332-8803-c2958f789336%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/A7A9A23F-24C3-495D-93C4-12A9B859E9FC%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Anthony King]

Sending a link to set a password isn't much better.
Perhaps a way to force a password change on login would be better, which
has more use elsewhere, such as being able to periodically force password
changes

On 16 Nov 2016 8:13 p.m., "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I wouldn’t dismiss the idea so quickly. Adding staff users from your
> company is a fairly common use case.
>
> Currently you have to email them a password and ask them to change it.
> This doesn’t set a good example.
>
> The better solution is SSO with the corporate directory (often
> ActiveDirectory or Google Apps), but not every project has taken the time
> to configure that.
>
> Best regards,
>
> --
> Aymeric.
>
> On 16 Nov 2016, at 20:59, Tim Graham  wrote:
>
> I don't think this registration model is common on most websites.
>
> On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da
> Silva wrote:
>>
>> Hello everyone,
>>
>> I have this simple idea that I think django could benefit from, which
>> would be the option to create a user by an invitation from the django admin
>> page. So the person who is creating a new user doesn't have to type a
>> password neither a username for this new user. He would only fill a form
>> with an email that the invitation would be sent to. Something like a reset
>> password link but to add a new user.
>>
>> Do you think it would be useful? That would be accepted as a PR for some
>> version in the future? What are your thoughts?
>>
>> I would like to implement it and contribute to django, but I need
>> feedback from you guys.
>>
>>
>> Thanks!
>>
>> --
>> Bruno Ribeiro da Silva
>> Python Dev and Homebrewer!
>>
>
> --
> 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/2c949269-59f5-4332-8803-
> c2958f789336%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/A7A9A23F-24C3-495D-93C4-
> 12A9B859E9FC%40polytechnique.org
> 
> .
> 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/CALs0z1bNRW072KZNJkkxiU3wjOfELZZ0fP51DJUWiBSX64A%2Bow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Aymeric Augustin]

Hello,

> On 16 Nov 2016, at 21:22, Anthony King  wrote:
> Sending a link to set a password isn't much better.
> 
The cardinal rule of passwords is “you must be the only person who knows your 
password”. This means never writing it down anywhere, except in a proper 
password manager, and never telling it to anyone, *even* your IT staff — to 
fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with knowing 
the user's password. Disregarding their own guidelines sets a poor example and 
reduces their credibility about password management in general.

Of course, on most Django websites, someone who can create a staff user can 
also change the user’s password — it’s rare to give the “create user” but not 
the “change user” permission. I’m not making a technical argument here, I’m 
thinking of IT literacy and educating users.

> Perhaps a way to force a password change on login would be better, which has 
> more use elsewhere, such as being able to periodically force password changes

Forcing a password change on login is another interesting idea to solve this 
problem. That’s what ActiveDirectory has to do, because OSes don’t have the 
same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password 
rotation. Django solved password validation recently; it could solve password 
rotation next. (Note that password rotation is controversial because it forces 
users to choose weak passwords with a basic rotation scheme like putting month 
number at the end, instead of storing strong random password in a password 
manager. Trade-offs.)

I still think a simple solution hooking into the current password reset 
mechanism, just with a different email template, could be a quick security win 
for a lot of Django sites. I’d encourage people to use it if it existed.

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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Curtis Maloney]

My solution to the "initial password problem" is to send a password 
reset token first...


And Django has this built in, handily :)

http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/

It would be very easy to use the same approach for an "invite" 
registration pattern.


--
C


On 17/11/16 19:38, Aymeric Augustin wrote:

Hello,


On 16 Nov 2016, at 21:22, Anthony King mailto:anthonydk...@gmail.com>> wrote:

Sending a link to set a password isn't much better.


The cardinal rule of passwords is “you must be the only person who knows
your password”. This means never writing it down anywhere, except in a
proper password manager, and never telling it to anyone, *even* your IT
staff — to fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with
knowing the user's password. Disregarding their own guidelines sets a
poor example and reduces their credibility about password management in
general.

Of course, on most Django websites, someone who can create a staff user
can also change the user’s password — it’s rare to give the “create
user” but not the “change user” permission. I’m not making a technical
argument here, I’m thinking of IT literacy and educating users.


Perhaps a way to force a password change on login would be better,
which has more use elsewhere, such as being able to periodically force
password changes


Forcing a password change on login is another interesting idea to solve
this problem. That’s what ActiveDirectory has to do, because OSes don’t
have the same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password
rotation. Django solved password validation recently; it could solve
password rotation next. (Note that password rotation is controversial
because it forces users to choose weak passwords with a basic rotation
scheme like putting month number at the end, instead of storing strong
random password in a password manager. Trade-offs.)

I still think a simple solution hooking into the current password reset
mechanism, just with a different email template, could be a quick
security win for a lot of Django sites. I’d encourage people to use it
if it existed.

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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
.
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/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Bruno Ribeiro da Silva]

Guys,

Thanks for the feedback. My initial thought was to have a more complete
approach to this problem, there is always the case that the admin who is
creating the user doesn't know the person's full name and/or what to use
for username.

This is the flow that I had in mind:

- Admin goes to user list page
- Next to the "ADD USER +" button we would have an "INVITE NEW USER" button
- At the invite page the admin would only have to insert the person's email
address. Optionally he could check if this new user would be a super user
and/or staff.
- At the invitation (link sent by email) page the user would be able to
fill the rest of the information, like: username, first name, last name and
password.

I know this approach requires more work but I think it would be nice to
free the admin from the burden of having to fill all necessary information.


2016-11-17 6:44 GMT-02:00 Curtis Maloney :

> My solution to the "initial password problem" is to send a password reset
> token first...
>
> And Django has this built in, handily :)
>
> http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/
>
> It would be very easy to use the same approach for an "invite"
> registration pattern.
>
> --
> C
>
>
> On 17/11/16 19:38, Aymeric Augustin wrote:
>
>> Hello,
>>
>> On 16 Nov 2016, at 21:22, Anthony King >> > wrote:
>>>
>>> Sending a link to set a password isn't much better.
>>>
>>> The cardinal rule of passwords is “you must be the only person who knows
>> your password”. This means never writing it down anywhere, except in a
>> proper password manager, and never telling it to anyone, *even* your IT
>> staff — to fight social engineering attacks.
>>
>> Sending a password in clear over email means the IT staff is okay with
>> knowing the user's password. Disregarding their own guidelines sets a
>> poor example and reduces their credibility about password management in
>> general.
>>
>> Of course, on most Django websites, someone who can create a staff user
>> can also change the user’s password — it’s rare to give the “create
>> user” but not the “change user” permission. I’m not making a technical
>> argument here, I’m thinking of IT literacy and educating users.
>>
>> Perhaps a way to force a password change on login would be better,
>>> which has more use elsewhere, such as being able to periodically force
>>> password changes
>>>
>>
>> Forcing a password change on login is another interesting idea to solve
>> this problem. That’s what ActiveDirectory has to do, because OSes don’t
>> have the same password reset possibilities that web applications have.
>>
>> However I think that would mean solving the general problem of password
>> rotation. Django solved password validation recently; it could solve
>> password rotation next. (Note that password rotation is controversial
>> because it forces users to choose weak passwords with a basic rotation
>> scheme like putting month number at the end, instead of storing strong
>> random password in a password manager. Trade-offs.)
>>
>> I still think a simple solution hooking into the current password reset
>> mechanism, just with a different email template, could be a quick
>> security win for a lot of Django sites. I’d encourage people to use it
>> if it existed.
>>
>> 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/76AE3F1E
>> -6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
>> > E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org?utm_
>> medium=email&utm_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/ms
> gid/django-developers/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

-- 
You received this messag

Re: Feature idea

[Aymeric Augustin]

Hello Bruno,

This is getting quite specific. In that case, I think a third-party, pluggable 
application is a better way to do this.

Best regards,

-- 
Aymeric.

> On 17 Nov 2016, at 13:38, Bruno Ribeiro da Silva  
> wrote:
> 
> Guys,
> 
> Thanks for the feedback. My initial thought was to have a more complete 
> approach to this problem, there is always the case that the admin who is 
> creating the user doesn't know the person's full name and/or what to use for 
> username.
> 
> This is the flow that I had in mind:
> 
> - Admin goes to user list page
> - Next to the "ADD USER +" button we would have an "INVITE NEW USER" button
> - At the invite page the admin would only have to insert the person's email 
> address. Optionally he could check if this new user would be a super user 
> and/or staff.
> - At the invitation (link sent by email) page the user would be able to fill 
> the rest of the information, like: username, first name, last name and 
> password.
> 
> I know this approach requires more work but I think it would be nice to free 
> the admin from the burden of having to fill all necessary information.
> 
> 
> 2016-11-17 6:44 GMT-02:00 Curtis Maloney  >:
> My solution to the "initial password problem" is to send a password reset 
> token first...
> 
> And Django has this built in, handily :)
> 
> http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/ 
> 
> 
> It would be very easy to use the same approach for an "invite" registration 
> pattern.
> 
> --
> C
> 
> 
> On 17/11/16 19:38, Aymeric Augustin wrote:
> Hello,
> 
> On 16 Nov 2016, at 21:22, Anthony King  
> >> wrote:
> 
> Sending a link to set a password isn't much better.
> 
> The cardinal rule of passwords is “you must be the only person who knows
> your password”. This means never writing it down anywhere, except in a
> proper password manager, and never telling it to anyone, *even* your IT
> staff — to fight social engineering attacks.
> 
> Sending a password in clear over email means the IT staff is okay with
> knowing the user's password. Disregarding their own guidelines sets a
> poor example and reduces their credibility about password management in
> general.
> 
> Of course, on most Django websites, someone who can create a staff user
> can also change the user’s password — it’s rare to give the “create
> user” but not the “change user” permission. I’m not making a technical
> argument here, I’m thinking of IT literacy and educating users.
> 
> Perhaps a way to force a password change on login would be better,
> which has more use elsewhere, such as being able to periodically force
> password changes
> 
> Forcing a password change on login is another interesting idea to solve
> this problem. That’s what ActiveDirectory has to do, because OSes don’t
> have the same password reset possibilities that web applications have.
> 
> However I think that would mean solving the general problem of password
> rotation. Django solved password validation recently; it could solve
> password rotation next. (Note that password rotation is controversial
> because it forces users to choose weak passwords with a basic rotation
> scheme like putting month number at the end, instead of storing strong
> random password in a password manager. Trade-offs.)
> 
> I still think a simple solution hooking into the current password reset
> mechanism, just with a different email template, could be a quick
> security win for a lot of Django sites. I’d encourage people to use it
> if it existed.
> 
> 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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
>  
> 
>   
> 

Re: Feature idea

[Gregor Müllegger]

I also needed this functionality in one of my apps and just went the
way of copy and pasting the existing solution that is already
implemented in django.contrib.admin. But making this code reuseable
would IMO be a benefit for some app developers.

But I think the approach of using an setting for this purpose is not
the ideal way. Admin does a great job in that way, because it only
uses the autodiscover functionality on demand. My need for an
autodiscover functionality was directly tight to a management command.
I don't want to load these modules unless I invoke the management
command, which is possible with the admin like autodiscover() function
instead of using a setting.

My proposal would go into the direction of pulling the autodiscover
function out of the django.contrib.admin module and putting it
somewhere in the core. Since the admin needs some special
functionality on errors while loading an admin.py module from an app,
I would suggest a Autodiscover class that provides some hooks to be
better customizable.

Something like:


class Autodiscover(object):
def __init__(self, module_name):
self.module_name = module_name

def __call__(self):
# existing autodiscover code from django.contrib.admin

def pre_load(self, app_label):
# gets called directly before trying to load an app's module

def post_load(self, app_label):
# gets called after trying to load an app's module even if the
# import failed

def on_success(self, app_label, module):
# gets called if the module was imported successfully

def on_error(self, app_label):
# gets called if the module didn't exist or import failed


In django.contrib.admin or in any other app we can use:

from django.core.autodiscover import Autodiscover

autodiscover = Autodiscover('admin')


This also provides backwards compatibility since the following snippet still
works:

from django.contrib import admin

admin.autodiscover()


Yours,
Gregor Müllegger

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

Re: Feature idea

[Gabriel Hurley]

I like the idea of boxing up the autodiscover code into a publicly
accessible utility class... it's a problem many people solve for
themselves (myself included) but even moreso it would go well with the
new startup.py proposal that's in the works.

Once it's easy to have things run once at startup, the desire to run
some sort of autodiscovery mechanism from those startup files is
likely to take off. And it's not that it's a hard problem for someone
to solve themselves, but it might be one worth solving once and being
done with it.

The downside, of course, is the cost of maintaining it and ensuring
backwards compatibility going forward.

All the best,

- Gabriel

On Jun 1, 12:02 pm, Gregor Müllegger  wrote:
> I also needed this functionality in one of my apps and just went the
> way of copy and pasting the existing solution that is already
> implemented in django.contrib.admin. But making this code reuseable
> would IMO be a benefit for some app developers.
>
> But I think the approach of using an setting for this purpose is not
> the ideal way. Admin does a great job in that way, because it only
> uses the autodiscover functionality on demand. My need for an
> autodiscover functionality was directly tight to a management command.
> I don't want to load these modules unless I invoke the management
> command, which is possible with the admin like autodiscover() function
> instead of using a setting.
>
> My proposal would go into the direction of pulling the autodiscover
> function out of the django.contrib.admin module and putting it
> somewhere in the core. Since the admin needs some special
> functionality on errors while loading an admin.py module from an app,
> I would suggest a Autodiscover class that provides some hooks to be
> better customizable.
>
> Something like:
>
>     class Autodiscover(object):
>         def __init__(self, module_name):
>             self.module_name = module_name
>
>         def __call__(self):
>             # existing autodiscover code from django.contrib.admin
>
>         def pre_load(self, app_label):
>             # gets called directly before trying to load an app's module
>
>         def post_load(self, app_label):
>             # gets called after trying to load an app's module even if the
>             # import failed
>
>         def on_success(self, app_label, module):
>             # gets called if the module was imported successfully
>
>         def on_error(self, app_label):
>             # gets called if the module didn't exist or import failed
>
> In django.contrib.admin or in any other app we can use:
>
>     from django.core.autodiscover import Autodiscover
>
>     autodiscover = Autodiscover('admin')
>
> This also provides backwards compatibility since the following snippet still
> works:
>
>     from django.contrib import admin
>
>     admin.autodiscover()
>
> Yours,
> Gregor Müllegger

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

Re: Feature idea

[Sean O'Connor]

I've been generally thinking about putting together a package of reusable
tools to implement common "patterns" for reusable apps.  Included in this
would be this type of auto-discovery system as well as a registration
pattern.  Unfortunately I probably won't get much practical work done on
this too soon due to other obligations.

That being said I'd be very interested to see what initial stabs other
people may take in this direction or what other patterns would make sense
for this type of package.  Once a toolset of this nature does exist, I think
it'll be a great asset to reusable apps and even more so to the domain
specific frameworks like imagekit or haystack.


Sean O'Connor
http://seanoc.com


On Tue, Jun 1, 2010 at 3:34 PM, Gabriel Hurley  wrote:

> I like the idea of boxing up the autodiscover code into a publicly
> accessible utility class... it's a problem many people solve for
> themselves (myself included) but even moreso it would go well with the
> new startup.py proposal that's in the works.
>
> Once it's easy to have things run once at startup, the desire to run
> some sort of autodiscovery mechanism from those startup files is
> likely to take off. And it's not that it's a hard problem for someone
> to solve themselves, but it might be one worth solving once and being
> done with it.
>
> The downside, of course, is the cost of maintaining it and ensuring
> backwards compatibility going forward.
>
> All the best,
>
>- Gabriel
>
> On Jun 1, 12:02 pm, Gregor Müllegger  wrote:
> > I also needed this functionality in one of my apps and just went the
> > way of copy and pasting the existing solution that is already
> > implemented in django.contrib.admin. But making this code reuseable
> > would IMO be a benefit for some app developers.
> >
> > But I think the approach of using an setting for this purpose is not
> > the ideal way. Admin does a great job in that way, because it only
> > uses the autodiscover functionality on demand. My need for an
> > autodiscover functionality was directly tight to a management command.
> > I don't want to load these modules unless I invoke the management
> > command, which is possible with the admin like autodiscover() function
> > instead of using a setting.
> >
> > My proposal would go into the direction of pulling the autodiscover
> > function out of the django.contrib.admin module and putting it
> > somewhere in the core. Since the admin needs some special
> > functionality on errors while loading an admin.py module from an app,
> > I would suggest a Autodiscover class that provides some hooks to be
> > better customizable.
> >
> > Something like:
> >
> > class Autodiscover(object):
> > def __init__(self, module_name):
> > self.module_name = module_name
> >
> > def __call__(self):
> > # existing autodiscover code from django.contrib.admin
> >
> > def pre_load(self, app_label):
> > # gets called directly before trying to load an app's module
> >
> > def post_load(self, app_label):
> > # gets called after trying to load an app's module even if
> the
> > # import failed
> >
> > def on_success(self, app_label, module):
> > # gets called if the module was imported successfully
> >
> > def on_error(self, app_label):
> > # gets called if the module didn't exist or import failed
> >
> > In django.contrib.admin or in any other app we can use:
> >
> > from django.core.autodiscover import Autodiscover
> >
> > autodiscover = Autodiscover('admin')
> >
> > This also provides backwards compatibility since the following snippet
> still
> > works:
> >
> > from django.contrib import admin
> >
> > admin.autodiscover()
> >
> > Yours,
> > Gregor Müllegger
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Feature idea

[Dj Gilcrease]

On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger  wrote:
> My proposal would go into the direction of pulling the autodiscover
> function out of the django.contrib.admin module and putting it
> somewhere in the core. Since the admin needs some special
> functionality on errors while loading an admin.py module from an app,
> I would suggest a Autodiscover class that provides some hooks to be
> better customizable.
>
> Something like:


I like this idea better then mine provided the startup.py proposal
goes forward. I very much dislike having autodiscover stuff being
loaded in urls.py as a hack to get an app bootstrapped and part of
what I am trying to solve is the need for app consumers (End
Developers) to bootstrap your app in urls.py.


I figured a setting was slightly more explicit then the bit of magic
that would go on by having your own autodiscover sub-class being
initiated in startup.py (I really think that should be named
bootstrap.py but I digress). Even with the setting there is nothing
preventing you from adding your module to the autodiscover setting
when you call your management command, but as I said I like the class
approach provided a application bootstrap system is provided.

If the class based approach is chosen then I think it should love in
django.utils.autodiscover as it is something the application developer
must subclass if they want to use it, and if it is in core I would
expect it to be something used internally and only to be tinkered with
by advanced users.

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

Re: Feature idea

[Gregor Müllegger]

I would volunteer for the development needed to get this into django.
I will start working on it right after a core developer has looked
into this discussion and points out if my proposal is at least the
right direction.

--
Servus,
Gregor Müllegger

2010/6/1 Dj Gilcrease :
> On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger  wrote:
>> My proposal would go into the direction of pulling the autodiscover
>> function out of the django.contrib.admin module and putting it
>> somewhere in the core. Since the admin needs some special
>> functionality on errors while loading an admin.py module from an app,
>> I would suggest a Autodiscover class that provides some hooks to be
>> better customizable.
>>
>> Something like:
> 
>
> I like this idea better then mine provided the startup.py proposal
> goes forward. I very much dislike having autodiscover stuff being
> loaded in urls.py as a hack to get an app bootstrapped and part of
> what I am trying to solve is the need for app consumers (End
> Developers) to bootstrap your app in urls.py.
>
>
> I figured a setting was slightly more explicit then the bit of magic
> that would go on by having your own autodiscover sub-class being
> initiated in startup.py (I really think that should be named
> bootstrap.py but I digress). Even with the setting there is nothing
> preventing you from adding your module to the autodiscover setting
> when you call your management command, but as I said I like the class
> approach provided a application bootstrap system is provided.
>
> If the class based approach is chosen then I think it should love in
> django.utils.autodiscover as it is something the application developer
> must subclass if they want to use it, and if it is in core I would
> expect it to be something used internally and only to be tinkered with
> by advanced users.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Feature idea

[burc...@gmail.com]

Hi Dj Gilcrease,

I've almost implemented kinda similar proposal (draft here:
http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95
),

and what worries me, is that in current Django you just can't do
autodiscover of django contribs in settings.py because of circular
dependency on django.db.utils.

On Wed, Jun 2, 2010 at 1:43 AM, Dj Gilcrease  wrote:
> On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger  wrote:
>> My proposal would go into the direction of pulling the autodiscover
>> function out of the django.contrib.admin module and putting it
>> somewhere in the core. Since the admin needs some special
>> functionality on errors while loading an admin.py module from an app,
>> I would suggest a Autodiscover class that provides some hooks to be
>> better customizable.
>>
>> Something like:
> 
>
> I like this idea better then mine provided the startup.py proposal
> goes forward. I very much dislike having autodiscover stuff being
> loaded in urls.py as a hack to get an app bootstrapped and part of
> what I am trying to solve is the need for app consumers (End
> Developers) to bootstrap your app in urls.py.
>
>
> I figured a setting was slightly more explicit then the bit of magic
> that would go on by having your own autodiscover sub-class being
> initiated in startup.py (I really think that should be named
> bootstrap.py but I digress). Even with the setting there is nothing
> preventing you from adding your module to the autodiscover setting
> when you call your management command, but as I said I like the class
> approach provided a application bootstrap system is provided.
>
> If the class based approach is chosen then I think it should love in
> django.utils.autodiscover as it is something the application developer
> must subclass if they want to use it, and if it is in core I would
> expect it to be something used internally and only to be tinkered with
> by advanced users.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



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

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

Re: Feature idea

[Reinout van Rees]

On 06/01/2010 09:42 PM, Sean O'Connor wrote:

I've been generally thinking about putting together a package of
reusable tools to implement common "patterns" for reusable apps.
  Included in this would be this type of auto-discovery system as well
as a registration pattern.


Auto-discovery and registration: setuptools entry points can be used for 
this.  That at least is an existing (partial) solution.


I'm already using it in a django project where I've got a couple of 
packages that can register a render-something-on-a-map method.  In the 
one location where I need it I can then just ask setuptools (well, 
pkg_resources) for a list of methods and call them.


Just for the idea, here's a snippet from a setup.py:

  entry_points={
  'lizard_map.layer_method': [
'shapefile_layer = lizard_map.layers:shapefile_layer',
]
  },

And afterwards iterate through all the entry points and call them (or do 
something else with them):


for entrypoint in pkg_resources.iter_entry_points(
group="lizard_map.layer_method"):
method = entrypoint.load()
method("some argument)


Some longer explanation: http://tinyurl.com/ylf3kjb


Reinout


--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"

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

Re: Feature idea

[Jacob Kaplan-Moss]

Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
cover this use case, as well as a whole lot more. There's a few hints
in the logging discussion a few threads down.

So I'm -1 on this specific proposal, but only because I expect it to
be obsoleted by me and Russ' startup proposal. Which one of us really
should write up :)

Jacob

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

Re: Feature idea

[Gregor Müllegger]

Hi Jacob,

I don't know much about the startup proposal, but I expect it to be a
startup.py file in an application folder that gets loaded right after
the django internals are ready and before the models have been loaded.
The mechanism we ask for in this thread is something different.

It would be nice to have a way to load modules from applications
excatly like the startup.py file, but that the loading component is
reusable and can be used for other modulenames specified by the app
developer. This could be used by django.contrib.admin to load all
admin.py files or by haystack to load all search_indexes.py files and
so on.

If this is also covered somehow by the startup proposal, just ignore
me and I wait until this is written down somewhere.
Thanks.

--
Servus,
Gregor Müllegger

2010/6/2 Jacob Kaplan-Moss :
> Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
> cover this use case, as well as a whole lot more. There's a few hints
> in the logging discussion a few threads down.
>
> So I'm -1 on this specific proposal, but only because I expect it to
> be obsoleted by me and Russ' startup proposal. Which one of us really
> should write up :)
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Feature idea

[Jacob Kaplan-Moss]

On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger  wrote:
> I don't know much about the startup proposal, but I expect it to be a
> startup.py file in an application folder that gets loaded right after
> the django internals are ready and before the models have been loaded.
> The mechanism we ask for in this thread is something different.
>
> It would be nice to have a way to load modules from applications
> excatly like the startup.py file, but that the loading component is
> reusable and can be used for other modulenames specified by the app
> developer. This could be used by django.contrib.admin to load all
> admin.py files or by haystack to load all search_indexes.py files and
> so on.
>
> If this is also covered somehow by the startup proposal, just ignore
> me and I wait until this is written down somewhere.

Basically, the idea is that the app's startup handler could do any
auto-discovery on its own. So django.contrib.admin or Haystack or
whatever could provide a startup hook that just did the autodiscovery
there (or listened a signal to perform it later, more likely).

I'm trying to avoid having multiple "do things at startup" registries,
so having a "autodiscovery registry" along with a "logging startup"
along with the normal settings and app loading just starts to sound
like a bunch of different "do this at startup" cases. I'd like to kill
all these birds with one stone.

Again, I'll try to write up a startup proposal more completely, and
when I do you can see if it matches your usecase. I think it does,
though.

Jacob

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

Re: Feature idea

[Dj Gilcrease]

On Wed, Jun 2, 2010 at 3:14 PM, Jacob Kaplan-Moss  wrote:
> Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
> cover this use case, as well as a whole lot more. There's a few hints
> in the logging discussion a few threads down.
>
> So I'm -1 on this specific proposal, but only because I expect it to
> be obsoleted by me and Russ' startup proposal. Which one of us really
> should write up :)

Sounds good to me, my proposal was based on need and limited
understanding of the startup proposal based on the mentioning of it in
the logging thread where I assumed it would just be something like the
admin's auto discovery that looked for startup.py instead of admin.py

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

Feature idea: forms signals

[David Seddon]

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/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A new feature idea

[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: Feature idea: forms signals

[Aymeric Augustin]

Hello,

My experience with Django — and not just with inexperienced developers — is 
that signals are a footgun. I've seen them misused as workarounds for badly 
structured code and unclear dependency trees too often. I'm not eager to 
encourage their use.

Fundamentally, signals in Django allow a developer to declare a function call 
at the callee site instead of at the caller site. That provides a way for app 
developers to modify the behavior of libraries written by others, but not a 
very good one.

"Signals as an API" have the drawbacks as "subclassing as an API", such as 
making it difficult to tell what happens just by following function calls in 
the code, and then some, for example :

- managing exceptions: while signals give control back from the library to the 
app, they also create their own tiny area of inversion control where the 
signals framework manages execution of signal receivers ; you can either get 
all exceptions or ignore them all, but it's the library that makes this 
decision, not the app.

- transactional behavior: as a consequence of the previous point, it's very 
hard to make guarantees about what the consistency of code that executed 
successfully or failed to execute when signals are involved.

- execution order of receivers: I'm supposed to have rewritten app-loading in 
Django 1.7 to make it deterministic, but I still don't quite believe it's 
reasonable to rely on import order.

- no encapsulation: even if encapsulation is merely a convention in Python, at 
least inheritance defines some boundaries on the behavior.

I'd really prefer if Django encouraged people to support customizing forms 
through dependency injection, which in my opinion is the proper way to perform 
such customizations. It can be as simple as specifying a dotted Python path to 
a form class in settings if there's a desire to stay away from the factory 
pattern and minimise boilerplate setup code.

I must be one of the more anti-signals people here — I could make the argument 
that signals aren't GOTOs, they're COMEFROMs with a straight face — so don't 
take may opinion as reflecting the consensus. It would be nice to know what 
other solutions you considered before proposing this one, though.

Best regards,

-- 
Aymeric.



> On 6 Mar 2017, at 19:10, 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/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%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/F928DC5B-78AC-4755-95A5-2689D48953DA%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[David Seddon]

I totally agree that signals are open to misuse, and I take your points. 
 Inexperienced developers often seem to use them just because they're 
there, rather than to encapsulate their apps and avoid circular 
dependencies.  The Django signals documentation could probably do with a 
bit more guidance of when to use them.  On the other hand, I have seen a 
lot of great uses of models signals too.

There are other solutions, and I've actually given a talk about these here 
(https://skillsmatter.com/skillscasts/7129-encapsulated-django-keeping-your-apps-small-focused-and-free-of-circular-dependencies).
 
 The idea of OVERLOADED_CLASSES above is also a really interesting idea, 
but a lot more of a fundamental shift than just dispatching a few signals 
from the existing form classes.

What I would say in terms of form signals support is that in a former life 
I was a Drupal developer.  That framework has shortcomings but there are 
also things that work really well, and one of the best is a hook for 
altering forms (hook_form_alter) which works very well for Drupal's highly 
modular approach.  This hook is used everywhere in Drupal projects.  I 
think exposing this kind of hook would make it a lot easier for Django 
developers to architect their projects as small, pluggable apps - something 
that is pretty difficult to make work with forms.

David

On Monday, 6 March 2017 21:43:47 UTC, contact wrote:
>
> Hi ! 
> I'd prefer to that a standardized way of overloading classes, like with 
> a proper setting : 
> OVERLOADED_CLASSES = { 
>  'app.forms.MyForm': 'myapp.forms.MyForm' 
> } 
> Having (or not) myapp.forms.MyForm extend app.forms.MyForm. So whenever 
> a CBV declares its form is app.forms.MyForm, it would instead create an 
> instance of myapp.forms.MyForm. Same thing for the instanciation of the 
> views classes. 
> After thatn it gets a bit trickier for the manual instanciation you 
> could find in FormView.get_form() for example. But I'm not fully aware 
> of Python's possibilities regarding such a functionality. As the mocking 
> library allows to replace a class with another on the fly, I'm pretty 
> sure it can be done, but I have no idea at what expense that would be 
> and what the side effects could be. 
>
> Anyway, I fully agree that there's something to do about it, as the ways 
> to do it by now are not really obvious. 
>
> Brice 
>

-- 
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/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Aymeric Augustin]

Hi David,

It's good to hear that you did significant research in this area (which I 
couldn't tell from your original email).

I get how this feature can come in handy and I won't stand in the way if it 
gets implemented.

Improving the guidance about when (not) to use signals in the process would be 
great.

-- 
Aymeric.



> On 7 Mar 2017, at 10:29, David Seddon  wrote:
> 
> I totally agree that signals are open to misuse, and I take your points.  
> Inexperienced developers often seem to use them just because they're there, 
> rather than to encapsulate their apps and avoid circular dependencies.  The 
> Django signals documentation could probably do with a bit more guidance of 
> when to use them.  On the other hand, I have seen a lot of great uses of 
> models signals too.
> 
> There are other solutions, and I've actually given a talk about these here 
> (https://skillsmatter.com/skillscasts/7129-encapsulated-django-keeping-your-apps-small-focused-and-free-of-circular-dependencies).
>   The idea of OVERLOADED_CLASSES above is also a really interesting idea, but 
> a lot more of a fundamental shift than just dispatching a few signals from 
> the existing form classes.
> 
> What I would say in terms of form signals support is that in a former life I 
> was a Drupal developer.  That framework has shortcomings but there are also 
> things that work really well, and one of the best is a hook for altering 
> forms (hook_form_alter) which works very well for Drupal's highly modular 
> approach.  This hook is used everywhere in Drupal projects.  I think exposing 
> this kind of hook would make it a lot easier for Django developers to 
> architect their projects as small, pluggable apps - something that is pretty 
> difficult to make work with forms.
> 
> David
> 
> On Monday, 6 March 2017 21:43:47 UTC, contact wrote:
> Hi ! 
> I'd prefer to that a standardized way of overloading classes, like with 
> a proper setting : 
> OVERLOADED_CLASSES = { 
>  'app.forms.MyForm': 'myapp.forms.MyForm' 
> } 
> Having (or not) myapp.forms.MyForm extend app.forms.MyForm. So whenever 
> a CBV declares its form is app.forms.MyForm, it would instead create an 
> instance of myapp.forms.MyForm. Same thing for the instanciation of the 
> views classes. 
> After thatn it gets a bit trickier for the manual instanciation you 
> could find in FormView.get_form() for example. But I'm not fully aware 
> of Python's possibilities regarding such a functionality. As the mocking 
> library allows to replace a class with another on the fly, I'm pretty 
> sure it can be done, but I have no idea at what expense that would be 
> and what the side effects could be. 
> 
> Anyway, I fully agree that there's something to do about it, as the ways 
> to do it by now are not really obvious. 
> 
> Brice 
> 
> -- 
> 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/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%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/26353977-6013-49DE-9A33-550D53E065CE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[James Pic]

Seems similar to this discussion:
https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ

Yes, signal/slot is a pattern that allows quick and easy decoupling of
components that have to work on the same payload, and I've been using
happily for at least a decade but I take your point as well.

About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow
an AppConfig to override a field of another app's form class, that was made
possible by David's initial proposal using signals.

If we're going to change this bit in Django, I'd like to recommend that we
try to cover a broader spectrum of use case, than just allowing a user not
to override a url to pass a different form.

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

Re: Feature idea: forms signals

[Adam Johnson]

I'm +1 on adding some signals to forms, because I feel it's weird for
Django to have several signals for models, and none for forms. However I
don't really have an opinion on what the useful signal points are, because
I don't touch forms that often.

On 7 March 2017 at 11:13, James Pic  wrote:

> Seems similar to this discussion: https://groups.google.com/
> forum/#!searchin/django-developers/forms%7Csort:
> relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ
>
> Yes, signal/slot is a pattern that allows quick and easy decoupling of
> components that have to work on the same payload, and I've been using
> happily for at least a decade but I take your point as well.
>
> About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow
> an AppConfig to override a field of another app's form class, that was made
> possible by David's initial proposal using signals.
>
> If we're going to change this bit in Django, I'd like to recommend that we
> try to cover a broader spectrum of use case, than just allowing a user not
> to override a url to pass a different form.
>
> --
> 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/CAC6Op18ifztiCqCm1Vr39%
> 2BNGJJpCnu8a3gmYZ8sBMXyGtFZwSg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 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/CAMyDDM3LsYg-NyuUiMrMz_RjKE0frqwBdi%2Bb%3DD3vr6Qe0M1-nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Melvyn Sopacua]

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?

Use case code:

*class PrefixedFormView(*generic.FormView*):def post(*self, request, 
***args, 
kwargs*):*self.prefix *= *request.GET.get*('prefix'*, *None)
return 
/super/()*.post*(*request, ***args, kwargs*)*

*class WrappedForm(/object/):def __init__(*self, form_class*: *BaseForm, 
action_url*: *str, is_multipart*: *bool *= False*, 
model_instance*: *Model 
*= None*, initial*: *dict *= None*, prefix*: *str *= 'auto'*, 
kwargs*):*
*

**if *prefix *== 'auto':*self.prefix *= *uuid4*()*.hex  
  *else:
*self.prefix *= *prefixself.form *= None
*self._set_query_prefix*()

def _set_query_prefix(*self*):*final_url *= 
*urlparse*(*self.action_url*)
*query *= *QueryDict*(*query_string*=*final_url.query, mutable*=True)
*query[*'prefix'*] *= *self.prefixparts *= (*final_url.scheme, 
final_url.netloc, 
final_url.path, final_url.params, query.urlencode*()*, 
final_url.fragment*)
*self.action_url *= *urlunparse*(*parts*)


*

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

Re: Feature idea: forms signals

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

Re: Feature idea: forms signals

[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

[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

[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

[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

[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: Feature idea: forms signals

[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: A new feature idea

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

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

Feature Idea for overwrite_default_connection context manager

[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: Feature Idea for overwrite_default_connection context manager

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

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

Re: Feature Idea for overwrite_default_connection context manager

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

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

Feature idea: bulk_associate: Add ManyToMany relationships in bulk

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

Feature Idea: Allow setting session cookie name dynamically

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

Feature Idea: extend dumpdata command with django-filters

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

new feature idea: even and odd forloop iteration variables

[skazhy]

Hi all!

I've been working with Django for a while now, but today I decided to
make a first contribution to Django that would make templates less
ugly by adding these two values to loop_dict (in django/template/
defaulttags.py):

loop_dict['even'] = (i %2 == 0)
loop_dict['odd'] = (i %2 != 0)

Using {% if forloop.even %} would be more clear and readable than {%
if forloop|divisibleby:"2" %}.
As I am new to working *on* Django I don't know the history of this
idea (if there is one) and the correct way of sending patches, all
comments (and corrections!) are appreciated!


-Karlis Lauva /skazhy/

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

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

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

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

[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

[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

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

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

[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 

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

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

[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 
> 
>  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, 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

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

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

Re: Feature Idea: Allow setting session cookie name dynamically

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

Re: Feature Idea: Allow setting session cookie name dynamically

[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

[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

[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

[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: new feature idea: even and odd forloop iteration variables

[Jonas H.]

On 09/19/2011 12:58 PM, skazhy wrote:

Hi all!

I've been working with Django for a while now, but today I decided to
make a first contribution to Django that would make templates less
ugly by adding these two values to loop_dict (in django/template/
defaulttags.py):

loop_dict['even'] = (i %2 == 0)
loop_dict['odd'] = (i %2 != 0)

Using {% if forloop.even %} would be more clear and readable than {%
if forloop|divisibleby:"2" %}.
As I am new to working *on* Django I don't know the history of this
idea (if there is one) and the correct way of sending patches, all
comments (and corrections!) are appreciated!


-Karlis Lauva /skazhy/



https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatetag-cycle

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

Re: new feature idea: even and odd forloop iteration variables

[Travis Swicegood]

Hey Karlis;

This is a cool idea.  I don't do enough template work to always remember the
cycle syntax, but an odd/even is pretty simple to remember.

As for getting this into Django, check out the Contributing Docs[1].  It has
everything you need on how to help out.  In particular the Requesting New
Features[2] section will be of interest to you.  The first thing to do is
bring it up here on the list (like you've done) and see if others are
interested in adding it.  You might also want to include links to any code
that you've changed so other's can take a look at the code.

Hope this help,
-T

[1]: https://docs.djangoproject.com/en/dev/internals/contributing/
[2]:
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/#requesting-features

On Mon, Sep 19, 2011 at 5:58 AM, skazhy  wrote:

> Hi all!
>
> I've been working with Django for a while now, but today I decided to
> make a first contribution to Django that would make templates less
> ugly by adding these two values to loop_dict (in django/template/
> defaulttags.py):
>
> loop_dict['even'] = (i %2 == 0)
> loop_dict['odd'] = (i %2 != 0)
>
> Using {% if forloop.even %} would be more clear and readable than {%
> if forloop|divisibleby:"2" %}.
> As I am new to working *on* Django I don't know the history of this
> idea (if there is one) and the correct way of sending patches, all
> comments (and corrections!) are appreciated!
>
>
> -Karlis Lauva /skazhy/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Travis Swicegood | @tswicegood (most everywhere) | Senior Open Source
Engineer @ Texas Tribune / Armstrong

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

Re: new feature idea: even and odd forloop iteration variables

[Russell Keith-Magee]

On Tue, Sep 20, 2011 at 2:57 AM, Travis Swicegood  wrote:
> Hey Karlis;
> This is a cool idea.  I don't do enough template work to always remember the
> cycle syntax, but an odd/even is pretty simple to remember.

I disagree, for a number of reasons

 * There should be Only One Way To Do It

 * Cycle syntax isn't that complex

 * Cycle syntax is a lot more flexible -- it allows, for example,
cycles by 3 instead of just even/odd, or a/a/b cycles, or whatever
other crazy things you might need.

 * I already have difficulty remembering the names of the context
variables that the for loop adds.

So, call me a -0 on a specific even/odd counter on the for loop.

Yours,
Russ Magee %-)

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

Re: new feature idea: even and odd forloop iteration variables

[Luke Plant]

Hi skazhy,

> I've been working with Django for a while now, but today I decided to
> make a first contribution to Django that would make templates less
> ugly by adding these two values to loop_dict (in django/template/
> defaulttags.py):
> 
> loop_dict['even'] = (i %2 == 0)
> loop_dict['odd'] = (i %2 != 0)
> 
> Using {% if forloop.even %} would be more clear and readable than {%
> if forloop|divisibleby:"2" %}.
> As I am new to working *on* Django I don't know the history of this
> idea (if there is one) and the correct way of sending patches, all
> comments (and corrections!) are appreciated!

I agree with Russell - this overlaps completely with 'cycle' or
'divisibleby', and we prefer Only One Way To Do It.

Thanks for the idea though,

Luke

-- 
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor)

Luke Plant || http://lukeplant.me.uk/

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

Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

[Ben Welsh]

Hello,

I am a big fan of PostgreSQL's excellent bulk loader COPY 
. It can rapidly 
load a CSV file directly into the database, an oftentimes tedious task that 
I have to do frequently as part of my job. 

I am not a big fan of having to write my COPY commands in raw SQL. I'd much 
rather use Django's ORM. 

So last week I put together an app call django-postgres-copy 
 that 
attempts to integrate COPY into Django, modeling its design on the 
excellent LayerMapping 
 
utility in contrib.gis, which I also use frequently. 

I wrote a blog post about the approach here

http://www.californiacivicdata.org/2015/07/17/hello-django-postgres-copy/

You can find more complete technical documentation here

http://django-postgres-copy.californiacivicdata.org/en/latest/

And all of the code is up here on GitHub

https://github.com/california-civic-data-coalition/django-postgres-copy

Since Django has already begun to integrate other PostgreSQL-specific 
features in contrib.postgres, I'm curious if the core developers are be 
interested in adding COPY support as well. 

I'm not attached to the style of my library and I'd welcome a different 
approach if it got the job done. I'd be thrilled to have the opportunity to 
carry the torch and do whatever refactoring and additional coding is 
necessary to qualify it for a merge.

Please let me know what you think. And if I've overlooked some previous 
discussion or superior third-party library in this area, please forgive me. 
I searched around but was unable to find anything.

Sincerely,

Ben Welsh

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

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

[thinkwelldesigns]

That looks interesting - I might be able to use your module for a project 
I'll be working on soon. Two questions I had about data transformation from 
the temp column to model column.

1. Can you create datetime stamps from the text data?
2. Can you skip rows where a column == "unwanted data"?

Pardon the simple questions - I'm not too much of a django guru.  Looks 
like an interesting 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1f1b416f-82a7-48ef-b02d-8651f67d9d50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

[Ben Welsh]

Glad you're interested!

1. Yes you can. You can use the field or model method transformations 

 
to provide any SQL you'd like. PostgreSQL has a to_timestamp 
 
function that I bet could do what you want.

2. There isn't a trick to exclude rules based on a test. Part of what makes 
this method fast is that it doesn't evaluate every row in the CSV. Though I 
suspect there could be some way to achieve this goal by fiddling with the 
bulk insert 

 
from the temporary table to the model table. You could subclass that 
function and do it yourself now. And I'm open to ideas about how that 
portion of the code could be surfaced to make configuring it less work. 

On Thursday, July 23, 2015 at 5:05:18 AM UTC-7, thinkwel...@gmail.com wrote:
>
> That looks interesting - I might be able to use your module for a project 
> I'll be working on soon. Two questions I had about data transformation from 
> the temp column to model column.
>
> 1. Can you create datetime stamps from the text data?
> 2. Can you skip rows where a column == "unwanted data"?
>
> Pardon the simple questions - I'm not too much of a django guru.  Looks 
> like an interesting 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc6e18ca-2013-4b60-878b-3ccb0fc456f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

[Aaron Williams]

+1 for this feature addition.

I work with a lot of public data and I almost always go through the steps 
of loading data into PostgreSQL and building from there. COPY reduces data 
load time significantly so a core load command for Django is welcome.

I've used LOAD DATA INFILE for MySQL on occasion too, but I'd rather stick 
to Django's ORM (and PostgreSQL) instead of writing raw SQL as Ben 
mentioned.

Another neat idea is to borrow from GeoDjango's ogrinspect 

 and 
do the same thing for CSVs (I wrote a simple implementation here 
).
 
These two tools together will be huge leap in productivity for the data 
journalism / open data communities.

I should add I just used django-postgres-copy for a project I'm working on 
and it ran like a charm.

On Saturday, July 18, 2015 at 3:19:49 PM UTC-7, Ben Welsh wrote:
>
> Hello,
>
> I am a big fan of PostgreSQL's excellent bulk loader COPY 
> . It can rapidly 
> load a CSV file directly into the database, an oftentimes tedious task that 
> I have to do frequently as part of my job. 
>
> I am not a big fan of having to write my COPY commands in raw SQL. I'd 
> much rather use Django's ORM. 
>
> So last week I put together an app call django-postgres-copy 
>  that 
> attempts to integrate COPY into Django, modeling its design on the 
> excellent LayerMapping 
>  
> utility in contrib.gis, which I also use frequently. 
>
> I wrote a blog post about the approach here
>
> http://www.californiacivicdata.org/2015/07/17/hello-django-postgres-copy/
>
> You can find more complete technical documentation here
>
> http://django-postgres-copy.californiacivicdata.org/en/latest/
>
> And all of the code is up here on GitHub
>
> https://github.com/california-civic-data-coalition/django-postgres-copy
>
> Since Django has already begun to integrate other PostgreSQL-specific 
> features in contrib.postgres, I'm curious if the core developers are be 
> interested in adding COPY support as well. 
>
> I'm not attached to the style of my library and I'd welcome a different 
> approach if it got the job done. I'd be thrilled to have the opportunity to 
> carry the torch and do whatever refactoring and additional coding is 
> necessary to qualify it for a merge.
>
> Please let me know what you think. And if I've overlooked some previous 
> discussion or superior third-party library in this area, please forgive me. 
> I searched around but was unable to find anything.
>
> Sincerely,
>
> Ben Welsh
>

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

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

[William Chambers]

+1 for this integration. This is a great feature that I've been using on 
projects as well. I'd love to be able to do it within django rather than 
hack my own sql scripts around it. The efficiency/speed up is very real. 

This solves the problem that when working with data where people replicate 
across machines (because of time/space/security/cost issues ) Sending a csv 
via box/dropbox and then loading it in with postgres COP is great way to 
make sure that everyone has the information they need in a way that they 
can query efficiently and build on using django!


On Saturday, July 18, 2015 at 3:19:49 PM UTC-7, Ben Welsh wrote:
>
> Hello,
>
> I am a big fan of PostgreSQL's excellent bulk loader COPY 
> . It can rapidly 
> load a CSV file directly into the database, an oftentimes tedious task that 
> I have to do frequently as part of my job. 
>
> I am not a big fan of having to write my COPY commands in raw SQL. I'd 
> much rather use Django's ORM. 
>
> So last week I put together an app call django-postgres-copy 
>  that 
> attempts to integrate COPY into Django, modeling its design on the 
> excellent LayerMapping 
>  
> utility in contrib.gis, which I also use frequently. 
>
> I wrote a blog post about the approach here
>
> http://www.californiacivicdata.org/2015/07/17/hello-django-postgres-copy/
>
> You can find more complete technical documentation here
>
> http://django-postgres-copy.californiacivicdata.org/en/latest/
>
> And all of the code is up here on GitHub
>
> https://github.com/california-civic-data-coalition/django-postgres-copy
>
> Since Django has already begun to integrate other PostgreSQL-specific 
> features in contrib.postgres, I'm curious if the core developers are be 
> interested in adding COPY support as well. 
>
> I'm not attached to the style of my library and I'd welcome a different 
> approach if it got the job done. I'd be thrilled to have the opportunity to 
> carry the torch and do whatever refactoring and additional coding is 
> necessary to qualify it for a merge.
>
> Please let me know what you think. And if I've overlooked some previous 
> discussion or superior third-party library in this area, please forgive me. 
> I searched around but was unable to find anything.
>
> Sincerely,
>
> Ben Welsh
>

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