Re: MOSS Award to Django

Hi Andrew, Thanks for the detailed response. I'm glad to hear you have tried a few different ways to implement this, and having read through your reply, and the channels docs again, I have more questions :-) Your point about asynchronous code introducing needless complexity is very well

Re: [Question] MySQL Microseconds stripping

Thanks for the suggestion, I think that work around might just add too much code, so I'm probably going the way of converting every datetime column of every table to datetime(6) and afford the extra storage (and probably a little performance impact ?). I think the documented change might need a

Re: Questions pertaining the dubious value and the origin of "common" passwords

Hi, the way I try to answer these types of design decision questions is by using git blame to find the ticket that introduced the feature. From there, you can often find links to the pull request or mailing list discussions which might explain the decision. As noted in the documentation [1],

Questions pertaining the dubious value and the origin of "common" passwords

Today, I decided to check out Django's new password validation functionality (which is a great feature, btw). I noticed there was a CommonPasswordValidator, which mentions "1000 common passwords"... Part 1. The first thing that came to mind was, how would one compile a list of 1000 common

Re: [Question] MySQL Microseconds stripping

On Sunday 20 December 2015 11:47:54 Erik Cederstrand wrote: > > Why not strip the microseconds explicitly as soon as you're handed a > datetime with microseconds? That way you make it explicit that you really > don't want microseconds. That's less head-scratching for the next person > to work

Re: [Question] MySQL Microseconds stripping

> Den 20. dec. 2015 kl. 01.04 skrev Cristiano Coelho : > > About using a custom datetime field that strips microseconds, that won't work > for raw queries I believe, not even .update statements as they ignore > pre-save? As the stripping happens (or used to happen) at

Re: Decoupling the ORM

When I wrote small I was thinking along the lines of clearing up particular methods to ensure they're not breaking semi-formal contracts. Layering on a new abstraction to fields is quite a bit bigger, but is still small relative to the goal of "decoupling the ORM". If you can show a clear

Re: Decoupling the ORM

I was more referring to 'above' in a broad way, as the fields are constructed from the data returned by the ORM when building the model. which should also be above the ORM. Pulling open the Django code in PyCharm and taking a look at things, with an eye towards "lots of smaller incremental