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

[Aymeric Augustin]

Hello,

I agree that different names would be better. I wouldn’t use the word “simple” 
since many “simple” things grow and become less simple in the long run. SOAP 
stands for Simple Object Access Protocol… For this reason url() and regex_url() 
have my preference.

I’m in favor of the  order because I believe that “consistency with 
Python” is a stronger argument than “consistency with Flask”, but I have to 
admit that I never made significant use of Flask.

Best regards,

-- 
Aymeric.

> On 04 Oct 2016, at 00:11, Markus Holtermann  wrote:
> 
> Thanks for the draft, Tom. I'm a bit concerned that the different
> `url*()` functions you can import will become confusing. Can we have
> `regex_url()` (with chim for `url()`) -- as proposed -- and
> `simple_url()` instead?
> 
> /Markus
> 
> On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:
>> Okay then, I've made some updates:
>> 
>> * Updated the import design, in line with Jacob's suggestion.
>> * Brief note on URL conventions, and the leading '/'.
>> * Section on guarding against errors between `from django.conf.urls import
>> url` and `from django.urls import url`.
>> * Brief note on the internal RegexURLPattern API.
>> * Breakout of required implementation tasks.
>> 
>> Also, wrt Ryan's suggestion of reversing the ordering of name and type:
>> I've some sympathy towards it, but I believe that presenting a consistent
>> API between both Flask and Django is a more important factor.
>> 
>> Cheers all,
>> 
>> 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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%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/20161003221128.GB23889%40pyler.local.
> 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/DF8D81E2-7370-494C-90E4-E28E0A9B3897%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: does anyone use models with underscores in the name?

[Constantine Covtushenko]

I am using such names in one of my project.
I found it very helpful for audit like fields: _cr_date and _cr_user

Regards,
Constantine C.

> On Oct 3, 2016, at 19:30, Tim Graham  wrote:
> 
> Ticket #27295 notes that the ORM doesn't work well with models that start 
> with an underscore (e.g. _UsersGroup). I didn't check if the same problem 
> exists with an underscore anywhere in the name, but I wanted to ask if anyone 
> has seen model names that use underscores? If not, my proposal is to add a 
> system check that prohibits an underscore in model names.
> 
> https://code.djangoproject.com/ticket/27295
> 
> -- 
> 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/44532a2c-69b7-45d7-8782-7b87eea09a20%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/E699F724-9436-41BC-A291-C238F9318039%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Abridged summary of django-developers@googlegroups.com - 3 updates in 2 topics

[Greg Brown]

On 3 Oct 2016, at 16:39, django-developers@googlegroups.com wrote:


=
Today's topic summary
=

Group: django-developers@googlegroups.com
Url:
  
https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/django-developers/topics

  - Built-in router link generator in Django [1 Update]
http://groups.google.com/group/django-developers/t/7a5e967ef4a220ae
  - Contributing to ORM module [2 Updates]
http://groups.google.com/group/django-developers/t/7b43c05ddb6f1e3d

=
Topic: Built-in router link generator in Django
Url: 
http://groups.google.com/group/django-developers/t/7a5e967ef4a220ae

=

-- 1 of 1 --
From: Val Neekman 
Date: Oct 02 07:24PM -0700
Url: 
http://groups.google.com/group/django-developers/msg/6aaed05dec214


Folks,

I am wondering if Django would benefit from the inclusion of this 
package

or something like it?

https://github.com/un33k/django-menuware

A utility module to auto generate links from

=
Topic: Contributing to ORM module
Url: 
http://groups.google.com/group/django-developers/t/7b43c05ddb6f1e3d

=

-- 1 of 2 --
From: evgeniym...@gmail.com
Date: Oct 02 05:49AM -0700
Url: 
http://groups.google.com/group/django-developers/msg/687486b878ea2


Hi everyone!

First of all, I'm not sure that I'm writing in the right place, so 
excuse

me if this so.

Second - let me introduce myself - my Name is Evgeniy, I'm active web

-- 2 of 2 --
From: ludovic coues 
Date: Oct 02 05:58PM +0200
Url: 
http://groups.google.com/group/django-developers/msg/688d09fbe8398


There is a list of bug and feature request on the django's tracker

https://code.djangoproject.com/query

--

Cordialement, Coues Ludovic
+336 148 743 42

--
You received this digest because you're subscribed to updates for this 
group. You can change your settings on the group membership page:

  
https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/django-developers/join
.
To unsubscribe from this group and stop receiving emails from it send 
an email to django-developers+unsubscr...@googlegroups.com.



--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/32CD6390-99D1-486B-8240-94CFDBA3FA45%40gregbrown.co.nz.
For more options, visit https://groups.google.com/d/optout.

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

[Markus Holtermann]

Thanks for the draft, Tom. I'm a bit concerned that the different
`url*()` functions you can import will become confusing. Can we have
`regex_url()` (with chim for `url()`) -- as proposed -- and
`simple_url()` instead?

/Markus

On Mon, Oct 03, 2016 at 02:34:58PM -0700, Tom Christie wrote:

Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import
url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

Also, wrt Ryan's suggestion of reversing the ordering of name and type:
I've some sympathy towards it, but I believe that presenting a consistent
API between both Flask and Django is a more important factor.

Cheers all,

 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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%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/20161003221128.GB23889%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Tom Christie]

Okay then, I've made some updates:

* Updated the import design, in line with Jacob's suggestion.
* Brief note on URL conventions, and the leading '/'.
* Section on guarding against errors between `from django.conf.urls import 
url` and `from django.urls import url`.
* Brief note on the internal RegexURLPattern API.
* Breakout of required implementation tasks.

 Also, wrt Ryan's suggestion of reversing the ordering of name and type: 
I've some sympathy towards it, but I believe that presenting a consistent 
API between both Flask and Django is a more important factor.

Cheers all,

  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/6a75cb7d-6df2-45e7-8efe-6c2f0526cfbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature suggestion: Option to suppress system checks in commands

[Tim Graham]

I'm interested to know which checks you want to suppress only in some cases?

On Friday, September 30, 2016 at 7:33:02 AM UTC-4, Bogdan Bursuc wrote:
>
> Hi,
>
> You could add the setting through and env variable and obtain that 
> variable inside the settings file with
> SILENCED_SYSTEM_CHECKS = bool(os.environ.get("SILENCED_SYSTEM_CHEKS", 
> false))
>
>
> On Fri, Sep 30, 2016 at 11:31 AM Vlastimil Zíma  > wrote:
>
>> Hi everyone,
>>
>> I'd suggest an options for all commands to suppress a defined system 
>> checks when running a command. I know it is possible to defined 
>> SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything 
>> including the check command itself. My point is to suppress system checks 
>> mainly for cron jobs, so they don't report errors. I don't want to use 
>> settings because I don't want to suppress checks for migrate and other 
>> commands when deploying new version of application.
>>
>> I don't want to suppress checks for our commands either, since there is 
>> only option to suppress checks completely.
>>
>> Any support for this feature?
>>
>> Regards,
>> Vlastimil
>>
>> -- 
>> 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/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Thanks,
> Bogdan I. Bursuc
>

-- 
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/e739bad8-dbd1-4fd8-b6b0-658288040ec7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Contributing to ORM module

[Tim Graham]

You can filter tickets by "Component". You'll want to look at the "Database 
layer (models, ORM)" component.

There are plenty of non-trivial issues to tackle, although it requires a 
lot of time just to understand the basics. I'd recommend trying to tackle 
some small issues first. That'll give you a better understanding of how 
much work some of the larger issues might be.

On Sunday, October 2, 2016 at 11:31:23 AM UTC-4, evgen...@gmail.com wrote:
>
> Hi everyone!
>
> First of all, I'm not sure that I'm writing in the right place, so excuse 
> me if this so.
>
> Second - let me introduce myself - my Name is Evgeniy, I'm active web 
> developer (mostly Django) for at least one year, and I'm finishing 
> university this winter by speciality "program engineering". So right now 
> I'm choosing a theme for my diploma. My background in SQL databases is more 
> deep, so I thought that I could implement some feature in Django's ORM 
> module, and describe it in my graduation work.
> The question is - is there available unimplemented features that should 
> improve performance of ORM module and at the same time is not easy, but 
> also is not incredible hard for one person like me? Thanks in advance, hope 
> for answer!
>

-- 
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/d4411175-d038-4a45-bf39-2b62e0a7b40e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Built-in router link generator in Django

[Michael Manfre]

Speaking generically about Django supporting community apps, which one
should get the golden ticket and be supported? There are usually many
similar options with groups of developers who support each for their own
reasons. Trying to pick one is a non-trivial task.

With regards to a menu generator, I don't think this is something Django
should officially support for the same reasons mentioned by Marc.

Regards,
Michael Manfre

On Mon, Oct 3, 2016 at 9:44 AM James Pic  wrote:

> True, this is a feature that's been invented a countless number of times.
> Perhaps one implementation could be supported by the organization ?
>
> --
> 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/CALC3Kacd2DJxG%2BfcACre5z%2Bp%2BnO%3DmhuM6RRHRT4DOV4k%2BBd%2B%2BQ%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/CAGdCwBsLzfWgymu1G%2BN7_bCxS7mo3vBJmxr6KS0qhJ2hOtROYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[Aymeric Augustin]

Hello,

FYI django-two-factor-auth builds upon django-otp; they aren't alternatives. 

This is an ambitious project. I suggest to start by getting a better 
understanding of what these libraries do, what the different scenarios for two 
factor authentication are, and writing a DEP to describe the APIs that would be 
added to Django. Look at the current public APIs of django.contrib.auth and 
figure out what would be needed to support 2FA with similar principles.

Starting from the lower layers — the equivalent of django-otp — seems (to me) 
to be a better way to go about this, but perhaps this is just a bottom-up vs 
top-down thing. Anyway, I suspect that a DEP that boils down to “merge 
django-two-factor-auth into Django” and includes integration with arbitrarily 
chosen commercial services would face some resistance; you need more structure 
and details.

I hope this helps,

-- 
Aymeric.

> On 03 Oct 2016, at 15:21, m.leven...@web.de wrote:
> 
> I would like to work on this ticket. As for the implementation there doesn't 
> seem to be much choice. The implementation with the most features is from 
> Bouke . It supports U2F, 
> TOTP, SMS and phone call (with Twilio by default). Beside that one only a few 
> packages exist:
> https://github.com/gavinwahl/django-u2f 
> : supports only U2F, according to 
> the developer it's not production ready
> https://bitbucket.org/psagers/django-otp/ 
> : supports TOTP, HOTP
> Based on the ticket description and the django developers discussion U2F and 
> TOTP are the most desired authentication methods. So I would like to 
> integrate them (orienting on Bouke 
> 's implementation) first. 
> And if SMS and email based authentication are also desired I would go about 
> them next.
> 
> -- 
> 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/0e80fdf8-2387-4835-8ba0-2d2af01442ec%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/0999AB8D-3CEF-494E-B9A6-A1F8E6F120EC%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[m . levental]

I would like to work on this ticket. As for the implementation there 
doesn't seem to be much choice. The implementation with the most features 
is from Bouke . It 
supports U2F, TOTP, SMS and phone call (with Twilio by default). Beside 
that one only a few packages exist:

   - https://github.com/gavinwahl/django-u2f: supports only U2F, according 
   to the developer it's not production ready
   - https://bitbucket.org/psagers/django-otp/: supports TOTP, HOTP

Based on the ticket description and the django developers discussion U2F 
and TOTP are the most desired authentication methods. So I would like to 
integrate them (orienting on Bouke 
's implementation) first. 
And if SMS and email based authentication are also desired I would go about 
them next.

-- 
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/0e80fdf8-2387-4835-8ba0-2d2af01442ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Aleksej Manaev]

Hello, I would like to work on this in the scope of my study project. Is 
someone already working on this?
I am fairly new to contributing to the framework, can you provide me more 
information on the current state of the issue, which problems need to be 
solved and which possible solutions there are available? Are there some 
resources I can read to educate myself in this topic?
I have already read the comments in this discussion and Django 
documentation 

https://docs.djangoproject.com/en/1.10/howto/static-files/ 
andhttps://docs.djangoproject.com/en/1.10/howto/static-files/deployment/.


Am Freitag, 28. November 2014 15:15:03 UTC+1 schrieb Tim Graham:
>
> Berker has worked on integrating gunicorn with runserver 
>  so that we might be able to 
> deprecate our own homegrown webserver. Windows support for gunicorn is 
> supposedly coming soon which 
> may actually make the idea feasible. This way we provide a more secure 
> solution out of the box (anecdotes indicate that runserver is widely used 
> in production despite our documentation warnings against doing so).
>
> On the pull request, Anssi had an idea to use dj-static 
>  to serve static/media files. 
> My understanding is that we would basically integrate the code for 
> dj-static into Django and then add a dependency on static 
> . It could be an optional dependency 
> since you might want to serve static files differently in production, but 
> it would likely be more or less universally used in development. We could 
> then say that django.views.static.serve (and its counterpart in 
> staticfiles) is okay to use in production (and I guess people are already 
> using them in production despite our warnings that they are not hardened 
> for production use).
>
> What do you think of this plan?
>

-- 
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/342138dd-953d-4aa4-8c7d-f4627591005a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

Loving this work! There's one thing that Flask's routing syntax does that 
strikes me as backward, and it may be a good idea to consider reversing it: the 
converter indication.

I suggest that rather than it being `` it should be 
``, because the converter is very similar to a type, and we 
have the precedence of Python's typing syntax of `name: type`. It meets my 
sensibilities to follow Python's example.

Of course, we've also got the example from Flask to contend with, so it's a 
value judgement.


> On Oct 3, 2016, at 10:55 AM, Aymeric Augustin 
>  wrote:
> 
> +1 Tom’s proposal and Jacob’s comments.
> 
> -- 
> Aymeric.
> 
>> On 03 Oct 2016, at 16:39, Jacob Kaplan-Moss > > wrote:
>> 
>> Hi Tom -
>> 
>> Thanks for putting this together! Overall, +1 from me as well: I've taught 
>> Django to a bunch of beginners, and URLs are one of the major pain points. 
>> I'd love to make them easier, and your proposal looks pretty dang great.
>> 
>> Some specific feedback:
>> 
>> 1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my 
>> experience has been that every time we try to be clever like that, we end up 
>> regretting it down the line. "Explicit is better than implicit", and all 
>> that. It's more awkward, but I'd prefer different calls/constructors for 
>> URLs. I think this also lets us set up a better upgrade/transition path. My 
>> suggestion is that we move towards `url()` giving "new style" patterns, and 
>> have another helper ("url_regex"? "urlr"?) that provides regex resolving. We 
>> could also take this opportunity to simplify import paths, so:
>> 
>> - `from django.urls import url` <--- new-style resolver
>> - `from django.urls import url_regex` <--- old-style resolver
>> - `from django.conf.urls import url` <--- old-style resolver, with 
>> PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade 
>> path.
>> 
>> 2. Huge +1 on copying Flask's converters and API. Flask nailed the routing 
>> syntax, no need to reinvent the wheel!
>> 
>> 3. Documentation: I suggest introducing the new syntax immediately in all 
>> the documentation. It's better for like 90% of the cases.
>> 
>> Thanks again, I'm stoked to see some motion here.
>> 
>> Jacob
>> 
>> On Mon, Oct 3, 2016 at 3:24 AM, 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 
>>  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/1450171a-be2b-41e8-b221-91bfe656d039%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 

Re: does anyone use models with underscores in the name?

[ludovic coues]

I have seen that and so far I haven't found any issue if the
underscore is in the middle of the model name.

2016-10-03 18:30 GMT+02:00 Tim Graham :
> Ticket #27295 notes that the ORM doesn't work well with models that start
> with an underscore (e.g. _UsersGroup). I didn't check if the same problem
> exists with an underscore anywhere in the name, but I wanted to ask if
> anyone has seen model names that use underscores? If not, my proposal is to
> add a system check that prohibits an underscore in model names.
>
> https://code.djangoproject.com/ticket/27295
>
> --
> 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/44532a2c-69b7-45d7-8782-7b87eea09a20%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%2BTZ-7O0snWMis2S6Sw2oA_cAaKSP_OYAaTsKTFAbwP5upg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

does anyone use models with underscores in the name?

[Tim Graham]

Ticket #27295 notes that the ORM doesn't work well with models that start 
with an underscore (e.g. _UsersGroup). I didn't check if the same problem 
exists with an underscore anywhere in the name, but I wanted to ask if 
anyone has seen model names that use underscores? If not, my proposal is to 
add a system check that prohibits an underscore in model names.

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

-- 
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/44532a2c-69b7-45d7-8782-7b87eea09a20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aymeric Augustin]

+1 Tom’s proposal and Jacob’s comments.

-- 
Aymeric.

> On 03 Oct 2016, at 16:39, Jacob Kaplan-Moss  wrote:
> 
> Hi Tom -
> 
> Thanks for putting this together! Overall, +1 from me as well: I've taught 
> Django to a bunch of beginners, and URLs are one of the major pain points. 
> I'd love to make them easier, and your proposal looks pretty dang great.
> 
> Some specific feedback:
> 
> 1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my 
> experience has been that every time we try to be clever like that, we end up 
> regretting it down the line. "Explicit is better than implicit", and all 
> that. It's more awkward, but I'd prefer different calls/constructors for 
> URLs. I think this also lets us set up a better upgrade/transition path. My 
> suggestion is that we move towards `url()` giving "new style" patterns, and 
> have another helper ("url_regex"? "urlr"?) that provides regex resolving. We 
> could also take this opportunity to simplify import paths, so:
> 
> - `from django.urls import url` <--- new-style resolver
> - `from django.urls import url_regex` <--- old-style resolver
> - `from django.conf.urls import url` <--- old-style resolver, with 
> PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade 
> path.
> 
> 2. Huge +1 on copying Flask's converters and API. Flask nailed the routing 
> syntax, no need to reinvent the wheel!
> 
> 3. Documentation: I suggest introducing the new syntax immediately in all the 
> documentation. It's better for like 90% of the cases.
> 
> Thanks again, I'm stoked to see some motion here.
> 
> Jacob
> 
> On Mon, Oct 3, 2016 at 3:24 AM, 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 
>  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/1450171a-be2b-41e8-b221-91bfe656d039%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/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%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 
"Djang

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

[Tom Christie]

> My suggestion is that we move towards `url()` giving "new style" patterns

Agreed. I couldn't see a nice way around to do that, but moving the import 
to `from django.urls import url` sidesteps the issue nicely.
Sounds good to 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/5384cbd3-5873-4532-9a0f-9963d20d13dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jacob Kaplan-Moss]

Hi Tom -

Thanks for putting this together! Overall, +1 from me as well: I've taught
Django to a bunch of beginners, and URLs are one of the major pain points.
I'd love to make them easier, and your proposal looks pretty dang great.

Some specific feedback:

1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my
experience has been that every time we try to be clever like that, we end
up regretting it down the line. "Explicit is better than implicit", and all
that. It's more awkward, but I'd prefer different calls/constructors for
URLs. I think this also lets us set up a better upgrade/transition path. My
suggestion is that we move towards `url()` giving "new style" patterns, and
have another helper ("url_regex"? "urlr"?) that provides regex resolving.
We could also take this opportunity to simplify import paths, so:

- `from django.urls import url` <--- new-style resolver
- `from django.urls import url_regex` <--- old-style resolver
- `from django.conf.urls import url` <--- old-style resolver, with
PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade
path.

2. Huge +1 on copying Flask's converters and API. Flask nailed the routing
syntax, no need to reinvent the wheel!

3. Documentation: I suggest introducing the new syntax immediately in all
the documentation. It's better for like 90% of the cases.

Thanks again, I'm stoked to see some motion here.

Jacob

On Mon, Oct 3, 2016 at 3:24 AM, 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
>  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/1450171a-be2b-41e8-b221-
> 91bfe656d039%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/CAK8PqJEbne2fp9X3Q1Dgr7OG3Ns54A1gqdndwCD5FXNT8j%3DXTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tom Christie]

> There's text that elaborates on how to detect which one of the two 
options is implied. I'd recommend making that a section in and of itself.

Probably a good plan, yup. I was somewhat writing that section as I 
thought, so it comes out a bit jumbled. I'm more confident in retrospect 
that regex vs typed detection is a reasonable approach. I can't see any 
obvious problems there that I'm missing. I'll take another pass at that in 
due course.

> The DEP states that the new routing will be implemented in terms of the 
existing regex based system. Could you add a note here stating that that's 
merely an implementation detail?

Yup - I've done a bit of re-wording in order to try to clear that up.

Thanks!

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

Re: Built-in router link generator in Django

[James Pic]

True, this is a feature that's been invented a countless number of times.
Perhaps one implementation could be supported by the organization ?

-- 
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/CALC3Kacd2DJxG%2BfcACre5z%2Bp%2BnO%3DmhuM6RRHRT4DOV4k%2BBd%2B%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sjoerd Job Postmus]

Hi Tom,

Nicely written DEP.

I have some ideas/suggestions:

- There's text that elaborates on how to detect which one of the two 
options is implied. I'd recommend making that a section in and of itself.
- The DEP states that the new routing will be implemented in terms of the 
existing regex based system. Could you add a note here stating that that's 
merely an implementation detail?

Kind regards,
Sjoerd Job

On Monday, October 3, 2016 at 12:24:04 PM UTC+2, 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 
>  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/1d4e1382-e91b-469d-9f7b-dbf84a94e6b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Built-in router link generator in Django

[Marc Tamlyn]

This doesn't seem like something which is the responsibility of core django
to me. There are dozens of different ways to build your menus, I don't see
anything about that package which makes it the best way of doing it.

On 3 October 2016 at 03:24, Val Neekman  wrote:

> Folks,
>
> I am wondering if Django would benefit from the inclusion of this package
> or something like it?
>
> https://github.com/un33k/django-menuware
>
> A utility module to auto generate links from configuration.
>
> Thanks,
> Val
>
>
> --
> 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/6df84fa1-e831-4ee2-abaf-
> e140d9e28b89%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/CAMwjO1EcCBp%3DYyr0c39L3n2YeiyiK4Gm4Fq7aWndsXdYzmxWEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

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 
 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/1450171a-be2b-41e8-b221-91bfe656d039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.