Looking for feedback on implementation of UserManager.with_perm()

[Berker Peksağ]

https://github.com/django/django/pull/7153/ implements
UserManager.with_perm() [1] as:

def with_perm(self, perm):
for backend in auth.get_backends():
if hasattr(backend, 'with_perm'):
return backend.with_perm(perm)
return self.get_queryset().none()

[1] "Shortcut to get users by permission":
https://code.djangoproject.com/ticket/18763

With this implementation, users of UserManager.with_perm() won't get
users with permissions for all backends. Also, result of
UserManager.with_perm() will depend on the order of
settings.AUTHENTICATION_BACKENDS. See also
https://code.djangoproject.com/ticket/18763#comment:9 for more
information about the current strategy.

I suggested an alternative approach at
https://github.com/django/django/pull/7153/files#r78226234 with the
following implementation:

def with_perm(self, perm, backend=None):
if backend is None:
backends = _get_backends(return_tuples=True)
if len(backends) != 1:
raise ValueError(
'You have multiple authentication backends configured and '
'therefore must provide the `backend` argument.'
)
_, backend = backends[0]
if hasattr(backend, 'with_perm'):
return backend.with_perm(perm)
else:
backend = load_backend(backend)
if hasattr(backend, 'with_perm'):
return backend.with_perm(perm)
return self.get_queryset().none()

This also simulates what django.contrib.auth.login() does when
multiple authentication backends are defined:

https://github.com/django/django/blob/18c72d59e0807dae75ac2c34890d08c1e0972d0a/django/contrib/auth/__init__.py#L100

Tim suggested to get some feedback about possible use cases:

"I'm not sure about the use cases. For example, someone might want to
get users with permissions for all backends. It would be nice if we
had some feedback about what users are implementing on their own to
confirm we're targeting the largest use case."

Is there any other possible use cases? Which one of the suggested
approaches cover the largest use case?

Thanks!

--Berker

-- 
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/CAF4280%2BmaOn6m%2BcoHDDdhQaUGNfOvw_KSf%2BsnMEtc_EF-pRn6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Ares Ou]

Emil,

Please count me in if you'd like to start a new DEP. I'm also
very interested to take this new challenge. And maybe we
should dive into the code of URL resolver part of Django before
we actually kick off?

Anyway, I myself as a experienced user also like this idea. But as
Tim and Ludovic mentioned, we might better research a bit first.
Understanding how third-party libraries implemented this kind of
simple URL could be very helpful.

Thanks.

Best regards,
Ares Ou

*Software Engineer / Full-Stack Python Developer*

*Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj
*Stack Overflow:* http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

On Tue, Sep 13, 2016 at 12:54 PM, ludovic coues  wrote:

> There is third party module providing third party url function. Surlex
> [1] have been mentionned. But any third party solution will need to
> provide function compatible with django.conf.urls.url.
> Line 64 of django/urls/revolvers.py is get_resolver. This function
> return a RegexURLResolver, using is argument or the setting
> ROOT_URLCONF as argument.
>
> This make impossible, for exemple, to have resolver giving to the view
> an int argument.
>
> [1] http://codysoyland.com/2009/sep/6/introduction-surlex/
>
> 2016-09-13 21:40 GMT+02:00 Tim Graham :
> > I would like to see if this could be done as a third-party project (allow
> > "pluggable URLs" which could use any syntax). If not, then let's accept a
> > patch to Django to support it. Over time, if there's some strong
> consensus
> > about a particular third-party package, then we could bring it in to
> core. I
> > think this approach is less controversial then Django adopting some new,
> > untested syntax right now.
> >
> > On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
> >>
> >> So it looks to me that the consensus is that this IS in fact a good
> idea,
> >> to supply a simpler, regex-free method to define URL:s.
> >>
> >> It also seems that the best liked version is something that's similar to
> >> what flask uses: /articles///.
> >>
> >> I've never written a DEP before, but it sounds like a fun challenge.
> I'll
> >> try to look at existing DEPs for a pattern and then apply that.
> >>
> >> Does anyone have something in particular that they would like to add to
> >> the DEP? I figure I'll try to keep this first version as simple as
> possible,
> >> while maintaining extension points for features that can be added later
> on.
> >>
> > --
> > 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/
> 37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAEuG%2BTa-d_RsMqj5HbspEBdKUKemfBPvjBh2%
> 2BdJmQjU04b-V7w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Challenge teaching Django to beginners: urls.py

[ludovic coues]

There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.

This make impossible, for exemple, to have resolver giving to the view
an int argument.

[1] http://codysoyland.com/2009/sep/6/introduction-surlex/

2016-09-13 21:40 GMT+02:00 Tim Graham :
> I would like to see if this could be done as a third-party project (allow
> "pluggable URLs" which could use any syntax). If not, then let's accept a
> patch to Django to support it. Over time, if there's some strong consensus
> about a particular third-party package, then we could bring it in to core. I
> think this approach is less controversial then Django adopting some new,
> untested syntax right now.
>
> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
>>
>> So it looks to me that the consensus is that this IS in fact a good idea,
>> to supply a simpler, regex-free method to define URL:s.
>>
>> It also seems that the best liked version is something that's similar to
>> what flask uses: /articles///.
>>
>> I've never written a DEP before, but it sounds like a fun challenge. I'll
>> try to look at existing DEPs for a pattern and then apply that.
>>
>> Does anyone have something in particular that they would like to add to
>> the DEP? I figure I'll try to keep this first version as simple as possible,
>> while maintaining extension points for features that can be added later on.
>>
> --
> 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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Challenge teaching Django to beginners: urls.py

[Emil Stenström]

One problem with this approach, to let the community decide on this type of 
feature, is the target audience of it. This is mainly a feature for 
beginners, and more experienced users are expected to switch over to using 
regexes directly to get the exact behavior they want. Beginners likely 
won't look at all the different options and choose one based on it's 
merits, they'll pick whatever their teacher suggests they use. Also 
installing an extra package when setting up django feels a bit strange.

So in summary, I think this COULD be done outside of Django, but that most 
of the benefit of this feature will come from it being part of Django. All 
because of the target audience.

/Emil

On Tuesday, 13 September 2016 21:40:47 UTC+2, Tim Graham wrote:
>
> I would like to see if this could be done as a third-party project (allow 
> "pluggable URLs" which could use any syntax). If not, then let's accept a 
> patch to Django to support it. Over time, if there's some strong consensus 
> about a particular third-party package, then we could bring it in to core. 
> I think this approach is less controversial then Django adopting some new, 
> untested syntax right now.
>
> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
>>
>> So it looks to me that the consensus is that this IS in fact a good idea, 
>> to supply a simpler, regex-free method to define URL:s. 
>>
>> It also seems that the best liked version is something that's similar to 
>> what flask uses: /articles///.
>>
>> I've never written a DEP before, but it sounds like a fun challenge. I'll 
>> try to look at existing DEPs for a pattern and then apply that.
>>
>> Does anyone have something in particular that they would like to add to 
>> the DEP? I figure I'll try to keep this first version as simple as 
>> possible, while maintaining extension points for features that can be added 
>> later on.
>>
>>

-- 
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/859b15b7-9851-43cd-a110-f3ec8266de75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Tim Graham]

I would like to see if this could be done as a third-party project (allow 
"pluggable URLs" which could use any syntax). If not, then let's accept a 
patch to Django to support it. Over time, if there's some strong consensus 
about a particular third-party package, then we could bring it in to core. 
I think this approach is less controversial then Django adopting some new, 
untested syntax right now.

On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
>
> So it looks to me that the consensus is that this IS in fact a good idea, 
> to supply a simpler, regex-free method to define URL:s. 
>
> It also seems that the best liked version is something that's similar to 
> what flask uses: /articles///.
>
> I've never written a DEP before, but it sounds like a fun challenge. I'll 
> try to look at existing DEPs for a pattern and then apply that.
>
> Does anyone have something in particular that they would like to add to 
> the DEP? I figure I'll try to keep this first version as simple as 
> possible, while maintaining extension points for features that can be added 
> later on.
>
>

-- 
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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Emil Stenström]

So it looks to me that the consensus is that this IS in fact a good idea, 
to supply a simpler, regex-free method to define URL:s. 

It also seems that the best liked version is something that's similar to 
what flask uses: /articles///.

I've never written a DEP before, but it sounds like a fun challenge. I'll 
try to look at existing DEPs for a pattern and then apply that.

Does anyone have something in particular that they would like to add to the 
DEP? I figure I'll try to keep this first version as simple as possible, 
while maintaining extension points for features that can be added later on.

-- 
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/da4701e6-5c04-4370-823c-947f85952bab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Ares Ou]

Hi,

Good to hear so much from you.

Just want know more, could anyone also explain why at first Django
chose to use regex instead of a simple URL routing, except for the
flexibility?

By the way, like you said, routing in flask (or should say Werkzeug?) is
also
converting the simple URLs into Regex and store it into the map.

Cheers,

Best regards,
Ares Ou

*Software Engineer / Full-Stack Python Developer*

*Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj
*Stack Overflow:* http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

On Mon, Sep 12, 2016 at 11:37 PM, Anthony King 
wrote:

> This is actually an interesting concept, and wouldn't incur an, overheard
> at runtime if simple_url translated in to full regex format at launch time
> (or on first request, which is when the urls get loaded if I recall
> correctly).
>
> I don't think this would get in the way of includes, and if it's a
> translator to full regex format, it can be done in a separate format.
>
> Your example of flask's is interesting. What if we could define regex for
> our urls to have it pluggable.
>
> simple_url.register('integer', r'[0-9]+')
>
> On 13 Sep 2016 07:26, "Ares Ou"  wrote:
>
>> Hi,
>>
>> Actually flask uses a style very similar to what you want.
>>
>> To my knowing, you must use this pattern for Django because it has the
>> concept of *including *
>> URLs.
>>
>> Routing in flask:
>>
>> @app.route('post/', methods=['GET'])
>> def post_view(post_id=None):
>> # do something to render the post
>> return render_template('post.html', post=post)
>>
>> But the problem is, you have to specify the whole URL for every view you
>> define.
>>
>> Django avoids this by separating URL patterns into different levels,
>> that's why it uses regex to
>> identify the exact path. I guess it is hard for Django to organize URLs
>> in different apps by using
>> such simple method.
>>
>> Looking forward to more ideas!
>>
>> Best regards,
>> Ares Ou
>>
>> *Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328
>> - 5968
>>
>> *Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
>> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
>>
>> Ares Ou
>>
>> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
>> constantine.covtushe...@gmail.com> wrote:
>>
>>> Hi Emil,
>>>
>>> It is a very interesting idea.
>>>
>>> +1 from me
>>>
>>> On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
>>>
 Hi Djangonauts,

 I'm just back from my second year of teaching Django to absolute
 beginners. The course is a combination of HTML, CSS, Python, and Django,
 and after five days of coding they have a real live website that they can
 show to friends. It's always such a great experience to see the look in
 their eyes when they finally understand how they can tame Django to do what
 they want.

 There's one big thing that keeps tripping them up is urls.py. When
 specifying URL:s I get lots of questions about the regexes that they have
 to specify. First: there's a strange "r" in front of each line: r"regex".
 That means I will have to explain string escaping to them. Then there's the
 "^" and "$" signs, both which requires explaining regular expressions at
 length. Then there's [0-9]+ and finally there's the parenthesis around the
 regex. All in all, looking at URLs from a beginners perspective, they are a
 bunch of hieroglyphs, and very hard for beginners to grasp right away.

 I'm not suggesting that urls.py are changed for most users, I'm
 suggesting that *simple_url* method (name inspired by simple_tag) is added
 to django.conf.urls that new users can use to get started quickly.
 This means that most beginners can postpone learning regexes a couple of
 months. The exact syntax that simple_url takes isn't important to me, as
 long it's a lot more beginner friendly than what we have today:

 https://docs.djangoproject.com/en/1.10/topics/http/urls/#example

 Just to get the ideas flowing, here's a suggestion, inspired by rails
 (again, exact syntax isn't important to me, simplicity to beginners is, so
 feel free to suggest something else if you agree that this is an important
 issue):

 from django.conf.urls import simple_url
 from . import views
 urlpatterns = [
 simple_url('articles/2003/', views.special_case_2003),
 simple_url('articles/:year)/', views.year_archive),
 simple_url('articles/:year/:month/', views.month_archive),
 simple_url('articles/:year/:month/:day/', views.article_detail),
 ]

 All parameters would be passed to the view as keyword parameters with the 
 name given and as a string, and validation would happen there instead.

 I'm thinking there should be no settings with simple_url, and that any 
 more advanced 

Re: Django Channels Load Testing Results

[Erik Cederstrand]

> Den 13. sep. 2016 kl. 09.28 skrev Erik Cederstrand 
> :
> 
> 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/CBB8087C-063B-4F91-8870-AEA981FE33F2%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Migration Questioner and String-Type Fields

[Markus Holtermann]

Thank you for your input, Jarek.

Assuming I have an existing model, adding

   models.CharField(blank=True, max_length=150)

to it, doesn't invoke the questioner on current master. Changing this
field to

   models.CharField(max_length=150)

doesn't call the questioner either.

Looking at the SQL Django generates, the first change results in

   ALTER TABLE "example_mymodel" ADD COLUMN "name2" varchar(150) DEFAULT '' NOT 
NULL;
   ALTER TABLE "example_mymodel" ALTER COLUMN "name2" DROP DEFAULT;

and the second in a noop.

I'm trying to understand what change you're proposing in order to figure
out if going forward with your proposal is something we should do.

Cheers,

Markus

On Sun, Sep 11, 2016 at 05:08:38AM -0700, Jarek Glowacki wrote:

Mm, convenience over strict correctness. Perhaps all that's needed is a
slight rephrasing of the prompt and we can have both?

Adding field with no `blank=True` and no `null=True`:

You are trying to add a non-nullable field '%s' to %s without a default; we
can't do that (the database needs something to populate existing rows).
[provide default | cancel]

Removing `null=True` from field:

You are trying to change the nullable field '%s' on %s to non-nullable
without a default; we can't do that (the database needs something to
populate existing rows). [provide default | fix later | cancel]

Removing `blank` from field:

?? (I only skimmed the code; not sure if this even opens up questioner)


This kind of implies to the user that they're doing something wrong. Maybe
if, for string fields, it read something more along the lines of:

You are adding/altering a field without setting `blank=True`. This will
populate existing rows with emptystring despite it being an invalid form
input. Are you sure? [yes | let me provide a one-time default for existing
rows | cancel]


So basically changing "you can't do this!" (exception-esque) to "are you
sure you want this?" (warning-esque).

Anyway I think I'll leave it here. I've exhausted my discussion points now,
and you already resolved my particular use case back in the ticket, so I no
longer feel so strongly about this to continue trying to push for a change
(though am willing to submit a PR if any of the suggested changes are
approved).

Cheers,


On Saturday, September 10, 2016 at 10:08:27 AM UTC+10, Tim Graham wrote:


Sure, but I don't think that use case should take priority. It's not much
work to type an empty string into the questioner if that's what you want.
If we remove the prompt, it's significantly more work (editing a migration
file or using RunPython) for a developer to set a non-empty value.

On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote:


Instances created afterwards, via `MyModel.objects.create()`, with this
field unset won't pass form validation either.
The use case is where this field is not expected to appear on a Django
form.

On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:


If blank=False, then a new column with a non-blank value means that all
existing objects won't pass form validation. Therefore, I don't see why a
prompt for a value isn't helpful.

On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:


I made a rant/ticket regarding the hidden usage of `blank` here: #27197
.

In short, I don't think that `blank` should dictate whether or not the
migration questioner runs.
Building on this, I don't think it should run for for string-type
fields at all. If they have `default` set, use that for existing rows. Else
if they have `null=True`, set existing rows to `NULL`. Else, set existing
rows to empty string.

See linked rant/ticket for some (hopefully) compelling arguments..

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/60bf1464-7e70-41c4-b8de-b201af84b4b7%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/20160912092451.GB17876%40inel.local.
For more options, visit 

Re: Django Channels Load Testing Results

[Michael Manfre]

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

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

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Hi,

I don't think that the 'including' URLs part forms a problem here.

For the given example, it should be easily doable

> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year)/', views.year_archive),
> simple_url('articles/:year/:month/', views.month_archive),
> simple_url('articles/:year/:month/:day/', views.article_detail),
> ]

The following should make it possible:

import re

def simple_url(route, view, *args, **kwargs):
regex_route = re.escape(route)
regex_route = re.sub(r':([A-Za-z0-9_-]+)', r'(?P<\1>[^/]+)', 
regex_route)
# Anchor it to the beginning.
regex_route = '^' + regex_route

if not isinstance(view, (list, tuple)):
# It's not an include...
regex_route += '$'

return url(regex_route, view, *args, **kwargs)

(Not 100% tested, but I tested the re.sub ;) ).

So I think it is at least possible. Whether or not it's desirable though
is another question which I think I'm not suited to answer.

Kind regards,
Sjoerd Job

On Mon, Sep 12, 2016 at 11:26:36PM -0700, Ares Ou wrote:
> Hi,
> 
> Actually flask uses a style very similar to what you want.
> 
> To my knowing, you must use this pattern for Django because it has the
> concept of *including *
> URLs.
> 
> Routing in flask:
> 
> @app.route('post/', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
> 
> But the problem is, you have to specify the whole URL for every view you
> define.
> 
> Django avoids this by separating URL patterns into different levels, that's
> why it uses regex to
> identify the exact path. I guess it is hard for Django to organize URLs in
> different apps by using
> such simple method.
> 
> Looking forward to more ideas!
> 
> Best regards,
> Ares Ou
> 
> *Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328 -
> 5968
> 
> *Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
> 
> Ares Ou
> 
> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
> constantine.covtushe...@gmail.com> wrote:
> 
> > Hi Emil,
> >
> > It is a very interesting idea.
> >
> > +1 from me
> >
> > On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
> >
> >> Hi Djangonauts,
> >>
> >> I'm just back from my second year of teaching Django to absolute
> >> beginners. The course is a combination of HTML, CSS, Python, and Django,
> >> and after five days of coding they have a real live website that they can
> >> show to friends. It's always such a great experience to see the look in
> >> their eyes when they finally understand how they can tame Django to do what
> >> they want.
> >>
> >> There's one big thing that keeps tripping them up is urls.py. When
> >> specifying URL:s I get lots of questions about the regexes that they have
> >> to specify. First: there's a strange "r" in front of each line: r"regex".
> >> That means I will have to explain string escaping to them. Then there's the
> >> "^" and "$" signs, both which requires explaining regular expressions at
> >> length. Then there's [0-9]+ and finally there's the parenthesis around the
> >> regex. All in all, looking at URLs from a beginners perspective, they are a
> >> bunch of hieroglyphs, and very hard for beginners to grasp right away.
> >>
> >> I'm not suggesting that urls.py are changed for most users, I'm
> >> suggesting that *simple_url* method (name inspired by simple_tag) is added
> >> to django.conf.urls that new users can use to get started quickly. This
> >> means that most beginners can postpone learning regexes a couple of months.
> >> The exact syntax that simple_url takes isn't important to me, as long it's
> >> a lot more beginner friendly than what we have today:
> >>
> >> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
> >>
> >> Just to get the ideas flowing, here's a suggestion, inspired by rails
> >> (again, exact syntax isn't important to me, simplicity to beginners is, so
> >> feel free to suggest something else if you agree that this is an important
> >> issue):
> >>
> >> from django.conf.urls import simple_url
> >> from . import views
> >> urlpatterns = [
> >> simple_url('articles/2003/', views.special_case_2003),
> >> simple_url('articles/:year)/', views.year_archive),
> >> simple_url('articles/:year/:month/', views.month_archive),
> >> simple_url('articles/:year/:month/:day/', views.article_detail),
> >> ]
> >>
> >> All parameters would be passed to the view as keyword parameters with the 
> >> name given and as a string, and validation would happen there instead.
> >>
> >> I'm thinking there should be no settings with simple_url, and that any 
> >> more advanced use-case should switch to using url instead.
> >>
> >> Two 

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

This is actually an interesting concept, and wouldn't incur an overheard at 
runtime if simple_url translated in to full regex format at launch time (or 
on first request, which is when the urls get loaded if I recall correctly).

I don't think this would get in the way of includes, and if it's a 
translator to full regex format, it can be done in a separate format. 


The example from flask is interesting. What if we could define regex for 
our urls to have it pluggable.


simple_url.register('integer', r'[0-9]+')


On Monday, 12 September 2016 21:32:45 UTC+1, Emil Stenström wrote:
>
> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute 
> beginners. The course is a combination of HTML, CSS, Python, and Django, 
> and after five days of coding they have a real live website that they can 
> show to friends. It's always such a great experience to see the look in 
> their eyes when they finally understand how they can tame Django to do what 
> they want.
>
> There's one big thing that keeps tripping them up is urls.py. When 
> specifying URL:s I get lots of questions about the regexes that they have 
> to specify. First: there's a strange "r" in front of each line: r"regex". 
> That means I will have to explain string escaping to them. Then there's the 
> "^" and "$" signs, both which requires explaining regular expressions at 
> length. Then there's [0-9]+ and finally there's the parenthesis around the 
> regex. All in all, looking at URLs from a beginners perspective, they are a 
> bunch of hieroglyphs, and very hard for beginners to grasp right away. 
>
> I'm not suggesting that urls.py are changed for most users, I'm suggesting 
> that *simple_url* method (name inspired by simple_tag) is added to 
> django.conf.urls 
> that new users can use to get started quickly. This means that most 
> beginners can postpone learning regexes a couple of months. The exact 
> syntax that simple_url takes isn't important to me, as long it's a lot more 
> beginner friendly than what we have today:
>
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>
> Just to get the ideas flowing, here's a suggestion, inspired by rails 
> (again, exact syntax isn't important to me, simplicity to beginners is, so 
> feel free to suggest something else if you agree that this is an important 
> issue):
>
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [ 
> simple_url('articles/2003/', views.special_case_2003), 
> simple_url('articles/:year)/', views.year_archive), 
> simple_url('articles/:year/:month/', views.month_archive), 
> simple_url('articles/:year/:month/:day/', views.article_detail), 
> ]
>
> All parameters would be passed to the view as keyword parameters with the 
> name given and as a string, and validation would happen there instead. 
>
> I'm thinking there should be no settings with simple_url, and that any more 
> advanced use-case should switch to using url instead.
>
> Two questions:
>
> A) What do you think about the prospect of simplifying urls.py for beginners?
> B) What do you think about the specific suggestion to mimic Rails urls with a 
> simple_url tag?
>
> Thanks for reading!
>
>

-- 
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/545a0c83-07c5-4468-b14a-bacfb949b7ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Emil Stenström]

Hi Ares,

Your suggestion, used in urls.py would translate to:

from django.conf.urls import simple_url
from . import views
urlpatterns = [ 
simple_url('articles/2003/', views.special_case_2003), 
simple_url('articles//', views.year_archive), 
simple_url('articles///', 
views.month_archive), 
simple_url('articles', 
views.article_detail), 
]


... which would also be fine by me. This would mean that the types of 
parameters would have to be specified beforehand by django. Therefore I 
would suggest we instead use the simpler method I suggested earlier. 

On Tuesday, 13 September 2016 08:26:44 UTC+2, Ares Ou wrote:
>
> Hi,
>
> Actually flask uses a style very similar to what you want. 
>
> To my knowing, you must use this pattern for Django because it has the 
> concept of *including *
> URLs.
>
> Routing in flask:
>
> @app.route('post/', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
>
> But the problem is, you have to specify the whole URL for every view you 
> define.
>
> Django avoids this by separating URL patterns into different levels, 
> that's why it uses regex to 
> identify the exact path. I guess it is hard for Django to organize URLs in 
> different apps by using
> such simple method.
>
> Looking forward to more ideas!
>
> Best regards,
> Ares Ou
>
> *Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328 
> - 5968
>
> *Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack 
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
>
> Ares Ou
>
> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
> constantine...@gmail.com > wrote:
>
>> Hi Emil,
>>
>> It is a very interesting idea.
>>
>> +1 from me
>>
>> On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström > > wrote:
>>
>>> Hi Djangonauts,
>>>
>>> I'm just back from my second year of teaching Django to absolute 
>>> beginners. The course is a combination of HTML, CSS, Python, and Django, 
>>> and after five days of coding they have a real live website that they can 
>>> show to friends. It's always such a great experience to see the look in 
>>> their eyes when they finally understand how they can tame Django to do what 
>>> they want.
>>>
>>> There's one big thing that keeps tripping them up is urls.py. When 
>>> specifying URL:s I get lots of questions about the regexes that they have 
>>> to specify. First: there's a strange "r" in front of each line: r"regex". 
>>> That means I will have to explain string escaping to them. Then there's the 
>>> "^" and "$" signs, both which requires explaining regular expressions at 
>>> length. Then there's [0-9]+ and finally there's the parenthesis around the 
>>> regex. All in all, looking at URLs from a beginners perspective, they are a 
>>> bunch of hieroglyphs, and very hard for beginners to grasp right away. 
>>>
>>> I'm not suggesting that urls.py are changed for most users, I'm 
>>> suggesting that *simple_url* method (name inspired by simple_tag) is added 
>>> to django.conf.urls that new users can use to get started quickly. This 
>>> means that most beginners can postpone learning regexes a couple of months. 
>>> The exact syntax that simple_url takes isn't important to me, as long it's 
>>> a lot more beginner friendly than what we have today:
>>>
>>> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>>>
>>> Just to get the ideas flowing, here's a suggestion, inspired by rails 
>>> (again, exact syntax isn't important to me, simplicity to beginners is, so 
>>> feel free to suggest something else if you agree that this is an important 
>>> issue):
>>>
>>> from django.conf.urls import simple_url
>>> from . import views
>>> urlpatterns = [ 
>>> simple_url('articles/2003/', views.special_case_2003), 
>>> simple_url('articles/:year)/', views.year_archive), 
>>> simple_url('articles/:year/:month/', views.month_archive), 
>>> simple_url('articles/:year/:month/:day/', views.article_detail), 
>>> ]
>>>
>>> All parameters would be passed to the view as keyword parameters with the 
>>> name given and as a string, and validation would happen there instead. 
>>>
>>> I'm thinking there should be no settings with simple_url, and that any more 
>>> advanced use-case should switch to using url instead.
>>>
>>> Two questions:
>>>
>>> A) What do you think about the prospect of simplifying urls.py for 
>>> beginners?
>>> B) What do you think about the specific suggestion to mimic Rails urls with 
>>> a simple_url tag?
>>>
>>> Thanks for reading!
>>>
>>> -- 
>>> 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 

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

This is actually an interesting concept, and wouldn't incur an, overheard
at runtime if simple_url translated in to full regex format at launch time
(or on first request, which is when the urls get loaded if I recall
correctly).

I don't think this would get in the way of includes, and if it's a
translator to full regex format, it can be done in a separate format.

Your example of flask's is interesting. What if we could define regex for
our urls to have it pluggable.

simple_url.register('integer', r'[0-9]+')

On 13 Sep 2016 07:26, "Ares Ou"  wrote:

> Hi,
>
> Actually flask uses a style very similar to what you want.
>
> To my knowing, you must use this pattern for Django because it has the
> concept of *including *
> URLs.
>
> Routing in flask:
>
> @app.route('post/', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
>
> But the problem is, you have to specify the whole URL for every view you
> define.
>
> Django avoids this by separating URL patterns into different levels,
> that's why it uses regex to
> identify the exact path. I guess it is hard for Django to organize URLs in
> different apps by using
> such simple method.
>
> Looking forward to more ideas!
>
> Best regards,
> Ares Ou
>
> *Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328
> - 5968
>
> *Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
>
> Ares Ou
>
> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
> constantine.covtushe...@gmail.com> wrote:
>
>> Hi Emil,
>>
>> It is a very interesting idea.
>>
>> +1 from me
>>
>> On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
>>
>>> Hi Djangonauts,
>>>
>>> I'm just back from my second year of teaching Django to absolute
>>> beginners. The course is a combination of HTML, CSS, Python, and Django,
>>> and after five days of coding they have a real live website that they can
>>> show to friends. It's always such a great experience to see the look in
>>> their eyes when they finally understand how they can tame Django to do what
>>> they want.
>>>
>>> There's one big thing that keeps tripping them up is urls.py. When
>>> specifying URL:s I get lots of questions about the regexes that they have
>>> to specify. First: there's a strange "r" in front of each line: r"regex".
>>> That means I will have to explain string escaping to them. Then there's the
>>> "^" and "$" signs, both which requires explaining regular expressions at
>>> length. Then there's [0-9]+ and finally there's the parenthesis around the
>>> regex. All in all, looking at URLs from a beginners perspective, they are a
>>> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>>>
>>> I'm not suggesting that urls.py are changed for most users, I'm
>>> suggesting that *simple_url* method (name inspired by simple_tag) is added
>>> to django.conf.urls that new users can use to get started quickly. This
>>> means that most beginners can postpone learning regexes a couple of months.
>>> The exact syntax that simple_url takes isn't important to me, as long it's
>>> a lot more beginner friendly than what we have today:
>>>
>>> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>>>
>>> Just to get the ideas flowing, here's a suggestion, inspired by rails
>>> (again, exact syntax isn't important to me, simplicity to beginners is, so
>>> feel free to suggest something else if you agree that this is an important
>>> issue):
>>>
>>> from django.conf.urls import simple_url
>>> from . import views
>>> urlpatterns = [
>>> simple_url('articles/2003/', views.special_case_2003),
>>> simple_url('articles/:year)/', views.year_archive),
>>> simple_url('articles/:year/:month/', views.month_archive),
>>> simple_url('articles/:year/:month/:day/', views.article_detail),
>>> ]
>>>
>>> All parameters would be passed to the view as keyword parameters with the 
>>> name given and as a string, and validation would happen there instead.
>>>
>>> I'm thinking there should be no settings with simple_url, and that any more 
>>> advanced use-case should switch to using url instead.
>>>
>>> Two questions:
>>>
>>> A) What do you think about the prospect of simplifying urls.py for 
>>> beginners?
>>> B) What do you think about the specific suggestion to mimic Rails urls with 
>>> a simple_url tag?
>>>
>>> Thanks for reading!
>>>
>>> --
>>> 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 

Re: Challenge teaching Django to beginners: urls.py

[Michal Petrucha]

Tjena Emil,

On Mon, Sep 12, 2016 at 01:32:45PM -0700, Emil Stenström wrote:
> Hi Djangonauts,
> 
> I'm just back from my second year of teaching Django to absolute beginners. 
> The course is a combination of HTML, CSS, Python, and Django, and after 
> five days of coding they have a real live website that they can show to 
> friends. It's always such a great experience to see the look in their eyes 
> when they finally understand how they can tame Django to do what they want.
> 
> There's one big thing that keeps tripping them up is urls.py. When 
> specifying URL:s I get lots of questions about the regexes that they have 
> to specify. First: there's a strange "r" in front of each line: r"regex". 
> That means I will have to explain string escaping to them. Then there's the 
> "^" and "$" signs, both which requires explaining regular expressions at 
> length. Then there's [0-9]+ and finally there's the parenthesis around the 
> regex. All in all, looking at URLs from a beginners perspective, they are a 
> bunch of hieroglyphs, and very hard for beginners to grasp right away. 
> 
> I'm not suggesting that urls.py are changed for most users, I'm suggesting 
> that *simple_url* method (name inspired by simple_tag) is added to 
> django.conf.urls 
> that new users can use to get started quickly. This means that most 
> beginners can postpone learning regexes a couple of months. The exact 
> syntax that simple_url takes isn't important to me, as long it's a lot more 
> beginner friendly than what we have today:
> 
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
> 
> Just to get the ideas flowing, here's a suggestion, inspired by rails 
> (again, exact syntax isn't important to me, simplicity to beginners is, so 
> feel free to suggest something else if you agree that this is an important 
> issue):
> 
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [ 
> simple_url('articles/2003/', views.special_case_2003), 
> simple_url('articles/:year)/', views.year_archive), 
> simple_url('articles/:year/:month/', views.month_archive), 
> simple_url('articles/:year/:month/:day/', views.article_detail), 
> ]
> 
> All parameters would be passed to the view as keyword parameters with the 
> name given and as a string, and validation would happen there instead. 
> 
> I'm thinking there should be no settings with simple_url, and that any more 
> advanced use-case should switch to using url instead.
> 
> Two questions:
> 
> A) What do you think about the prospect of simplifying urls.py for beginners?

I can certainly see where this proposal is coming from. I understand
that diving into regular expressions can derail the learning process,
and regular expressions are quite a heavy topic, especially when you
just want to move forward through the URL routing part.

On the other hand, regular expressions are a bit more flexible than
what for example Flask does with is own syntax, and I'm not a big fan
of having two ways of doing things. Then again, one very rarely needs
the full power of regular expressions, so having something simpler by
default wouldn't hurt the readability of most URL patterns.

I guess I'm about +0 on this question...

> B) What do you think about the specific suggestion to mimic Rails urls with a 
> simple_url tag?

FWIW, if we choose to implement your proposal, I'm not very convinced
by the Rails syntax (just based on your example). It feels like it
hides too much – how does it decide on which character it will end the
":year" argument? There's no information that would make it apparent
what characters will land inside the argument, and which will not.

I'd be more in favor of the syntax used by Flask (or is it
Werkzeug...?), where you add type information as well: .
This, in my opinion, gives a better idea of what kind of characters is
expected there. On the other hand, it could also lead to
misunderstandings if we just turn those patterns into regular
expressions, and otherwise use the same resolver machinery that we
already have – the view would then still get the string extracted from
the URL, not an integer as it says in the pattern. Not sure if that
can be a problem or not.

Cheers,

Michal

-- 
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/20160913073232.GR6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Django Channels Load Testing Results

[Erik Cederstrand]

> Den 13. sep. 2016 kl. 03.41 skrev 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?

First of all, thanks for taking the time to actually do the measurements! It's 
insightful and very much appreciated.

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". Also, 300K requests in 10 minutes is 500 rps, but 
the text says 500 rps. Which is it?

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.

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.

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?

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/4CB46E99-6603-42A3-BEFD-C49CC920EEA2%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Florian Apolloner]

Hi Emil,

There are projects like https://github.com/codysoyland/surlex which I like 
very much. In the end, whatever you can come up which translates to regex 
in the background would work just fine for django. I personally like what 
werkzeug does -- "stealing" that sounds like an idea too :D I do not think 
any core dev would be opposed to get rid of regexes by default (as long as 
you can still fall back to them). I personally would really like a system 
that works without regex on the "outside", and I'd be happy about a DEP 
after some further discussions here.

Cheers,
Florian

On Monday, September 12, 2016 at 10:32:45 PM UTC+2, Emil Stenström wrote:
>
> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute 
> beginners. The course is a combination of HTML, CSS, Python, and Django, 
> and after five days of coding they have a real live website that they can 
> show to friends. It's always such a great experience to see the look in 
> their eyes when they finally understand how they can tame Django to do what 
> they want.
>
> There's one big thing that keeps tripping them up is urls.py. When 
> specifying URL:s I get lots of questions about the regexes that they have 
> to specify. First: there's a strange "r" in front of each line: r"regex". 
> That means I will have to explain string escaping to them. Then there's the 
> "^" and "$" signs, both which requires explaining regular expressions at 
> length. Then there's [0-9]+ and finally there's the parenthesis around the 
> regex. All in all, looking at URLs from a beginners perspective, they are a 
> bunch of hieroglyphs, and very hard for beginners to grasp right away. 
>
> I'm not suggesting that urls.py are changed for most users, I'm suggesting 
> that *simple_url* method (name inspired by simple_tag) is added to 
> django.conf.urls 
> that new users can use to get started quickly. This means that most 
> beginners can postpone learning regexes a couple of months. The exact 
> syntax that simple_url takes isn't important to me, as long it's a lot more 
> beginner friendly than what we have today:
>
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>
> Just to get the ideas flowing, here's a suggestion, inspired by rails 
> (again, exact syntax isn't important to me, simplicity to beginners is, so 
> feel free to suggest something else if you agree that this is an important 
> issue):
>
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [ 
> simple_url('articles/2003/', views.special_case_2003), 
> simple_url('articles/:year)/', views.year_archive), 
> simple_url('articles/:year/:month/', views.month_archive), 
> simple_url('articles/:year/:month/:day/', views.article_detail), 
> ]
>
> All parameters would be passed to the view as keyword parameters with the 
> name given and as a string, and validation would happen there instead. 
>
> I'm thinking there should be no settings with simple_url, and that any more 
> advanced use-case should switch to using url instead.
>
> Two questions:
>
> A) What do you think about the prospect of simplifying urls.py for beginners?
> B) What do you think about the specific suggestion to mimic Rails urls with a 
> simple_url tag?
>
> Thanks for reading!
>
>

-- 
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/710c9f61-af2e-4b4f-9653-7adda8481c71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Ares Ou]

Hi,

Actually flask uses a style very similar to what you want.

To my knowing, you must use this pattern for Django because it has the
concept of *including *
URLs.

Routing in flask:

@app.route('post/', methods=['GET'])
def post_view(post_id=None):
# do something to render the post
return render_template('post.html', post=post)

But the problem is, you have to specify the whole URL for every view you
define.

Django avoids this by separating URL patterns into different levels, that's
why it uses regex to
identify the exact path. I guess it is hard for Django to organize URLs in
different apps by using
such simple method.

Looking forward to more ideas!

Best regards,
Ares Ou

*Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328 -
5968

*Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
Overflow:* http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
constantine.covtushe...@gmail.com> wrote:

> Hi Emil,
>
> It is a very interesting idea.
>
> +1 from me
>
> On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
>
>> Hi Djangonauts,
>>
>> I'm just back from my second year of teaching Django to absolute
>> beginners. The course is a combination of HTML, CSS, Python, and Django,
>> and after five days of coding they have a real live website that they can
>> show to friends. It's always such a great experience to see the look in
>> their eyes when they finally understand how they can tame Django to do what
>> they want.
>>
>> There's one big thing that keeps tripping them up is urls.py. When
>> specifying URL:s I get lots of questions about the regexes that they have
>> to specify. First: there's a strange "r" in front of each line: r"regex".
>> That means I will have to explain string escaping to them. Then there's the
>> "^" and "$" signs, both which requires explaining regular expressions at
>> length. Then there's [0-9]+ and finally there's the parenthesis around the
>> regex. All in all, looking at URLs from a beginners perspective, they are a
>> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>>
>> I'm not suggesting that urls.py are changed for most users, I'm
>> suggesting that *simple_url* method (name inspired by simple_tag) is added
>> to django.conf.urls that new users can use to get started quickly. This
>> means that most beginners can postpone learning regexes a couple of months.
>> The exact syntax that simple_url takes isn't important to me, as long it's
>> a lot more beginner friendly than what we have today:
>>
>> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>>
>> Just to get the ideas flowing, here's a suggestion, inspired by rails
>> (again, exact syntax isn't important to me, simplicity to beginners is, so
>> feel free to suggest something else if you agree that this is an important
>> issue):
>>
>> from django.conf.urls import simple_url
>> from . import views
>> urlpatterns = [
>> simple_url('articles/2003/', views.special_case_2003),
>> simple_url('articles/:year)/', views.year_archive),
>> simple_url('articles/:year/:month/', views.month_archive),
>> simple_url('articles/:year/:month/:day/', views.article_detail),
>> ]
>>
>> All parameters would be passed to the view as keyword parameters with the 
>> name given and as a string, and validation would happen there instead.
>>
>> I'm thinking there should be no settings with simple_url, and that any more 
>> advanced use-case should switch to using url instead.
>>
>> Two questions:
>>
>> A) What do you think about the prospect of simplifying urls.py for beginners?
>> B) What do you think about the specific suggestion to mimic Rails urls with 
>> a simple_url tag?
>>
>> Thanks for reading!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%
>> 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