Re: get_random_secret_key not documented!?

[Fab]

There isn't a recommended way so you can generate it however you want. The 
function is used in the startproject 

 command 
for convenience.

On Monday, 16 May 2022 at 13:09:36 UTC+1 Sam wrote:

> In the DigitalOcean documentation 
> 
>  
> I just found that they use
> `from django.core.management.utils import get_random_secret_key`
> to generate a new, unique secret key.
>
> I didn't know that there was such a function.
> and the get_random_secret_key function seems to be not documented so far 
> .
>
> Is this the recommended way to generate secret keys for Django apps?
> If that's the case wouldn't it make sense to write a piece of 
> documentation for that?
>
> Kind regards,
> Samuel✌
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/b2018ec8-0cc0-475e-8ede-81f10c1e193bn%40googlegroups.com.

Re: get_random_secret_key not documented!?

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

Python's secrets module has token_hex and a short recipe for generating
random strings:
https://docs.python.org/3.10/library/secrets.html#recipes-and-best-practices
. I don't think Django needs to provide a public function here. I would
advise Digital Ocean to recommend the secrets module.

On Wed, Jun 1, 2022 at 10:22 AM Fab  wrote:

> There isn't a recommended way so you can generate it however you want. The
> function is used in the startproject
> 
>  command
> for convenience.
>
> On Monday, 16 May 2022 at 13:09:36 UTC+1 Sam wrote:
>
>> In the DigitalOcean documentation
>> 
>> I just found that they use
>> `from django.core.management.utils import get_random_secret_key`
>> to generate a new, unique secret key.
>>
>> I didn't know that there was such a function.
>> and the get_random_secret_key function seems to be not documented so far
>> .
>>
>> Is this the recommended way to generate secret keys for Django apps?
>> If that's the case wouldn't it make sense to write a piece of
>> documentation for that?
>>
>> Kind regards,
>> Samuel✌
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/b2018ec8-0cc0-475e-8ede-81f10c1e193bn%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/CAMyDDM2TiTctT9uEL1gvy%3DGo8NfoYmYBUsuOx0LtS5TGgAKdAg%40mail.gmail.com.

Re: get_random_secret_key not documented!?

[epokeins]

Thank you.

I thought every function should be documented and nobody realized that 
this one is not.
But if that's not the case maybe one should at least point out to the 
Python best practice which your just mentioned Adam.


I didn't know that recipe one so far.
But shouldn't almost everyone create another secret key at least once 
(for production)?


Then it would be great to describe (or link to) a recommend way to do it 
in the Django Docs, from my point of view.


Am 6/1/2022 um 11:28 AM schrieb 'Adam Johnson' via Django developers 
(Contributions to Django itself):
Python's secrets module has token_hex and a short recipe for 
generating random strings: 
https://docs.python.org/3.10/library/secrets.html#recipes-and-best-practices 
. I don't think Django needs to provide a public function here. I 
would advise Digital Ocean to recommend the secrets module.


On Wed, Jun 1, 2022 at 10:22 AM Fab  wrote:

There isn't a recommended way so you can generate it however you
want. The function is used in the startproject


 command
for convenience.

On Monday, 16 May 2022 at 13:09:36 UTC+1 Sam wrote:

In the DigitalOcean documentation


I just found that they use
`from django.core.management.utils import get_random_secret_key`
to generate a new, unique secret key.

I didn't know that there was such a function.
and the get_random_secret_key function seems to be not
documented so far
.

Is this the recommended way to generate secret keys for Django
apps?
If that's the case wouldn't it make sense to write a piece of
documentation for that?

Kind regards,
Samuel✌

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

Groups "Django developers (Contributions to 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/b2018ec8-0cc0-475e-8ede-81f10c1e193bn%40googlegroups.com

.

--
You received this message because you are subscribed to a topic in the 
Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/0nHdj8X_v6Y/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAMyDDM2TiTctT9uEL1gvy%3DGo8NfoYmYBUsuOx0LtS5TGgAKdAg%40mail.gmail.com 
.


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

Django bugfix release: 4.0.5

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/jun/01/bugfix-release/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/CAJwKpyQhY%3DkMzHX-ALZSdUMW8mrxfnCQoY7tX73XTEuBEj5FEQ%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.