Estonian).
>> On Monday, September 19, 2022 at 4:07:26 PM UTC+2 matthew.pava wrote:
>>
>>> I wonder if maybe you should look at the APPEND_SLASH setting.
>>>
>>> https://docs.djangoproject.com/en/4.1/ref/settings/#append-slash
>>>
>>>
>>&
-d...@googlegroups.com *On
>> Behalf Of *Meiyer
>> *Sent:* Monday, September 19, 2022 8:59 AM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Re: Optional URL parameters in django.urls.path
>&g
:* Monday, September 19, 2022 8:59 AM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Optional URL parameters in django.urls.path
>
>
>
> > One approach is to route two patterns (one with the parameter and one
: Re: Optional URL parameters in django.urls.path
> One approach is to route two patterns (one with the parameter and one
> without) to the same URL. Some duplication but (perhaps) easier to read at a
> glance than either an optional `?` operator.
I thought about that, but it won&#x
>
> > One approach is to route two patterns (one with the parameter and one
> without) to the same URL. Some duplication but (perhaps) easier to read at
> a glance than either an optional `?` operator.
>
I thought about that, but it won't work if I want both cases to be named
similarly (via th
One approach is to route two patterns (one with the parameter and one
without) to the same URL. Some duplication but (perhaps) easier to read at
a glance than either an optional `?` operator.
Given that — and the alternative re_path() approach being available —
unless there was a particularly sim
Hi,
I feel there is a use case that the `path()` function does not address and
thus requires to switch over to `re_path()` which immediately adds a lot of
additional and error-prone syntax.
Often there is a need to capture a URL parameter which can be optional into
the view’s kwargs. In terms
