Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Aymeric Augustin]

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 (validator propagation from db field to form 
> field), adding a "looser" validator in validators.py and better documenting 
> usage of alternate validators for EmailFields.
> But I won't block the boat if I'm in the minority!
> 
> Claude
> 
> -- 
> 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 receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c3138fc8-fb78-4ff3-898d-2ed92433b13e%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CC67D220-07EB-425D-8EDA-E8D9CD5EAB1B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Andrew Godwin]

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" and "disconnect" events.

Because of the separate events, having them covered in one
consumer/function, even in an async style, is not possible under something
that works in the same overall way as ASGI does at the base level; instead,
it would have to be modified substantially so that whatever the server was
bundled all those things together into a single asyncio function, and then
we'd have to stick a key on there that made it clear what it was.

The thing I wanted to investigate, and which I started making progress
towards at PyCon, was keeping the same basic architecture as ASGI (that is,
server -> channel layer <- consumer), but stripping it way back to the
in-memory layer with a very small capacity, so it basically just acts as a
async-thread-to-async-thread channel in the same way things would in, for
example, Go.

This resulted in me adding receive_async() to the memory layer so that
works, but it's a relatively slow implementation as it has to coexist with
the rest of the layer which works synchronously. I suspect there is
potential for a very fast async-only layer that can trigger the await
that's hanging in a receive_async() directly from a send() to a related
channel, rather than sticking it onto a memory location and waiting. This
could be done with generic channel names like in the spec
("websocket.connect"), and end up with a server that has less worker
contexts/threads than sockets waiting, or with specific channel names per
connection ("websocket.connect?j13DkW2") and then spin up one handling
function per connection per message type, which seems sub-optimal.

Otherwise, it seems the only way to re-engineer it is to shove all the
message types for a protocol into a single async handling function, which
seems less than ideal to me, or start down the path of having these things
represented as classes with callables on them - so you'd call
"consumer.connect()", "consumer.receive()" etc., which is probably my
preferred design for keeping the event separation nice and clean.

Andrew

On Thu, Jun 1, 2017 at 3:18 AM, Tom Christie  wrote:

> 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 -> Channels <- Worker Process -> ASGI Consumer
>
> In the Gunicorn worker implementation above, we're instead calling the
> consumer interface directly...
>
> Protocol Server -> ASGI Consumer
>
> There's a few things that're promising here...
>
> 1. The ASGI consumer interface is suitable for async application
> frameworks, where WSGI necessarily can't be.
>
> In WSGI the response gets returned when the callable returns, you can't
> queue an asynchronous task to perform some work later.
> With an ASGI consumer, the messaging interface style means that you can
> push tasks onto the event loop and return immediately.
> In short, you can use async...await under ASGI.
>
> 2. The uvloop and httptools implementations are seriously speedy.
>
> For comparative purposes, plaintext hello world servers against a few
> different implementations on my MacBook Air
>
> wrk -d20s -t10 -c200 http://127.0.0.1:8080/
>
>   Throughput Latency (stddev)
> Go  44,000 req/s 6ms  92%
> uvloop+httptools, ASGI  33,000 req/s 6ms  67%
> meinheld, WSGI  16,000 req/s12ms  91%
> Node 9,000 req/s22ms  91%
>
> As application developers those baselines aren't typically a priority, but
> if we want Python web frameworks to be able to nail the same kind of
> services that node and go currently excel in, then having both async
> support, and a low framework overhead *is* important.
>
> It's not immediately clear to me if any of this is interesting to Django
> land directly or not. The synchronous nature of the framework means that
> having the separation of async application servers, and synchronous workers
> behind a channel layer makes a lot of sense. Tho you could perfectly well
> run a regular HTTP Django application on top of this implementation
> (replacing wsgi.py with an asgi.py that uses ASGIHandler) and be no worse
> off for it. (Sure you're running blocking operations while running in the
> context of an event loop, but that's no worse than running blocking
> operations in a standard WSGI configuration)
>
> However it is valuable if you want to be able to write HTTP frameworks
> that support async...await, or if you want to support websockets and don't
> require the 

Django bugfix release: 1.11.2

[Tim Graham]

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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45ab39ab-cc38-467d-97bc-c8c39f971c8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

[Tim Graham]

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:
>
> 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 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 a have access to self.liveserver_url"
>
> On Saturday, October 15, 2016 at 5:13:07 PM UTC+3, Tim Graham wrote:
>>
>> At the time of the implementation [0], no one raised that use case. 
>> Probably we can reopen the ticket and add it back.
>>
>> [0] 
>> https://groups.google.com/d/topic/django-developers/_TD8IkSLgqE/discussion
>>
>> On Saturday, October 15, 2016 at 9:32:54 AM UTC-4, Andrew Wall wrote:
>>>
>>> Very much appreciate the Django framework.  
>>>
>>> I noticed in the docs 
>>> 
>>>  
>>> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* 
>>> environmental variable is slated to be removed, along with the accompanying 
>>> python manage.py test *--liveserver* option.  I'm concerned that 
>>> without the ability to specify a remote IP address using --liveserver, it 
>>> will no longer be possible to run functional tests using selenium against 
>>> an external server.  I learned this technique from Harry Percival's 
>>> excellent TDD with Python (see 
>>> http://chimera.labs.oreilly.com/books/123400754/ch08.html#_configuring_domains_for_staging_and_live),
>>>  
>>> where the test command is called from the local machine but you pass in the 
>>> external IP.  Will there be a different way to do this in Django 1.11? 
>>> Perhaps the change to bind LiveserverTestCase to port zero by default can 
>>> be made while retaining the option to pass in --liveserver?  Realize the 
>>> release is a ways away but would appreciate any help as I've come to rely 
>>> on this method to test server deployments.  Thank you!
>>>
>> -- 
> 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 receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b74d3aa2-a033-4f98-a558-cdbbd68717d3%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97ad8d10-c277-4aff-9756-8f6ce7be8ac1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

[Tom Forbes]

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 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 a have access to self.liveserver_url"

On Saturday, October 15, 2016 at 5:13:07 PM UTC+3, Tim Graham wrote:
>
> At the time of the implementation [0], no one raised that use case.
> Probably we can reopen the ticket and add it back.
>
> [0] https://groups.google.com/d/topic/django-developers/_TD8IkSL
> gqE/discussion
>
> On Saturday, October 15, 2016 at 9:32:54 AM UTC-4, Andrew Wall wrote:
>>
>> Very much appreciate the Django framework.
>>
>> I noticed in the docs
>> 
>> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental
>> variable is slated to be removed, along with the accompanying
>> python manage.py test *--liveserver* option.  I'm concerned that without
>> the ability to specify a remote IP address using --liveserver, it will no
>> longer be possible to run functional tests using selenium against an
>> external server.  I learned this technique from Harry Percival's excellent
>> TDD with Python (see http://chimera.labs.oreilly.co
>> m/books/123400754/ch08.html#_configuring_domains_for_staging_and_live),
>> where the test command is called from the local machine but you pass in the
>> external IP.  Will there be a different way to do this in Django 1.11?
>> Perhaps the change to bind LiveserverTestCase to port zero by default can
>> be made while retaining the option to pass in --liveserver?  Realize the
>> release is a ways away but would appreciate any help as I've come to rely
>> on this method to test server deployments.  Thank you!
>>
> --
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 receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/b74d3aa2-a033-4f98-a558-cdbbd68717d3%40googlegroups.
com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJOUyiiEU2oYTMNuxoJgDdweY0r0qoAgQe0HKFg2MVCU9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

[Francis Mwangi]

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 a have access to self.liveserver_url"

On Saturday, October 15, 2016 at 5:13:07 PM UTC+3, Tim Graham wrote:
>
> At the time of the implementation [0], no one raised that use case. 
> Probably we can reopen the ticket and add it back.
>
> [0] 
> https://groups.google.com/d/topic/django-developers/_TD8IkSLgqE/discussion
>
> On Saturday, October 15, 2016 at 9:32:54 AM UTC-4, Andrew Wall wrote:
>>
>> Very much appreciate the Django framework.  
>>
>> I noticed in the docs 
>> 
>>  
>> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental 
>> variable is slated to be removed, along with the accompanying 
>> python manage.py test *--liveserver* option.  I'm concerned that without 
>> the ability to specify a remote IP address using --liveserver, it will no 
>> longer be possible to run functional tests using selenium against an 
>> external server.  I learned this technique from Harry Percival's excellent 
>> TDD with Python (see 
>> http://chimera.labs.oreilly.com/books/123400754/ch08.html#_configuring_domains_for_staging_and_live),
>>  
>> where the test command is called from the local machine but you pass in the 
>> external IP.  Will there be a different way to do this in Django 1.11? 
>> Perhaps the change to bind LiveserverTestCase to port zero by default can 
>> be made while retaining the option to pass in --liveserver?  Realize the 
>> release is a ways away but would appreciate any help as I've come to rely 
>> on this method to test server deployments.  Thank you!
>>
>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b74d3aa2-a033-4f98-a558-cdbbd68717d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Incorrect escaping in Django SQL query

[Roshan Raghupathy]

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(timezone.now(), 
output_field=DateTimeField(

It translates to:

SELECT  FROM "mymodel" WHERE "mymodel"."created" < 
(DATE_TRUNC('day', %%s AT TIME ZONE %s))

before Django performs parameter substitution. Note that the first %s has 
been escaped to %%s. This causes the parameter substitution to throw an 
exception.

Is this intended behaviour or a bug?


I dug into the internals a bit to figure this out and the issue comes from this 
line 

 where 
the query till that point is escaped but later, they are never escaped back 
to the original form for correct parameter substitution. I went ahead and 
added code to replace `%%s` with `%s` before parameter substitution and it 
worked fine. Am I missing something here or should I file a bug(has it been 
filed already?)?

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa9432e7-cd3d-4c9a-b064-b5b009d13895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On ASGI...

[Tom Christie]

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 -> Channels <- Worker Process -> ASGI Consumer

In the Gunicorn worker implementation above, we're instead calling the 
consumer interface directly...

Protocol Server -> ASGI Consumer

There's a few things that're promising here...

1. The ASGI consumer interface is suitable for async application 
frameworks, where WSGI necessarily can't be.

In WSGI the response gets returned when the callable returns, you can't 
queue an asynchronous task to perform some work later.
With an ASGI consumer, the messaging interface style means that you can 
push tasks onto the event loop and return immediately.
In short, you can use async...await under ASGI.

2. The uvloop and httptools implementations are seriously speedy.

For comparative purposes, plaintext hello world servers against a few 
different implementations on my MacBook Air

wrk -d20s -t10 -c200 http://127.0.0.1:8080/

  Throughput Latency (stddev)
Go  44,000 req/s 6ms  92%
uvloop+httptools, ASGI  33,000 req/s 6ms  67% 
meinheld, WSGI  16,000 req/s12ms  91%
Node 9,000 req/s22ms  91%

As application developers those baselines aren't typically a priority, but 
if we want Python web frameworks to be able to nail the same kind of 
services that node and go currently excel in, then having both async 
support, and a low framework overhead *is* important.

It's not immediately clear to me if any of this is interesting to Django 
land directly or not. The synchronous nature of the framework means that 
having the separation of async application servers, and synchronous workers 
behind a channel layer makes a lot of sense. Tho you could perfectly well 
run a regular HTTP Django application on top of this implementation 
(replacing wsgi.py with an asgi.py that uses ASGIHandler) and be no worse 
off for it. (Sure you're running blocking operations while running in the 
context of an event loop, but that's no worse than running blocking 
operations in a standard WSGI configuration)

However it is valuable if you want to be able to write HTTP frameworks that 
support async...await, or if you want to support websockets and don't 
require the kinds of broadcast functionality that adding a channel layer 
provides for.

---

At the moment I'm working against the ASGI consumer interface as it's 
currently specified. There's a few things that I'm interested in next:

1. If there'd be any sense in mandating that the ASGI callable *may* be a 
coroutine. (requiring an asyncio worker or server implementation)
2. If there'd be any sense in including `.loop` as either a mandatory or as 
an optional attribute on a channel layer that supports the syncio extension.
3. Andrew's mentioned that he's been considering an alternative that maps 
more simply onto WSGI, I'd really like to see what he's thinking there.
4. Response streaming isn't a problem - you can send multiple message back 
to the channel, and run that off the event loop. However, I've not quite 
got my head around how you handle streaming request bodies, or around how 
you'd invert the interface so that from the application perspective there's 
something like an interface available for  `chunk = await body.read()`.
5. One other avenue of interest here might be if it's worth considering 
bringing ASGIHandler out of channels and into Django core, so that we can 
expose either an asgi consumer callable or a wsgi callable interface to 
Django, with `runworker` being only one of a number of possible ASGI 
deployments.

Plenty to unpack here, feedback on any aspects most welcome!

Cheers,

  T :)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db158350-60a9-4950-b11c-83f2f7a9221c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Adam Johnson]

>
> 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/falsey are mostly "empty string, 0
(int/float/fraction...), False and None are falsey, the rest are truthy".
Making AnonymousUser anything other than truthy just seems wrong to me.


On 1 June 2017 at 10:22, Linus Lewandowski  wrote:

> 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 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.
>
> We could make it a warning forever, or use RemovedInDjango30Warning, and
> then switch to return False OR an exception in 3.0.
>
> Linus
>
>
> On Thu, Jun 1, 2017 at 9:34 AM Brice PARENT  wrote:
>
>> Wouldn't that be better placed in a linter library (such as *django_linter
>> *)? The syntax is right, it
>> really does what it describes, but it may be wrongly understood, so the
>> syntax could be pointed out as possible cause of bug, but the behaviour we
>> have now seems totally logic and the change would probably have side
>> effects on many projects.
>>
>> I'm not using specific linters other than the one included in PyCharm,
>> but it would probably be a good idea, when you write "if request.user:" to
>> have it propose to rewrite it as "if request.user.is_authenticated:" if
>> it's what we meant.
>>
>> -- Brice
>>
>> Le 31/05/17 à 18:44, li...@lew21.net a écrit :
>>
>> I suggest adding __bool__() method returning False to the AnonymousUser
>> class.
>>
>> This way it'll be possible to check if the user is authenticated by
>> simply writing "if request.user:"
>>
>> It's a frequent source of bugs (at least for me, but probably I'm not
>> alone) that right now this code returns True for anonymous users. If
>> unnoticed, such bugs can also lead to security issues.
>>
>> Related ticket: https://code.djangoproject.com/ticket/28259
>> --
>> 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 receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>>
>>
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/065eb9a5-d935-466d-a301-
>> d7de87e6fbb0%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/django-developers/rGWdttZO06g/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/ba96fd99-43ce-2a0b-b79f-eed955bc7be8%40brice.xyz
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAB96mebXAH5SLN3p2wDCtvQs4POVD
> 6Xrh-NHOLVM31Q%3DUvX_NQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Re: Make bool(AnonymousUser) evaluate to false

[Marten Kenbeek]

{% 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)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bad3dbf9-a1e9-4364-9f01-53c0899dcfc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Linus Lewandowski]

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

We could make it a warning forever, or use RemovedInDjango30Warning, and
then switch to return False OR an exception in 3.0.

Linus


On Thu, Jun 1, 2017 at 9:34 AM Brice PARENT  wrote:

> Wouldn't that be better placed in a linter library (such as *django_linter
> *)? The syntax is right, it
> really does what it describes, but it may be wrongly understood, so the
> syntax could be pointed out as possible cause of bug, but the behaviour we
> have now seems totally logic and the change would probably have side
> effects on many projects.
>
> I'm not using specific linters other than the one included in PyCharm, but
> it would probably be a good idea, when you write "if request.user:" to have
> it propose to rewrite it as "if request.user.is_authenticated:" if it's
> what we meant.
>
> -- Brice
>
> Le 31/05/17 à 18:44, li...@lew21.net a écrit :
>
> I suggest adding __bool__() method returning False to the AnonymousUser
> class.
>
> This way it'll be possible to check if the user is authenticated by simply
> writing "if request.user:"
>
> It's a frequent source of bugs (at least for me, but probably I'm not
> alone) that right now this code returns True for anonymous users. If
> unnoticed, such bugs can also lead to security issues.
>
> Related ticket: https://code.djangoproject.com/ticket/28259
> --
> 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 receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
>
>
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/065eb9a5-d935-466d-a301-d7de87e6fbb0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/rGWdttZO06g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ba96fd99-43ce-2a0b-b79f-eed955bc7be8%40brice.xyz
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAB96mebXAH5SLN3p2wDCtvQs4POVD6Xrh-NHOLVM31Q%3DUvX_NQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Is it possible to save changes before changing from page basic settings to advanced settings in the popup-window?

[C. Waidi]

Summary 

When clicking on page -> page settings, you have on the left bottom corner 
two buttons to change between basic settings and advanced settings.
If you have edited something on the base settings and change to the 
advanced settings - the changes won't be saved. Is it possible to trigger a 
save-command, when switching between basic and advanced settings?
Expected behaviour 

Trigger a save-command, when switching between basic and advanced settings
Actual behaviour 

The changes at basic settings will be dismissed at switching to the 
advanced settings.
Environment 
   
   - Python version: 2.7
   - Django version: 1.9.12
   - django CMS version: 3.3.3

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/271963b3-b2b8-4a90-ac3b-706cc0f8aecd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Claude Paroz]

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 better 
documenting usage of alternate validators for EmailFields.
But I won't block the boat if I'm in the minority!

Claude

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c3138fc8-fb78-4ff3-898d-2ed92433b13e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.