Re: injecting settings

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi folks,

On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote:
> If we're only talking about providing default values for settings, currently 
> there are two straightforward solutions:
> 
> 1. Like Adam suggested, access settings like this: getattr(settings, 
> 'MY_SETTING', 'my_default').
> 
> This works well when you access settings just once, probably at import time, 
> and cache their value.
> 
> Here's an example: 
> https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34
>  
> 

This approach, however, makes it impossible to use the decorators and
context managers from django.test that override settings. Of course,
there are other ways to tune those knobs in tests, but it takes away a
standard solution provided by the framework.

> 2. Set a default value at import time:
> 
> # apps.py
> 
> from django.apps import AppConfig
> from django.conf import settings
> 
> class MyAppConfig(AppConfig):
> name = 'my_app'
> verbose_name = "..."
> 
> def ready(self):
> if not hasattr(settings, 'MY_SETTING'):
> settings.MY_SETTING = 'my_default'
> 
> If you have many settings, you can define defaults in a DEFAULT_SETTINGS dict 
> and do this:
> 
> def ready(self):
> for setting_name, default_value in DEFAULT_SETTINGS:
> if not hasattr(settings, setting_name):
> setattr(settings, setting_name, default_value)

Nice, I guess it's been a while since I spent any brain cycles on this
topic, but this solution seems much less tedious than what I'd seen
back in the days of Django 1.4. Almost feels good enough, except for
the fact that it goes against what the docs say about modifying
settings.

> > On 7 May 2019, at 17:15, Christian González  
> > wrote:
> > 
> > I myself am using an implementation like DRF does it:
> > 
> > https://github.com/encode/django-rest-framework/blob/e16273a6584f9657c1e5c388558e9c5c92e7ba38/rest_framework/settings.py
> >  
> > 
> > They create a class "APISettings", and mimic the Django behaviour.
> > 
> 
> This is yet another approach. DRF relies on a single Django setting which is 
> a dict containing all individual DRF settings. Then it converts that Django 
> setting to an object and uses this abstraction to access individual settings 
> as properties.

This seems to have become one of the current best practices, but it
requires each reusable package that goes down this road to include a
bunch of boilerplate just to deal with default values for settings. I
suppose that boilerplate could be factored out into its own reusable
package, but my gut tells me that there must be a better way to handle
something as fundamental as providing defaults for settings.
Definitely a very subjective claim, but I just feel like this is
something that should be the responsibility of the framework itself.

> Here we're talking about something slightly different: formalizing how an 
> application can declare default values for its own settings — essentially a 
> per-app equivalent of Django's global_settings.py. To do this properly, we 
> need two things:
> 
> - a good convention for declaring these settings: I would find it elegant to 
> consider every uppercase class attribute of an AppConfig class as a setting, 
> but that might be too magic (and perhaps backwards-incompatible);

I definitely agree that this feels too magic-y. Maybe introducing a
class attribute such as “DEFAULT_SETTINGS” that would hold a
dictionary could work, though?

> - a way to insert them properly into the settings object: I tried to figure 
> out how LazySettings and friends handle global_settings, unfortunately there 
> are more use cases than I was willing to untangle tonight.

Another thing to possibly consider, what should happen if multiple
packages try to provide different defaults for the same setting? I
mean, of course, this has kind of been floated in this thread already,
but it would add one more item to the list of things affected by the
order of INSTALLED_APPS.

Cheers,

Michal
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUX01Y24NsLRJUN8tcDtP8g8z+SUFAlzSo6gACgkQcDtP8g8z
+SX2iw//bKFrh4tfq2k1gefcSDzhOBclqK4e7er3hwq6bRhevLvIgqVo/i3pwxlj
qSVop7ZnbnNk60xsPXLzzlEokkj+QDwldAUsaswckHmdP7zs6UiYWXzvQYc7ufpA
/+lcF3LHrBdBBn77Ip0760KxRPX5kjC0gCPSLKPpiBKxwb+31jkjLHkgIzHiYmUL
VGzpxDxkL1qLNafefXgezL7+mcUb6Mgj+jnYe+zIWGjDN8HBSQfNcALiyHWY9p5q
SCMP2+dH4wL/CsTk8eUEZZwxjlk1X5t2WuoDUxZCqybf9hJG85SjqHGbwnFZI0ar
aE9BMEy+e7brZYO3sX3QFoMHM8I0PUBPIPLbQtuEDJdnp9r69TnyNDL4kA/b9T4P
MHlta99sOe0VGaXV9LoANypJVVAiIQGU3Wxz9EVdu7g+Fdd2Y3THwaWaKes6r6nC
295lnfJP0MEIO81VDTal571Zqkw+kpm0P4uJVPlI9xgnglHoYOU0Er85ajkopqSl
UzI1X7s1GXbfBvd0E

Re: injecting settings

[Aymeric Augustin]

> On 8 May 2019, at 11:38, Michal Petrucha  wrote:
> 
> On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote:
>> If we're only talking about providing default values for settings, currently 
>> there are two straightforward solutions:
>> 
>> 1. Like Adam suggested, access settings like this: getattr(settings, 
>> 'MY_SETTING', 'my_default').
>> 
>> This works well when you access settings just once, probably at import time, 
>> and cache their value.
>> 
>> Here's an example: 
>> https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34
>>  
>> 
> 
> This approach, however, makes it impossible to use the decorators and
> context managers from django.test that override settings. Of course,
> there are other ways to tune those knobs in tests, but it takes away a
> standard solution provided by the framework.

I'm not sure I understand what you're referring to. The framework provides the 
setting_changed signal, which seems to work well here: 
https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/test_signals.py#L8-L18

>> DRF relies on a single Django setting which is a dict containing all 
>> individual DRF settings. Then it converts that Django setting to an object 
>> and uses this abstraction to access individual settings as properties.
> 
> This seems to have become one of the current best practices, but it
> requires each reusable package that goes down this road to include a
> bunch of boilerplate just to deal with default values for settings. I
> suppose that boilerplate could be factored out into its own reusable
> package, but my gut tells me that there must be a better way to handle
> something as fundamental as providing defaults for settings.
> Definitely a very subjective claim, but I just feel like this is
> something that should be the responsibility of the framework itself.

I'm ambivalent about this. I did it myself (TEMPLATES). I'm not sure that was 
worth doing.

Grouping a bunch of related settings in a dict looks satisfying. However, it's 
less practical than giving them a common prefix, notably to override them in 
tests.

I suppose I could support a well-written proposal, though :-)

>> Here we're talking about something slightly different: formalizing how an 
>> application can declare default values for its own settings — essentially a 
>> per-app equivalent of Django's global_settings.py. To do this properly, we 
>> need two things:
>> 
>> - a good convention for declaring these settings: I would find it elegant to 
>> consider every uppercase class attribute of an AppConfig class as a setting, 
>> but that might be too magic (and perhaps backwards-incompatible);
> 
> I definitely agree that this feels too magic-y. Maybe introducing a
> class attribute such as “DEFAULT_SETTINGS” that would hold a
> dictionary could work, though?

Yes, it could work too. I considered it and didn't choose it because it 
increases the distance between what global_settings.py looks like and what app 
settings would look like. Not a very strong argument ;-)

Also there's already magic to include only uppercase variables currently: 
https://github.com/django/django/blob/ef9f2eb69c9396683cefa742bc7d0a0792090e8d/django/conf/__init__.py#L135-L137

>> - a way to insert them properly into the settings object: I tried to figure 
>> out how LazySettings and friends handle global_settings, unfortunately there 
>> are more use cases than I was willing to untangle tonight.
> 
> Another thing to possibly consider, what should happen if multiple
> packages try to provide different defaults for the same setting? I
> mean, of course, this has kind of been floated in this thread already,
> but it would add one more item to the list of things affected by the
> order of INSTALLED_APPS.

Yes. Since the semantic is "make this value the default if there isn't a value 
already" (i.e. setdefault), the most intuitive behavior should be "first app in 
INSTALLED_APPS wins".

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/20D907CE-D92E-4EF5-8EF4-8AF87F646017%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

After #28321 len(formset.forms) != len(formset.errors) is possible

[Carsten Fuchs]

Dear group,

I just upgraded from Django 1.11 to 2+ and thereby found 
https://code.djangoproject.com/ticket/28321
The ticket was resolved with commit 
https://github.com/django/django/commit/f32d24652b920135eb6a0f3de74599f03e181731

Well, this change leaves us with a situation where `formset.forms` possibly no 
longer aligns with `self.errors`.

Was that intended?

The original ticket reporter suggested that for a deleted form with errors, an 
empty dict should be added to formset._errors in a formset's full_clean(). This 
would have preserved the alignment of formset.forms and formset.errors.

Note that the formset implementation often uses index-based iterations over the 
forms which seems to suggest, although there is no other indication or hint, 
that formset.forms[i] correlates to formset.errors[i] for all valid i. (That 
was also my understanding from the documentation before having looked at the 
implementation.)

[ In my application code I have the requirement that even deleted forms must 
meet certain validation criteria. Therefore I relied on the Django 1.11 / 
pre-#28321 behavior, where at the same time   formset.is_valid() == True   and  
 any(formset.errors) == True   was possible. While I found this undocumented, 
it was my preferred behavior. ]

Any thoughts?

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/ca5755d2-f905-f9ed-a8a9-60704bdaac4d%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Adding Quantum Encryption to Django Project

[Harold Heard]

Greetings Django Development Community,

I am interested to know if the Django community is open and/or considering 
adding quantum hashing to the project.

I have a project need for this functionality and would like to capture the 
vision and direction in this area.

I'm glad to participate to the depth required.

Thank you,
Harold Heard
Email: m...@haroldheard.com
https://linkedin.com/in/haroldheard

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/BYAPR04MB4245572AAAC7D62476B59406B9320%40BYAPR04MB4245.namprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Introduction

[Ruchit Vithani]

Hello developers! My name is Ruchit Vithani and I am a student at DA-IICT, 
Gandhinagar in India. I'm familiar with open source and I've also 
contributed to some projects.  I'd love to be a part of this awesome 
community and would like to contribute. I've read the contributing guide. 
Can someone guide me on what to do next? Also, please inform me if there 
are any other community platforms to chat and where should I pick my first 
ticket to work on. Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/db352292-9886-4bc5-ace0-d688804de5da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Form not valid error

[Dimple Mathew]

I am trying to pass data from a form to view, but form is not valid.

I have 3 drop-downs on this form on clicking on submit, if any relavant 
data is available in the database it should be loaded on the template. 
Basically this form is a set of filters that load data based on selection.

views.py

def mentioe(request):
emp_dd= request.user.username
flag=0if request.method == 'POST':
form = Management_Collector(request.POST or None)
if form.is_valid():
m_s = form.cleaned_data.get('month_start')
m_e = form.cleaned_data.get('month_end')
y = form.cleaned_data.get('process_select')

mentione= mrg_bpo.objects.filter(Q(emp_id=emp_dd) & Q(month=m_s))

if not mentione:
messages.error(request, 'Data is not available for your selection 
please consider re-selecting.')
else:
messages.success(request, 'Search Result Displayed Below')
return render(request, 'mentione.html', {'form': form, 'mentione': 
mentione})
else:
print(form.errors)
print('some issue')

else:
print('i go to else')
form = Management_Collector()return render(request, 'mentione.html', 
{'form': form})

forms.py class Management_Collector(forms.ModelForm):

class Meta:
model = mrg_bpo
fields = ['month','year','process_select']
labels = {
"month": _(""),
}
widget = {
'month':forms.HiddenInput(),
'year':forms.HiddenInput(),
}

index.html



{%csrf_token%}

  {% for i in form.month %}{{ i }}
{% endfor %}

 

 {% for i in form.month %}{{ i }}
{% endfor %}
 

{{form.year}}
{{form.process_select}}
 Submit

I want to get the value of all the drop downs in my view

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/cb4599dd-d98f-4331-b7ae-56be77acb335%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Channels

[Faizan Nazeer]

how Django channels connect with android mobile ...
I want to send message on a browser and that message receive on the android 
application how channels work that 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/3510ae85-6d77-4acf-9102-833b840b2159%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: After #28321 len(formset.forms) != len(formset.errors) is possible

[Carlton Gibson]

Hi Carsten. 

Any chance you can put this into a failing test case in a PR? (Much easier 
to reason about code. 🙂) 

Thanks. 
C. 

On Wednesday, 8 May 2019 13:58:25 UTC+2, Carsten Fuchs wrote:
>
> Dear group, 
>
> I just upgraded from Django 1.11 to 2+ and thereby found 
> https://code.djangoproject.com/ticket/28321 
> The ticket was resolved with commit 
> https://github.com/django/django/commit/f32d24652b920135eb6a0f3de74599f03e181731
>  
>
> Well, this change leaves us with a situation where `formset.forms` 
> possibly no longer aligns with `self.errors`. 
>
> Was that intended? 
>
> The original ticket reporter suggested that for a deleted form with 
> errors, an empty dict should be added to formset._errors in a formset's 
> full_clean(). This would have preserved the alignment of formset.forms and 
> formset.errors. 
>
> Note that the formset implementation often uses index-based iterations 
> over the forms which seems to suggest, although there is no other 
> indication or hint, that formset.forms[i] correlates to formset.errors[i] 
> for all valid i. (That was also my understanding from the documentation 
> before having looked at the implementation.) 
>
> [ In my application code I have the requirement that even deleted forms 
> must meet certain validation criteria. Therefore I relied on the Django 
> 1.11 / pre-#28321 behavior, where at the same time   formset.is_valid() == 
> True   and   any(formset.errors) == True   was possible. While I found this 
> undocumented, it was my preferred behavior. ] 
>
> Any thoughts? 
>
> Best regards, 
> Carsten 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/a4703c73-6c25-46ef-a948-c3377057d09a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction

[Carlton Gibson]

Hi Ruchit, 

Welcome aboard! 🙂

There's a whole section on finding a ticket in the talk I gave at DjangoCon 
Europe recently. Check it out: 

https://www.youtube.com/watch?v=F4StlMFb5Ms

In the Trac you can filter by component which helps: 

https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id

(That has the Admin selected, but you can change that.) 

If you get into specific issues getting started email django-core-mentorship 
 and we'll 
see if we can get you going. 

Good luck. Have fun! 

Carlton

On Wednesday, 8 May 2019 13:59:36 UTC+2, Ruchit Vithani wrote:
>
> Hello developers! My name is Ruchit Vithani and I am a student at DA-IICT, 
> Gandhinagar in India. I'm familiar with open source and I've also 
> contributed to some projects.  I'd love to be a part of this awesome 
> community and would like to contribute. I've read the contributing guide. 
> Can someone guide me on what to do next? Also, please inform me if there 
> are any other community platforms to chat and where should I pick my first 
> ticket to work on. Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/43b0b23f-793c-4a06-ab94-55aece5fe888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels

[Adam Johnson]

This mailing list is for the development of Django itself, not for support
using Django. Please use the django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.

On Wed, 8 May 2019 at 11:33, Faizan Nazeer  wrote:

> how Django channels connect with android mobile ...
> I want to send message on a browser and that message receive on the
> android application how channels work that
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To 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/3510ae85-6d77-4acf-9102-833b840b2159%40googlegroups.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/CAMyDDM3afVMyw5rJK1JEn7FUHyLbSVdhJ0u_Vu0zgRFi5szZxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Allow ManyToMany using a intermediary table to be defined as symmetrical

[Collin Anderson]

Hi Nadège,

Sorry for the delay. Yeah, when I was working on PR 8981, I ran into the 
symmetrical case and wasn't sure what the behavior should be, so I left the 
check in place to not allow the behavior. I asked my self the same question 
you did about possibly needing "through_reverse_defaults" and didn't have 
answer. I also didn't have a use-case for symmetrical with 
intermediary/through. I wasn't sure about other unintended consequences and 
just wanted to get the rest of the change out the door.

If you think "both objects should have the same value" then I'd say go for 
it. I suppose it does make sense considering it's supposed to be 
symmetrical as you said. If later people want through_reverse_defaults we 
could always add it later.

Thanks,
Collin


On Tuesday, April 23, 2019 at 8:13:35 AM UTC-4, Nadège Michel wrote:
>
> Hello,
>  
> We use self.referencing ManyToMany relationships with intermediate tables 
> in our work project 
> and I was wondering why we had to create ourselves the reverse link when 
> we need the relationship to be symmetrical.
> I looked at the 'symmetrical' attribute documentation and though we should 
> just set it to True instead of False, 
> but you may know that it triggers the error "fields.E332 Many-to-many 
> fields with intermediate tables must not be symmetrical.".
>
> I searched for a corresponding existing ticket a found this one which is 
> kind of related https://code.djangoproject.com/ticket/9475
> And you can see in the PR some discussion about the check 
> https://github.com/django/django/pull/8981#discussion_r247946460
> Thanks to the work of Collin Anderson in the previous PR I think we can 
> now remove that check.
>
> Questions I had:
>
>- retro compatibility?
>
> As the current behavior forces the user to set 'symmetrical=False', the 
> change is retro-compatible.
>
>- use 'through_defaults' when creating both objects or define a new 
>'through_reverse_defaults' to give different values for each row? 
>
> if you want symmetrical relationship, both objects should have the same 
> values 
> so I chose to use 'through_defaults' for both objects. Which was also what 
> was done in the #8981 
>  PR in 
> the first place.
>
> I have a patch 
> 
>  
> with theses changes:
>
>- removed the check 
>- removed tests for that check
>- added tests (tests/m2m_through, tests/m2m_recursive)
>- updated documentation (may need a bit more work)
>- added back the use of 'through_defaults' of #8981 
> in 
>the:
>
> if self.symmetrical:  
> self  ._add_items(...) 
>
> Tests suite runs fine.
>
> Any thoughts on this design change / new feature?  
> I'll be happy to create a ticket and submit my patch for reviews :) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/4ef6730a-1f81-456c-9e05-7373da73da5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: injecting settings

[Dan Davis]

> Another thing to possibly consider, what should happen if multiple
> packages try to provide different defaults for the same setting? I
> mean, of course, this has kind of been floated in this thread already,
> but it would add one more item to the list of things affected by the
> order of INSTALLED_APPS.

Thus, why Adam called this a Hard Problem(tm).

To resolve this, there would need to be a way for an app in INSTALLED_APPS
to declare that it depends on another app.   Then, despite the order in
INSTALLED_APPS, the ready call could be re-ordered, or rather a new call
could be introduced so that the dependent app could be informed once its
parent has been initialized.The app could also be called before its
"parents" are readied, so that it can tell what the user gave in settings.
 Maybe None is the default for a setting in the parent package, but 'lower'
is to be the default setting in the dependent app...

I am not asserting that such a feature is worth it, just shooting the S**T.

On Wed, May 8, 2019 at 7:38 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> > On 8 May 2019, at 11:38, Michal Petrucha  wrote:
> >
> > On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote:
> >> If we're only talking about providing default values for settings,
> currently there are two straightforward solutions:
> >>
> >> 1. Like Adam suggested, access settings like this: getattr(settings,
> 'MY_SETTING', 'my_default').
> >>
> >> This works well when you access settings just once, probably at import
> time, and cache their value.
> >>
> >> Here's an example:
> https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34
> <
> https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34
> >
> >
> > This approach, however, makes it impossible to use the decorators and
> > context managers from django.test that override settings. Of course,
> > there are other ways to tune those knobs in tests, but it takes away a
> > standard solution provided by the framework.
>
> I'm not sure I understand what you're referring to. The framework provides
> the setting_changed signal, which seems to work well here:
> https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/test_signals.py#L8-L18
>
> >> DRF relies on a single Django setting which is a dict containing all
> individual DRF settings. Then it converts that Django setting to an object
> and uses this abstraction to access individual settings as properties.
> >
> > This seems to have become one of the current best practices, but it
> > requires each reusable package that goes down this road to include a
> > bunch of boilerplate just to deal with default values for settings. I
> > suppose that boilerplate could be factored out into its own reusable
> > package, but my gut tells me that there must be a better way to handle
> > something as fundamental as providing defaults for settings.
> > Definitely a very subjective claim, but I just feel like this is
> > something that should be the responsibility of the framework itself.
>
> I'm ambivalent about this. I did it myself (TEMPLATES). I'm not sure that
> was worth doing.
>
> Grouping a bunch of related settings in a dict looks satisfying. However,
> it's less practical than giving them a common prefix, notably to override
> them in tests.
>
> I suppose I could support a well-written proposal, though :-)
>
> >> Here we're talking about something slightly different: formalizing how
> an application can declare default values for its own settings —
> essentially a per-app equivalent of Django's global_settings.py. To do this
> properly, we need two things:
> >>
> >> - a good convention for declaring these settings: I would find it
> elegant to consider every uppercase class attribute of an AppConfig class
> as a setting, but that might be too magic (and perhaps
> backwards-incompatible);
> >
> > I definitely agree that this feels too magic-y. Maybe introducing a
> > class attribute such as “DEFAULT_SETTINGS” that would hold a
> > dictionary could work, though?
>
> Yes, it could work too. I considered it and didn't choose it because it
> increases the distance between what global_settings.py looks like and what
> app settings would look like. Not a very strong argument ;-)
>
> Also there's already magic to include only uppercase variables currently:
> https://github.com/django/django/blob/ef9f2eb69c9396683cefa742bc7d0a0792090e8d/django/conf/__init__.py#L135-L137
>
> >> - a way to insert them properly into the settings object: I tried to
> figure out how LazySettings and friends handle global_settings,
> unfortunately there are more use cases than I was willing to untangle
> tonight.
> >
> > Another thing to possibly consider, what should happen if multiple
> > packages try to provide different defaults for the same setting? I
> > mean, of course, this has ki

Re: Introduction

[Ruchit Vithani]

Thanks! Carlton. Will surely check out those links. 

On Wednesday, May 8, 2019 at 5:46:33 PM UTC+5:30, Carlton Gibson wrote:
>
> Hi Ruchit, 
>
> Welcome aboard! 🙂
>
> There's a whole section on finding a ticket in the talk I gave at 
> DjangoCon Europe recently. Check it out: 
>
> https://www.youtube.com/watch?v=F4StlMFb5Ms
>
> In the Trac you can filter by component which helps: 
>
>
> https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id
>
> (That has the Admin selected, but you can change that.) 
>
> If you get into specific issues getting started email 
> django-core-mentorship 
>  and 
> we'll see if we can get you going. 
>
> Good luck. Have fun! 
>
> Carlton
>
> On Wednesday, 8 May 2019 13:59:36 UTC+2, Ruchit Vithani wrote:
>>
>> Hello developers! My name is Ruchit Vithani and I am a student at 
>> DA-IICT, Gandhinagar in India. I'm familiar with open source and I've also 
>> contributed to some projects.  I'd love to be a part of this awesome 
>> community and would like to contribute. I've read the contributing guide. 
>> Can someone guide me on what to do next? Also, please inform me if there 
>> are any other community platforms to chat and where should I pick my first 
>> ticket to work on. Thanks!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/7330c435-33ae-4c46-b3eb-359f2607c187%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding Quantum Encryption to Django Project

[Fabio Caritas Barrionuevo da Luz]

What do you mean by Quantum Encryption/Quantum hashing?

It would be nice to explain what it is and / or send some links to more 
information.

That said, I think for anything to be integrated into the core of django, 
it should first, as far as possible, prove its concept as an external 
django app and prove to be useful for a large number of projects.


On Wednesday, May 8, 2019 at 8:59:20 AM UTC-3, Harold Heard wrote:
>
> Greetings Django Development Community,
>
>  
>
> I am interested to know if the Django community is open and/or considering 
> adding quantum hashing to the project.  
>
>  
>
> I have a project need for this functionality and would like to capture the 
> vision and direction in this area.
>
>  
>
> I’m glad to participate to the depth required.
>
>  
>
> Thank you,
>
> *Harold Heard*
>
> Email: *m...@haroldheard.com *
>
> *https://linkedin.com/in/haroldheard 
> *
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/7393d263-a6d8-45de-a8d4-98688eab2c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.