Re: Password validation in Django revisited

[Josh Smeaton]

I agree with you that the extra implementation complexity is probably not 
right or at least not worth the gain, especially when it comes to things 
like testing. I take back what I said about switching behaviour based on 
DEBUG. You should also be able to run validators in DEBUG if you choose to. 
I don't think there's an issue with requiring users to explicitly disable 
the validators in their local settings file if they want to use insecure 
passwords for development.

I don't mind the AUTH_PASSWORD_VALIDATORS = [ .. ] if not DEBUG else [] 
pattern. Perhaps it's worth just documenting that pattern as a note for 
users to use themselves?

On Tuesday, 8 September 2015 10:31:23 UTC+10, Tim Graham wrote:
>
> The extra complexity of varying validation logic based on DEBUG doesn't 
> seem quite right to me, but I guess I won't oppose it if that's the 
> consensus.
>
> Another option could be this in the generated settings file:
>
> AUTH_PASSWORD_VALIDATORS = [
> {
> 'NAME': 
> 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
> },
> ...
> ] if not DEBUG else []
>
> Of course this depends on whether or not you expect other places like the 
> admin's change password form to do validation in debug mode.
>
> On Monday, September 7, 2015 at 8:09:00 PM UTC-4, Aron Podrigal wrote:
>>
>> I started using django-classy-settings and it works very well for me.
>> On Sep 7, 2015 8:04 PM, "Josh Smeaton"  wrote:
>>
>>> I don't think removing the default list from the template is the right 
>>> idea. We'd be sacrificing some production users that don't go through 
>>> security options on deployment checklists to better support development 
>>> environments where the security issue (probably) isn't present. I do think 
>>> we need some kind of solution though, because I don't want these validators 
>>> in development either. Personally, I have no issue with adding a SETTING=[] 
>>> to my local_settings. It would be nicer to drive a solution based on DEBUG 
>>> though.
>>>
>>> Cheers
>>>
>>>
>>> On Tuesday, 8 September 2015 09:26:36 UTC+10, Tim Graham wrote:

 I think the simplest solution could be to remove the default list of 
 AUTH_PASSWORD_VALIDATORS that have been added to the project template 
 settings file and let the user add it to their own production settings 
 instead. Do you think this reduces the usefulness of the feature? We could 
 add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an 
 alternate way of encouraging its use.

 On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:
>
> +1
> On Sep 7, 2015 4:56 PM, "Shai Berger"  wrote:
>
>> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
>> > I agree with Aymeric and Markus that createsuperuser should not 
>> validate
>> > strength of passwords when DEBUG is on. Having to use a secure 
>> password for
>> > development/test accounts is an unnecessary level of interference 
>> for
>> > users.
>> >
>> > I agree its safer to prevent using admin/admin in production and 
>> this is a
>> > good thing, but there's no reason to prevent this for development. 
>> In fact,
>> > I'd argue enforcing it for development will encourage teams to have 
>> a
>> > "standard" secure password for their sites, which is also used in
>> > production. By allowing admin/admin in development, and enforcing 
>> something
>> > better in production we are more helpfully enforcing best practice.
>> >
>> +1.
>>
>> Shai.
>>
> -- 
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/1aba1352-89ba-4cfe-a789-77430c504026%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Possible bug when filter per month on a variable generated by annotate

[Paulo Maciel]

Possible bug when filter per __month on a variable generated by annotate

p = Person.objects.annotate(
main_date=Case(
When(ok=True, then='date_a'), 
default=F('date_b'), 
output_field=DateField()
)
)
a = p.filter(main_date__month=9)
print(a)


IndexError at /

tuple index out of range


Traceback:
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/core/handlers/base.py"
 
in get_response
  132. response = wrapped_callback(request, *
callback_args, **callback_kwargs)
File "/Users/z/projects/myapp/views.py" in persons
  42. print(a):
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/models/query.py"
 
in __iter__
  162. self._fetch_all()
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/models/query.py"
 
in _fetch_all
  965. self._result_cache = list(self.iterator())
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/models/query.py"
 
in iterator
  238. results = compiler.execute_sql()
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/models/sql/compiler.py"
 
in execute_sql
  840. cursor.execute(sql, params)
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/backends/utils.py"
 
in execute
  79. return super(CursorDebugWrapper, self).execute(sql, params
)
File 
"/Users/z/.virtualenvs//lib/python3.4/site-packages/django/db/backends/utils.py"
 
in execute
  64. return self.cursor.execute(sql, params)


Exception Type: IndexError at /
Exception Value: tuple index out of range

but when I use __range works

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4e4cf468-b5d1-4961-a95d-882e95b61b38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Tim Graham]

The extra complexity of varying validation logic based on DEBUG doesn't 
seem quite right to me, but I guess I won't oppose it if that's the 
consensus.

Another option could be this in the generated settings file:

AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 
'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
...
] if not DEBUG else []

Of course this depends on whether or not you expect other places like the 
admin's change password form to do validation in debug mode.

On Monday, September 7, 2015 at 8:09:00 PM UTC-4, Aron Podrigal wrote:
>
> I started using django-classy-settings and it works very well for me.
> On Sep 7, 2015 8:04 PM, "Josh Smeaton"  
> wrote:
>
>> I don't think removing the default list from the template is the right 
>> idea. We'd be sacrificing some production users that don't go through 
>> security options on deployment checklists to better support development 
>> environments where the security issue (probably) isn't present. I do think 
>> we need some kind of solution though, because I don't want these validators 
>> in development either. Personally, I have no issue with adding a SETTING=[] 
>> to my local_settings. It would be nicer to drive a solution based on DEBUG 
>> though.
>>
>> Cheers
>>
>>
>> On Tuesday, 8 September 2015 09:26:36 UTC+10, Tim Graham wrote:
>>>
>>> I think the simplest solution could be to remove the default list of 
>>> AUTH_PASSWORD_VALIDATORS that have been added to the project template 
>>> settings file and let the user add it to their own production settings 
>>> instead. Do you think this reduces the usefulness of the feature? We could 
>>> add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an 
>>> alternate way of encouraging its use.
>>>
>>> On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:

 +1
 On Sep 7, 2015 4:56 PM, "Shai Berger"  wrote:

> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> > I agree with Aymeric and Markus that createsuperuser should not 
> validate
> > strength of passwords when DEBUG is on. Having to use a secure 
> password for
> > development/test accounts is an unnecessary level of interference for
> > users.
> >
> > I agree its safer to prevent using admin/admin in production and 
> this is a
> > good thing, but there's no reason to prevent this for development. 
> In fact,
> > I'd argue enforcing it for development will encourage teams to have a
> > "standard" secure password for their sites, which is also used in
> > production. By allowing admin/admin in development, and enforcing 
> something
> > better in production we are more helpfully enforcing best practice.
> >
> +1.
>
> Shai.
>
 -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1aba1352-89ba-4cfe-a789-77430c504026%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce56e16c-38d4-49c4-be45-68e2948d627c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Podrigal, Aron]

I started using django-classy-settings and it works very well for me.
On Sep 7, 2015 8:04 PM, "Josh Smeaton"  wrote:

> I don't think removing the default list from the template is the right
> idea. We'd be sacrificing some production users that don't go through
> security options on deployment checklists to better support development
> environments where the security issue (probably) isn't present. I do think
> we need some kind of solution though, because I don't want these validators
> in development either. Personally, I have no issue with adding a SETTING=[]
> to my local_settings. It would be nicer to drive a solution based on DEBUG
> though.
>
> Cheers
>
>
> On Tuesday, 8 September 2015 09:26:36 UTC+10, Tim Graham wrote:
>>
>> I think the simplest solution could be to remove the default list of
>> AUTH_PASSWORD_VALIDATORS that have been added to the project template
>> settings file and let the user add it to their own production settings
>> instead. Do you think this reduces the usefulness of the feature? We could
>> add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an
>> alternate way of encouraging its use.
>>
>> On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:
>>>
>>> +1
>>> On Sep 7, 2015 4:56 PM, "Shai Berger"  wrote:
>>>
 On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
 > I agree with Aymeric and Markus that createsuperuser should not
 validate
 > strength of passwords when DEBUG is on. Having to use a secure
 password for
 > development/test accounts is an unnecessary level of interference for
 > users.
 >
 > I agree its safer to prevent using admin/admin in production and this
 is a
 > good thing, but there's no reason to prevent this for development. In
 fact,
 > I'd argue enforcing it for development will encourage teams to have a
 > "standard" secure password for their sites, which is also used in
 > production. By allowing admin/admin in development, and enforcing
 something
 > better in production we are more helpfully enforcing best practice.
 >
 +1.

 Shai.

>>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1aba1352-89ba-4cfe-a789-77430c504026%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yin%2BZk9uSkjYUm3V-3a437gMYHjvu24szkThNs75kKxCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Josh Smeaton]

I don't think removing the default list from the template is the right 
idea. We'd be sacrificing some production users that don't go through 
security options on deployment checklists to better support development 
environments where the security issue (probably) isn't present. I do think 
we need some kind of solution though, because I don't want these validators 
in development either. Personally, I have no issue with adding a SETTING=[] 
to my local_settings. It would be nicer to drive a solution based on DEBUG 
though.

Cheers


On Tuesday, 8 September 2015 09:26:36 UTC+10, Tim Graham wrote:
>
> I think the simplest solution could be to remove the default list of 
> AUTH_PASSWORD_VALIDATORS that have been added to the project template 
> settings file and let the user add it to their own production settings 
> instead. Do you think this reduces the usefulness of the feature? We could 
> add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an 
> alternate way of encouraging its use.
>
> On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:
>>
>> +1
>> On Sep 7, 2015 4:56 PM, "Shai Berger"  wrote:
>>
>>> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
>>> > I agree with Aymeric and Markus that createsuperuser should not 
>>> validate
>>> > strength of passwords when DEBUG is on. Having to use a secure 
>>> password for
>>> > development/test accounts is an unnecessary level of interference for
>>> > users.
>>> >
>>> > I agree its safer to prevent using admin/admin in production and this 
>>> is a
>>> > good thing, but there's no reason to prevent this for development. In 
>>> fact,
>>> > I'd argue enforcing it for development will encourage teams to have a
>>> > "standard" secure password for their sites, which is also used in
>>> > production. By allowing admin/admin in development, and enforcing 
>>> something
>>> > better in production we are more helpfully enforcing best practice.
>>> >
>>> +1.
>>>
>>> Shai.
>>>
>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1aba1352-89ba-4cfe-a789-77430c504026%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Tim Graham]

I think the simplest solution could be to remove the default list of 
AUTH_PASSWORD_VALIDATORS that have been added to the project template 
settings file and let the user add it to their own production settings 
instead. Do you think this reduces the usefulness of the feature? We could 
add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an 
alternate way of encouraging its use.

On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:
>
> +1
> On Sep 7, 2015 4:56 PM, "Shai Berger"  
> wrote:
>
>> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
>> > I agree with Aymeric and Markus that createsuperuser should not validate
>> > strength of passwords when DEBUG is on. Having to use a secure password 
>> for
>> > development/test accounts is an unnecessary level of interference for
>> > users.
>> >
>> > I agree its safer to prevent using admin/admin in production and this 
>> is a
>> > good thing, but there's no reason to prevent this for development. In 
>> fact,
>> > I'd argue enforcing it for development will encourage teams to have a
>> > "standard" secure password for their sites, which is also used in
>> > production. By allowing admin/admin in development, and enforcing 
>> something
>> > better in production we are more helpfully enforcing best practice.
>> >
>> +1.
>>
>> Shai.
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39fe284c-9115-4166-89ab-9fa02f5a34e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Shai Berger]

Ok, two things:

1) Markus' idea of having more than one folder for migration modules seems 
reasonable enough. I disagree with his comment about the placement of merge 
migrations -- 

> Django needs to know where to
> place the merge-migration. I'd go with the first item in the list

I'd require an explicit selection by the user; I'd still want to make sure the 
selected path is one of those specified for migration modules, so a dialog for 
selection may be more appropriate than a command-line parameter.

BUT

2) Emma's experiment, essentially, proves that the migration system can live, 
migrate, and generate new migrations with two leaf-migrations present. Which 
begs the question -- are merge migrations really necessary at all? I know why 
they were necessary for South, where migrations in an app were ordered 
linearly, but we have grown past that.

If, as I now suspect, we actually don't need them, then the whole idea sounds 
much more reasonable. I still feel funny about a migration which belongs to 
one app and works on the models of another, and would prefer some better-
looking solution -- e.g. "project migrations" (there are other reasons to 
think of them, like, special migrations to change swappable models); but 
unless some such idea gets some backing, I'd be only -0 on this.

Shai.

Re: Password validation in Django revisited

[Podrigal, Aron]

+1
On Sep 7, 2015 4:56 PM, "Shai Berger"  wrote:

> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> > I agree with Aymeric and Markus that createsuperuser should not validate
> > strength of passwords when DEBUG is on. Having to use a secure password
> for
> > development/test accounts is an unnecessary level of interference for
> > users.
> >
> > I agree its safer to prevent using admin/admin in production and this is
> a
> > good thing, but there's no reason to prevent this for development. In
> fact,
> > I'd argue enforcing it for development will encourage teams to have a
> > "standard" secure password for their sites, which is also used in
> > production. By allowing admin/admin in development, and enforcing
> something
> > better in production we are more helpfully enforcing best practice.
> >
> +1.
>
> Shai.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiD3PYCWzMQOV8ixG%2BM0LXC7Oa2R7-jDCbkxr%2BfkUT%2B5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Shai Berger]

On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> I agree with Aymeric and Markus that createsuperuser should not validate
> strength of passwords when DEBUG is on. Having to use a secure password for
> development/test accounts is an unnecessary level of interference for
> users.
> 
> I agree its safer to prevent using admin/admin in production and this is a
> good thing, but there's no reason to prevent this for development. In fact,
> I'd argue enforcing it for development will encourage teams to have a
> "standard" secure password for their sites, which is also used in
> production. By allowing admin/admin in development, and enforcing something
> better in production we are more helpfully enforcing best practice.
> 
+1.

Shai.

Re: draft blog post for Oracle help

[Mariusz Felisiak]

Hi everybody,

I would like to volunteer to help maintain Oracle and Oracle GIS backend. I 
have been developing (commercial) apps with Django framework and oracle 
backend for 8 years now. I am familiar with the problems associated with it 
because few times I have been forced to find ways to solve them:)

FeliXX

W dniu czwartek, 13 sierpnia 2015 18:12:17 UTC+2 użytkownik Tim Graham 
napisał:
>
> I've drafted a blog post to advertise our need for Oracle expertise. 
> Please take a look and give feedback before it's published. Thanks!
>
> Django team seeks help maintaining Oracle and Oracle GIS backends
>
> ---
>
> Several members of the Django team that have previously provided Oracle
> expertise no longer work with Oracle in their day jobs, and therefore, the 
> team
> is seeking new contributors who have an ongoing interest in the backend.
>
> Ideally, the team seeks to move the Oracle backend from "built-in" status, 
> to a pip
> installable backend that would be maintained under the "django" GitHub 
> account.
> Your duties would include monitoring a build that runs with Django master 
> and the
> latest version of the Oracle backend and fixing any issues that arise. To 
> help with
> the continuous integration infrastructure, knowledge of maintaining Oracle 
> servers
> would also be a plus, but these duties could be split among several 
> people. Please
> introduce yourself on the `django-developers mailing list`_ if this is 
> something you
> are interested in.
>
> Also, the Oracle GIS backend has been broken for several months and
> no one has answered `requests for help`_ on the django-developers and
> geodjango mailing lists. If no one helps out, this backend will be dropped 
> in
> Django 1.9. This is the least used backend according to the `Django 
> Developers
> Community Survey`_, receiving 5 votes out of more than 3,000 responses.
>
> .. _django-developers mailing list: 
> https://groups.google.com/forum/#!forum/django-developers
> .. _requests for help: 
> https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
> .. _Django Developers Community Survey: 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bbb2ccfe-cc2b-4665-b440-6f211d2f8808%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for making Storage API timezone aware

[Carl Meyer]

Hi James,

This proposal makes good sense to me. I think the problem is worth
fixing (I saw this problem on a previous project and never did get to
the bottom of what was causing it!), and you've carefully identified a
backwards-compatible route to fixing it, where no existing code breaks
(further) without a deprecation path.

Having to switch to new names for those methods doesn't bother me; the
new names you're proposing (with `get_` prepended) are at least as good
as the old ones. Methods should ideally be named as verb phrases anyway,
and properties/attributes as nouns.

Carl

On 09/07/2015 10:52 AM, James Aylett wrote:
> Ticket: https://code.djangoproject.com/ticket/23832
> 
> This is something that's been bugging me for a while, but it's tricky
> to get a good compatibility story. Here I'll lay out what's going on
> now including obstacles to change, where I think we should be and a
> possible route for getting there.
> 
> 
> # Current situation
> 
> Storage backends are documented as returning naive datetime objects
> from a number of calls [1]. (Currently no similar calls return aware
> objects ever.)
> 
> One significant user of these calls is staticfiles, which compares
> modified_time between (possibly) different storage backends when doing
> collectstatic as a way of avoiding copying static asset files when not
> needed.
> 
> Storage backends can be freely implemented, and a number of third
> party extensions do so. Two popular ones are (there are likely more):
> 
>  * django-compressor (which actually overrides the datetime-returning
>methods; django-pipeline also has custom backends, but does not)
>  
>  * django-storages (including support for a large number of "remote"
>backends, and some others -- one of the most important being
>S3Boto); this is mildly complicated by at least one fork,
>django-storages-redux, although the original now seems stalled
>(which is why that fork exists)
> 
> Additionally, various other extensions (and user code) consume from
> one or more of the time methods. (For instance, django-filebrowser
> does; this itself has various forks.) In many cases, they won't actually
> care whether they're being passed an aware or naive datetime.
> 
> This would only be a backwards compatibility problem, except that
> S3Boto returns a naive datetime in UTC, but FileSystemStorage (and
> others) return in the local timezone. This results in changed files not
> being overwritten [2] if your time zone is "west" of UTC. (This is a bug
> in django-storages, which came about from when the documentation
> didn't mention timezones at all for these methods.)
> 
> 
> [1]
> https://docs.djangoproject.com/en/1.8/ref/files/storage/#the-storage-class
> 
> [2] https://github.com/jschneier/django-storages/issues/49
> 
> 
> # What should happen
> 
> I think the following should be the long-term goal:
> 
> 1. If USE_TZ=False then datetimes returned from storage backends should be
>naive in local time
>
> 2. If USE_TZ=True then datetimes returned from storage backends should be
>aware in UTC
> 
> This would I believe match the behaviour of other TZ-aware systems in
> Django. It should allow, for instance, for datetimes coming from
> storage backends to round trip through the ORM without warnings.
> 
> 
> # A route through this
> 
> To go straight to the end result is a significant enough breaking
> change that it would annoy a lot of people. Here's one approach that I
> think would be fairly painless for people relying on this to Just Work.
> 
> We want the following properties in our approach:
> 
>  * ensure that clients of storage engines get a suitable deprecation
>warning and timeline to enable them to move
> 
>  * provide a BC approach for clients of storage engines so they can write
>code that works from LTS to LTS
> 
>  * ensure that implementors of storage engines get a suitable deprecation
>warning and timeline to enable them to move (this will probably also
>involve users of those storage engines getting the warnings)
> 
>  * provide a BC approach for implementors of storage engines so they can
>write code that works from LTS to LTS
> 
> I've included steps where extensions have to change as well as changes
> to Django; I think it's important in this case to make sure that
> popular extensions are moved forward. This is obviously dependent
> somewhat on the communities around those extensions, so there is some
> risk there.
> 
> There are other ways of doing things to this, but I think this is a clean
> approach. There's almost certainly something I've forgotten or simply got
> wrong though.
> 
> 
> ## Step 1: introduce new methods
> 
> get_modified_time(name)
> get_creation_time(name)
> get_accessed_time(name)
> 
> Same signature as the old ones, but with "get_" at the front. Return
> naive or aware datetime objects as dictated by USE_TZ and described
> above.
> 
> Change core code (I believe this is still only staticfiles'
> 

Re: Password validation in Django revisited

[Unai Zalakain]

Security comes first, so the should stay on by default.


True, security comes first, but from the philosophical point of view, I 
wouldn't like forcing by default any particular password policy to the 
users. If I understood it right, it isn't just a simple warning that 
says your password is too weak and lets you continue: it blatantly 
refuses to set that password for you. That is what I don't like.


Some other related questions also come to my mind: What exactly are we 
considering a secure password? Why not leave the validator list empty by 
default and document the feature on the security checklist, with the 
rest of deployment-related features that aren't on by default?


Don't take me wrong, I *do* think this is a great feature, but it should 
be the developers choice to turn it on.


--
unai

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150907173044.GC11490%40def.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Password validation in Django revisited

[Marc Tamlyn]

I agree with Aymeric and Markus that createsuperuser should not validate
strength of passwords when DEBUG is on. Having to use a secure password for
development/test accounts is an unnecessary level of interference for users.

I agree its safer to prevent using admin/admin in production and this is a
good thing, but there's no reason to prevent this for development. In fact,
I'd argue enforcing it for development will encourage teams to have a
"standard" secure password for their sites, which is also used in
production. By allowing admin/admin in development, and enforcing something
better in production we are more helpfully enforcing best practice.

On 7 September 2015 at 16:44, Florian Apolloner 
wrote:

>
>
> On Monday, September 7, 2015 at 5:37:03 PM UTC+2, Unai Zalakain wrote:
>>
>> I would even dare to say I'm totally against activated-by-default
>> password validators.
>
>
> Security comes first, so the should stay on by default.
>
>
>> I think it should be a decision the developers take
>> consciously, as it again adds just more overhead (which Django surely
>> doesn't need).
>>
>
> I doubt the overhead there is big, got any numbers to back up that claim?
> Also if it adds too much overhead for you, feel free to disable them.
>
> Cheers,
> Florian
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e653f37d-dc81-430b-87c4-47477bd971d9%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ECNTs-iGbtvzqsZGPigmDLKSAM-QB3MTd5yMj5PwnnOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Proposal for making Storage API timezone aware

[James Aylett]

Ticket: https://code.djangoproject.com/ticket/23832

This is something that's been bugging me for a while, but it's tricky
to get a good compatibility story. Here I'll lay out what's going on
now including obstacles to change, where I think we should be and a
possible route for getting there.


# Current situation

Storage backends are documented as returning naive datetime objects
from a number of calls [1]. (Currently no similar calls return aware
objects ever.)

One significant user of these calls is staticfiles, which compares
modified_time between (possibly) different storage backends when doing
collectstatic as a way of avoiding copying static asset files when not
needed.

Storage backends can be freely implemented, and a number of third
party extensions do so. Two popular ones are (there are likely more):

 * django-compressor (which actually overrides the datetime-returning
   methods; django-pipeline also has custom backends, but does not)
 
 * django-storages (including support for a large number of "remote"
   backends, and some others -- one of the most important being
   S3Boto); this is mildly complicated by at least one fork,
   django-storages-redux, although the original now seems stalled
   (which is why that fork exists)

Additionally, various other extensions (and user code) consume from
one or more of the time methods. (For instance, django-filebrowser
does; this itself has various forks.) In many cases, they won't actually
care whether they're being passed an aware or naive datetime.

This would only be a backwards compatibility problem, except that
S3Boto returns a naive datetime in UTC, but FileSystemStorage (and
others) return in the local timezone. This results in changed files not
being overwritten [2] if your time zone is "west" of UTC. (This is a bug
in django-storages, which came about from when the documentation
didn't mention timezones at all for these methods.)


[1] 
https://docs.djangoproject.com/en/1.8/ref/files/storage/#the-storage-class

[2] https://github.com/jschneier/django-storages/issues/49


# What should happen

I think the following should be the long-term goal:

1. If USE_TZ=False then datetimes returned from storage backends should be
   naive in local time
   
2. If USE_TZ=True then datetimes returned from storage backends should be
   aware in UTC

This would I believe match the behaviour of other TZ-aware systems in
Django. It should allow, for instance, for datetimes coming from
storage backends to round trip through the ORM without warnings.


# A route through this

To go straight to the end result is a significant enough breaking
change that it would annoy a lot of people. Here's one approach that I
think would be fairly painless for people relying on this to Just Work.

We want the following properties in our approach:

 * ensure that clients of storage engines get a suitable deprecation
   warning and timeline to enable them to move

 * provide a BC approach for clients of storage engines so they can write
   code that works from LTS to LTS

 * ensure that implementors of storage engines get a suitable deprecation
   warning and timeline to enable them to move (this will probably also
   involve users of those storage engines getting the warnings)

 * provide a BC approach for implementors of storage engines so they can
   write code that works from LTS to LTS

I've included steps where extensions have to change as well as changes
to Django; I think it's important in this case to make sure that
popular extensions are moved forward. This is obviously dependent
somewhat on the communities around those extensions, so there is some
risk there.

There are other ways of doing things to this, but I think this is a clean
approach. There's almost certainly something I've forgotten or simply got
wrong though.


## Step 1: introduce new methods

get_modified_time(name)
get_creation_time(name)
get_accessed_time(name)

Same signature as the old ones, but with "get_" at the front. Return
naive or aware datetime objects as dictated by USE_TZ and described
above.

Change core code (I believe this is still only staticfiles'
collectstatic) to use the new methods.

Put deprecation warnings on the three old methods in both Storage (the
base class) and FileSystemStorage in core.

Implement the new methods for FileSystemStorage.

Implement the new methods for Storage in terms of the old methods,
with deprecation warnings.


Outcomes:

 * client code using storage backends gets deprecation warnings until
   they move to the new methods

 * storage backends that don't implement the new methods will result
   in deprecation warnings when clients (including staticfiles'
   collectstatic) use new methods

 * all old code continues to work, with deprecation warnings emitted
   by Django (except where 3rd party storage backends have overridden
   the old methods)

 * lands a long-term API that supports timezones and USE_TZ correctly
   (although storage backend implementors 

Re: Password validation in Django revisited

[Florian Apolloner]

On Monday, September 7, 2015 at 5:37:03 PM UTC+2, Unai Zalakain wrote:
>
> I would even dare to say I'm totally against activated-by-default 
> password validators.


Security comes first, so the should stay on by default.
 

> I think it should be a decision the developers take 
> consciously, as it again adds just more overhead (which Django surely 
> doesn't need). 
>

I doubt the overhead there is big, got any numbers to back up that claim? 
Also if it adds too much overhead for you, feel free to disable them.

Cheers,
Florian

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e653f37d-dc81-430b-87c4-47477bd971d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: request for API review of streaming responses additions

['Tom Evans' via Django developers (Contributions to Django itself)]

On Mon, Sep 7, 2015 at 3:04 PM, Aymeric Augustin
 wrote:
> 2015-09-07 10:00 GMT+02:00 Yann Fouillat :
>> I agree, do you know what tools could I use to emulate 3G ?
>
> As far as I know, the canonical tools are:
>
> - on Linux, netem:
> http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
> - on OS X, Network Link Conditioner:
> https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html
>

As well as these tools, there is similar functionality built in to the
chrom(e|ium) browser.

Inspect the page, toggle "Device mode" (click the phone icon next to
"Elements" tab), and options to throttle the network (with various
presets) will appear on the page.

I don't know a way to throttle network in chrome without also toggling
device emulation however, so the page will look different (within a
viewport).

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1L70nEAhUSOovkjLBH0CyRxABx1yUCvcVwAz5k45DDJvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Unai Zalakain]

Hi Wim,

In my opinion, it is very safe and consistent to use password 
validation in

all instances and places. It definitely prevents people from using
admin/admin and markus/markus as a login, which sounds safe to me.

If you don't want that, you can change the validators depending on DEBUG in
your settings; or disable them in your local_settings. In addition, you can
change the password using the shell as you suggested.


I think using admin/admin or company/company at the development stage is 
quite a common and widely-used pattern. Making the developer use strong 
passwords or going through the hassle of deactivating password 
validators seems a bit too much waste of time for little or no gain to 
me.


I would even dare to say I'm totally against activated-by-default 
password validators. I think it should be a decision the developers take 
consciously, as it again adds just more overhead (which Django surely 
doesn't need).



--
unai

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150907153636.GB11490%40def.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: request for API review of streaming responses additions

[Aymeric Augustin]

Hello,

2015-09-07 10:00 GMT+02:00 Yann Fouillat :

> First I will say that most of this pull request is a port of
> https://github.com/django/django/pull/1037 which I ported more or less
> blindly.
>

As far as I can tell, this previous PR was never discussed on
django-developers. Someone threw the code on GitHub, that's all; you can't
make any assumptions about its suitability for inclusion in Django. Usually
we discuss how a feature should be implement, look for consensus, and then
submit the code ;-)


1) About the general API design
>>
>> This patch adds 7 new “stream” public APIs that duplicate the current
>> “render”
>> APIs. Adding a stream=False argument to the current APIs would be a more
>> lightweight alternative. Passing stream=True would enable the streaming
>> behavior. Was this alternative considered and if so, why was it rejected?
>>
>
> I'm not sure it was considered, but I don't think it would really be less
> intrusive. The documentation would be better, but the code would be less
> readable with a lot more conditions in the rendering logic (as opposed to
> keeping the same logic in stream and joining the streams in render).
>

The point of Django is to handle the painful stuff in the framework to make
our users' lives easier. If we need to write slightly more complicated code
to improve the API, that's just fine.

Also I doubt there will be many more conditions. The higher levels will
just pass the stream keyword argument to the lower levels and eventually to
the template engine. The only conditional should be be `response_class =
StreamingHttpResponse if stream else HttpResponse`.

I'm aware of the irony of me making this argument. I set a bad precedent
when I added StreamingHttpResponse. I didn't think of
HttpResponse(stream=True) at the time. The prospect of having 25
StreamingFooBar classes in Django makes me realize this wasn't a great
idea. Let's learn from this mistake. (The stakes are a bit low to consider
fixing it through a deprecation path, though.)


I think it would make the patch less intrusive and keep the documentation
>> more
>> readable. Specifically I'm concerned about making several parts of the
>> documentation twice longer for a relatively uncommon need.
>>
>> It's unclear to me why TemplateView gets a StreamingTemplateView sibling
>> while
>> other generic class base views that inherit TemplateResponseMixin don't.
>> All
>> GCBVs except View and RedirectView could get a Streaming version. Even if
>> the
>> initial patch doesn't do it, someone will do it eventually, which amounts
>> to
>> 13 additional classes.
>>
>
> As I said, it was done on the original PR so I did it too. Maybe putting
> it as an example in the doc would be enough, so users know how to use
> streaming templates in GCBVs.
>

I'm proposing to add a `stream = False` attribute to TemplateResponseMixin.


2) About third-party template engines
>>
>> How should third-party template engines that don't support streaming
>> rendering
>> behave? Neither the code nor the release notes provide any guidance on
>> this
>> issue. I suggest to add a stream() method that raises NotImplementedError
>> to
>> the base class for template backends.
>>
>>
> The Template class in the backends doesn't inherits from another class
> though, unless I'm missing something ?
>

I'm talking about template backends e.g.
https://github.com/django/django/blob/aaacaeb0/django/template/backends/django.py#L21
.



> The current patch implements a stream() method that doesn't actually
>> stream in
>> the DummyBackend and a boilerplate render() method that concatenates a
>> list of
>> one element. This is bad, all the more since the dummy backend is
>> intended to
>> be a template for third-party engines.
>>
>>
> Should the NotImplemented be in the DummyBackend stream method then ?
>

Yes, in order to keep
https://github.com/django/django/blob/adff499e/django/template/backends/dummy.py#L17
a simple example of how to implement a Django template backend.



> All template backends have the same copy-pasted render() method. Perhaps
>> it's
>> a symptom of a problem with the API. Perhaps it should just be pulled to
>> the
>> base class.
>>
>>
> So we should have a base class for backends' Template class ?
>

You're mixing template backends (instantiated once per template engine
configured in settings.TEMPLATES) and templates (instanciated once per call
to render() or equivalent).



> 3) About performance
>>
>> I think benchmarks are required:
>>
>> a. to ensure that this change doesn't degrade performance for the
>> traditional
>>   rendering mode
>>
>> Yann Malet's recent bug report shows that even modest performance
>> regressions
>> in template rendering can be a real problem for users.
>>
>>
> b. to assess the performance of streaming rendering which could be
>>   unexpectedly slow on a realistic network (try over 3G tethering)
>>
>> I agree, do you know what tools could I use to emulate 3G ?
>

As far as I 

Re: request for API review of streaming responses additions

[Yann Fouillat]

Hello and thanks for the review,

First I will say that most of this pull request is a port 
of https://github.com/django/django/pull/1037 which I ported more or less 
blindly.

On Sunday, 23 August 2015 19:18:20 UTC+2, Aymeric Augustin wrote:
>
>
> 1) About the general API design
>
> This patch adds 7 new “stream” public APIs that duplicate the current 
> “render”
> APIs. Adding a stream=False argument to the current APIs would be a more
> lightweight alternative. Passing stream=True would enable the streaming
> behavior. Was this alternative considered and if so, why was it rejected?
>
>
I'm not sure it was considered, but I don't think it would really be less 
intrusive. The documentation would be better, but the code would be less 
readable with a lot more conditions in the rendering logic (as opposed to 
keeping the same logic in stream and joining the streams in render).
 

> I think it would make the patch less intrusive and keep the documentation 
> more
> readable. Specifically I'm concerned about making several parts of the
> documentation twice longer for a relatively uncommon need.
>
> It's unclear to me why TemplateView gets a StreamingTemplateView sibling 
> while
> other generic class base views that inherit TemplateResponseMixin don't. 
> All
> GCBVs except View and RedirectView could get a Streaming version. Even if 
> the
> initial patch doesn't do it, someone will do it eventually, which amounts 
> to
> 13 additional classes.
>
>
As I said, it was done on the original PR so I did it too. Maybe putting it 
as an example in the doc would be enough, so users know how to use 
streaming templates in GCBVs.
 

> I'm -1 on the concept of duplicating every Django API that deals with HTTP
> responses. That design doesn't strike a good balance between simplicity for
> newcomers and power for advanced users.
>
> 2) About third-party template engines
>
> How should third-party template engines that don't support streaming 
> rendering
> behave? Neither the code nor the release notes provide any guidance on this
> issue. I suggest to add a stream() method that raises NotImplementedError 
> to
> the base class for template backends.
>
>
The Template class in the backends doesn't inherits from another class 
though, unless I'm missing something ?
 

> The current patch implements a stream() method that doesn't actually 
> stream in
> the DummyBackend and a boilerplate render() method that concatenates a 
> list of
> one element. This is bad, all the more since the dummy backend is intended 
> to
> be a template for third-party engines.
>
>
Should the NotImplemented be in the DummyBackend stream method then ?
 

> All template backends have the same copy-pasted render() method. Perhaps 
> it's
> a symptom of a problem with the API. Perhaps it should just be pulled to 
> the
> base class.
>
>
So we should have a base class for backends' Template class ?
 

> 3) About performance
>
> I think benchmarks are required:
>
> a. to ensure that this change doesn't degrade performance for the 
> traditional
>   rendering mode
>
> Yann Malet's recent bug report shows that even modest performance 
> regressions
> in template rendering can be a real problem for users.
>  
>
b. to assess the performance of streaming rendering which could be
>   unexpectedly slow on a realistic network (try over 3G tethering)
>
> I'm bringing this up because streaming rendering will often yield many 
> small
> chunks. If each of these ends up in its own TCP packet -- which is going to
> happen unless the application server provides additional buffering -- I 
> expect
> poor performance. If that's confirmed, it should be mentioned in the docs.
> Streaming rendering will still be useful for rendering gigantic amounts of
> data. But it isn't the performance optimization it may look like.
>
>
I agree, do you know what tools could I use to emulate 3G ?
 

> -- 
> Aymeric.
>
>
>
> On 19 août 2015, at 00:18, Tim Graham  
> wrote:
>
> I'd like to ask for a high-level API review of some proposed streaming API
> additions (I have already given the patch a couple of detailed reviews, 
> but 
> other eyes would be welcome on the details as well).
>
> Summary:
>
> * django.views.generic.base.StreamingTemplateView to stream a template
>   rather than render it.
>
> * A Template.stream() method, a django.template.loader.stream() function,
>   and django.shortcuts.stream_to_response() and
>   django.shortcuts.stream() shortcuts.
>
> * django.template.response.StreamingTemplateResponse and
>   django.template.response.SimpleStreamingTemplateResponse classes to
>   handle streaming of templates.
>
> Pull request:
> https://github.com/django/django/pull/4783
>
> Thanks!
>
> -- 
> 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 

Re: request for API review of streaming responses additions

[Yann Fouillat]

Hello and thanks for the review,

On Monday, 24 August 2015 15:25:11 UTC+2, Tom Christie wrote:
>
> Potential there to treat these as separately reviewable pull requests.
>
> For example - needing streaming template generation doesn't *necessarily* 
> imply needing streaming responses. The node-by-node rendering might mean 
> imply that less memory is used during the template rendering, even if the 
> complete response content all ends up in memory. (I haven't got a handle 
> from the pull request on if that'd be the case or not, and it's possible 
> that I've misrepresented it, and there's no benefit other than being able 
> to stream the output bytes)
>
> More generally: As presented there's lots of technical change, with very 
> little simple end-user presentable "why and when this is a benefit?".
>
> * Template.stream()
>
> What's the data to back this up?
> Does this result in lower memory usage during the template generation, or 
> is there no difference aside from allowing the output to be streamed? If 
> there is an internal benefit then how large do those templates need to be 
> before that's significant?
>
>
As said in the other review, benchmarking is necessary to determine that.
 

> * StreamingTemplateResponse
>
> Again, where's the data to back this up? We're introducing a decision 
> point for our users without giving them any basis on which to make that 
> decision. At what point would I likely want to use this, and what 
> real-world cases for our users are driving this? (For really large CSV 
> responses are templates a good idea in any case?)
>
> I also don't really understand from the documentation how the behavior for 
> SimpleStreamingTemplateResponse and StreamingTemplateResponse differs - 
> "does not handle any rendering attributes/methods (including callbacks)" - 
> I understand what the callbacks refer to there, but what does the rest of 
> that mean?
>
>
The methods defined by SimpleTemplateResponse 
(https://github.com/Gagaro/django/blob/ticket_13910/django/template/response.py#L112)
 
are not available to SimpleStreamingTemplateResponse. 
 

> * django.views.generic.base.StreamingTemplateView
>
> Unclear to me that the decision point this view introduces to users is 
> worth the benefit it provides.
> Writing a view that streams a simple template is just about as simple a 
> view as is possible to write in Django - would it be better if we simply 
> took an informed decision on which of TemplateView / StreamingTemplateView 
> is likely to be a better default on behalf of our users?
>
> Also lukewarm on introducing a new GCBV that actually just requires a 
> one-line addition to an existing GCBV. Should we prefer to instead document 
> the usage of `response_class` more fully, rather than extending the API 
> surface area?
>
>
As I said in the other answer, I did port this blindly from the old PR. It 
could be better off in the documentation instead.
 

> Apologies for jumping in with the criticisms - intended positively! 
> Understand the intent behind this, but a bit wary of changes that come 
> across as purely technical with very little in the way of concrete 
> demonstration of benefit. Think it'd be good to see it approached from a 
> perspective of "what are we actually recommending our users do here?"
>
>
Thanks for the criticisms, it helps going forward :).
 

> Cheers & thanks to everyone for their hard work!
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c55b8260-7b82-446b-ac97-7da89582154d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Wim Feijen]

Hi Markus and Aymeric,

In my opinion, it is very safe and consistent to use password validation in 
all instances and places. It definitely prevents people from using 
admin/admin and markus/markus as a login, which sounds safe to me. 

If you don't want that, you can change the validators depending on DEBUG in 
your settings; or disable them in your local_settings. In addition, you can 
change the password using the shell as you suggested.

I don't agree that we should allow unsafe passwords in some cases and I 
don't think we should. 

I apologize for differing in opinion,

Wim

On Saturday, 5 September 2015 19:27:07 UTC+2, Aymeric Augustin wrote:
>
> Well, I would prefer asking for confirmation ;-) but not enough to write 
> the code myself.
>
> -- 
> Aymeric.
>
>
>
> On 5 sept. 2015, at 10:54, Markus Holtermann  > wrote:
>
> Hey Aymeric,
>
> I think I'd prefer "downgrade the message to a warning and proceed" for 
> DEBUG=True and list all validation errors, much like for forms. Sticking to 
> the current implementation for DEBUG=False is fine with me. For example:
>
> $ python manage.py createsuperuser
> Username (leave blank to use 'markus'):
> Email address: 
> Password:
> Password (again):
> The passwords do not match.
> Password:
> Password (again):
> You used a password that doesn't fulfill all validation requirements:
>   - This password is too short. It must contain at least 8 characters.
>   - The password is too similar to the email address.
>
> Superuser successfully created
>
> Cheers,
>
> /Markus
>
> On Saturday, September 5, 2015 at 5:14:16 PM UTC+10, Aymeric Augustin 
> wrote:
>>
>> Hello,
>>
>> Indeed, this will be annoying for development.
>>
>> I don’t find the “admins don’t need rules, they know what they’re doing” 
>> argument compelling. The cobbler children’s go barefoot… Besides, if admins 
>> know the rules, having validation enabled won’t hurt :-)
>>
>> I’m in favor of implementing an escape hatch when DEBUG = True:
>>
>> - either downgrade the message to a warning and proceed
>> - or ask the user if they want to proceed with the invalid password 
>> (--no-input would skip this step and proceed silently)
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 5 sept. 2015, at 01:56, Markus Holtermann  
>> wrote:
>>
>> Hey,
>>
>> while I like the idea of having the validation in all places to not 
>> forget one that might be user facing, I was surprised by the fact that the 
>> validation also happens in dev environments when you create the superuser 
>> (this whole mail applies to the changepassword command, too):
>>
>> $ python manage.py createsuperuser
>> Username (leave blank to use 'markus'):
>> Email address: 
>> Password:
>> Password (again):
>> This password is too short. It must contain at least 8 characters.
>> Password:
>> Password (again):
>> The password is too similar to the email address.
>> Password:
>>
>>
>> This is a bit annoying for me, given that I normally use "markus" or 
>> "admin" as username and password for the superuser and u1:u1, as 
>> username:password combination for additional users.
>>
>> There are a few solutions to that behavior I'd like to see revisited for 
>> 1.9:
>>
>>1. Disable password validation when DEBUG=True -- I don't think we 
>>really want that
>>2. Don't have password validation for createsuperuser/changepassword: 
>>I personally don't see the benefit for that in the command anyways.
>>   1. In production environments I would expect the admins having 
>>   access to the management command to know their regulations (after all, 
>> they 
>>   need to configure them) and to know what good passwords are. 
>>   2. As somebody who is able to run the "createsuperuser" command I 
>>   figure I can also run "shell", giving me unlimited access to the 
>> password 
>>   field of users, allowing me to set a password that doesn't match the 
>>   requirements.
>>   3. It breaks backwards compatibility with tools like Expect (
>>   https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in 
>>   the past)
>>3. Disable validation when passing --no-validate or 
>>--no-validate-password to createsuperuser, though this is still backwards 
>>incompatible and a lot to type -- I'd better of with having a valid 
>>password -- or the other way around, passing --validate / 
>>--validate-password, but this feels pointless
>>
>> My preference is definitely (2), though I'm sorry for not bringing this 
>> up earlier when the issue was created.
>>
>> The original issue: https://code.djangoproject.com/ticket/25089
>> Respective PR: https://github.com/django/django/pull/5073
>>
>> Cheers,
>>
>> /Markus
>>
>> On Thursday, July 9, 2015 at 6:13:18 PM UTC+10, Alex Becker wrote:
>>>
>>> Hi Erik,
>>>
>>> I've written such a patch, which also fixes an html escape bug and adds 
>>> validation to the auth management commands.
>>> The