I favor raising an exception in this case, because values in this context are
not coerced to strings (unlike the case in {{ }} references).
IMO, and in order to protect the writers of all 3rd-party filters, the only way
to solve this without raising an exception is to resolve the whole filter
e
I agree with Claude.
--
Aymeric.
> On 1 Jun 2017, at 09:50, Claude Paroz wrote:
>
> As for me, I still think the current validator is valid for 99% of use cases.
> And 99% of the time, an email address with dot-less domain is a user input
> error.
>
> So I would prefer fixing #25594 (vali
Thanks for the continued speedy research, Tom!
Weighing in on the design of an ASGI-direct protocol, the main issue I've
had at this point is not HTTP (as there's a single request message and the
body stuff could be massaged in somehow), but WebSocket, where you have
separate "connect", "receive"
Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2017/jun/01/bugfix-release/
--
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
Maybe the LiveServerTestCase.port attribute added in Django 1.11.2 will
help, https://code.djangoproject.com/ticket/28212.
At this point, the original change is released, so we would open a new
ticket for further changes.
On Thursday, June 1, 2017 at 10:50:54 AM UTC-4, Tom Forbes wrote:
>
> Sho
Shouldn't A.url be a relative URL in this case?
I agree the ticket should be re-opened though, we had some pains working
around this, but it was surmountable.
On 1 Jun 2017 15:31, "Francis Mwangi" wrote:
please reopen the ticket, we are having a pain testing code that generating
code. For insta
please reopen the ticket, we are having a pain testing code that generating
code. For instance
class A(object):
url = "some_url"
test.py
class TestingA(LiveserverTestcase):
def test_a()
"we can't override the url defined in object A since its
initialized even before we
Hi,
I came across an issue yesterday caused by TruncDay function. You can find
it here:
https://stackoverflow.com/questions/44287443/incorrect-escaping-in-django-sql-query
Copy pasting from there:
Here's the query I'm trying to run:
MyModel.objects.filter(created__lt=functions.TruncDay(Value(
I've been doing some initial work on a Gunicorn worker process that
interfaces with an ASGI consumer callable, rather than a WSGI callable.
https://github.com/tomchristie/asgiworker
In the standard channels setup, the application is run behind a message
bus...
Protocol Server -> Channe
>
> On the other hand, maybe it's a good idea to report a warning in the
> __bool__ method? In most cases, bool(AnonymousUser) is a programming error,
> and not a valid code, so this might be helpful.
>
bool(AnonymousUser) is very pythonic, not a "programming error". The rules
for python's truthy/
{% if request.user %} is a perfectly valid way to check if the user object is
available in the template. I don't think we should change that or give a
warning.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" gro
In my mental model, the request either was sent by a user (that has a User
object) or not (and in this case it should be None, or at least something
that works like None). However, looks like the majority of you have a
different model, so I'm not going to press for that.
On the other hand, maybe i
As for me, I still think the current validator is valid for 99% of use
cases. And 99% of the time, an email address with dot-less domain is a user
input error.
So I would prefer fixing #25594 (validator propagation from db field to
form field), adding a "looser" validator in validators.py and b
13 matches
Mail list logo
