Re: The blacklist / master issue

[Robert Roskam]

Hey All,

I see this opportunity to rename these things to be what they in plain, 
descriptive language. Since we will rarely have as many people together 
considering this change, I find it useful to think what we would have named 
these things from the beginning and then consider if our naming could be 
more clear.

I also found the term master odd when I first started using git. It didn't 
map to anything or have an analogy that I found useful. If we switched to 
main/trunk or whatever Github decides on, I don't much care what the new 
name scheme is. 

Further, I find the allow/deny, accept/block for lists of things as far 
more descriptive.

Some elaboration: when I first came into professional technical circles, I 
found the tendency to use color as a short-cut for culturally accepted 
meaning to be potentially confusing to those from other cultures.  
White/black, red/green/yellow may have received _technical_ meanings from 
the last 50-60 years or so from the American-centric culture, and I speak 
ignorantly, since I'm an American, but I don't know if I can assume that 
other cultures do the same. 

Robert Roskam



On Monday, June 15, 2020 at 12:28:23 PM UTC-4, Tom Carrick wrote:
>
> This ticket was closed wontfix 
> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a 
> discussion here.
>
> David Smith mentioned this Tox issue 
> <https://github.com/tox-dev/tox/issues/1491> stating it had been closed, 
> but to me it seems like it hasn't been closed (maybe there's something I 
> can't see) and apparently a PR would be accepted to add aliases at the 
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article 
> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
>  
> - it seems like Google have already made moves in this direction and GitHub 
> is also planning to. Usually Django is somewhere near the front for these 
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use 
> that terminology, but I'm less sure about black/whitelist, though right now 
> it seems more positive than negative. Most arguments against use some kind 
> of etymological argument, but I don't think debates about historical terms 
> are as interesting as how they affect people in the here and now.
>
> I don't think there is an easy answer here, and I open this can of worms 
> somewhat reluctantly. I do think Luke is correct that we should be 
> concerned with our credibility if we wrongly change this, but I'm also 
> worried about our credibility if we don't.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/53ebc9a5-d795-4449-9900-af948135bd33o%40googlegroups.com.

Re: Google Patch Rewards program

[Robert Roskam]

I've made some minor contributions to django-csp, and CSP is an active area 
of interest to me. Should I send out the proposal myself or work with the 
core team?

On Saturday, December 21, 2019 at 12:51:11 PM UTC-5, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open source 
> security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well 
>in this thread: 
>
> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>  
>)
>- Adding CSP to SecurityMiddleware and shipping some default 
>(django-csp is a good start but requires users to actively seek it: 
>https://django-csp.readthedocs.io/en/latest/ )
>- Adding CORS to Django itself (I'm maintaining django-cors-headers, 
>but its design is a bit pants 
>https://github.com/adamchainz/django-cors-headers )
>- Other things in James Bennett's list of suggestions from this thread 
>in May 2018: 
>
> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>
> Thoughts?
> -- 
> Adam
>

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

Raising awareness to issue #17664

[Robert Roskam]

I spent some time looking at this issue last week, and I wanted to raise 
awareness here. It's an issue that's been out there for 6 years, and I 
think I have a path forward.

However, the path forward would be a breaking change.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/9706ad6e-7e3a-40fa-b42e-5753886ddbdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a tutorial for Channels

[Robert Roskam]

+1

On Monday, February 5, 2018 at 7:05:11 AM UTC-5, David Foster wrote:
>
> This weekend I spent several hours getting Channels configured to run a 
> simple chat server . 
> This was an experiment I wanted to do before trying to integrate Channels 
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official 
> Channels docs  similar 
> in style to the Django tutorial 
>  that showed how 
> to configure Channels and use it to work with WebSockets while also 
> touching on the important Channels concepts and linking to reference 
> documentation where appropriate. So I'd like to offer to write such a 
> tutorial.
>
> Would this be a welcome contribution?
>
> - 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/3494fc07-d40c-4b54-abb6-118db758bd35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Robert Roskam]

Hey Tom,

My main goal is to improve the Django Form API interface for writing Python 
code for what Django has historically done: server-side rendered web pages. 
So any client-validation hooks I might provide would not be fully 
implemented integrations rather a more convenient integration. (I'm 
thinking of things like Parsley.js here.)

If I can happen to improve the API for interfacing with JS frameworks, then 
I'll be happy to do so, but that's honestly not even secondary in 
importance to me. However, my experience so far as been they assume a REST 
API on the backend and otherwise want to be in charge of the DOM inside 
them.

Robert Roskam

On Monday, February 5, 2018 at 5:26:25 PM UTC-5, Tom Forbes wrote:
>
> > Perhaps we should just be able to swap Forms with WTForms or another 
> python library and bake in ElementUI,
>
> There are a plethora of UI frameworks with different tradeoffs, I really 
> don't think Django sound pick one.
>
> However a stronger integration with the JS-build tools of the day like 
> Yarn, webpack et al would be a good step in the right direction, and more 
> agnostic than just 'use this UI framework we picked for you'.
>
> > perhaps it's time for npm to become a first class citizen.
>
> I think if Django is going to stay relevant to building most/all kinds of 
> web apps this is something that will need to happen. To be fair, npm and 
> the whole frontend ecosystem has only really 'matured' in the last couple 
> of years, it's come a long way since Django started.
>
> On 4 Feb 2018 00:36, "Jamesie Pic" > 
> wrote:
>
> On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn  > wrote:
> > This is a huge project to achieve everything you mentioned in your 
> email, and it has implications across a large number of Django packages 
> (not least the admin). I don't want to discourage you, but don't 
> underestimate how much work it would be to get a good replacement for forms 
> for the modern web.
>
> Perhaps we should just be able to swap Forms with WTForms or another 
> python library and bake in ElementUI, even if that means replacing 
> template_name with vue_name in the view generic class, but if we're talking 
> about "modern web" then perhaps it's time for npm to become a first class 
> citizen.
>
> > Your next steps should be to research, spec and potentially write a DEP.
>
> In my recent research it seemed ElementUI the most feature complete UI. It 
> includes ajax file upload which every user expects in the modern web which 
> seems to be the feature which defines feature-completion of a UI framework, 
> compared to what HTML offers out of the box.
>
> Thanks a lot for doing something about this Robert, forms in django 
> definitely needs a major refactoring sprint, typically remove the 
> field/widget layer and rely on one level inheritance that will help a lot 
> for example with material design which displays field.name inside the 
> widget, not possible with current object design.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com?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/msgid/django-developers/2213a3ba-a4e3-4e3c-b022-f81c01ce3c9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: models.CalculatedField feature

[Robert Roskam]

Hey, 

So has this stalled? Because this looked really great, and I was looking 
forward to seeing it!

On Monday, November 20, 2017 at 10:31:31 PM UTC-5, ilya.ka...@jetbrains.com 
wrote:
>
> Thank you all.
>
> I've created a feature request https://code.djangoproject.com/ticket/28822 
> and 
> will try to implement in my Django fork next week. I am not Django source 
> code guru, so any help is welcome:)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/be1cb10d-e3a9-42a9-899c-1215eeef9175%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Robert Roskam]

Hey Marc,

Yeah, I totally agree it's a big job. It's just that the first step for 
proposing (sry about the previous misspelling) the idea. I saw the issues 
I've run into, and It just seemed like a better interface could be 
provided. 

I'll look at what you have worked on.

Robert Roskam

On Thursday, February 1, 2018 at 6:47:29 AM UTC-5, Marc Tamlyn wrote:
>
> Hi Robert,
>
> I have a whole heap of ideas about this, some of which are captured in 
> documentation here: http://django-adapters.readthedocs.io/en/latest/ The 
> code generally doesn't exist yet, but the project is at 
> https://github.com/mjtamlyn/django-adapters.
>
> This is a *huge* project to achieve everything you mentioned in your 
> email, and it has implications across a large number of Django packages 
> (not least the admin). I don't want to discourage you, but don't 
> underestimate how much work it would be to get a good replacement for forms 
> for the modern web.
>
> Your next steps should be to research, spec and potentially write a DEP.
>
> Marc
>
> On 31 January 2018 at 16:24, Collin Anderson  > wrote:
>
>> I personally use the (undocumented?) formfield() method, which takes the 
>> model defaults and lets you override things. I think it's pretty elegant, 
>> though maybe it could use some less verbose syntax (maybe have a 
>> forms.ModelDefault(label='Note') that does this for you).
>>
>> class NoteModalForm(forms.ModelForm):
>> comment = Note._meta.get_field('comment').formfield(label='Note')
>> is_blocker = 
>> Note._meta.get_field('is_blocker').formfield(label='Blocking 
>> Issue', initial=False)
>> picture = Note._meta.get_field('picture').formfield(label='Picture', 
>> required=True, widget=DragNDropFileButtonInput(button_text='Select file 
>> to Upload', button_classes='btn btn-bordered uploader'))
>>
>> class Meta:
>> model = Note
>> fields = ['comment', 'is_blocker', 'equipment', 'picture']
>>
>> I should also note, you can change fields without overriding __init__; 
>> just use base_fields:
>> NoteModalForm.base_fields['picture'].required = True
>> NoteModalForm.base_fields['is_blocker'].initial = False
>>
>> As far as client-side validation goes, yes, Django really only does 
>> client-side validation that's available from plain html. Do you have some 
>> ideas for how dependent fields should work? I personally think it would be 
>> hard to find a one-size-fits all solution for more complicated cases, but 
>> it's probably possible. I think there are some 3rd party libraries that do 
>> this. I think a first step would be to natively handle dependent-fields 
>> programmatically in the back-end, so the form "knows" that those fields are 
>> related. Then maybe django could pass that relationship information to the 
>> html as data-* attributes.
>>
>> On Wed, Jan 31, 2018 at 10:31 AM, Robert Roskam > > wrote:
>>
>>> Hey All,
>>>
>>> Something I've regularly run into as a challenge is the implementation 
>>> of Django forms work well in the simple use cases, but as the use case 
>>> grows in complexity, Django forms become more difficult to work with.
>>>
>>> I know that's a super general statement, but here's the simplest complex 
>>> example I can give you. Lets say you're making an application for a home 
>>> builder, so that their Project Managers can better coordinate the builds. 
>>> One of the features is the ability to take notes and pictures on anything 
>>> that's not yet done and specifically if it relates to a specific piece of 
>>> equipment (AC, furnace, water pump, etc), they can add that too. Below is a 
>>> moderately simplistic example:
>>>
>>> class Note(models.Model):
>>> project = models.ForeignKey('project_management.Project', 
>>> related_name="notes")
>>> equipment = models.ForeignKey('equipment.Equipment', null=True, 
>>> blank=True, related_name="notes")
>>> picture = models.FileField(null=True, blank=True)
>>> is_blocker = models.BooleanField(default=True)
>>> comment = models.TextField()
>>> created_by = models.ForeignKey('users.User', verbose_name="Created 
>>> By")
>>> created_date = models.DateTimeField(default=timezone.now, 
>>> ver

DEP Pre-posal: Re-Designing Django Forms

[Robert Roskam]

Hey All,

Something I've regularly run into as a challenge is the implementation of 
Django forms work well in the simple use cases, but as the use case grows 
in complexity, Django forms become more difficult to work with.

I know that's a super general statement, but here's the simplest complex 
example I can give you. Lets say you're making an application for a home 
builder, so that their Project Managers can better coordinate the builds. 
One of the features is the ability to take notes and pictures on anything 
that's not yet done and specifically if it relates to a specific piece of 
equipment (AC, furnace, water pump, etc), they can add that too. Below is a 
moderately simplistic example:

class Note(models.Model):
project = models.ForeignKey('project_management.Project', 
related_name="notes")
equipment = models.ForeignKey('equipment.Equipment', null=True, 
blank=True, related_name="notes")
picture = models.FileField(null=True, blank=True)
is_blocker = models.BooleanField(default=True)
comment = models.TextField()
created_by = models.ForeignKey('users.User', verbose_name="Created By")
created_date = models.DateTimeField(default=timezone.now, 
verbose_name="Created Date")


class NoteModalForm(forms.ModelForm):
class Meta:
fields = ('comment', 'is_blocker','equipment', 'picture')
model = Note
labels = {
'comment': 'Note',
'is_blocker': 'Blocking Issue',
'picture': 'Picture',
}
widgets = {
'picture': DragNDropFileButtonInput(button_text='Select file to 
Upload',
button_classes='btn 
btn-bordered uploader'),
}



General comments first: 

   1. I would say there's no better way to accomplish what is currently on 
   that form given the current Form Meta API. (Willing to be challenged on 
   this point, btw.)
   2. The repetition of picture 3 times over (fields tuple, labels dict, 
   widgets, dict) seems to be inherently not DRY. If this gets very long, then 
   it becomes harder to manage.
   3. The API on the Model Form itself behaves not quite like you'd expect 
   initially. You'd expect redeclaring fields directly on a form for it to 
   function like a dictionary update, if the value doesn't exist in the 
   incoming dictionary, it keeps what's there. It actually behaves like 
   re-declaration. This very significant behavior is buried in a note 
   
(https://docs.djangoproject.com/en/2.0/topics/forms/modelforms/#overriding-the-default-fields).
 
   Additionally, you'll have sources like pydanny basically tell you this is 
   an anti-pattern: https://www.pydanny.com/overloading-form-fields.html
   4. The API on Meta leads you to believe initially that you can override 
   lots of things via Meta, and it's difficult to discover what is or is not 
   supported. (I usually dig into django.forms.models, and then wander around 
   until I get to ModelForm.) 
  - Here's the list: *model, fields, exclude, widgets, 
  localized_fields, labels, help_texts, error_messages, field_classes.* 
  - What's missing that's on a *default* field? *Required, 
  initial, show_hidden_initial, validators, disabled, label_suffix. *
  - Anything not on this list you basically need to override in __init__
   5. The Django Form API both does and does not care about the client side 
   implementation. I say it does care because it sets the default values in 
   the DOM if you use the form as recommended in the docs. However, there is 
   no recommended approach for anything beyond this. 

Here are some simple scenarios that are made difficult:

Scenario #1
If I'd like on this form--and this form only--to make *picture* always 
required or change the default value of *is_blocker, *we have to override 
__init__. And generally it looks like this:

def __init__(self, *args, **kwargs):
super(NoteModalForm, self).__init__(*args, **kwargs)
self.fields['picture'].required = True
self.fields['is_blocker'].initial = False


Scenario #2
If I have the feature request that notes that are blockers require pictures 
or notes that have equipment requires pictures, then you have to implement 
this pattern:

https://docs.djangoproject.com/en/2.0/ref/forms/validation/#cleaning-and-validating-fields-that-depend-on-each-other

Oh, but wait! The best in class approach to this problem would be to inform 
the user before they submit the form that this is a problem. This catches 
it only on the server side. How should we implement that? You're on your 
own to figure it out.


So in summary, I feel like this could be im

Re: Feature request: get_first_or_404

[Robert Roskam]

I'd like a better fleshed out example from OP, as it seems trivial to 
implement yourself whenever you need it. It may be that I'm not 
understanding the suggestion.

On Wednesday, November 29, 2017 at 2:20:39 AM UTC-5, Sergey Fedoseev wrote:
>
> IMO it shouldn't be added to Django because the same thing can be done in 
> one line: get_object_or_404(qs[:1]), but we could add such using to 
> get_object_or_404() docs.
>
> On Wednesday, November 29, 2017 at 3:41:54 AM UTC+5, Piotr Domański wrote:
>>
>> Currently we have get_object_or_404 and get_list_or_404 but sometimes we 
>> just want to get first matching record for some criteria.
>> If criteria aren't unique then get_object_or_404 raises 
>> MultipleObjectsReturned so request ends with internal server error.
>>
>> My idea is to add function which returns just first matching element and 
>> ends with 404 if no elements match.
>> This function will have parameter order_by (optional or required) of type 
>> List['str'] 
>> which determines which element choose first if there are many matching 
>> elements.
>>
>> In my opinion addition of this feature is good idea, because it is useful 
>> and safe for Django framework.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/9df713de-2141-4a3e-91ab-141a6e8d47dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: models.CalculatedField feature

[Robert Roskam]

+1 for this approach.

On Sunday, November 19, 2017 at 7:49:09 PM UTC-5, ilya.ka...@jetbrains.com 
wrote:
>
> Ok, can we have
>
>  is_adult = models.DBCalculatedField(ExpressionWrapper(Q(age__gt=18), 
> output_field=BooleanField()))
>
> Any query for model with this field will be automatically annotated with 
> .annotate(is_adult =ExpressionWrapper(Q(age__gt=18), 
> output_field=BooleanField()))
>
> We may use F fields also, something like 
> full_name = models.DBCalculatedField(ExpressionWrapper(F('first_name') + 
> F('last_name'), output_field=CharField()))
>
> We may simplify it to
>  is_adult = models.DBCalculatedField(expr=Q(age__gt=18), 
> output_field=BooleanField()))
>
> It will work for any object, created from database.
>
> For local computation we may give user ability to provide lambda or 
> decorate method (as in your example).
>
> After it, I can create my own mixin as *third party lib* to patch model 
> with DBCalculatedField and calcuate its expression locally.
>
>
> class Customer(models.Model, UnsafeCalculateDbLocallyMixin):
> age = models.IntegerField()
> is_adult = models.DBCalculatedField(expr=Q(age__gt=18), 
> output_field=BooleanField()))
>
>
> Ilya.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/4aca72c6-e603-497c-ba0a-c91575d7f808%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paginator Class - Refactor page function for better abstraction

[Robert Roskam]

So the existing Paginator class is great for the standard use case. 

But recently I wanted to be have a Paginator that would return *at least 
per_page *x items. I called it FlexPaginator. My use case was that I had a 
group_by value that I wanted to keep together on the same page, and so the 
rows per page needed to grow. When it was all said an done, I had a 
completely different looking page function on my FlexPaginator.

Here's the default one for reference:

def page(self, number):
"""
Returns a Page object for the given 1-based page number.
"""
number = self.validate_number(number)
bottom = (number - 1) * self.per_page
top = bottom + self.per_page
if top + self.orphans >= self.count:
top = self.count
return self._get_page(self.object_list[bottom:top], number, self)



I'd like to refactor several things about it that would have made it more 
abstract and easier for me, but still keep it backwards compatible:

   - rename bottom and top variables, instead self.first and self.last 
   respectively
   - turn their inline calculations into function calls to  a new, 
   self.first() and self.last()
   - move the entire self.object_list[bottom:top] into its own line
   - move that specific logic into a function called self.get_page_objects
   - store that function's value into  self.page_objects

Any comments?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/b11166ec-0800-48f6-a647-62f41b67631c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to merge django-csp into contrib

[Robert Roskam]

OK, I'll probably hold off for a little bit just in case someone else wants 
it. But I'll probably have some time soon to work on it.

Robert Roskam

On Wednesday, February 15, 2017 at 9:13:45 PM UTC-5, Tim Graham wrote:
>
> Yes, if a ticket goes weeks or months without activity, it's unlikely 
> someone is working on it, so it's fine to reassign.
>
> On Wednesday, February 15, 2017 at 9:11:01 PM UTC-5, Robert Roskam wrote:
>>
>> Hey All,
>>
>> So it's over a year later, and even though there is consensus, this 
>> ticket (https://code.djangoproject.com/ticket/15727) appears to have had 
>> no progress.
>>
>> Would it be OK if someone else were to pick up this ticket and move it 
>> forward?
>>
>> Robert Roskam
>>
>> On Sunday, December 6, 2015 at 11:22:20 AM UTC-5, Thomas Grainger wrote:
>>>
>>> Yeah this makes a lot more sense in SecurityMiddleware
>>>
>>> On Sunday, 6 December 2015 10:01:54 UTC, Florian Apolloner wrote:
>>>>
>>>>
>>>>
>>>> On Sunday, December 6, 2015 at 10:13:46 AM UTC+1, Aymeric Augustin 
>>>> wrote:
>>>>>
>>>>> I understand that the “just merge django-csp” approach minimizes 
>>>>> effort. However the result doesn’t feel well integrated with Django. I 
>>>>> left 
>>>>> a few comments that all boil down to “this isn’t how we would have done 
>>>>> if 
>>>>> we’d started from a clean slate” and quickly gave up when I noticed that 
>>>>> trend.
>>>>>
>>>>
>>>> Ditto, I'd like to see this in core and as part of SecurityMiddleware.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/60788491-d220-44b6-b692-ea4a49e67268%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should Model.save() fix incorrect types that happen to save correctly?

[Robert Roskam]

+1, documenting in this case seems to be the most appropriate. 

Robert Roskam


On Monday, February 13, 2017 at 10:51:59 AM UTC-5, Adam Johnson wrote:
>
> What do you think? Absent a better suggestion, we could document this 
>> pitfall so that there's something to point to when related tickets come in.
>
>
> +1, as Aymeric points out the more complex fields probably won't work with 
> coercion-on-set.
>
> On 13 February 2017 at 15:27, charettes > 
> wrote:
>
>> > What do you think? Absent a better suggestion, we could document this 
>> pitfall so that there's something to point to when related tickets come in.
>>
>> I also think this is the most appropriate solution.
>>
>> Le lundi 13 février 2017 09:57:49 UTC-5, Tim Graham a écrit :
>>>
>>> Once in a while, there's a ticket about this behavior:
>>>
>>> m = Model(decimal='12.9')
>>> m.save()
>>> self.assertEqual(m.decimal, '12.9')
>>> m.refresh_from_db()
>>> self.assertEqual(m.decimal, Decimal('12.9'))
>>>
>>> That is, you can create a model with an incorrect type and it won't be 
>>> fixed until you refresh the object from the database.
>>>
>>> Most recent complaint, "it is only a basic expectation that the DB layer 
>>> and the Application layer will correspond to each-other after performing 
>>> save, which is in other words, syncing your state with the DB. 
>>> Personally, this bug (one way binding between application and db on save) 
>>> broke many of my tests and took a lot of my time." [0] See [1] for another 
>>> manifestation of this.
>>>
>>> I think calling to_python() in Model.save() would have unacceptable 
>>> performance consequences for little benefit considering that it's a 
>>> reasonable expectation for developers to provide the correct type. Further, 
>>> you can use full_clean() to coerce to the correct types:
>>>
>>> m = Model(decimal='12.9')
>>> m.full_clean()
>>> self.assertEqual(m.decimal, Decimal('12.9'))
>>>
>>> What do you think? Absent a better suggestion, we could document this 
>>> pitfall so that there's something to point to when related tickets come in.
>>>
>>> [0] https://code.djangoproject.com/ticket/27825
>>> [1] https://code.djangoproject.com/ticket/24028
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/4e59974e-9916-434e-8840-4f42996e5052%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/4e59974e-9916-434e-8840-4f42996e5052%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/4728e4e7-2810-441a-a729-109f84253215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to merge django-csp into contrib

[Robert Roskam]

Hey All,

So it's over a year later, and even though there is consensus, this ticket 
(https://code.djangoproject.com/ticket/15727) appears to have had no 
progress.

Would it be OK if someone else were to pick up this ticket and move it 
forward?

Robert Roskam

On Sunday, December 6, 2015 at 11:22:20 AM UTC-5, Thomas Grainger wrote:
>
> Yeah this makes a lot more sense in SecurityMiddleware
>
> On Sunday, 6 December 2015 10:01:54 UTC, Florian Apolloner wrote:
>>
>>
>>
>> On Sunday, December 6, 2015 at 10:13:46 AM UTC+1, Aymeric Augustin wrote:
>>>
>>> I understand that the “just merge django-csp” approach minimizes effort. 
>>> However the result doesn’t feel well integrated with Django. I left a few 
>>> comments that all boil down to “this isn’t how we would have done if we’d 
>>> started from a clean slate” and quickly gave up when I noticed that trend.
>>>
>>
>> Ditto, I'd like to see this in core and as part of SecurityMiddleware.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/3c475cca-1c43-40e5-8a09-5899d8732821%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guidelines to name python modules of Django applications?

[Robert Roskam]

+1

On Wednesday, December 7, 2016 at 11:25:05 AM UTC-5, Marc Tamlyn wrote:
>
> What Aymeric and Florian sayid.
>
> On 7 December 2016 at 15:58, Florian Apolloner  > wrote:
>
>> On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin 
>> wrote:
>>>
>>> I still think I wouldn't use a django_ prefix when I create new apps 
>>> because 
>>> it adds a small but pervasive overhead to prevent conflicts that aren't 
>>> common 
>>> in practice. 
>>>
>>
>> Same here, I am certainly against making that a recommendation from/in 
>> Django itself.
>>
>> Cheers,
>> Florian
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ba0114d9-0baa-4662-8fff-f7c9b03b90d3%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/b6258a98-2f7e-4617-bb44-e7bc14952327%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django

[Robert Roskam]

Hey there!

Happy to have you join our community! This group is for Django core 
development (aka, the framework itself), not for people using Django. I 
suggest you go to the django-users list for help:  
http://groups.google.com/group/django-users 

For a great tutorial, please go 
to: https://docs.djangoproject.com/en/1.10/intro/tutorial01/ 

Robert Roskam

On Tuesday, November 1, 2016 at 10:39:49 AM UTC-4, bhaskergaddam128 wrote:
>
> Hi everyone,
> I am new to django,i want learn django indepth,could please let me know 
> ,how to start learning django and how start django practice ,could please 
> help me ,if any one have idea about how to fluent django,i am ready to do 
> hard work on python and django.
>
>  please help me 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/a737287d-c272-4c9c-949a-a9cb66f7363b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Robert Roskam]

+1 from me. I really like this approach to help making my queries more DRY.

I also like how lightweight the library is altogether. Well done!


For those looking for a direct link, here you 
go: https://github.com/Nepherhotep/django-orm-sugar



On Thursday, October 6, 2016 at 1:04:56 PM UTC-4, Alexey Zankevich wrote:
>
> Hey all,
>
> Just want to announce recent changes in Django ORM Sugar library, which 
> might be useful in future Django query syntax enhancement (if ever happens).
> 1. Now it supports indexes and slices:
>
> >>> Q.data.owner.other_pets[0].name='Fishy'
> Q(data__owner__other_pets__0__name='Fishy')
> >>> Q.tags[0] == 'thoughts'
> Q(tags__0='thoughts')
> >>> Q.tags[0:2].contains(['thoughts']) 
> Q(tags__0_2__contains=['thoughts'])
>
>
> 2. Previously, it was only possible to call defined method (like it is 
> done for *is_not_null()* function) or registered with decorator. Now if 
> you try to call unknown function of sugar Q, it will internally pass 
> function name and append it as *__functionname *to lookup field:
>
> >>> Q.user.username.contains('Rodriguez')
> Q(user__username__contains='Rodriguez')
>
>
> There is no such function "contains" anymore in sugar Q, however, it just 
> adds *__contains* to lookup field and passes parameter to it.
>
> 3. It will pass a tuple to lookup if multiple arguments passed:
>
> >>> Q.user.create_datetime.range(d1, d2)
> Q(user__create_datetime__range=(d1, d2))
>
>
> I think the library is at the final state now and isn't going to get new 
> substantial features, but responses are highly appreciated.
>
> Regards,
> Alexey
>
>
> On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>>
>> Hi all,
>>
>> This topic is related to the current ORM query syntax with underscores.
>> There are lots of arguing related to it, anyway it has pros and cons.
>>
>> Let's take a concrete example of querying a model:
>>
>> >>> 
>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>>
>>
>> Pros:
>>
>> 1. The syntax is easy to understand
>> 2. Can be extended with custom transforms and lookups
>>
>> However, there are several cons:
>>
>> 1. Long strings is hard to read, especially if we have fields with 
>> underscores.
>> It's really easy to make a mistake by missing one:
>>
>> >>> 
>> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>>
>> Not easy to catch missing underscore between user and profile, is it? Even
>> though, it's not easy to say whether it should be "user_profile" 
>> attribute or
>> user.profile foreign key.
>>
>> 2. Query strings can't be reused, thus the approach violates DRY 
>> principle.
>> For example, we need to order results by last_login_date:
>>
>> >>> 
>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) \
>> .order_by('user__profile__last_login_date')
>>
>> We can't keep user__profile_login_date as a variable as in the first part 
>> of the
>> expression we use a keyword argument, meanwhile in the second part - just 
>> a 
>> string. And thus we just have to type query path twice.
>>
>> 3. Lookup names not natural to Python language and require to be 
>> remembered or
>> looked up in documentation. For example, "__gte" or "__lte" lookups tend 
>> to be
>> confused with "ge" and "le" due to similarity to methods "__ge__" and 
>> "__le__".
>>
>> 4. Lookup keywords limited to a single argument only, very inconvenient 
>> when
>> necessary to filter objects by range.
>>
>> I was thinking a lot trying to solve those issues, keeping in mind Django
>> approaches. Finally I came up with solution to extend Q objects with dot
>> expression syntax:
>>
>> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= yesterday)
>>
>> Q is a factory instance for old-style Q objects. Accessing attribute by 
>> dot
>> returns a child factory, calling factory will instantiate old-style Q 
>> object.
>>
>> >>> Q
>> 
>>
>> >>> Q.user.profile
>> 
>>
>> >>> Q(user__name='Bob')
>> 
>>
>> It overrides operators, so comparing factory with value returns a related 
>> Q
>> object:
>>
>> >>> Q.user.name == 'Bob'
>> 
>>
>> Factory has several helper functions for lookups which aren't related to 
>> any
>> Python operators directly:
>>
>> >>> Q.user.name.icontains('Bob')
>> 
>>
>> And helper to get query path as string, which requred by order_by or
>> select_related queryset methods: 
>>
>> >>> Q.user.profile.last_login_date.get_path()
>> 'user__profile__last_login_date'
>>
>> You can check implementation and more examples here
>> https://github.com/Nepherhotep/django-orm-sugar
>>
>> How it solves issues:
>>
>> #1. Dots hard to confuse with underscores
>> #2. Query paths can be reused:
>>
>> >>> factory = Q.user.profile.last_login_date
>> >>> query = GameSession.objects.filter(factory >= yesterday)
>> >>> query = query.order_by(factory.get_path())
>>
>> #3. Not neccessary to remember most of lookup names and use comparison 
>> operators
>> instead.
>> #4. Possible to use multiple 

Re: DEP pre-proposal for a simpler URLs syntax.

[Robert Roskam]

Hey All,

Sorry all. I accidentally submitted my message somehow.

I wanted to say that I like the direction Django is going compared to the 
other Python frameworks for its routing. I've looked at Express.js, 
angularjs, rails, and MVC.NET as well. And Django is definitely the easiest 
to read among them.

I think this syntax offers both simplicity in not missing dumb stuff like 
the leading ^ and the trailing $, but it also lets us work toward more 
expressive routing patterns in the future.

Robert Roskam

On Wednesday, October 5, 2016 at 4:08:08 PM UTC-4, Robert Roskam wrote:
>
> Hey Tom,
>
> I really like your current implementation. I think it's an elegant 
> solution to a complex problem, and I like that you looked at Flask for some 
> inspiration. 
>
> I thought that to round out the discussion I'd do a quick comparison to 
> other frameworks. (I've added in slug examples):
>
> *Django*
>
> urlpatterns = [ 
> url(r'^articles/2003/$', views.special_case_2003),
> url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
> views.month_archive),
> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
> views.article_detail),url(r'^articles/(?P[\w-]+)/$', 
> views.slug_view),
> ]
>
>
>
> *DEP*
>
> urlpatterns = [ 
> path('articles/2003/', views.special_case_2003),
> path('articles//', views.year_archive),
> path('articles///', views.month_archive),
> path('articles', views.article_detail), 
>path('articles//', views.slug_view),
> ]
>
>
>
>
>
> *Flask*
> Doesn't really have the idea of putting all your routes in one spot. So 
> pardon the silly example.
>
> 
> @app.route('articles/2003/') 
> def special_case_2003():
>   pass
>
> @app.route('articles//') 
> def year_archive(year):
>   pass
>
> @app.route('articles///') 
> def month_archive(year, month):
>   pass
>
> @app.route('articles') 
> def article_detail(year, month, day):
>   pass
>
> @app.route('articles//')
> def slug_view(slug):
>   pass
>
>
>
>
> *Bottle*
> It's basically Flask (big surprise).
>
> @route('articles/2003/') 
> def special_case_2003():
> pass
>
> @route('articles//')
> def year_archive(year):
>   pass
>
> @route('articles///')
> def month_archive(year, month):
>   pass
>
> @route('articles') 
> def article_detail(year, month, day):
>   pass
>
> @route('articles//')
> def slug_view(slug):
>   pass
>
>
>
>
>
>
> *Pyramid*
> This one is kind of interesting. They don't have any built in validators. 
> And they call their equivalent predicates 
> <http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/hooks.html#view-and-route-predicates>,
>  
> and their usage is far more board. 
>
> config.add_route('special_case_2003', 'articles/2003/')
> config.add_route('year_archive', 'articles/{year}/')
> config.add_route('month_archive', 'articles/{year}/{month}/')
> config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
> config.add_route('slug_view', 'articles/{slug}/')
> config.scan()
>
>
>
>
>
>
> Robert Roskam
>
> On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>>
>> Hi folks,
>>
>> I wanted to push forward the consideration of introducing a simpler URLs 
>> syntax, plus support for URL parameter type conversion.
>>
>> A pre-proposal is available here: 
>> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>>
>> At this point I'm seeking feedback, before hopefully iterating on the 
>> proposal, and making a formal submission.
>>
>> I'm not making any assumptions right now about where this might get too, 
>> or who'd be involved if it does make it to the DEP stage, and would very 
>> much welcome outside involvement. I'm also aware that while there's been 
>> some positive reception, it's not yet clear if we'll reach a consensus on 
>> inclusion in core.
>>
>> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
>> is a rather glaring and unnecessary pain point.
>>
>> Thanks to everyone who's started to kick this off, in particular Emil 
>> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
>> work on the Django Simple URL 
>> <https://github.com/sjoerdjob/django-simple-url> package.
>>
>>   - Tom
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/db1f38e2-3716-41d0-870e-ea7b84d0cfc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Robert Roskam]

Hey Tom,

I really like your current implementation. I think it's an elegant solution 
to a complex problem, and I like that you looked at Flask for some 
inspiration. 

I thought that to round out the discussion I'd do a quick comparison to 
other frameworks. (I've added in slug examples):

*Django*

urlpatterns = [ 
url(r'^articles/2003/$', views.special_case_2003),
url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
views.month_archive),
url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
views.article_detail),url(r'^articles/(?P[\w-]+)/$', views.slug_view),
]



*DEP*

urlpatterns = [ 
path('articles/2003/', views.special_case_2003),
path('articles//', views.year_archive),
path('articles///', views.month_archive),
path('articles', views.article_detail),   
 path('articles//', views.slug_view),
]





*Flask*
Doesn't really have the idea of putting all your routes in one spot. So 
pardon the silly example.


@app.route('articles/2003/') 
def special_case_2003():
pass

@app.route('articles//') 
def year_archive(year):
pass

@app.route('articles///') 
def month_archive(year, month):
pass

@app.route('articles') 
def article_detail(year, month, day):
pass

@app.route('articles//')
def slug_view(slug):
pass




*Bottle*
It's basically Flask (big surprise).

@route('articles/2003/') 
def special_case_2003():
pass

@route('articles//')
def year_archive(year):
pass

@route('articles///')
def month_archive(year, month):
pass

@route('articles') 
def article_detail(year, month, day):
pass

@route('articles//')
def slug_view(slug):
pass






*Pyramid*
This one is kind of interesting. They don't have any built in validators. 
And they call their equivalent predicates 
<http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/hooks.html#view-and-route-predicates>,
 
and their usage is far more board. 

config.add_route('special_case_2003', 'articles/2003/')
config.add_route('year_archive', 'articles/{year}/')
config.add_route('month_archive', 'articles/{year}/{month}/')
config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
config.add_route('slug_view', 'articles/{slug}/')
config.scan()






Robert Roskam

On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs 
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here: 
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the 
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too, 
> or who'd be involved if it does make it to the DEP stage, and would very 
> much welcome outside involvement. I'm also aware that while there's been 
> some positive reception, it's not yet clear if we'll reach a consensus on 
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil 
> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
> work on the Django Simple URL 
> <https://github.com/sjoerdjob/django-simple-url> package.
>
>   - Tom
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/1177f3c9-fe36-41b4-b6b3-69daae8d8409%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Robert Roskam]

Hey Chris,

Sure thing! I'm going to add a little color to this; probably a little more 
than required.

I have gunciorn for comparison on both graphs because channels supports 
HTTP requests, so we wanted to see how it would do against a serious 
production environment option. I could have equally done uwsgi. I chose 
gunicorn out of convenience. It serves as a control for the redis channels 
setup.

The main point of comparison is to say: yeah, Daphne has an order of 
magnitude higher latency than gunicorn, and as a consequence, it's 
throughput in the same period of time as gunicorn is less. This really 
shouldn't be surprising. Channels is processing an HTTP request, stuffing 
it in a redis queue, having a worker pull it out, process it, and then send 
a response back through the queue. This has some innate overhead in it. 

You'll note I didn't include IPC for latency comparison. It's because it's 
so bad that it would make the graph unreadable. You can get the sense of 
that when you see it's throughput. So don't use it for serious production 
machines. Use it for a dev environment when you don't want a complex setup, 
or use it with nginx splitting traffic for just websockets if you don't 
want to run redis for some reason.



Robert Roskam

On Wednesday, September 14, 2016 at 10:21:27 AM UTC-4, Chris Foresman wrote:
>
> Yes. Honestly, just explain what these results mean in words, because I 
> cannot turn these graphs into anything meaningful on my own.
>
>
>
> On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam wrote:
>>
>> Hey Chris,
>>
>> The goal of these tests is to see how channels performs with normal HTTP 
>> traffic under heavy load with a control. In order to compare accurately, I 
>> tried to eliminate variances as much as possible. 
>>
>> So yes, there was one worker for both Redis and IPC setups. I provided 
>> the supervisor configs, as I figured those would be helpful in describing 
>> exactly what commands were run on each system.
>>
>> Does that help bring some context? Or would you like for me to elaborate 
>> further on some point?
>>
>> Thanks,
>> Robert
>>
>>
>> On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>>>
>>> Is this one worker each? I also don't really understand the implication 
>>> of the results. There's no context to explain the numbers nor if one result 
>>> is better than another.
>>>
>>> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>>>
>>>> Hello All,
>>>>
>>>> The following is an initial report of Django Channels performance. 
>>>> While this is being shared in other media channels at this time, I fully 
>>>> expect to get some questions or clarifications from this group in 
>>>> particular, and I'll be happy to add to that README anything to help 
>>>> describe the results.
>>>>
>>>>
>>>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>>>
>>>>
>>>> Robert Roskam
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/b0ecbe51-7da6-40d0-b788-ccb27c0faedc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Robert Roskam]

<https://lh3.googleusercontent.com/-Sas91kA2iFU/V-hzvh_OmFI/5ik/4Huax5ef9loRHYFdWaXXdcKfoIFF3F0AQCLcB/s1600/Throughput%2Bnon-accumulated.PNG>
Hey Erik,

You are absolutely correct! It was 500 rps. It's a typo. Very sorry! I'll 
fix it!

To your other points,

> At least for me, it took a long time to find out what the graphs were 
actually showing. In the first graph, maybe the title could be more 
descriptive, e.g. "Request latency at 300 rps". 

That sounds better! It's an accurate description. I appreciate the feedback.


> The unit in the second graph is requests per minute, which is 
inconsistent since the first graph is requests per second. This also makes 
comparison difficult. Also, it doesn't actually show the requests per 
minute value unless you break out a calculator, since the X axis stops at 
50 seconds. 

So is your request basically for me to give the slope on each one so that 
you can interpolate the results from one graph to the other?


> Also, the lines in the second graph are suspiciously linear - how many 
measurements were made, at which points in time, what is the jitter? Just 
show the actual measurements as dots, then I can live with the straight 
line. That would also show any effects of the autothrottle algorithm. 

I'll have to regather that data. I had not logged every single response. I 
was aggregating the results every 5 seconds. I can resample this one.



> Finally, I have a hard time understanding the latency values - the config 
shows 1 worker, so I'm assuming seial output. But for Gunicorn, the graph 
shows ~80.000 rpm which corresponds to a latency of 0,75ms, while the text 
says 6ms. Likewise, according to the graph, Redis has a latency of 1,7ms 
and IPC 6ms, which does not align with the text. Is this the effect of an 
async I/O behind the scenes, og are there multiple threads within the 
worker? 

I'm pressed to understand what you're trying to say. I'm not sure where you 
got the 80 (or is it 80 thousand?) rps from. If you're trying to sum the 
values of gunicorn through time, I guess that exposes something else that I 
either misrepresented or said incorrectly. The values presented are 
accumulated. Perhaps, that's not the correct way to present this.

Try the below instead.:

<https://lh3.googleusercontent.com/-Sas91kA2iFU/V-hzvh_OmFI/5ik/4Huax5ef9loRHYFdWaXXdcKfoIFF3F0AQCLcB/s1600/Throughput%2Bnon-accumulated.PNG>





Robert Roskam

On Tuesday, September 13, 2016 at 9:50:18 AM UTC-4, Erik Cederstrand wrote:
>
>
> > Den 13. sep. 2016 kl. 09.28 skrev Erik Cederstrand <
> erik+...@cederstrand.dk >: 
> > 
> > First of all, thanks for taking the time to actually do the 
> measurements! It's insightful and very much appreciated. 
> > 
> > [...]300K requests in 10 minutes is 500 rps, but the text says 500 rps. 
> Which is it? 
> ^^^ 
> 300 rps 
>
> Jeez, not even the email whining about inconsistencies can get the numbers 
> right :-) 
>
> Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/ac741ad0-27f5-4909-a62f-2ef23f2757bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Robert Roskam]

Hey Micahel,

Yes, I ran the tests locally in redis. I thought this would be the best 
choice for a 1-to-1 comparison. In my opinion, it would invalidate the 
results to run the tests on an outside server or service.



On Tuesday, September 13, 2016 at 7:13:04 AM UTC-4, Michael Manfre wrote:
>
> Hi Robert,
>
> Thanks for doing this load testing. More context would be useful to help 
> us outside observers to understand the potentially different variables. Is 
> redis running locally or are you using elasticache?
>
> Regards,
> Michael Manfre
>
> On Mon, Sep 12, 2016 at 9:41 PM Robert Roskam  > wrote:
>
>> Hey Chris,
>>
>> The goal of these tests is to see how channels performs with normal HTTP 
>> traffic under heavy load with a control. In order to compare accurately, I 
>> tried to eliminate variances as much as possible. 
>>
>> So yes, there was one worker for both Redis and IPC setups. I provided 
>> the supervisor configs, as I figured those would be helpful in describing 
>> exactly what commands were run on each system.
>>
>> Does that help bring some context? Or would you like for me to elaborate 
>> further on some point?
>>
>> Thanks,
>> Robert
>>
>>
>>
>> On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>>>
>>> Is this one worker each? I also don't really understand the implication 
>>> of the results. There's no context to explain the numbers nor if one result 
>>> is better than another.
>>>
>>> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>>>
>>>> Hello All,
>>>>
>>>> The following is an initial report of Django Channels performance. 
>>>> While this is being shared in other media channels at this time, I fully 
>>>> expect to get some questions or clarifications from this group in 
>>>> particular, and I'll be happy to add to that README anything to help 
>>>> describe the results.
>>>>
>>>>
>>>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>>>
>>>>
>>>> Robert Roskam
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com?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/msgid/django-developers/e5c17d4f-c3c4-444e-a654-69ab42dac8fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Robert Roskam]

Hey Chris,

The goal of these tests is to see how channels performs with normal HTTP 
traffic under heavy load with a control. In order to compare accurately, I 
tried to eliminate variances as much as possible. 

So yes, there was one worker for both Redis and IPC setups. I provided the 
supervisor configs, as I figured those would be helpful in describing 
exactly what commands were run on each system.

Does that help bring some context? Or would you like for me to elaborate 
further on some point?

Thanks,
Robert


On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>
> Is this one worker each? I also don't really understand the implication of 
> the results. There's no context to explain the numbers nor if one result is 
> better than another.
>
> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>
>> Hello All,
>>
>> The following is an initial report of Django Channels performance. While 
>> this is being shared in other media channels at this time, I fully expect 
>> to get some questions or clarifications from this group in particular, and 
>> I'll be happy to add to that README anything to help describe the results.
>>
>>
>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>
>>
>> Robert Roskam
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Channels Load Testing Results

[Robert Roskam]

Hello All,

The following is an initial report of Django Channels performance. While 
this is being shared in other media channels at this time, I fully expect 
to get some questions or clarifications from this group in particular, and 
I'll be happy to add to that README anything to help describe the results.

https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst


Robert Roskam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/119c3f8d-8f12-46ea-89bc-ab2b7a9084c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and WebSocket Routing and URL Parameters

[Robert Roskam]

Awesome! I was looking for this way back in early May and couldn't find it. 
Shame on me for not reading the docs.

Robert Roskam

On Thursday, August 18, 2016 at 1:12:26 PM UTC-4, Andrew Godwin wrote:
>
> Hi Robert,
>
> That blog post dates from before the URL/parameter matching in channels. 
> You can now do things like this:
>
> chat_routing = [
> route("websocket.connect", chat_connect, 
> path=r"^/(?P[a-zA-Z0-9_]+)/$),
> route("websocket.disconnect", chat_disconnect),
> ]
>
> routing = [
> # You can use a string import path as the first argument as well.
> include(chat_routing, path=r"^/chat"),
> ]
>
> You can read more in the docs here: 
> http://channels.readthedocs.io/en/latest/getting-started.html#routing
>
> Andrew
>
> On Thu, Aug 18, 2016 at 7:45 AM, Robert Roskam  > wrote:
>
>> It seems like passing parameters through routing for websockets should be 
>> something that we want, but I've been surprised that I've seen absolutely 0 
>> comments or questions on this so far.
>>
>> What am I saying specifically? Let me show you from the popular article 
>> that jacobian wrote up on Heroku's blog:
>>
>> https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
>>  
>>
>> 
>>
>> Need to hook each of these channels up in routing.py:
>>
>> from . import consumers
>>
>> channel_routing = {
>> 'websocket.connect': consumers.ws_connect,
>> 'websocket.receive': consumers.ws_receive,
>> 'websocket.disconnect': consumers.ws_disconnect,
>> }
>>
>> Pretty simple stuff: just connect each channel to an appropriate 
>> function. Now, let’s look at those functions. By convention we’ll put these 
>> functions in aconsumers.py (but, like views, these could be anywhere.)
>>
>> Let’s look at ws_connect first:
>>
>> from channels import Group
>> from channels.sessions import channel_session
>> from .models import Room
>>
>> @channel_session
>> def ws_connect(message):
>> prefix, label = message['path'].strip('/').split('/')
>> room = Room.objects.get(label=label)
>> Group('chat-' + label).add(message.reply_channel)
>> message.channel_session['room'] = room.label
>>
>> ___
>>
>>
>> So everything above is straight from that article. I'd like to focus in 
>> on this line:
>>
>> prefix, label = message['path'].strip('/').split('/').
>>
>> It seems like this should not be tightly coupled to this consumer. It 
>> seems like this should be handled more like this:
>>
>>
>> from channels.urls import parameters  # I know this doesn't exist
>>
>> from. import consumers 
>>
>> channel_routing = {
>> parameters('websocket.connect', consumers.ws_connect, 
>> path=r'chat/(?P\w+)',
>> 'websocket.receive': consumers.ws_receive,
>>'websocket.disconnect': consumers.ws_disconnect,
>> }
>>
>>
>> Then you would be able to consume the result this way:
>>
>> from channels import Group
>> from channels.sessions import channel_session
>> from .models import Room
>>
>> @channel_session
>> def ws_connect(message, *args, **kwrags):
>> label = kwargs['label']
>> room = Room.objects.get(label=label)
>> Group('chat-' + label).add(message.reply_channel)
>> message.channel_session['room'] = room.label
>>
>>
>> Thoughts?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/eb8bb34d-7c07-4443-960e-fe20a6b2eb90%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/eb8bb34d-7c07-4443-960e-fe20a6b2eb90%40googlegroups.com?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/msgid/django-developers/701a628a-fa2f-45c4-a70a-d8169fcc7d33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Channels and WebSocket Routing and URL Parameters

[Robert Roskam]

It seems like passing parameters through routing for websockets should be 
something that we want, but I've been surprised that I've seen absolutely 0 
comments or questions on this so far.

What am I saying specifically? Let me show you from the popular article 
that jacobian wrote up on Heroku's blog:
https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
 



Need to hook each of these channels up in routing.py:

from . import consumers

channel_routing = {
'websocket.connect': consumers.ws_connect,
'websocket.receive': consumers.ws_receive,
'websocket.disconnect': consumers.ws_disconnect,
}

Pretty simple stuff: just connect each channel to an appropriate function. 
Now, let’s look at those functions. By convention we’ll put these functions 
in aconsumers.py (but, like views, these could be anywhere.)

Let’s look at ws_connect first:

from channels import Group
from channels.sessions import channel_session
from .models import Room

@channel_session
def ws_connect(message):
prefix, label = message['path'].strip('/').split('/')
room = Room.objects.get(label=label)
Group('chat-' + label).add(message.reply_channel)
message.channel_session['room'] = room.label

___


So everything above is straight from that article. I'd like to focus in on 
this line:

prefix, label = message['path'].strip('/').split('/').

It seems like this should not be tightly coupled to this consumer. It seems 
like this should be handled more like this:


from channels.urls import parameters  # I know this doesn't exist

from. import consumers 

channel_routing = {
parameters('websocket.connect', consumers.ws_connect, 
path=r'chat/(?P\w+)',
'websocket.receive': consumers.ws_receive,
   'websocket.disconnect': consumers.ws_disconnect,
}


Then you would be able to consume the result this way:

from channels import Group
from channels.sessions import channel_session
from .models import Room

@channel_session
def ws_connect(message, *args, **kwrags):
label = kwargs['label']
room = Room.objects.get(label=label)
Group('chat-' + label).add(message.reply_channel)
message.channel_session['room'] = room.label


Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/eb8bb34d-7c07-4443-960e-fe20a6b2eb90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding an some warnings, checks, or exceptions for urls

[Robert Roskam]

I totally agree. There are circumstances when you'll omit a caret or a 
dollar sign, but as far as I can think of, it would seem to only be related 
to an include, so couldn't there be some kind of inspection done on whether 
there's an include an raise some message to basically say "yeah, I'm 
sure."? I think there could be.

One thing I hadn't thought about, though, is that core django maybe not be 
the right place, maybe django-lint or something like that.


On Monday, April 25, 2016 at 12:48:00 PM UTC-4, Tom Evans wrote:
>
> On Mon, Apr 25, 2016 at 1:00 PM, Robert Roskam  > wrote: 
> > I realize this is a really, really obvious and easily fixed newbie 
> error. 
> > But here it is: 
> > 
> > urlpatterns = [ 
> > url(r'^sitemap/', 
> > TemplateView.as_view(template_name='brochure/sitemap.html'), 
> > name="sitemap"), 
> > # More urls 
> > ] 
> > 
> > Sitemap should end with dollar sign. 
>
> The problem is that the url should *usually* end with a dollar sign. 
> There are valid use cases for a url not starting with a caret or 
> ending with a dollar. 
>
> Cheers 
>
> Tom 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/dc5a5373-540d-4c67-b4f8-b66ed745169a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding an some warnings, checks, or exceptions for urls

[Robert Roskam]

I realize this is a really, really obvious and easily fixed newbie error. 
But here it is:

urlpatterns = [
url(r'^sitemap/', 
TemplateView.as_view(template_name='brochure/sitemap.html'), 
name="sitemap"),
# More urls
]

Sitemap should end with dollar sign. The problem isn't bad when it 
immediately happens and you can slap yourself over the face and fix it. The 
problem is when you have a massive stack of these url patterns and you 
don't have a problem until you max a change by reordering.

So I think something should exist to make this easier to discover. Maybe a 
check or a warning. An exception seems rather harsh.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/a538d0ab-76c7-4b5a-9030-9b6892276382%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Robert Roskam]

I'll give it a shot. First day here in the group, so wasn't sure of the 
procedures.

On Wednesday, June 10, 2015 at 2:58:25 PM UTC-4, Tim Graham wrote:
>
> I forgot about the existing settings checks in django.conf__init__.py. 
> That seems like a reasonable place.
>
> Robert do you want to try to write a patch and/or open a ticket?
>
> On Wednesday, June 10, 2015 at 2:38:31 PM UTC-4, Carl Meyer wrote:
>>
>> On 06/10/2015 11:55 AM, Tim Graham wrote: 
>> > We added such a check in runserver [1]. 
>>
>> Unfortunately, this doesn't help for the (likely) most common case of 
>> "local dev with runserver and DEBUG=True, deployment with another server 
>> and DEBUG=False". 
>>
>> > For other servers it seems less 
>> > clear to me where that check would go -- in the WSGI handler? In 
>> > django.setup()? 
>>
>> I was thinking django.setup() or directly in django.conf.settings. 
>>
>> > (obviously, there is no need for ALLOWED_HOSTS if you 
>> > are using Django outside a webserver context, so the check could be 
>> > annoying if it's there). 
>>
>> Yes, this is true. I guess we have to weigh the debugging issues caused 
>> by not having such a check against the (rare?) case of someone running 
>> Django in a non-request-serving capacity with a different settings file 
>> from the one they use to serve requests. (It's that latter clause that 
>> makes it seem a rare case to me - normally when you run e.g. Celery or 
>> some other type of worker process, you'd want to run it with exactly the 
>> same settings as your request-serving processes, in order to avoid other 
>> inconsistencies causing problems.) 
>>
>> And the workaround for the annoying case would be simple - just go ahead 
>> and configure ALLOWED_HOSTS to something non-empty, even though you 
>> technically don't need it. 
>>
>> Carl 
>>
>> > [1] https://code.djangoproject.com/ticket/19875 
>> > 
>> > On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote: 
>> > 
>> > On 06/10/2015 09:55 AM, Robert Roskam wrote: 
>> > > I realize this is a simple thing, but I'm sure this will save 
>> some 
>> > > people time. 
>> > > 
>> > > Since Allowed_Hosts is a required setting, when debug mode is 
>> off, it 
>> > > should raise an appropriate ImproperlyConfigured error. 
>> > > 
>> > > I'm sure there's some broader discussion surrounding which 
>> settings 
>> > > should have this and why, but I haven't been able to find it. 
>> > 
>> > This makes sense - a configuration with DEBUG=False and empty 
>> > ALLOWED_HOSTS can't possibly work, so why should we even allow it 
>> to 
>> > start up? Can anyone else recall a reason why we didn't do this? 
>> > 
>> > Carl 
>> > 
>> > -
>>
>

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

Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

[Robert Roskam]

I realize this is a simple thing, but I'm sure this will save some people 
time.

Since Allowed_Hosts is a required setting, when debug mode is off, it 
should raise an appropriate ImproperlyConfigured error.

I'm sure there's some broader discussion surrounding which settings should 
have this and why, but I haven't been able to find it.

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/fe4359c0-f2c7-49ea-a1de-5b35f3980f2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.