DEP pre-proposal for a simpler URLs syntax.

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

Re: Built-in router link generator in Django

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 i

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

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 bas

Re: Built-in router link generator in Django

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 f

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

> 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

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

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

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

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

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

+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 mak

does anyone use models with underscores in the name?

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

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

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 proble

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

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 t

Re: delegating our static file serving

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 a

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

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 onl

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

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 A

Re: Built-in router link generator in Django

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,

Re: Contributing to ORM module

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 yo

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

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 = b

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

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 Re

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

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 t

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

On 3 Oct 2016, at 16:39, django-developers@googlegroups.com wrote: = Today's topic summary = Group: django-developers@googlegroups.com Url:

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

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

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

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 beca