Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

2017-02-12 Thread Brian May 
On Friday, 13 January 2017 19:22:13 UTC+11, Aymeric Augustin wrote:
>
> I agree that this setting has become less useful now that  
> has won.
>
> It made more sense when it wasn’t clear whether XHTML1.1 would take over 
> HTML4.
>
> I’d be interested to hear about use cases, if someone still uses it and 
> reads this.
>

Sorry for delay in responding.

If you depreciate `DEFAULT_CONTENT_TYPE` I am not sure what you plan to do 
instead? Would Django hard code "text/html" as the default?

I hadn't realised that the XHTML standards are basically dead (and doesn't 
appear to be supported in HTML5), in which case this probably makes sense.

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 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/c04be7c1-6ade-469c-b97c-0499598d2084%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pull request: write feeds with ordered attributes

2017-02-12 Thread Georg Sauthoff 
On Sat, Feb 11, 2017 at 08:15:08PM +, Adam Johnson wrote:
> I can see the advantage from an operational perspective with files matching
> byte-for-byte. I know many API's do the same with sorting the keys in their
> JSON output for the same reason.
 
> I should think the performance impact isn't too great, but would be nice to
> see some benchmarking to prove it's not disastrous.

I did a small benchmark, and as expected, the impact is really small.

Without the pull-request, generating an Atom feed with 100 medium sized
entries takes ~ 0.01 s on consumer hardware. The sorting and
creation of OrderedDicts increases the runtime by ~ 27 %.

Note that this benchmark generates the same feed several times in a row
because the absolute runtime is so small. See
https://gist.github.com/gsauthof/e2787adc7e9a46811dcb6aff2054110c for
details.

It pays off to only sort+create OrderedDict if there are attributes,
e.g.:

def startElement(self, name, attrs):
xs = collections.OrderedDict(sorted(attrs.items())) if attrs else attrs
super().startElement(name, xs)

That version yields an ~ 18 % runtime increase.

We can get down to ~ 7 % runtime increase if we - in feedgenerator.py - replace
the attribute dictionaries  with a simple wrapper around a list that provides
the items() method, e.g.:

class Atts:
def __init__(self, items):
self.xs = items
def items(self):
return self.xs

And then add the elements with attributes like this:

handler.addQuickElement("atom:link", None,
Atts([("rel", "self"), ("href", self.feed['feed_url'])]))

But IMHO, this would be a premature optimization that just
obfuscates the feedgenerator code.

Even the conditional sorting is hardly necessary outside of
microbenchmarking scenarios.

Best regards
Georg
-- 
'One must not put a loaded rifle on the stage if no one is
thinking of firing it.'   ( Anton Chekhov, 1889 )

-- 
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/20170212162710.GA12316%40dell12.lru.li.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

2017-02-12 Thread Martin Koistinen 
If anyone is still following this thread... =)

I've just updated the Google sheet above with significant changes. I was 
using the wrong values for PBKDF2-HMAC-SHA256 hash performance. I now have 
up-to-date hw costs and new evidence in play. Definitely worth having a 
look at the latest version. The up-side is PBKDF2 is significantly better 
than was previously calculated.

Enjoy!

On Monday, January 30, 2017 at 2:09:56 PM UTC-5, Martin Koistinen wrote:
>
> *IMPORTANT NOTICE:* I've just made an important change to the Google Docs 
> Sheet here: 
> https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
>
> Realizing that most security policies make requirements such as "At least 
> 1 character must be a numeral", etc. for other character classes, I've 
> adjusted this sheet to take this into account *along with the resulting 
> reduction of password strength that comes with it.* I do recognize that 
> these symbol-requirements policies are there to force people to choose 
> passwords that use a broader set of symbols which has the desired effect of 
> raising password strength, but the actual, theoretical maximum entropy of 
> the resulting passwords is *significantly *lowered as a result.
>
> As a result, a 8-character password formed with at least 1 of each of 
> these sets:
>
>- numerals (10);
>- lower-case letters (26);
>- upper-case letters (26);
>- and punctuation symbols (10-ish);
>
> will offer *at most* 40.7 bits of entropy.
>
> Passwords of this level of strength, when used on a system that uses 3 
> iterations of PBKDF2 will be quickly and easily cracked by virtually any 
> serious attacker. 100,000 iterations isn't really any better.
>

-- 
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/1731b228-94b4-4fa1-844f-e0dfcc5c43c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pull request: write feeds with ordered attributes

2017-02-12 Thread Adam Johnson 
Ok, looks like the second version (conditionally sorting) is the most
sensible to go with.

On 12 February 2017 at 16:27, Georg Sauthoff  wrote:

> On Sat, Feb 11, 2017 at 08:15:08PM +, Adam Johnson wrote:
> > I can see the advantage from an operational perspective with files
> matching
> > byte-for-byte. I know many API's do the same with sorting the keys in
> their
> > JSON output for the same reason.
>
> > I should think the performance impact isn't too great, but would be nice
> to
> > see some benchmarking to prove it's not disastrous.
>
> I did a small benchmark, and as expected, the impact is really small.
>
> Without the pull-request, generating an Atom feed with 100 medium sized
> entries takes ~ 0.01 s on consumer hardware. The sorting and
> creation of OrderedDicts increases the runtime by ~ 27 %.
>
> Note that this benchmark generates the same feed several times in a row
> because the absolute runtime is so small. See
> https://gist.github.com/gsauthof/e2787adc7e9a46811dcb6aff2054110c for
> details.
>
> It pays off to only sort+create OrderedDict if there are attributes,
> e.g.:
>
> def startElement(self, name, attrs):
> xs = collections.OrderedDict(sorted(attrs.items())) if attrs else
> attrs
> super().startElement(name, xs)
>
> That version yields an ~ 18 % runtime increase.
>
> We can get down to ~ 7 % runtime increase if we - in feedgenerator.py -
> replace
> the attribute dictionaries  with a simple wrapper around a list that
> provides
> the items() method, e.g.:
>
> class Atts:
> def __init__(self, items):
> self.xs = items
> def items(self):
> return self.xs
>
> And then add the elements with attributes like this:
>
> handler.addQuickElement("atom:link", None,
> Atts([("rel", "self"), ("href",
> self.feed['feed_url'])]))
>
> But IMHO, this would be a premature optimization that just
> obfuscates the feedgenerator code.
>
> Even the conditional sorting is hardly necessary outside of
> microbenchmarking scenarios.
>
> Best regards
> Georg
> --
> 'One must not put a loaded rifle on the stage if no one is
> thinking of firing it.'   ( Anton Chekhov, 1889 )
>
> --
> 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/20170212162710.GA12316%40dell12.lru.li.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM0cqYXskMatJiwv5Q%3D6Cs8SK7YJ9Yj3%2B_F%2BzYyabE-dyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

2017-02-12 Thread Adam Johnson 
>
> Would Django hard code "text/html" as the default?


Yes, that's exactly what would happen.

Thanks for the bump up, finally added a ticket:
https://code.djangoproject.com/ticket/27829

On 12 February 2017 at 07:28, Brian May 
wrote:

> On Friday, 13 January 2017 19:22:13 UTC+11, Aymeric Augustin wrote:
>>
>> I agree that this setting has become less useful now that 
>> has won.
>>
>> It made more sense when it wasn’t clear whether XHTML1.1 would take over
>> HTML4.
>>
>> I’d be interested to hear about use cases, if someone still uses it and
>> reads this.
>>
>
> Sorry for delay in responding.
>
> If you depreciate `DEFAULT_CONTENT_TYPE` I am not sure what you plan to do
> instead? Would Django hard code "text/html" as the default?
>
> I hadn't realised that the XHTML standards are basically dead (and doesn't
> appear to be supported in HTML5), in which case this probably makes sense.
>
> 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 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/c04be7c1-6ade-469c-b97c-
> 0499598d2084%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM2pLcJvZgiAYP1VkhQ2HhBj%2Bow1Om%2B2z2oXcLtCw%3DcJWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.