filter_raw_string = r"""
^(?P%(constant)s)|
^(?P[%(var_chars)s]+|%(num)s)|
(?:\s*%(filter_sep)s\s*
(?P\w+)
(?:%(arg_sep)s
(?:
(?P%(constant)s)|
(?P[%(var_chars)s]+|%(num)s)
)
)?
)""" % {
'constant':
filter_raw_string = r"""
^(?P%(constant)s)|
^(?P[%(var_chars)s]+|%(num)s)|
(?:\s*%(filter_sep)s\s*
(?P\w+)
(?:%(arg_sep)s
(?:
(?P%(constant)s)|
(?P[%(var_chars)s]+|%(num)s)
)
)?
)""" % {
'constant':
Currently, spaces between filter separator( | ) and filter name is allowed.
Also, value name and filter separator.
So, following is allowed.
{{ value|filter:"arg" }}
{{ value|filter:"arg" }}
But, following is not allowed.
{{ value|filter: "arg" }}
users are confused by the
2018년 6월 5일 화요일 오전 10시 52분 16초 UTC+9, oli...@kidsnote.com 님의 말:
>
> Currently, django template system allow spaces between filter separator
> and filter name, also value name and filter separator.
> So, following is ok.
>
> {{ value|filter:"arg" }}
> {{ value|filter:"arg" }}
>
Currently, django template system allow spaces between filter separator and
filter name, also value name and filter separator.
So, following is ok.
{{ value|filter:"arg" }}
{{ value|filter:"arg" }}
But, following can't be parsed
{{ value|filter: "arg" }}
I think that this
On 06/05/2018 07:54 AM, Tom Forbes wrote:
Are the proposed modifications to how Django runs sensible?
I had a few random thoughts while reading your proposal:
I think getting rid of the related field references could be a big issue
here and cause a lot of headaches for existing
Hey Andrew, thank you for the very exciting proposal and the ongoing work
on Django channels! There is a lot to consider here and some very
interesting problems to work through - I’d love to help out wherever I can.
Do we think async is worth going after?
I think this is very much worth doing.
I don't think we should make any changes to HttpResponseRedirect, for
backwards compatibility reasons if nothing else.
It might make sense to encourage people to use HttpResonse(status=303)
directly, rather than using subclasses.
On Mon, Jun 4, 2018 at 3:51 PM, Duane Hutchins wrote:
> The "302
The "302 Found" redirect is used by default in django.http.response
HttpResponseRedirect.
Could we discuss changing this to use "303 See Other" redirects?
303 redirects are more in-line with the intent of the redirect after a
change, and also 303 redirects disallow browser caching.
If a
> Do we think async is worth going after?
I think this is hugely important. Django's advantage in the field currently
is in it's developer productivity and maintainability. As frameworks based
on Node or on languages with co-operative concurrency built-in continue to
mature it's going to face
Hello Andrew.
I like your proposal and want to help out. In particular, what I'm really
fond of is the approach of making async available only if you want it,
while keeping Django backwards-compatible. Django is brilliant in that,
like the Python language, it's easy and fun to pick and learn, but
Hi all,
Calendar Week 22 -- ending 1st June.
Reviewed Patches on:
https://code.djangoproject.com/ticket/29301 -- Reorder management command
arguments in --help output to prioritize command-specific arguments
https://code.djangoproject.com/ticket/29419 -- Document the change in
permissions
Week ending June 2, 2018
I also spent time spinning up some new CI servers with Ubuntu 18.04. That
required the GIS test fixes below.
Triaged
---
https://code.djangoproject.com/ticket/29455 - MySQL Backend & features
detection are not taking MariaDB Aria engine into account (invalid)
Hello everyone,
For a while now I have been working on potential plans for making Django
async-capable, and I finally have a plan I am reasonably happy with and
which I think we can actually do.
This proposed roadmap, in its great length, is here:
14 matches
Mail list logo
