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

In all fairness, it's actually magic_urlpatterns_you_will_never_see = path('/', include(the_urlconf)) Django uses the magic_urlpatterns_you_will_never_see, which already includes that slash. My recommendation would be to forgo the starting slash. In Flask you provide the full route ("absolute path"

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

Yup, good points there. I wasn't really considering `include` at that point. Definitely some awkwardnesses that need thinking about there. urlpatterns = [ path('', homepage), path('users/', users_list) ] Looks very odd to me, since those are not actually valid URL paths. ('/' and '/user

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

On Tue, Oct 04, 2016 at 09:21:33AM -0700, Tom Christie wrote: > > The only technical reason I see for enforcing the starting slash > > The leading slash in the syntax is open to discussion, however I'm very > strongly in favor due to two points: > > * It is a strong and consistent visual indicat

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

On Oct 4, 2016 15:53, ludovic coues wrote: > > > The question about the old routing system is about the plan to build > on top the old one. I'm not saying the old one is bad. But if we start > to build upon it, it will be harder to replace it. It might be more > interesting to refactor the routin

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

> About the url convention We're not changing anything about the URL conventions, we're changing the oath syntax. Django tends to use a trailing slash style by convention. This proposal wouldn't change that in any way. > The only technical reason I see for enforcing the starting slash The lead

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

On 04 Oct 2016, at 15:53, ludovic coues wrote: > Sorry about the way the question are formulated. Writing a rambling > post under emotion was pretty stupid of me. No worries. It happens :-) -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django deve

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

Sorry about the way the question are formulated. Writing a rambling post under emotion was pretty stupid of me. About the url convention, the DEP take a pretty strong stance, suggesting to raise an exception if the user don't use a convention which is different from the one in place. I don't recog

Re: delegating our static file serving

Hi, I don't know of any updates on this issue outside of this thread. I think you could read through the thread and summarize the problems and possible solutions just as well as I could. The solution might involve integrating whitenoise in Django, as well an adding some enhancements. The whiten

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

Hello Ludovic, On 04 Oct 2016, at 14:25, ludovic coues wrote: > I have a better DEP for you. > Introduce a dependency on django-simple-url. I don’t think we want to depend on a third party package for something as fundamental as URL dispatching. We can take good ideas and, if the license allow

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

In my opinion, there is too much question for this DEP. Here is a quick timeline. September 12, Emil Stenström rise a valid criticism, using regex for url routing is a bit too much in 99% of the case. It suggest a syntax similar to the ruby on rails routing syntax. September 13, someone mention sur

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

I think I once implemented something that dynamically generated model classes at runtime and prefixed the class names with an underscore. But I also didn't do much with those models other than set up tables for them and store/retrieve instances with very simple queries. Also, what I was doing was

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

On Mon, Oct 03, 2016 at 09:30:44AM -0700, 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 ha

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

To be clear, the proposed restriction is about starting model names with underscores, not model field names. I think you're usage refers to fields, but let me know if not. On Tuesday, October 4, 2016 at 1:45:34 AM UTC-4, Constantine Covtushenko wrote: > > I am using such names in one of my proj

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

Thanks for your update, Tom! 1. I think `route` is used in Django Channels (haven't looked it up. Not a real issue but something to think about). I'd prefer `path` instead. 2. Too much magic for my taste. I like the explicit name `typed_url` though (if we stick with `url` as opposed to `path` as

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

This looks like a useful addition. I'd also like to chip in with a DRY pattern I've been using in all my projects which might be worth considering. To take your example: def url_tree(regex, *urls): return url(regex, include(patterns('', *urls))) urlpatterns = [ > url_tree('articles/', >

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

Some possibilities: 1. Use a different name for the new function. path('/users//') Actually `path` is pretty valid as a name there - that's *exactly* what it represents - the path portion of the URL. Alternately `route`? 2. Keep `url` for both styles, but with a really simple determination

Re: AssertNumQueries and call stacks

I don’t mind that version. I’m withdrawing my wontfix. Sorry. -- Aymeric. > On 04 Oct 2016, at 10:03, Malcolm Box wrote: > > Hi, > > I'd like to open a discussion on bug #9363 > and #22320 > which are

AssertNumQueries and call stacks

Hi, I'd like to open a discussion on bug #9363 and #22320 which are about improving query logging to capture call stacks. The 9363 was marked wontfix, but I don't understand the reason given. The use case i

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

Hi, Am Tue, 4 Oct 2016 00:11:28 +0200 schrieb 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? yes,

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

Hi y'all, On Tue, Oct 04, 2016 at 08:15:45AM +0200, Aymeric Augustin wrote: 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()

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

@bogdan: I don't quite like to use environment variables as configuration, but this is probably the way I'll go. Thanks for pointing it out. @tim: This time its 'auth.W004'. In order to allow username recycling we have constraint for unique usernames among active user's only. Django doesn't exp